How to detect the availability of multiple HDD?

Question

I am studying operating system development. I recently read that the Hard Disk is denoted by 80h and so on. But in an MBR, the MBR must detect multiple HDD to choose booting from.

How is this done? How to detect the availability of multiple Hard Disk Drive and switch to and from it?

I'm using:

Ubuntu

Gas assembler

Note : I would like the answer in Assembly language during Real mode of a system.

Thanks.

Answer 1

The title and the body of your question ask two different things.

Regarding how a boot loader program, or in better terms an IPL (Initial Program Loader), detects which device to boot, you can check this specification to see that in section 6.5.1 it reads

This is so that once the boot handler has successfully loaded the device’s boot sector into memory at address 0000:7C00h, execution control can be transferred with the following register contents:

• ES:DI = Pointer to PnP Installation Check Structure
• DL = Drive number used for the INT 13h (00h, 80h, etc.)

So the IPL is given the driver number of the device is was loaded from.
The IPL can then use it with INT13h to load a second stage bootloader.

Simply put, if you are writing an MBR bootloader, you can find the driver number in dl, don't overwrite it before saving it.

;Simple snippet that load one sector from the booting device

mov ax, LOAD_SEG
mov es, ax
mov bx, LOAD_OFF           ;ES:BX = Where to load the data
mov ax, 0201h              ;AL = How many sectors
mov cx, 0001h              ;CX = Cylinder and sector
xor dh, dh                 ;DH = Head, DL = Driver number (As given by the BIOS)
int 13h
jc _handle_err

You are better off using the INT13h extensions rather than the INT13h itself, though for educational purpose the latter is simpler.

---

If you are writing a VBR bootloader then technically you are on your own, there is no standard interface between the VBR and the MBR code.
However, every MBR bootloader gives at least the driver number to the VBR bootloader (still in dl)
More metadata is usually passed, but such data is proprietary.

---

What to do once the MBR/VBR code is loaded is up to the programmer, for example GRUB has an hardcoded LBA (written during the installation).
This LBA is used to load the second stage, using the driver number from the BIOS. The second stage has a small file system driver that is used to read, by their paths, the config file the kernel.

The bottom of the line is that the bootloader has to know, somehow, where to find the rest of the code to load.

This is usually accomplished by writing some metadata in the binary image of the bootloader before writing it to the disk. Another strategy is relying on the MBR code to pass the partition number/start so that, if the second stage is put a fixed number of sector ahead of the first stage, the bootloader knows where it is located on the disk and hence where the second stage is.

Speaking of metadata leads us to the BIOS Parameter Block.
Despite the name, it is not created by the BIOS, but it is the result of the installation/format process of an OS.

It is not strictly necessary for custom loaders, it was used for two reasons:

1. It contains the geometry of the driver.
   For floppies this was important, as the software had to tell the FDC the geometry to use (i.e. how big a sector was).
   Now this is getting relevant again due to the presence of 4KiB sector HDDs.
2. It contains the information to find the file system.

Some BIOS assume the presence of a BPB and may attempt to patch same values, especially when booting from USB, so it is a good idea to include at least a DOS 3.31 BPB like NT bootloaders do.

---

In general, the first thing to do is decide the layout of a partition, this includes the FS type and the VBR format.
The general format is

+------------+------------------------------------+
| boot block |              FS block              |
+------------+------------------------------------+

Some space is reserved at the beginning of the partition for the bootloader code, the VBR contains a pointer to the FS block.
The bootloader can load the kernel directly if the FS is simple enough (this may be the case for toy OSes)or has special support, thus shrinking the boot block to the first sector only.

As an alternative, the bootloader loads a second stage that will have minimal, yet general, FS driver to locate the kernel by name.

Still speaking generally, the VBR code is not completely independent of the FS type of the volume.
For example, to install GRUB on an NTFS partition, you need to use a special version of it, GRUB4DOS that doesn't use the classic second stage.