CHS values in extended parttion tables

Programming, for all ages and all languages.
Post Reply
nullplan
Member
Member
Posts: 1767
Joined: Wed Aug 30, 2017 8:24 am

CHS values in extended parttion tables

Post by 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.")?
Carpe diem!
davmac314
Member
Member
Posts: 121
Joined: Mon Jul 05, 2021 6:57 pm

Re: CHS values in extended parttion tables

Post by 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
Member
Member
Posts: 1767
Joined: Wed Aug 30, 2017 8:24 am

Re: CHS values in extended parttion tables

Post by 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.
Carpe diem!
User avatar
BigBuda
Member
Member
Posts: 104
Joined: Fri Sep 03, 2021 5:20 pm

Re: CHS values in extended parttion tables

Post by BigBuda »

nullplan wrote: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.
Writing a bootloader in under 15 minutes: https://www.youtube.com/watch?v=0E0FKjvTA0M
nexos
Member
Member
Posts: 1078
Joined: Tue Feb 18, 2020 3:29 pm
Libera.chat IRC: nexos

Re: CHS values in extended parttion tables

Post by 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.
"How did you do this?"
"It's very simple — you read the protocol and write the code." - Bill Joy
Projects: NexNix | libnex | nnpkg
Octocontrabass
Member
Member
Posts: 5513
Joined: Mon Mar 25, 2013 7:01 pm

Re: CHS values in extended parttion tables

Post by Octocontrabass »

nullplan wrote: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.
nullplan wrote: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.
nullplan wrote: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. :wink:
Post Reply