The resolution to this problem is simple. In cases where the real boot drive was stored to the wrong memory location, the initial value stored at the drive_n label would be used. If the value of DS was not zero and the boot drive was something other than 0x00 then there was a good chance of failure. If the BIOS transfers control to your bootloader with a DS segment that isn't 0x0000 then mov, dl will write the drive number to a memory location you don't expect. The problem is that mov, dl is done before the segment registers are set up.
You can only be guaranteed that your bootloader will be loaded and run from physical address 0x00007c00 and that the boot drive number is loaded into the DL register.Īfter your question was updated with more pertinent code with what happens before the read the issue becomes evident: drive_n: db 0 They should be set up appropriately when your bootloader starts. When the BIOS jumps to your code you can't rely on CS,DS,ES,SS,SP registers having valid or expected values. I have a a Stackoverflow answer with a general set of bootloader tips. This causes the disk read routine to fail on some hardware. TL DR : In some situations the boot drive is not properly stored at label drive_n. I didn't intend for this question to be so long it just accumulated. hard drive information but it's hard to find any info on that.Īny help would be greatly appreciated. I bet it has something to do with the difference in how the computer handles floppy vs. What causes a failure in reading the disk if and only if USB hard disk drive emulation is enabled in the BIOS? I've tried changing up the partition table and the BPB but nothing seems to work.
00 000001 = high bits db 0x00)ĭb 79 7-0 bits of cylinder (insgesamt 9 bits)ĭd 0 32 bit value of number of sectors between MBR and partitionĭd 2880 32 bit value of total number of sectors end sector = 2880th sector (because a floppy disk is 1.44mb)ĭb 18 cyilinder = 79, sector = 18 (2 cylinder high bits, and sector.
00 000001 = high bits db 0x00)ĭb 0 7-0 bits of cylinder (insgesamt 9 bits) 0x1be Partition 1 - create one big partition that spans the whole disk (2880 sectors, 1.44mb)ĭb 0b00000001 cyilinder = 0, sector = 1 (2 cylinder high bits, and sector. continue onward happily! (without any errors)ĭb "12345678", 0x0, 0x0 10 byte unique id Je fail_read *** This jump happens only on real machines with check if attempts to read remain, if not, hlt system (jmp to fail_read) Mov bx, 0x7E00 location to load bootstrapper Mov cl, 0x02 (1= bootloader, 2=start of bootstrapper Mov si, start_str start_str = pointer to "Bootloader Found."Ĭall write_str routine that prints string in si register to screen Mov sp, 0x7C00 stack will grow downward to lower adresses BPB (BIOS parameter block) & Disk accessing routine bits 16 I just added the 64bit MBR partition table and reading data into memory fails instantly. I have no clue why this might happen, as I've not changed any of the actual bootloader code. With the added partition table code, the bootloader fails to load the secondary bootloader into memory and the BIOS INT 13h fails. So, following this osdev wikipage, I added a partition-table at the end of the MBR so that the newer machine could boot from the USB.
This new computer did not have a floppy emulation option in its BIOS configuration and therefore could not boot from the USB drive. It worked like a charm.Īfter testing the bootloader on my own machine, I tested it on another, newer machine. Subsequently, I added a BPB (BIOS parameter block) to my bootloader, made a bootable USB, and tested it on my real machine with USB Floppy Emulation (which I set-up in the configuration screen of the BIOS of my real machine). I've got it working in the emulators (Virtualbox, Qemu, and Bochs). I'm working on a basic bootloader that reads a secondary bootloader into memory with the BIOS INT 13h AH=02h interrupt.