8 bit IDE (XTA) Replacement Project

[JayesonLS]

How about this? You set up the firmware of the device so if it's uninitialized any boot attempt (IE, a read of sector zero) is answered with a synthetic MBR that contains a code payload that when loaded simply looks at the BIOS Fixed Disk Parameter Table to figure out the size of the disk (maybe print this on the screen for future reference) and then makes an INT13h call to read the last logical sector on the drive? (Actually, won't even need the FDPT for this, the INT13h AH=08h call has the info we need in it?) Your drive can then autoconfigure itself based on that bogus sector read attempt because you'll know it'll have the highest value for all three parameters. On the drive end the "configured" flag gets set, the MBR code reboots the PC, and bam, your drive matches whatever the BIOS is set to perfectly.

I have thought about something quite similar to this. It gets back into the issue of not getting the drive parameters until after the drive is initialized. In this case, the drive is likely already partitioned and has DOS installed. It is certainly possible to reindex the SD card at this point - I am just trying to avoid it. It is the kind of thing that is likely to have bugs and is time consuming to test thoroughly.

I was thinking that it would be an OK user experience if the MBR code prompted the user on whether they would like to reindex the drive. But I think there is a concern that someone might move the drive to another machine. At this point it could blindly reorder the sectors on the SD card into something unreadable on any PC. I think the safer approach if re-indexing were implemented would be to trigger it from a command line tool so that chkdks/scandisk could be run beforehand to be sure the SD card is reading correctly.

I think re-indexing may be unnecessary anyway. Your idea of sniffing the MBR writes should get the CHS translation correct the vast majority of the time.

Fitting that boot manager into an MBR sector is pretty impressive. You don't even get 384 bytes to play with after accounting for the partition tables. I may have a read sometime to see how it was done.

 

[JayesonLS]

I did a schematic and layout for the 3.5" XTA variant of the drive. It is designed to fit into an inexpensive, metal 3.5" to 2.5" drive adapter. I decided against putting and IBM edge connector on the other end to keep things simple and the board small.

The Pico has very high switching speeds so I went with a 4 layer board. My first one. Ground planes on the outside made layout and coupling very easy. Hopefully I don't need too many bodges because those are going to be difficult!


The image options seem to be this tiny medium version, or an enormous large version. Click the image for more detail I guess.

 

[Eudimorphodon]

I have thought about something quite similar to this. It gets back into the issue of not getting the drive parameters until after the drive is initialized. In this case, the drive is likely already partitioned and has DOS installed. It is certainly possible to reindex the SD card at this point - I am just trying to avoid it. It is the kind of thing that is likely to have bugs and is time consuming to test thoroughly.

The solution I was suggesting wasn’t for a “reindexing” scenario, it would only be invoked if the drive were blank, IE, you’ve inserted an empty card if you’re writing directly to it, or if you’re using images the user has indicated they want to start a new one. (Presumably you maintain some kind of metadata to definitively know if you’ve touched a disk before if you’re not using image files. Said metadata would also likely include the virtualized CHS parameters currently in effect.) The “fake” MBR that contained the code to get the BIOS parameters wouldn’t be on the disk, it’d be thrown out of the MCU’s flash under that one singular circumstance. And again, for this we don’t need to know the drive parameters to generate it; the BIOS doesn’t care about partitions, it’s just knows enough to throw a read request for sector CHS 0:0:0, load it into memory, and execute the code block.

Basically this accomplishes roughly what you get from booting a DOS and having FDISK write an MBR (which you subsequently analyze a partition table entry of for the geometry) except with this idea the disk will configure itself properly even if the user intended to do something really bizarre with it, like, I dunno, run a non-DOS OS that doesn’t use a DOS compatible partition table.

If you take a real XTA drive and move it to another machine that’s jumpered for a different geometry drive it’s expected behavior for it not to work, worrying about making drive images automagically reformat for that scenario seems like a heck of a feature creep.

 

[JayesonLS]

The solution I was suggesting wasn’t for a “reindexing” scenario, it would only be invoked if the drive were blank, IE, you’ve inserted an empty card if you’re writing directly to it, or if you’re using images the user has indicated they want to start a new one. (Presumably you maintain some kind of metadata to definitively know if you’ve touched a disk before if you’re not using image files. Said metadata would also likely include the virtualized CHS parameters currently in effect.) The “fake” MBR that contained the code to get the BIOS parameters wouldn’t be on the disk, it’d be thrown out of the MCU’s flash under that one singular circumstance. And again, for this we don’t need to know the drive parameters to generate it; the BIOS doesn’t care about partitions, it’s just knows enough to throw a read request for sector CHS 0:0:0, load it into memory, and execute the code block.

Basically this accomplishes roughly what you get from booting a DOS and having FDISK write an MBR (which you subsequently analyze a partition table entry of for the geometry) except with this idea the disk will configure itself properly even if the user intended to do something really bizarre with it, like, I dunno, run a non-DOS OS that doesn’t use a DOS compatible partition table.

If you take a real XTA drive and move it to another machine that’s jumpered for a different geometry drive it’s expected behavior for it not to work, worrying about making drive images automagically reformat for that scenario seems like a heck of a feature creep.

OK, that makes sense. This is a productive conversation. You have inspired me to change the "Boot Floppy Image" button into a "Boot Menu" button. The setup instructions from the drive would include entering the boot menu an

I am thinking the boot menu would be like a terminal connection to the drive so all the logic can be implemented in the drive firmware in modern C++. The code running on the PC would be limited to displaying text, capturing input and a few other actions like "install floppy drive redirect code and run bootstrap.". This opens up all sorts of options. Things like implementing SD card initialization on the drive would become easier to implement. Something like:

IntelliDrive Boot Menu - Firmware version 0.1

Primary SD card detected (128MB, not initialized)
Secondary SD card detected (8GB, FAT32)

WARNING: Drive parameters are not configured to match this PC.

Select from the following:
1. Configure drive parameters (Recommended)
2. Configure other IntelliDrive options
3. Configure or erase Primary SD card partitions
4. Configure or erase Secondary SD card partitions
5. Boot from floppy disk in A: drive
6. Boot DISK001.IMG floppy image from secondary SD card
7. Boot IntelliDrive's included FreeDOS floppy image
8. Display installation instructions
9. Reboot system

Enter 1 to 9: _

 

[Svenska]

In the old days before LBA, all partitions had to start and end on a cylinder boundary. Since the first sector of the first cylinder contains the partition table, the first cylinder itself does not belong to any partition and the remainder of it goes unused. This is the common hiding spot for boot managers (I like XFDisk, which can also boot from floppy, even B: in older versions) or disk managers such as OnTrack. If I remember correctly, the MBR is simply 448 bytes of code followed by 64 bytes of partition table; the code can be anything and is usually written by whatever OS is installed.

Personally, I prefer disks behaving like disks - no magic by the BIOS (some IBM BIOSes require a bootable FAT16 partition, breaking Linux installations for no reason) or the devices itself (looking at CF cards doing the same). Operating systems such as Minix or Xenix will likely fail on a DOS-focused magic disk. Especially partition table setup should not be left to the operating system or other system tools, not the disk itself.

The "magic boot button" is a good idea. In this mode, the Pico could prove just a single cylinder containing your configuration utility. The actual parameters (either read from the BIOS or set manually) could be set by writing to a magic sector on that cylinder, triggering re-initialization. This approach could avoid needing jumpers on the hardware, since the user can select the desired geometry and jumper setting when configuring (and the Pico could write the settings to a configuration file, either on the SD card or elsewhere, allowing setup on a different system). Since the actual geometry is known, a regular flat image file would be usable as well.

Since the boot menu is only shown after the BIOS has finished initializing the whole system (which is different from an Option ROM), the code has access to all BIOS facilities, although staying with the most basic int10h (video) / int16h (keyboard) / int13h (disk) functions may be good for compatibility. No magic would be visible if the button has not been not pressed.

Did I miss anything important?

 

[Eudimorphodon]

Glad this has been of some use, I guess.

I am thinking the boot menu would be like a terminal connection to the drive so all the logic can be implemented in the drive firmware in modern C++. The code running on the PC would be limited to displaying text, capturing input and a few other actions like "install floppy drive redirect code and run bootstrap.". This opens up all sorts of options. Things like implementing SD card initialization on the drive would become easier to implement.

That sounds like a fine idea. I suppose the only thing I would caution is, obviously, don't get carried away with building a giant list of deliverables/user stories in the queue before you've proved the basic idea.

As a proof of concept/development milestone the idea I suggested doesn't require the implementation of any special "API" or other back channel communication to the drive; on the drive; it only requires the firmware to know it hasn't been configured with a geometry translation yet (and if that's true it should offer up that fake MBR boot sector to a read command against sector 0/0/0). Meanwhile the PC side of the code probably needs only a dozen or two assembly instructions to implement. IE, in the simplest iteration all it needs to do after the code is loaded by the BIOS and jumped to is:

A: run an INT13h AH=08 call to get the highest sector address BIOS thinks the disk has, parse that value out

B: make an INT13h read or write (ah=03 or ah=04) with the maximum CHS value. (Which the drive accepts via the normal controller command syntax and uses to set the LBA translation value.)

C: Reboot the PC. Or slap a message on the screen saying "drive initialized, hit ctrl-alt-delete", if you think an instantaneous spontaneous reboot is too scary.

The coding on the PC side is trivial (I'm a pretty raw newb with x86 assembly and I think even I could do it in an afternoon), and in the C++ drive firmware it's going to be even easier.

(Obviously once you decide what your API is you could evolve this in baby steps, like initially instead of just doing an INT13h read you could have it send the info from the AH=08 call directly to the new communication channel and demonstrate receiving an acknowledgement back, etc.)

FWIW, since you seem pretty concerned about making sure that all possible avenues are covered here I will point out that there were a few *really* off-spec cases for the use of these drives; for instance, I think they were used in hard disk expansions for some Amstrad PCW machines, which don't run DOS, presumably don't have conventional MBRs, and don't even have x86 cpus able to run this smart menu. For this use case specifically allowing the drive to be manually configured to emulate some "real" drive based on public specifications would still be a must, either by providing, I dunno, a serial port header, or the ability to manipulate a config written to the storage medium inserted into it. As much as you might try you simply can't bubble wrap every possible thing for every user, sometimes they just have to be able to read a manual.

 

[JayesonLS]

Did I miss anything important?

Thanks, I think we are thinking the same things.

And standard BIOS calls only for sure, along with any drive interface register level access where needed to access extra features.

 

[JayesonLS]

That sounds like a fine idea. I suppose the only thing I would caution is, obviously, don't get carried away with building a giant list of deliverables/user stories in the queue before you've proved the basic idea.

Indeed. The first pass will be a basic drive. It will not have any MBR injection or support for the second SD card. Maybe it will sniff changes to the first partition table entry, and if everything look valid, save the inferred heads and sectors value. That seems easy to implement will at least get the heads/sectors right for folks who set up the drive with fdisk.

FWIW, since you seem pretty concerned about making sure that all possible avenues are covered here I will point out that there were a few *really* off-spec cases for the use of these drives; for instance, I think they were used in hard disk expansions for some Amstrad PCW machines, which don't run DOS, presumably don't have conventional MBRs, and don't even have x86 cpus able to run this smart menu. For this use case specifically allowing the drive to be manually configured to emulate some "real" drive based on public specifications would still be a must, either by providing, I dunno, a serial port header, or the ability to manipulate a config written to the storage medium inserted into it. As much as you might try you simply can't bubble wrap every possible thing for every user, sometimes they just have to be able to read a manual.

That is a good point. So far, the drive replacement should always work as well as a real drive does. If the SD card is readable in another computer, that is a bonus. However I should definitely keep non-DOS usage iin the back of my mind. My understanding is that early DOS versions don't have a MBR either - the first sector is the boot sector of the FAT filesystem. I assume partitions were motivated by drives getting larger than the max filesystem size.

On serial, the RPi Pico has a USB port on it. I intend it to be the initial mechanism for updating the firmware and have made sure the port is accessible on the board layout. Firmware updating is built into the silicon: hold the button on the Pico while inserting the usb cable. It shows up as a USB drive and you just drag on the firmware file. This bootloader is built into ROM so it is not even possible to brick the Pico. This may be the only method for firmware update unless somebody else wants to write an alternative. I am not very keen on doing it.

My current WIP firmware already configures the USB port as a serial device. It would probably not be very hard to expose a subset of the boot menu over USB serial. Something to be able to manually configure the drive heads, cylinders and perhaps the size bits register would go a long way.

 

[Svenska]

My understanding is that early DOS versions don't have a MBR either - the first sector is the boot sector of the FAT filesystem.

To my knowledge, any version of DOS with support for hard disks also supports MBR partition tables.

My current WIP firmware already configures the USB port as a serial device. It would probably not be very hard to expose a subset of the boot menu over USB serial. Something to be able to manually configure the drive heads, cylinders and perhaps the size bits register would go a long way.

Possibly, although a configuration file next to the disk image should be easier to use for most users. The common case is using a known geometry, which can be inferred from the image file size even if no configuration file is present. This is how FlashFloppy works, and I like both its simplicity and configurability.

 

[JayesonLS]

To my knowledge, any version of DOS with support for hard disks also supports MBR partition tables.

You are correct from what I can tell. The original PCDOS 2.0 for the 5160 does come with fdisk and creates an MBR. It only allows creation of one partition - apparently you were supposed to create more partitions for other operating systems. Although how exactly is not clear to me.

Complicating MBR sniffing slightly, PCDOS 2.0 fdisk creates the DOS partition in the fourth partition slot, leaving the first three slots blank. The DOS partition also starts on the second sector. DOS 3.3 or 6.22 (I can't remember which) on the other hand started the first partition on an even sector boundary (first track, second head, first sector).

 

[1ST1]

Will it be configureable? I mean, that I can set up a specific XTA harddisk type from specific manufacturer like 20 MB Conner, or can I tell the CHS data for the drive image on the SD-Card? Another sexy thing would be that I can swap between different diskimages with a button (or by software) ? I know during that there should not be a disk access and then the system needs a reboot. And one more neat function for at least FAT partitions would be if the device can extract the files inside the image to a separate folder on the SD card so that it is easy for file transfer. Maybe also the other way arround to get data into the disk image...

 

[Eudimorphodon]

You are correct from what I can tell. The original PCDOS 2.0 for the 5160 does come with fdisk and creates an MBR. It only allows creation of one partition - apparently you were supposed to create more partitions for other operating systems. Although how exactly is not clear to me.

Microsoft just kicked that ball over the fence, assuming that any alternative OS would come with an FDISK/installer smarter than theirs and just giving you the option to leave empty space for that other, smarter FDISK was where their responsibility ended.

Complicating MBR sniffing slightly, PCDOS 2.0 fdisk creates the DOS partition in the fourth partition slot, leaving the first three slots blank. The DOS partition also starts on the second sector. DOS 3.3 or 6.22 (I can't remember which) on the other hand started the first partition on an even sector boundary (first track, second head, first sector).

It's only the end positions you care about, so if you go with the MBR analysis strategy just assume you should check all slots. Since the "must end on cylinder boundaries" thing seems like a pretty safe assumption reading *any* populated partition entry should give you the highest head and sector numbers, which is strictly all you care about. (As noted, doesn't matter if the drive thinks it has 1024 cylinders but the BIOS thinks it's only 900 or whatever, doesn't affect the CHS to LBA translation.

I guess it is also worth noting that strictly speaking the physical order of partitions in the MBR doesn't need to correspond with their position on the disk. It is technically valid to have the partition in the lowest cylinders in the highest MBR slot and vice-versa. It's probably bad practice, sure, but it is *allowed*.)

This is, again, strictly speaking, the advantage of my suggestion of running some kind of program that directly just makes an INT13h call and instructs the drive to read the last sector, whether you do it the fancy fake MBR way or, for Rev 0, just run this binary off a floppy. It eliminates all possible ambiguity. (If you look up some of the ugly details about, say, partition type labels, there does exist the possibility that, say, if you expect a DOS partition entry to be a particular type there may be some OEM version of DOS that used something else.)

FWIW, I would say that DOS 2.x is going to be a pretty rare edge case. It was *long* obsolete before XTA hard drives came out. The oldest machines I can think of with XTA ports are, what, 1988-ish vintage? About the only computer still on the market still shipping with DOS 2.x that late was the little stub inside of a Tandy 1000HX's ROM, and that version of DOS didn't even come with FDISK on the utility disk.

 

[JayesonLS]

Will it be configureable? I mean, that I can set up a specific XTA harddisk type from specific manufacturer like 20 MB Conner, or can I tell the CHS data for the drive image on the SD-Card? Another sexy thing would be that I can swap between different diskimages with a button (or by software) ? I know during that there should not be a disk access and then the system needs a reboot. And one more neat function for at least FAT partitions would be if the device can extract the files inside the image to a separate folder on the SD card so that it is easy for file transfer. Maybe also the other way arround to get data into the disk image...

CHS Parameters

The drive, will for sure, always work with any CHS parameters the system BIOS is using. It can do this because I will make the minimum primary SD card size 128MB. [EDIT: I am not sure it is even possible to buy MicroSD cards under 128MB]. Any CHS parameter mismatch between the BIOS and drive just means sectors will not be written in contiguous order. Or in other words, there will be unused sectors sprinkled across the SD card. Sectors not being contiguous means the file system on the SD card would not be accessible if used in a modern PC.

Most of the recent thread discussion has been how to configure the drive with CHS parameters so the sectors end up on the SD card in contiguous order. Eudimorphodon came up with a couple of great approaches on how to do this automatically. Assuming sufficient time and motivation, I am open to implementing versions of those and also a fully explicit CHS configuration. In the end, I am not overly concerned about the primary SD card being usable in another PC. I think it is most useful for getting files back and forward, especially when setting things up the first time. The plans for the secondary SD card will offer a couple of alternate ways of doing that. I am most keen on the ability to mount a floppy disk image as the A: drive. Making 360K or 720K floppies tends to be quite involved and error prone. A lot of the target machines seem to have unreliable floppy drives also.

There are challenges with trying to match specific drive parameters. All drives I have looked at have jumpers and the Seagate ST351 A/X for example has more configurations than I think I will ever figure out. Even if the drive is configured to match a real drive, there is still no guarantee that the BIOS CHS values match. They don't in the case of an early Commodore CPx0 BIOS I read about yesterday. It interprets 40MB drives as 10MB. I also suspect my Tandy TL/2 was wasting a head (entire platter surface) on the WD drive it came with. The drive seems to longer be working so I can't confirm that now. The better approach seems to be tell the drive what the BIOS is using. Or just not bother and skip being able to read the primary SD card in another PC.

All that said, it does makes sense for a 2.5" version of the drive to default to the CHS parameters for the little Connor 20MB.

Where I use the term CHS above, I really only care about heads and cylinders. The drive will always handle cylinder values up to the max possible (1023 or 1024, I can't recall what the max is).

Hard Drive Images

I think if I support booting hard drive images, it will be a bonus, advanced feature and the images will live on the secondary SD card. I know it would be quite powerful and seems especially useful because you could create the drive image in an emulator. Things can get very fussy about CHS values matching and the failures are hard to diagnose - usually the system crashes trying to boot DOS. I think even the cylinder count being a little off can cause problems and the vintage PC BIOSes sometimes have slightly lower cylinder counts than the physical drives.

 

[Eudimorphodon]

Re: your suspicions that the Tandy TL/2 was “wasting a platter” on a drive, that’s highly unlikely.

One thing you’ll notice when you look at the specs for these XTA drives is the very same drive model will list multiple possibilities for the geometry. This is *not* because they made a bunch of secretly different versions of the hardware, it’s because many (most?) of these drives used translation schemes to camouflage their true hardware configuration. Some of these drives that claimed to have up to six heads in the BIOS had as little as two (a single platter) in real life. (ST351/AX) This Statson reference for some Western Digital XTA drives has a couple tables in it showing different virtual geometries for the same 40 MB drive:

https://stason.org/TULARC/pc/hard-drives-hdd/western-digital/WD-93028-X-20MB-3-5-HH-IDE-XT.html

If set to fake 17 sector tracks it had “five heads”, if set for 27 sectors it had four.

I know it sounds stupid today, but in the late 80’s there was all kinds of ridiculousness going on with hard disks. Some low level optimization/data recovery tools made catastrophically stupid assumptions, like that all hard disks had 17 sectors per track, and it was enough of a problem that some manufacturers thought they needed translation to hide that. And hard disks also started being made with more than 1024 tracks, which the standard INT13h/DOS CHS format didn’t support, so you needed translation for that. And really high capacity hard disks were starting to use zone density recording to fit more data on the longer outer tracks of the disk, which completely blows up CHS entirely, so you need translation for *that*…

Long story short, unless you’ve cracked open the actual physical drive and counted platters assume all BIOS geometries listed for a given XTA hard disk technically are lies. Pure unadulterated BS.

 

[Eudimorphodon]

… FWIW, though, some real hard drives had an odd number of data heads. Early voice coil positioner drives often used a “dedicated servo” surface on one platter, meaning one head was used solely to read information written when the drive was manufactured to provide positioning feedback, Most modern drives use “embedded servo” info instead, where data shares the same surface.

This is why you can destroy modern hard drives irreparably by running them through a bulk eraser. Erase the servo info and the drive is boned, you can’t write it back with the voice coil.

 

[JayesonLS]

Long story short, unless you’ve cracked open the actual physical drive and counted platters assume all BIOS geometries listed for a given XTA hard disk technically are lies. Pure unadulterated BS.

I didn't mean to refer to physical heads. I should not have confused things by referring to platters. All I know is that it had a 20-something meg partition on a 40 meg drive and fdisk seemed to think it was full. Maybe it just got imaged that way at the factory. I am hoping that one day it will come alive again. It had a few bad sectors which I was quite happy about so I could see how the drive behaved on read errors.

 

[vwestlife]

None of the 40 MB IDE-XT drives are "wasting a head". They're simply using the 980/5/17 parameters because those were the most common, based on Seagate's ST-251.

The 20 MB drives have one platter (two heads) and the 40 MB drives have two (four heads). But I dunno about the WD 30 MB drives -- they're listed as having 3 heads. So maybe they're actually 40 MB drives with one faulty platter surface? An easy way to make use of parts that otherwise would be discarded.

 

[Eudimorphodon]

None of the 40 MB IDE-XT drives are "wasting a head". They're simply using the 980/5/17 parameters because those were the most common, based on Seagate's ST-251.

... Yeah, I forgot about that reason for translation. Many early IDE drives used translation specifically to emulate drive geometries that were common in AT BIOS drive type tables. Having a user-specified type wasn't really common until 1990 or so.

I guess I will note that I have discovered it may be possible to confuse FDISK if you image a disk to the "wrong" size so maybe we can't entirely rule that out. I was experimenting at one point with using an emulator to get PC-DOS 7 installed directly off a CD-ROM distribution of it to use on my Tandy with XTIDE, and while that "worked" to generate a 2GB image and DD-it onto the flash device subsequently I discovered that I couldn't use FDISK on the Tandy to make any additional partitions. Normally you should be able to use the first 8GB of a drive (max supported by DOS CHS translation), but for some reason the 2GB total size from the DD'ed emulator image was "honored". That doesn't quite make sense to me given I *thought* the only place geometry is supposedly mentioned in the MBR is in the individual partition entries, but... shrug. I didn't dissect the MBR to see if DOS had created some dummy "free space" entry in another slot or anything.

 

[Svenska]

The original PCDOS 2.0 for the 5160 does come with fdisk and creates an MBR. It only allows creation of one partition - apparently you were supposed to create more partitions for other operating systems. Although how exactly is not clear to me.

Microsoft XENIX comes with its own FDISK utility, and so does OS/2. DOS simply ignores foreign partitions, and FDISK cannot not create such partitions because it does not know if other restrictions apply. (Although DOS FDISK shows XENIX partitions by name.)

While partitions should generally start and end on a cylinder boundary, it is not a strict requirement. But I think some versions of DOS (or other operating systems) require it for their partitions, at least. Some boot managers also require the remainder of the first cylinder to hide (e.g. GRUB), but others use their own partition (e.g. OS/2) or are made small enough (XFDisk).

The 20 MB drives have one platter (two heads) and the 40 MB drives have two (four heads). But I dunno about the WD 30 MB drives -- they're listed as having 3 heads. So maybe they're actually 40 MB drives with one faulty platter surface? An easy way to make use of parts that otherwise would be discarded

Either the last head contains diagnostic (or factory) data, or they use a more efficient encoding internally (RLL instead of MFM) and allocate the additional space as an additional head to avoid changing the geometry.

That doesn't quite make sense to me given I *thought* the only place geometry is supposedly mentioned in the MBR is in the individual partition entries, but... shrug. I didn't dissect the MBR to see if DOS had created some dummy "free space" entry in another slot or anything.

Unfortunately, some parts of the drive geometry are part of the FAT BPB, and some versions of DOS will corrupt other partitions if they don't match the drive. The 8 GB limit only applies to the maximum 1024/255/63 CHS values; if the BIOS assumes 17 sectors/track instead of 63, you end up with a 2.1 GB limit instead. The ECHS translation does not change the sector count (it keeps doubling heads/halving cylinders).

 

[vwestlife]

Either the last head contains diagnostic (or factory) data, or they use a more efficient encoding internally (RLL instead of MFM) and allocate the additional space as an additional head to avoid changing the geometry.

The Western Digital 20, 30, and 40 MB IDE-XT drives all have physical parameters of 782 cylinders and 27 sectors per track. The only difference is 2, 3, or 4 heads.