The PCChips (or Triple D Technology) Cotek AMI bios that came with Apolloboy and my M205 didn't have trouble using the native C/H/S inputs for a 2.5 GB WD Caviar (translated, but not LSB, I think) drive and all my 286s that are working (and the booting, but stuck at 512kB MB1212C I have) currently work with my remaining Quantum 170 AT drive.
https://stason.org/TULARC/pc/hard-drives-hdd/ … -SL-IDE-AT.html
I think it's an HP OEM variant of this, exact same CHS and capacity, but no exposed jumper pins. (and I couldn't get it working in a master/slave pair)
It's well within the 528 MB limit, but does use translation as many IDE (and I think some MFM) drives use for more convenient visible geometry. (translated C/H/S = 1011/15/22)
Manually putting those values into the user-defined CHS settings in the BIOS works fine. I'm pretty sure that WD drive we tried 9 years ago was a WD 32500 with 4960/16/63 C/H/S, and the FAT-16B partition used by DOS was suitably limited as well. (I didn't take a screen shot, but that same setting was still saved in the BIOS when I started using that board again last year, and it definitely had 2500 MB in the capacity parameter)
I'm not sure about the other boards, but I suspect that AMI BIOS for the Citygate D60 chipset (used by PCChips/Hedaka under various brands) supports at least up to the 4GB (4032 MB) limit natively and maybe beyond that. There's enough RAM/register space reserved to allow for up to 255 to be saved as the head number and sector number, and 65535 for the cylinder number, so it seems like full 8 and 16-bit integers are used (not truncated to fit into 20 or 24 bits). However, the capacity parameter (calculated by the BIOS automatically) is limited to 16 bits as well, and wraps around (overflows) for any C/H/S combination that over 2^16 (64 MB).
I remember some other (slightly later) BIOSs either refusing to allow illegal/overflow values to C/H/S slots or locking up (requiring reset) immediately after inputting an impossible value (but before any attempt to save to CMOS could be made), but these PCChips bioses seem to just wrap around values if you type an impossible value into the parameter string or defaults to 0 if you key in more digits than the string's limits actually allow. (like more than 5 digits for C, 3 for H, or 3 for S)
So the C/H/S values can at least hold the full 16+4+8 bit ATA specification as well as the 10+8+6 of the PC/XT int13h format. There's also the 22-bit address limit of the original WD IDE LBA specification. I think the last one just specifies a 22-bit value for the logical block to be used by the disk, so as long as the BIOS spits out the 22-bit block to the drive, various user-side values could be input to result in that output. (though for C/H/S, 12+4+6 bits would be convenient, but a literal 22-bit integer could potentially be specified as well: though IDE drives themselves usually provided C/H/S translated LBA values for the BIOS to use, and I'm not sure what the standard for that was, or if there was only a de-facto one)
22-bits could be split up as 10+4+8 or 12+4+6 for 22 bits, and I'd assume it's one of those two given 28-bit LBA used 16+4+8. And I think the 2GB cap limit setting on older hard drives uses ... or it's possible some BIOSes actually support a 24-bit LBA output from 12+4+8 or 14+4+6 or something like that. (the latter fits into the 8GB limit parameters Windows/DOS has, but that's a separate issue itself)
However, the BIOS code actually used to access/communicate with a hard drive controller might have additional constraints, as does the IDE specification itself, and sector values above 63 will be invalid at the very least, and probably further limits on either the Cylinder count or Head count as well. It might support the full 255 heads (as some translation mapping uses) or only the 16 of the original IDE specification.
It may have also been necessary to enable the 2GB capacity limiting jumper on that 2.5 GB drive if the BIOS natively only decoded 22 bits of address, but the nominal C/H/S values didn't need to be set any differently for that mode and the BIOS still reported the calculated capacity. (but limited the accessible partition to 2048 MB) That or the cap limit jumper didn't even need to be set as the partition for DOS was already at the 2 GB FAT-16B limit. (and I don't think I want to spend $20-30 on another one of those exact drives to try it out ... though I could at least try a larger drive with 16384/16/63 along with a 2GB partition and try with and without the cap limit jumper: I already tried an 8GB FAT-32 partition on a 1992 AMI 486 BIOS and it didn't work, but not 2GB in FAT-16 or 32)
Or it could be that the BIOS stores 16-bits of cylinder data, but ignores the upper 4 bits, so that 2.5 GB drive had 4960 cylinders turn into 864 or 865 (depending how the 12-bit integer is normally interpreted: ie 4096 or 4095) and 16/63 H/S for 425.25 or 425.75 MB actually visible. (and given the limited amount of space actually used in the DOS partition we tried out, that limit wouldn't have been obvious at the time)
I'm not totally sure how the LBA value is used by the disk controller, but it might be possible to input incorrect C/H/S values with BIOS limits and real LBA drive limits both in mind to get useable address space. (like on this 2.5 GB drive, ~2 GB could be useable if the bios supports 12+4+6 C/H/S addressing and the 4095 or 4096 was input as the C value)
The same wrap-around would result if the BIOS uses 10+4+8 bits and ignores the upper 6 bits of Cylinder data. (wraps to 0 every 1024 increments)
I'll have to do more experimenting to work out what's actually happening with these BIOSes.
The articles I've found (and wikipedia) either mention the 22-bit IDE specification without further details, or don't mention it at all.
Also, given so many drives stuck to the 16 head and 63 cylinder constraint while expanding head count beyond 1024 and standard large disks (over 8 GB) report 16383/16/63 geometry, it seems like there was some sort of 24-bit LBA constraint at some point with 14+4+6 bit limits. (that could've even been related to drive-controller side limitations, like wanting to limit address storage to 3 8-bit integers or a single 24-bit word, especially if a Microprocessor or DSP with native 24-bit registers and/or data words was used ... or something like that; I think several popular DSPs worked at 24-bit precision)
Some articles mention BIOSs with a 12-bit Cylinder field limit, but don't go further and connect this up with the 22-bit IDE LBA spec (it fits in nicely as 12+4+6 bits).
Or the 24-bit limitation comes from the IBM int13h disk format using a 24-bit field (10+8+6 bits for 1024/255/63 C/H/S) so the 14+4+6 bit C/H/S layout makes sense, though goes beyond the 22-bit LBA IDE spec. (but might also be the lowest common demoninator layout that got rolled into the 28-bit LBA standard's 16+4+8 bit standard and corresponds to the correct bit-shift-translation data for what DOS sees through the BIOS)
I'm still not sure what that means for old BIOSs and how they actually split out address data to the drives, but for what I'm seeing with these AMI BIOSes with 16+8+8 bit integers actually stored in CMOS (or other NV) memory, it must be storing more bits than needed and clipping/truncating unused ones and also padding out missing ones so the bit-shift-translation works out properly. (so the 16+8+8 bit fields get stored as such by the BIOS, but gets read/used/shifted as 14+4+6-bit values automatically for IDE/ATA disks and must also have provisions for older disks with other int13-compatible geometries ... maybe it defaults to 10-8-6 bits when the Cylinder value is 1024 or smaller, and switches to 14-4-6 if C > 1024, while others further restrict the latter case to 12-4-6 bits to conform to the 22-bit LBA)
As for articles/references See:
https://en.wikipedia.org/wiki/Logical_block_a … g#Enhanced_BIOS
https://en.wikipedia.org/wiki/Logical_block_a … #CHS_conversion
I have a 640 MB and 1GB drive that I can test later on, too, but haven't so far. (or tried only the 640MB one a while back, but it got formatted at the wrong capacity by DOS 5.0 and I need to reformat it ... it had had a working Linux Red Hat install on it when I got it, and that probably screwed with things even more)
I still haven't gotten that MB1212C AMI BIOS dumped, but I'll try to get that to you when I have it.