Hi analog_programmer,

Thanks for your 286 BIOS HDD Parameter table patching guide.
This is very useful information for us retro PC enthusiasts! 😀

To improve this guide, here are some remarks/additions.

AT (286) BIOS HDD table record entries pattern:
I’m afraid you confused bytes and nibbles here.
https://www.dataunitconverter.com/blog/bit-nibble-byte
You indicated the amount of nibbles for each record item, so the number of bytes is half of that.
Therefore, each of the 47 records in the table contains 16 bytes, not 32.

Note that the 286 BIOS is non-translating so it is limited to 504MB, and the maximum CHS values are 1024 Cylinders (400h), 16 Heads (10h), and 63 Sectors/track (3Fh).

Instructions on BIOS dump-file editing:
4. When calculating the 8-bit checksum, only adjust the last byte (at offset FFFFh for a 64KB BIOS) to arrive at zero with this last byte included in the addition.
The byte at offset FFFEh is the model_type and is FCh for a 286 or later PC.

Some final notes:
3) Table record number 15 is indeed never assigned. Because of the original expectation that there would never be more than 15 drive types in existence, only a single byte of CMOS memory was assigned for 2 drives. Of course, this limit was quickly exceeded, so another extended CMOS byte was assigned for each drive. The extended CMOS byte is used as the drive type when the original CMOS nibble type is 15. This is handled transparently by the setup program, however it explains why drive type 15 can’t be used.
(Book source: “The Undocumented PC, Second Edition” by Frank van Gilluwe.
https://archive.org/details/The_Undocumented_ … rankvan_Gilluwe
page 561.)

Cheers, Jan

Chkcpu wrote on 2025-06-18, 18:50:

Hi analog_programmer, […]
Show full quote

Hi analog_programmer,

Thanks for your 286 BIOS HDD Parameter table editing guide.
This is very useful information for us retro PC enthusiasts! 😀

To improve this guide, here are some remarks/additions.

AT (286) BIOS HDD table record entries pattern:
I’m afraid you confused bytes and nibbles here.
https://www.dataunitconverter.com/blog/bit-nibble-byte
You indicated the amount of nibbles for each record item, so the number of bytes is half of that.
Therefore, each of the 47 records in the table contains 16 bytes, not 32.

Note that the 286 BIOS is non-translating so it is limited to 504MB, and the maximum CHS values are 1024 Cylinders (400h), 16 Heads (10h), and 63 Sectors/track (3Fh).

Instructions on BIOS dump-file editing:
4. When calculating the 8-bit checksum, only adjust the last byte (at offset FFFFh for a 64KB BIOS) to arrive at zero with this last byte included in the addition.
The byte at offset FFFEh is the model_type and is FCh for a 286 or later PC.

Hi, Jan! Your remarks are correct. I'll make the corrections about the 16 bytes (not 32 bytes as I mistakenly wrote) for the pattern lenght in my first post, as I often mess in hurry these hexadecimal visual number representations. You know that all the table entries are 16 bytes long, not just the 47-th entry. Also the last checksum byte instead the two bytes - I've done the same stupid byte representation mistake.

As for the "max" values, I don't claim that 1 TB of HDD is usable on AT machine by this BIOS editing (you know what I mean 😉 ). Those values are just "examples" acceptable by the not-so-useful and buggy "BIOSUTIL" software and that's why I made an explicit final note 2) on this. The one, who will gonna make a modified 286 BIOS for non-existing HDD table entry, has to be aware of what's the real HDD's maximum acceptable volume by the edited 286 BIOS and his real CHS values for his HDD. I'll add the suggested real maximum values for CHS maximum values in note 2).

Thanks for these corrections!

Chkcpu wrote on 2025-06-18, 18:50:

Some final notes: 3) Table record number 15 is indeed never assigned. Because of the original expectation that there would never […]
Show full quote

Some final notes:
3) Table record number 15 is indeed never assigned. Because of the original expectation that there would never be more than 15 drive types in existence, only a single byte of CMOS memory was assigned for 2 drives. Of course, this limit was quickly exceeded, so another extended CMOS byte was assigned for each drive. The extended CMOS byte is used as the drive type when the original CMOS nibble type is 15. This is handled transparently by the setup program, however it explains why drive type 15 can’t be used.
(Book source: “The Undocumented PC, Second Edition” by Frank van Gilluwe.
https://archive.org/details/The_Undocumented_ … rankvan_Gilluwe
page 561.)

Cheers, Jan

So, I guessed correctly about the idiots with the standardized limiting stillborn ideas a-la "640 kB ought to be enough..." 😁 But it's good to learn some new details about this empty unusable table entry number 15 and how the things were "patched" after the limiting ideas took their place as standard.

Thanks for your opinion, corrections, notes and remarks! You're the only one "ancient BIOS" modification expert here.

A caveat is that there will be a large overlap between BIOSes without type 47, and an IRQ acknowledgement bug preventing reliable use of IDE/CF drives, described here Re: JCS286/SCAT (82C235) Motherboard among other places on the forum.

jakethompson1 wrote on 2025-06-18, 20:17:

A caveat is that there will be a large overlap between BIOSes without type 47, and an IRQ acknowledgement bug preventing reliable use of IDE/CF drives, described here Re: JCS286/SCAT (82C235) Motherboard among other places on the forum.

With all my respect to your work and research on some old BIOSes: Sorry, but I can't help with BIOS executable code bugs as I don't read op-codes like my native spoken language. And this is not a BIOS bug-patching manual.

I'll remove all the "patch"-ing words, so not to mislead the ones, who expect some modern HDD/CF-card + ancient 286 BIOS "miracles" here.

P.S. On some of the 16-bit ISA I/O controllers there is an option for selecting the PIO modes by some jumpers. I don't know if such a hardware setting for lower HDD transfer speed (with higher cycle time) can solve this "fast" HDD BIOS bug, but someone can try it. Again - this is a topic for another thread.

Few of my own notes that somebody might find useful:
- Drive types (1-47) might map to different geometries on different BIOSes/mobos. Especially starting with 24 and onwards.
- AMI BIOS might be using a 16-bit checksum stored at 0xFF50.
- Very early BIOSes might require the sector count to be 17, and some parts might be hardcoded for that.

As for the weird "over 8 heads" byte, I have some theory about that. There are some MFM controllers (from WD) that handle 8+ heads differently. There's a jumper for that on some cards. Basically it has to do with what head code is stored in the sector header, sometimes only 3 bits are used and thus heads 8-15 are stored as 0-7. This is not a problem as long as the controller that formatted the HDD is used to R/W it, but will fail if the HDD is moved to a card with a different/newer chip that stores all 4 bits. Perhaps the weird byte was some sort of attempt to create an extra flag, which would allow particular HDD types to have a software workaround for controllers that could switch the mode via a register rather than a jumper?

And a reminder that quite a few of these old BIOSes are buggy and will report to DOS one cylinder less than what is set, or perhaps this was done on purpose to always alloacte last cylinder to landing zone? Having LZ>CYL fixes it on some BIOSes but not all. The result of this "bug" is FDISK is never using the very last cylinder of the HDD, and for older, small drives (80MB and less) this is actually quite a loss of usable space.

I thought FDISK itself was responsible for reserving the last cylinder

Hi, Deunan, and thanks for the given details! I'll make some comments on them, based on my experience and research.

Deunan wrote on 2025-06-19, 12:04:

Few of my own notes that somebody might find useful:
- Drive types (1-47) might map to different geometries on different BIOSes/mobos. Especially starting with 24 and onwards.

This is possible. If you can't rely on CHS data from the HDD's label, one solution to get the needed specs for the BIOS HDD table entry is to attach the hard drive to motherboard with "user define" option for auto-detecting HDDs. This was the way I got WPC number and "Parking" Track (Sector) number for my HDD and the CHS from its label matches the data from the BIOS with HDD auto-detection option.

Deunan wrote on 2025-06-19, 12:04:

- AMI BIOS might be using a 16-bit checksum stored at 0xFF50.

I can't confirm this 'til I revisit those AMI BIOSes that I have for m 286 motherboard - 7 different AMI BIOSes from 7 different 286 boards with the very same chipset for the time period 1988-1990 (including). Generally these AMI BIOSes don't need any BIOS HDD table editing as they have an option to enter drive parameters for user's HDD.

For the MR BIOS that I have I checked it's for sure - the checksum byte is the last one (at address 0xFFFF).

Deunan wrote on 2025-06-19, 12:04:

- Very early BIOSes might require the sector count to be 17, and some parts might be hardcoded for that.

For all the early hard disk drive models in the BIOS tables I've inspected the hardcoded value for the Sectors count is 17 (0x11). And this is valid for newer ( 386, 486, etc) BIOSes as well.

Deunan wrote on 2025-06-19, 12:04:

As for the weird "over 8 heads" byte, I have some theory about that. There are some MFM controllers (from WD) that handle 8+ heads differently. There's a jumper for that on some cards. Basically it has to do with what head code is stored in the sector header, sometimes only 3 bits are used and thus heads 8-15 are stored as 0-7. This is not a problem as long as the controller that formatted the HDD is used to R/W it, but will fail if the HDD is moved to a card with a different/newer chip that stores all 4 bits. Perhaps the weird byte was some sort of attempt to create an extra flag, which would allow particular HDD types to have a software workaround for controllers that could switch the mode via a register rather than a jumper?

This byte is really weird one and the BIOSUTIL tool totally ignores it when creating a new table record entry for HDD with more than 8 heads - it always writes value of 0 (0x00) no matter if heads count is bigger or smaller/equal to 8. Good to know that it's related to those very early MFM drives. I included the condition when it has to be manually written as 8 (0x08), 'cause I see the same patterns in 386 BIOSes and just to be safe (BIOSUTIL is buggy and I can't trust its byte ignore here).

For note 4) in my first post I will add the link to your post later.

Deunan wrote on 2025-06-19, 12:04:

And a reminder that quite a few of these old BIOSes are buggy and will report to DOS one cylinder less than what is set, or perhaps this was done on purpose to always alloacte last cylinder to landing zone? Having LZ>CYL fixes it on some BIOSes but not all. The result of this "bug" is FDISK is never using the very last cylinder of the HDD, and for older, small drives (80MB and less) this is actually quite a loss of usable space.

OK, good to know this possible bug. But for the best BIOS HDD table editing results we have to rely on the actual hard drive CHS specs and not on what the BIOSes "report" to DOS.

EDIT: On a second thought: What if FDISK treats the "Landing Zone", "Parking" Track (Sector) or the surface of the HDD's plates were the heads "rest" when HDD is powered off as an entire unusable Cylinder instead of a single unusable Track (Sector)? This could be implemented for data safety reasons and may explain the "bug" in some particular cases.

analog_programmer wrote on 2025-06-19, 15:11:

Deunan wrote on 2025-06-19, 12:04:

- AMI BIOS might be using a 16-bit checksum stored at 0xFF50.

I can't confirm this 'til I revisit those AMI BIOSes that I have for m 286 motherboard - 7 different AMI BIOSes from 7 different 286 boards with the very same chipset for the time period 1988-1990 (including)...

Ok, we're both wrong about these checsum bytes in the AMI 286 BIOSes.

You're messing it with AMI 386/486 "color" BIOSes:

jakethompson1 wrote on 2021-08-28, 02:34:

Finally it also appears that the two-byte checksum is most likely stored at ff50h.

And I messed it with MR 286 BIOS that I've tinkered with. And this "universal" scr*wed-up "BIOSUTIL" tool treats all the BIOSes checksum's bytes the same way (as for Award), which is very inappropriate if used on AMI 286 BIOS (but still works with MR). I have to write some more detailed notes when testing multiple things at once.

For now I can't find any clue where are these "magic" checksum bytes or byte in these AMI 286 BIOSes. There is a hack in another forum's thread to bypass the checksum test on AMI 286 BIOS POSTing:

feipoa wrote on 2025-03-07, 13:18:

I disabled the checksum.
Offset: 819A
changed 74 to EB

In general no one should mess for a good reason with the AMI 286 BIOSes HDD table records, as these have a built-in BIOS option for HDD parameters user input. So I don't see any reason to dig into this more.

That AMI BIOS is also used on newer (20MHz+) 286 mobos, but yeah, it does allow user-definable HDDs so there is no need to hack it. Disabling the checksum test is another option, I did that too for some experiments with 486DLC patches, but for burning the final EPROM it's better to fix the checksum. This way the image can be quickly validated for any weak bits or degradation in few years time - even if the original image used to create it is lost.

Deunan wrote on 2025-06-20, 13:37:

That AMI BIOS is also used on newer (20MHz+) 286 mobos, but yeah, it does allow user-definable HDDs so there is no need to hack it. Disabling the checksum test is another option, I did that too for some experiments with 486DLC patches, but for burning the final EPROM it's better to fix the checksum. This way the image can be quickly validated for any weak bits or degradation in few years time - even if the original image used to create it is lost.

Ok, if you are sure, that there are 64 kB AMI "color" BIOSes (the ones for 386/486 motherboards) for some of the latest 286 mobos, then check this out 😉

Can you give me some example for a 286 mobo with 64 kB AMI "color" BIOS to test my checksum script with its BIOS?

Here's the BIOS in question. Mobo is PCChips M218, looks like this (mine is SIMM based): https://theretroweb.com/motherboards/s/pcchips-m218
I don't remember exactly how that BIOS looks like but it sure is AMI and has 16-bit checksum.

Deunan wrote on 2025-06-20, 23:26:

Here's the BIOS in question. Mobo is PCChips M218, looks like this (mine is SIMM based): https://theretroweb.com/motherboards/s/pcchips-m218
I don't remember exactly how that BIOS looks like but it sure is AMI and has 16-bit checksum.

Thanks. This really looks like AMI "color" BIOS with BIOS date from 05.05.1991. My script "says" that the two checksum correction bytes at address 0xFF50 are "FB 98" (LE ordered) and the calculated file checksum (16-bit "word" sequential 16-bit sum) is equal to 0 (it validates correctly).

So, at the end you're actually right - there are some later 286 boards with AMI "color" BIOSes and my script can be used to auto-correct their checksum bytes after manual editing/patching them.

I quickly checked if the HDD table record uses constant address in couple of different 386 AMI "color" BIOSes and yes - it uses the same starting "point" 0xE401.

I found some Phoenix BIOSes for my 286 mobo - one 32 kB and three 64 kB dump files. Their HDD table records addresses match the ones of the other BIOS brands .

Anyone familiar with the old Phoenix BIOS checksum protection mechanisms?