OSDev.org

Octocontrabass wrote:If you follow linuxyne's advice, you'll discover that the corruption occurs where the disk geometry would go if you had a BPB.

You can quickly test this by moving all of your code to the end of the block, and putting a relative jump to the start of your code at the beginning of the block.

I can't see anything wrong with the machine code. I'd try restoring the original partition table as that might make the BIOS think it's dealing with an MBR rather than a VBR - that way it should run the code without interfering with it.

If it continues to behave oddly, Spyder's suggestion is a good one - jump past the bytes that the BIOS might interfere with and then you can write some code to investigate what the BIOS has done, printing the bytes to the screen. To simplify code while debugging at this stage, it can be easier to write directly to screen memory without using the BIOS - just use ES:DI (set ES to B000h [* correction: use B800h]) and send AX to the screen using stosw, colour value in AH (e.g. 0Eh for yellow) and char in AL.

Another thing that might be worth considering is how this BIOS responds to other bootable media. For example, will a DOS floppy boot on it? A Linux floppy with GRUB, LILO, SYSLINUX, etc.? How about a linux USB stick? Remember that some BIOSes don't treat USB sticks well, and there are many different modes that they might emulate them in, so maybe try a real floppy if you can, or even a hard drive if you've got a spare.

DavidCooper wrote:To simplify code while debugging at this stage, it can be easier to write directly to screen memory without using the BIOS - just use ES:DI (set ES to B000h) and send AX to the screen using stosw, colour value in AH (e.g. 0Eh for yellow) and char in AL.

Correction: use B800h for ES.

Thank you all very much for the answers. After I had put an active partition entry there, as Octocontrabass had suggested, everything started working as expected. Meanwhile; I also started using an assembler instead of writing binary by hand.