state at 0x7c00 (x86)

[rdos]

No, the correct value is not always passed in DL. I have a PC/104 card with a CompactFlash where the BIOS seems to invoke the bootsector with DL=80h, but the CompactFlash is located at 81h, so the boot-process fails. It worked on another system where DL was passed as 82h, and this was the correct boot-drive.

[turdus]

The boot sector (normally) contains nothing to identify which drive ID it came from; even if it's a floppy with a "BIOS Parameter Block" and even if there's a partition table.

That's not absolutely true, bootable flag (usually 80h) in partition table represents the drive. So if you put 81h there, it means that you have to boot the partition from the 2nd drive. Although it works, it's not often used, and we agree that you should not rely on it.

Note: it's not true for the original IBM PC MBR, it's a hack that Microsoft put in in MSDOS and later in MSWIN MBR's code. Check it here:
http://thestarman.pcministry.com/asm/mb ... R.htm#CODE

Code: Select all

062D 8B14          MOV     DX,[SI]       ; This causes the Drive # (Yes,
                                         ; the Active BootFlag bytes in
; Partition Tables are Drive Numbers) to be placed into -> DL  and its
; Head # -> DH. For the Standard MBR, DL will always be 80h (see offset
; 0622 there with an 80h 'hardcoded' into the instruction) making only
; the first drive bootable!

[egos]

No, the correct value is not always passed in DL.

In this case you should patch boot loader and/or boot data structures.

[rdos]

The boot sector (normally) contains nothing to identify which drive ID it came from; even if it's a floppy with a "BIOS Parameter Block" and even if there's a partition table.

That's not absolutely true, bootable flag (usually 80h) in partition table represents the drive. So if you put 81h there, it means that you have to boot the partition from the 2nd drive. Although it works, it's not often used, and we agree that you should not rely on it.

Note: it's not true for the original IBM PC MBR, it's a hack that Microsoft put in in MSDOS and later in MSWIN MBR's code. Check it here:
http://thestarman.pcministry.com/asm/mb ... R.htm#CODE

Code: Select all

062D 8B14          MOV     DX,[SI]       ; This causes the Drive # (Yes,
                                         ; the Active BootFlag bytes in
; Partition Tables are Drive Numbers) to be placed into -> DL  and its
; Head # -> DH. For the Standard MBR, DL will always be 80h (see offset
; 0622 there with an 80h 'hardcoded' into the instruction) making only
; the first drive bootable!

Yes, I was afraid of something like that. Because MSDOS/Windows MBR does not depend on the value loaded into DL upon entry, some BIOSes are broken.

This leaves two alternatives:

1. Use the drive field in the BPB and hardcode it there with the disc-creation utility (or by writing the correct value when initializing a disc)

2. Use the BIOS value, but if the disc does not exist, either use the BPB value, or scan for existing discs.

[egos]

Windows Vista/Seven boot loaders (MBR boot loader and "primary loader") use DL.

[rdos]

No, the correct value is not always passed in DL.

In this case you should patch boot loader and/or boot data structures.

Yes, but I don't want several versions of the boot-images for different platforms. I want a single image to be bootable both if the boot drive is 81h and 82h, which I currently have. It is a pain to have a CompactFlash disk tied to a specific boot-drive #.

[egos]

I think we can regard that BIOSes as bugged and use DL anyway.

[rdos]

I think we can regard that BIOSes as bugged and use DL anyway.

I can't just write off this particular BIOS as buggy, as I will have to make some 300 boot-discs for it.

[rdos]

Turns out that BIOS uses DL=80h for the slave disc on the primary controller. It was the second-stage bootloader, which didn't use BIOS for disc-access, that failed because it believed it should boot from the master disc on the primary controller. I think I decided not to use BIOS for reading the OS-image because of LBA problems, and not all BIOSes supporting LBA-addressing properly.

Anyway, I solved the issue by trying all four discs on the primary and secondary controller if the drive passed from BIOS did not map to a physical disc correctly. I don't know if the drive-mappings are stored somewhere, but at least I couldn't find them in the BDA.

[54616E6E6572]

I would say it's never safe to assume anything, but you can always verify what standards a BIOS is compliant with to determine what values are in what registers.

On any BIOS that is Plug and Play compliant, ES:DI will contain a Pointer to the Plug and Play Installation Check Structure, and DL will contain the Physical device number the OS is being loaded from. CS:IP is only guaranteed to point to 0x7C00 (which means it could be 0x07C0:0x0000 or 0x0000:0x7C00).

Now if a BIOS is compliant with the BIOS boot specification any BAID (BIOS Aware IPL Device) device will have it's boot sector loaded into 0x0000:0x7C00. A BAID is any device that can boot an OS, but requires the BIOS to have specific code to support it. Some examples are: the first floppy drive, the first hard drive, ATAPI CD-ROM, PCMCIA, embedded network adapter, etc.

[edit]On a side note, the BIOS Boot Specification recommends that you use the drive number passed in the DL register instead of having the drive number hard-coded, and that you use INT 0x18 on boot failure so that control is returned to the BIOS. Now to still remain compliant with most MBR code, excluding Microsofts, and the UEFI Specification you should keep the BootIndicator of the Partition Table Entries at 0x80.[/edit]

This information was taken from the following specifications, which you can read to determine how to verify if a BIOS is compliant with the specifications (it's really simple, just verify a structure and call a function):
* Plug and Play BIOS Specification, Version 1.0A - May 5, 1994
* BIOS Boot Specification, Version 1.01 - January 11, 1996