More or less by accident I found myself writing a very basic DOS utility to read data off of an IDE drive. It started out by just issuing the IDENTIFY DRIVE command and capturing the data, but adding the ability to read sectors was not difficult.
In case that sounds pointless, it kind of is, except it allows me to attach a secondary IDE channel to an old 486 board whose BIOS only supports primary IDE. Thus the secondary channel is open to experiments without any BIOS interference. And this kind of setup lets me work with drives that for one reason or another do not work with a semi-modern system, including broken drives that may not be able to read/write at all but still have functioning electronics.
Once I got as far as identifying and reading old IDE drives, I realized that it’s not too difficult to extend the code to work with pre-IDE drives. The catch is not relying on IDENTIFY DRIVE but instead manually supplying the drive geometry. Once that was done, the rest of the code worked unchanged with my ancient Seagate ST-225 drive (by the way, that drive is now 35 years old and still can be read with no bad sectors).
Well… the code almost worked.
When the entire drive was read, the heads obviously ended up being positioned at the last cylinder. Upon starting the utility again, the drive started seeking back to the beginning but my code timed out before the drive was done moving the heads.
Okay, so I extended the timeout. That did the job, the second invocation of my utility now worked. But then I started wondering: The initial timeout was about three seconds. The ST-225 drive is specified to have maximum (full) seek time of 150 milliseconds. Three seconds really should have been far more than enough!
Yet I could clearly hear that the drive did take a bit more than three seconds to complete the full seek. Why could that be?
I’m fairly familiar with ATA standards and IDE drive documentation, but this turned out to be one of those things that IDE doesn’t really talk about at all. IDE drives, being integrated, don’t need to be told how fast they should seek—they already know.
But with old ST506 interface drives and PC/AT style controllers (in my case, a true blue IBM/WD adapter P/N 68X3948) it’s a little more complicated. Most ST506 drives, including the ST-225, can buffer step pulses that the controller issues very rapidly and then seek to the desired track as fast as the drive can.
Really old drives don’t work like that though. They behave very much like floppy drives and the controller directly moves the stepper motor. And just like with floppy drives, the step rate is variable. On the IBM/WD controller, it ranges from 0.5ms to 7.5ms in increments of 0.5ms. There are thus 15 step rates to choose from, and there’s a special 16th rate of 35 microseconds per step that is used with drives that can buffer step pulses.
Reading IBM’s Fixed Disk and Diskette Drive Adapter Technical Reference, the answer was staring me in the face: “After a Diagnose or Reset Command, the stepping rate is set to 7.5 milliseconds.”
The ST-225 drive has 615 cylinders; at 7.5ms per step, moving the head from one end of the drive to another takes over 4.5 seconds. No wonder the 3-second timeout wasn’t quite enough!
The same Technical Reference also explained how to fix the problem. The RECALIBRATE (called Restore in IBM documentation) and SEEK commands take the step rate as input in the low nibble of the command (1xh for RECALIBRATE, 7xh for SEEK). The step rate is then used for subsequent implied seeks, and my code only used implied seeks, not explicit SEEK commands.
Once I added a RECALIBRATE command to my code (with command code 10h, setting the maximum step rate), the full seek became quite a bit faster—presumably closer to 150 milliseconds than 4.5 seconds—and the drive sounded noticeably different, too. I could lower the timeout back to 3 seconds and things were no longer timing out.
Again, this detail is not mentioned anywhere in the ATA specifications, not even in the first ATA standard draft from 1990. But given the provenance of some early IDE drives, I’m now wondering if there might be some IDE drives where RECALIBRATE not only moves the heads to track zero but also sets the step rate, and if RECALIBRATE is omitted, seeks will be extremely slow. Something to investigate later.
I imagine you’ve checked this already – but I myself wonder if this is the underlying problem with your RECALIBRATE-demanding WD93044-A from a few weeks back: like this drive, its implied seeks are so slow by default, that the commands sent by the BIOS (and/or storage driver, depending on the age of the OS) are timing out.
I did check that, and found that the WD93044-A behaves like a proper IDE drive (I guess?) and ignores the step rate given to RECALIBRATE/SEEK. At least I couldn’t make it do the slow seek that’s easy to trigger with WD1003 controllers and MFM drives.
>In case that sounds pointless
I wrote such software to test upper memory regions for accessibility from non-CPU agents by executing READ DMA from PCI ATA BM controllers for example…