Through the course of time I’ve been going over the IDENTIFY data of various old IDE hard disks. Today I happened to come across a Conner CP30254H drive, apparently made in June 1993 or so.
This is a circa 250 MB drive, but looking at the contents of IDENTIFY words 57-58 (current CHS capacity in sectors), I see the value 2,195,324,935 which just does not look right, as it’d be about a terabyte; completely impossible for a drive without 48-bit LBA support. The drive reports 895/10/55 CHS geometry, so the capacity really should be 492,250 sectors. That’s rather far off from the reported value.
Now, 492,250 decimal is 782DA hex, whereas 2,195,324,935 decimal is 82DA0007 hex. Obviously not a coincidence. So what does the ATA standard say? The ATA-2 standard (1996) is quite clear (section 7.1.15): Some parameters are defined as 32 bit values (e.g., words 57 and 58). Such fields are transferred using two word transfers. The device shall first transfer the least significant bits, bits 15 through 0 of the value, on bits DD15 through DD0 respectively. After the least significant bits have been transferred, the most significant bits, bits 31 through 16 of the value, shall be transferred on DD15 through DD0 respectively.
The Conner drive is clearly doing it wrong. Except… a drive made in 1993 obviously can’t conform to a 1996 standard. So what does the original ATA standard which was finalized (but not yet officially ratified and published) in 1993 have to say about this?
It says nothing. At all. With word-sized values, there was never any question—the data is transferred as words in the first place, and no one was creative enough to do anything but return bit 0 on data pin 0, bit 1 on pin 1, and so on up to bit 15. But the original ATA standard gives no hint as to how double-word values should be transferred.
It is likely that the data was always meant to be transferred low word first, and the ATA-2 standard explicitly says that, but there is no such clarity in the original ATA standard.
And it wasn’t just Conner transferring the high word first. At minimum, Maxtor (seen with 25128 AT drive) and IBM (seen with H3256-A3 and H3342-A4 drives) did it the same way. On the other hand, Quantum (ELS 85A, LPS 170A drives) or Seagate (ST3243A, ST9096A drives) always returned the low word first.
I’m actually having some difficulty understanding why the current capacity in sectors in words 57-58 was even specified at all. It is defined to be the product of words 54, 55, and 56, i.e. current cylinders/heads/sectors per track. The host might as well calculate the product directly, instead of asking the drive. Moreover, if the product calculated by the host does not match what the drive returns, what is the host expected to do?
As it is, one practical use of the current sector count in words 57-58 is that the host can determine whether the drive returned the information with the low word first or high word first. But that alone is not particularly useful.
It is noteworthy that the first ATA standard also already specifies the LBA capacity in sectors, another 32-bit value presented in IDENTIFY words 60-61. The LBA capacity is not necessarily the same as the CHS capacity, and cannot be cross-checked with other data. But so far at least, all drives I have found that return “incorrect” (high word first) data in words 57-58 do not return the LBA capacity at all.
It is possible or even likely that the vendors who supported LBA access early (e.g. a 1994 Quantum ProDrive LPS 170AT) always reported the LBA capacity in words 60-61 with the low word first. I have not seen any hints in the ATA-2 standard that hosts should expect 32-bit LBA capacity values to be returned with the high word first.
I’m not aware of the low word vs. high word first discrepancy causing trouble in practice. I suspect that since words 54-58 (current CHS settings) are optional, most host software did not use them at all, and simply calculated the capacity from the CHS geometry. For LBA-capable drives, the value in words 60-61 would have been critical, but there were probably very few, if any, drives that both supported LBA and returned 32-bit values with the high word first.
In any case, this is a good illustration that standards should strive to be precise and complete. The first ATA standard was not, and clearly some companies understood it such that the high word should be returned first, while others returned the low word first. ATA-2 rectified the situation and unambiguously specified how 32-bit values should be returned in IDENTIFY data.
Defining the standard for multi-word transfers seems to have become necessary as the IDE specification moved to non-IBM PC architectures. It might be just a coincidence but Low End Mac lists IBM and Maxtor as reliable with Apple’s IDE controller while Seagate isn’t. I haven’t found any documentation stating how the Amiga 600HD or Quadra 630 IDE controllers requested data. Both controllers were renowned for having issues with many IDE drives.
“With word-sized values, there was never any question—the data is transferred as words in the first place, and no one was creative enough to do anything but return bit 0 on data pin 0, bit 1 on pin 1, and so on up to bit 15.”
With little endian and big endian, there is actually two ways to do this. We can all agree that a chunk of consecutive bytes start with the lowest address and each byte is stored at one address higher than the previous. With a little endian system like the x86 and a 16 bit wide data bus, the first byte at address N ends up at D0-D7 and the second byte at address N+1 ends up at D8-D15. However with a big endian system like for example the 68000 the first byte at address N ends up at D8-D15 while the second byte at address N+1 ends up at D0-D7.
For all the meta data and status information read from an IDE/ATA drive and all the configurations and command data written to those drives, it’s easy to just treat it as whatever it ends up with depending on how you connect the drive.
However in order to not have to byte swap each word written to / read from the disk while keeping the disk format compatible with other systems, a big endian system has to swap D0-D7 with D8-D15 as compared with a little endian system. This is the reason for all the Commodore made IDE controllers on the Amiga swaps D0-D7 with D8-D15 in hardware, which is also done more or less by all third party controllers made after Commodore made their first (A600HD). (Side track: The AdIDE controllers connect the data lines in what seems like a random order, they were made before the first Commodore controller and the signals are connected in the way that makes it as easy as possible to route the PCB that adds an IDE interface sitting between the 68000 CPU and it’s socket, primary intended for internal installation in an A500 but works in any Amiga with a 68000 CPU (i.e. also A2000, A1000 and probably the CDTV).
Richard: There were iirc three main problems with various mostly older disks used with the Amigas. One of them was that since most Amigas don’t have any battery backed up memory (many has a battery backed clock though), the computer has to try to detect a disk at each boot and to not make it horribly slow on systems without any disks the timeout is fairly short. IIRC the A1200 and A4000 had a longer timeout than the A600 (and I assume that you get the longer timeout if you upgrade the ROM to a newer version on an A600). The somewhat kludge fix was to simply cut the reset line between the computer and the drive. For once the drive would not have to wait the short moment the computer held the reset line, but more importantly it was fairly easy for the user to just push the three finger salute (on an Amiga it is ctrl + amiga + amiga) and the computer would reattempt detecting the drive. With the reset line in place the three finger salute would do a hardware reset on the drive and it would be too slow to respond again.
A problem that I think wasn’t very common was drives that reported the wrong configuration. Fortunately it was only during the initial step of partitioning of the drive that this mattered. In the Commodore provided setup program called HdToolBox you would push a button that reads the configuration from the drive, but then you could alter all read data to fit whatever the actual parameters were.
Something that would cause data corruption, lockups and whatnot was that many early IDE disks could only handle a read or write request of up to about 64k words. However that was also configurable using the “max transfer” setting, and the recommendation was to set it at hex 1FFFE which would read 128k-2 bytes.
A problem that can’t occur on a plain A600, but that can occur on an Amiga with some form of CPU accelerator, is that DMA on the main system bus can’t acccess local ram on the accelerator card. As all IDE controllers used PIO rather than DMA this was no problem with IDE disks, but it could be a problem with SCSI disks. There were a somewhat weird setting in HdToolBox called “mask” which would set a bit mask of allowable addresses to do DMA to/from. You would set it to the highest address that DMA would work on. With an Amiga where the disk controller used the 16-bit data bus and more importantly 24-bit address of the original 68000 but the CPU being upgraded to a 68020 or higher with a 32-bit address bus you would sett mask to hex FFFFFF. There were cases where you could configure an accelerator card to map it’s 32-bit wide ram to the address space usually used by 16-bit RAM, starting at hex 200000, and if that was the case (and the accelerator didn’t allow DMA into it’s local RAM) you would have to set the mask to 1FFFFF. With DMA I refer to what the PC world likes to call bus mastering, not the DMA/PIO distinction for the bus cycles on an IDE disk. In general most but not all SCSI controllers on an Amiga used DMA while afaik all IDE controllers used PIO, with the exception of the A590 (and maybe the A2091 if the IDE connector even were populated on that card) which used an XT-IDE drive. As a side track, thanks to the XT-IDE drive bus being really slow and there being no buffer between the drive and the computer (with buffer I refer to intermediate storage, not electrical buffers which there of course were), DMA would only steal a cycle now and then instead of stealing a bunch of consecutive cycles as when using a SCSI disk. Therefore at least in my experience the risk of losing characters on the serial port (which unfortunately didn’t have a FIFO) were less when down/uploading files to/from the IDE drive than to/from a SCSI drive. (Re lack of FIFO, unfortunately that part of the custom chip set were never updated, and the origins of the Amiga is so old that in the early pre release versions of the hardware reference manual it clearly indicates that the reason for the disk controller being able to both use MFM and GCR is to be able to read/write Apple II disks. Not a word about the MFM mode being able to read/write PC compatible disks 🙂 ) On the other hand, a program that would lock out all interrupts during a serial transfer could transfer data at iirc 921600 with short enough cables. In theory 1843200 should work but the speed of the 1488/1489 level converters in combination with the EMI filters gives a too slow slew rate even with a 10cm short cable between two computers. It would had been nice if that chip in the custom chip set would had been updated – a DMA channel for the serial port would had been nice, and updated audio hardware to handle 16 bit sound and a higher sample frequency than twice the horizontal frequency would also had been nice. As a tangent of this tangent, when using the VGA-ish modes added in later versions of the chipset, it was possible to play audio with a sample frequency of up to about 60kHz rather than about 30kHz for a regular 15kHz TV standard video mode. As there were hardware volume controls on the four audio channels it was also possible to set two channels to the highest volume and two other channels to a rather low setting, and by joining those four channels in pairs it was possible to play back stereo audio with an effective bit depth of 14 bits. Not really CD quality but it did actually sound way better than most PC sound cards of the 90’s, with excellent signal-to-noise ratio .
I ran into an issue like this in the industrial control world once. It involved protocol converter devices that convert various industrial protocols to Modbus TCP; like the ATA IDENTIFY data, they gave a view into a memory region breaking it up into 16-bit words. These worked by having a block of memory into which the “other” protocol writes arbitrary data (which may involve 32-bit integers or floats or doubles), and the Modbus TCP side reads it (and the other way around for transfers in the other direction).
What ends up happening is if this converter device has a big endian processor, 32-bit values get reversed as with the Conner drive described here, whereas if the device has a little endian processor, it’s the other way around. So perhaps the differences in drives could relate to what byte order their onboard controller processor uses?
I know early Conner drives used 16-bit Motorola MCUs (big endian), but I’m not sure when the model/serial was first reported. It might have been Conner, but it could have been WD ESDI controllers. On balance I suspect that the older WD1005 controller did not put any ASCII strings in the IDENTIFY data (the later WD1007A and WD1007V did) and Conner drives were the first.