CHS values in extended parttion tables

[nullplan]

Hi all,

I am currently writing a new MBR, just to have one. An MBR is a very simple program, as it is supposed to simply look up the first bootable partition, load its VBR to 7C00h and jump there. Now, my past MBRs have never had Extended Partition support, and I would like to change that now. However, it appears that my Google-fu is weak, and I just cannot figure out if the CHS values in the extended partition tables are absolute or relative. The LBA values are relative, but that is easy to address; I just keep track of the offset and keep adding the new offset to my current offset. But for CHS? I have no idea how to interpret the values. At the moment, I'm using the CHS values as cookies; essentially nonsense values I just pass through to the BIOS. I have no idea what they mean. I have no idea how to go about adding several of them together.

My plan is essentially to test if INT 13h Extensions are supported on the booting drive, and if so to use LBA, else to use CHS. I cannot convert between the two because for that I would need the drive geometry, which I don't have. At least I bloody hope I don't; the normal way would be for the BIOS to dirty up my boot sector with its parameter block. But I thought that is only for floppies. And MBR is a hard disk thing.

Or should I just abandon CHS and add "INT 13h Extensions not supported" as a third failure mode (the first two being "No active partition" and "Load error.")?

[davmac314]

Converting CHS to LBA and back is reasonably straightforward, see https://en.wikipedia.org/wiki/Logical_block_addressing -

LBA = (C × HPC + H) × SPT + (S − 1)

(The "S - 1" because sector numbers start at 1, rather than 0, unlike everything else).
And

C = LBA ÷ (HPC × SPT)
H = (LBA ÷ SPT) mod HPC
S = (LBA mod SPT) + 1

So, I would convert the CHS addresses in your extended partition to LBA and see what checks out (relative or absolute). If you need to add CHS together, add sectors and overflow into head, add heads and overflow into cylinder (or, convert both to LBA, add, then convert back).

[nullplan]

Unfortunately, I can't do that, since I don't know the disk's geometry, and don't know how to ask BIOS for it. And the more I research the topic the less sense it makes. DS:SI is supposed to point to the partition table entry when the VBR is jumped to, but that entry is useless if it is an extended entry, because the starting LBA is relative to the starting LBA of the partition table, which the VBR is never told. I rectify the issue by adding the LBA offset to the starting LBA in the partition table entry, so the number becomes relative to the start of disk.

The more I think about it, the more appealing the option of failing when LBA is not available becomes. We live in an age when you can plug an XTIDE adapter into even an original IBM 5150 and give it those extensions (at least for the drives it manages), so there is really no need to support CHS at all. Add to that the fact that there was a pretty low limit on disk size with that interface (way lower than the 2TB for 32-bit LBA) and CHS becomes even less useful. The only people that would get any utility out of an MBR that runs on a pure CHS machine are people running old hardware, and they have more than enough offerings already to do precisely that.

Plus, even though the MBR is written to run on an 8086, my OS is going to be pure 64-bit. And there is precious little need to use it when so many alternatives are available.

Now for my next crazy trick: An Ext2-ELF64 boot loader for 16-bit BIOS. And I have 1024 bytes for everything. Let's see how far I get.

[BigBuda]

Unfortunately, I can't do that, since I don't know the disk's geometry, and don't know how to ask BIOS for it. And the more I research the topic the less sense it makes. DS:SI is supposed to point to the partition table entry when the VBR is jumped to, but that entry is useless if it is an extended entry, because the starting LBA is relative to the starting LBA of the partition table, which the VBR is never told. I rectify the issue by adding the LBA offset to the starting LBA in the partition table entry, so the number becomes relative to the start of disk.

Besides the contents in the OSDev wiki, there's another source I always check, which is HelpPC: https://stanislavs.org/helppc/int_13-8.html

This information is on the OSDev wiki, on HelpPC and on Wikipedia (https://en.wikipedia.org/wiki/INT_13H#I ... Parameters). It's not hard to find at all.

[nexos]

I would just forget about CHS support. Basically all machines in use today that are not in a museum should have BIOS LBA support.

[Octocontrabass]

At the moment, I'm using the CHS values as cookies; essentially nonsense values I just pass through to the BIOS.

There's no guarantee those values will make sense to the BIOS. If you must support CHS, ask the BIOS what geometry it's using and translate LBA to CHS.

DS:SI is supposed to point to the partition table entry when the VBR is jumped to, but that entry is useless if it is an extended entry, because the starting LBA is relative to the starting LBA of the partition table, which the VBR is never told.

Common OSes don't care about DS:SI and will boot perfectly fine without it, even the ones that refuse to install onto an extended partition.

The only people that would get any utility out of an MBR that runs on a pure CHS machine are people running old hardware, and they have more than enough offerings already to do precisely that.

...Or would rather write our own.