The ultimate reason why I pulled out the old Seagate ST-225 drive was because I wanted to try connecting it to the Western Digital WD1003-IWH board that I recently acquired.
The WD1003-IWH is a curious evolutionary half-step between ST506 interface MFM drives and IDE drives, a kind of a missing link. The Compaq Portable II (released in February 1986) appears to have been the first PC with an IDE interface but not the first PC with an IDE drive. The WD1003-IWH board facilitated the connection of a standard ST506 MFM drive, either a Miniscribe 8212 (10 MB) or Miniscribe 8425 (20 MB), to the usual 40-pin IDE connector on the Portable II’s multipurpose controller board. Here’s what that looked like.
I don’t have any Miniscribe MFM drives, but I figured the WD1003-IWH is more or less a WD1003-WAH in a different form factor and with a funny connector (40-pin IDE rather than ISA bus).
Not knowing if my WD1003-IWH was even functional, all I could try was to hook it up to the ST-225 and see what happens. But what happened was a bit weird.
I could clearly see that the WD1003-IWH responded like a standard AT disk controller, with the expected register contents after reset and EXECUTE DRIVE DIAGNOSTIC (90h) command, and accepting an INITIALIZE DRIVE PARAMETER (91h) command. But anything else just resulted in an error with the ABRT bit set.
In fact the DRDY and DSC bits in the status register that should normally be set weren’t. When it wasn’t showing errors, the status register value was zero… as if no drive was even there.
The DRDY status bit should simply reflect the drive ready signal, which becomes active once the drive reaches nominal RPM. There’s no complex logic behind it, and I knew the drive was working.
I checked the short cables the WD1003-IWH board came with, as well as the connector pins. I found no problem.
Then I checked, double-checked, and triple-checked the board, but only found that for something made in 1986, it’s in remarkably good visual condition. And yet the WD1003-IWH behaved as if there was no drive connected at all. When there clearly was.
I considered the possibility that it might only work with the Miniscribe drives that Compaq used, but that seemed far-fetched. Again, at least the DRDY status bit is so basic that it should work with any drive.
The next day, I looked at the ST-225 drive again, noting the row of jumper pins:
What are those for? A couple of rarely used configuration options and a drive ID. Seagate’s own documentation is very terse, but it resulted in a facepalm: “If twisted cable, use Drive Select 2”. Of course! My IBM/WD disk controller uses a twisted control cable, so that each drive can be jumpered as drive 2, the same kind of arrangement that PC floppy drives use.
But the WD1003-IWH does not have a twisted cable, and therefore probably expects that the drive it talks to is configured as drive 1. Could that be all there is to it? I changed the jumper so that the ST-225 would respond as drive 1 and hooked it up to the 1003-IWH again.
Lo and behold, there it was! Suddenly the DRDY (drive ready) and DSC (seek complete) bits in the status registers were set, and it was possible to access the drive!
Later I double checked and verified that when the ST-225 is jumpered as drive 2, it does not show up as the second drive on the WD1003-IWH. Most likely the drive select signals for selecting a drive other than 1 aren’t wired since it’s physically impossible to connect more than one drive to the WD1003-IWH.
After reconfiguring the drive, recalibrating/reading/seeking no longer failed, the controller and drive were clearly alive. Unfortunately my joy was short-lived for two reasons, one expected and one unexpected.
The expected reason was that the WD1003-IWH does not support the IDENTIFY DRIVE command. That’s really not surprising, since the controller has no way to know what drive is connected to it. The WD1003-IWH really does appear to be a very close functional equivalent of the standard WD1003-WAH controller.
The unexpected reason was that all the data I read from the drive was garbage. But not at all random garbage. This is what the drive’s boot sector looked like when I read it:
This is what it should have looked like:
Notice how every odd byte is actually correct, but every even byte contains the next odd byte instead. This is when using 16-bit port I/O, which is a requirement for the AT disk controller data port. The exact same code and the exact same IDE cable and ISA I/O card work without any trouble with a number of old and not so old IDE drives. And no, 8-bit I/O does not work; the drive clearly does read 512 bytes from its buffer when the host reads 256 words.
I briefly considered the possibility that the WD1003-IWH controller isn’t reading data from the MFM drive correctly because it was written using a different controller. But that’s not possible, because then there would be CRC errors or worse, and there weren’t any. I also considered the possibility that the buffer memory on the WD1003-IWH is faulty, but that should have been discovered by the controller diagnostics (which passed) and the problem didn’t really look like bad memory.
I’m really not sure what the problem is. It has almost certainly something to do with the fact that the AT disk data port is the only 16-bit port in the I/O range and that the IOCS16 signal needs to be activated by the WD1003-IWH in time. But I do not understand the mechanism which causes the data to be corrupted the way they are.
Just for kicks, I decided to plug the WD1003-IWH directly into the onboard IDE connector. That goes to a VL-bus Adaptec IDE controller rather than through an ISA slot. Could that change anything?
Well… sure enough, it did. With the WD1003-IWH + ST-225 plugged directly into onboard IDE, the machine booted off the ST-225 drive. Or rather it did as soon as I fixed the drive type in the BIOS.
Clearly the buffer memory on the WD1003-IWH is just fine, and in fact the adapter seems to be working as well as it did 35 years ago when it was new… but when it’s plugged into the ISA I/O adapter I have, it’s not working right and 16-bit data transfers are corrupted. That is almost certainly not a fault that developed over time but rather a design issue with the controller that existed since day one but never showed up with the machines it was designed for.
So is the WD1003-IWH any good? Yes and no. It allows connecting an MFM drive to an IDE connector, but it doesn’t turn an ST506 interface drive into an IDE drive. The crucial missing ingredient is the IDENTIFY DRIVE command, without which any modern software won’t know what to do with the drive. However, for systems where the BIOS drive type can be explicitly set, it does work.
The WD1003-IWH has one mysterious jumper that is “documented” by Compaq. But all the Compaq manual says is that one position is for a 10 MB drive and the other for a 20 MB drive. I have no idea what the jumper really does, but it does do something, and placing it in the 10 MB drive position prevents the ST-225 (which is a 20-megabyte drive) from booting. The jumper appears to limit the maximum cylinder, although the purpose of this escapes me.
Since the ST-225 has the same geometry as Compaq’s 20 MB drive (Miniscribe 8425), it’s unclear whether the WD1003-IWH can generally work with any drive geometry or if it’s somehow limited to the two models Compaq used. If more MFM drives turn up, that would be something to test.
Anything funny in the ISA timings will go right through a mostly-passive ISA adapter and confuse the WD1003-IWH. That would explain why it works fine on the Adaptec controller.
I suspect the mystery jumper enables translation. The Miniscribe 8212 has only 2 heads, but the typical “type 1” geometry has 4. One of the jumpers on the WD1003-WAH enables translation for this exact scenario.
Oh, translation. That didn’t even occur to me, but it’d explain why the ST-225 totally failed to boot with the jumper set in the “10 MB” position even though I really don’t think it would have accessed anything beyond the first few cylinders. But if the jumper messed with the head translation then that’d upset things real fast. I could see that the MBR was read and probably also the boot sector of the DOS partition, but the boot sector reported an error.
I see the Miniscribe 8212 had 615/2/17 geometry, so that would get translated to 308/4/17. OK, so the W3 jumper on the WD1003-IWH seems to be the equivalent of W4 on the WD1003-WAH, except it’s backwards (1-2 default on IWH, 2-3 default on WAH). At any rate the default W3 setting on the WD1003-IWH should not mess with the drive geometry and likely works with many MFM drives.
Thanks, again I learned something old.
And yeah I know that the ISA adapter does ~nothing for IDE. I just don’t get why the WD1003-WAH misbehaves while a very similar IBM/WD disk controller works just fine in the same ISA slot. I should probably go through all the ISA MFM controllers I have and see if they all work OK or not. I should also try different boards because I strongly suspect that the problem will go away or at least be different with different boards/chipsets. FWIW, with the OPTi 499 chipset I tried tweaking the various ISA settings but nothing helped.
It also does not help that WD seems to have been updating their chips all the time and it’s next to impossible to find two controller models with the same WD chips. The changes usually were minor but if the problem is timing, any seemingly insignificant change could have an impact.
What’s interesting is that every individual I/O read goes wrong, so it does not matter how much waiting is inserted between reads. And since the reads have to be 16-bit, software has no control over this.
Looking at the board layout, I think it’s safe to say the buffer RAM drives the high data byte during the 16-bit read, and the WD11C00-JU drives the low data byte and the buffer address lines. In order to get the low data byte, the WD11C00 must first address the low data byte and latch it before addressing the high data byte.
Somehow, the OPTi chipset is confusing the WD11C00 into advancing the buffer address before the chipset has latched the data. I don’t think it’s related to IOCS16 – you would see the contents of the error register in place of every high byte if it were.
I agree it can’t be IOCS16 because the junk data is clearly coming from the data register, not error register, and because the reads never get completely misaligned, which implies that the data register must have seen the right number of read cycles, not more and not less.
The WD11C00 is unfortunately rather poorly documented… like most of the WD chips. I guess what you’re saying is that the WD11C00 is returning the low 8 bits as it should; the high 8 bits are coming straight from the SRAM, but somehow the WD11C00 already advanced to the next buffer address. I’m guessing that as soon as a read cycle completes, the WD11C00 has to advance the buffer address, read 8 bits, advance the address again, and wait for the next read cycle. So somehow the WD1003-WAH thinks the read cycle is done when the chipset hasn’t actually latched the data.
I thought the problem was that the OPTi chipset was too fast, but now it looks like it’s actually too slow. Will have to play with the settings some more…
>But I do not understand the mechanism which causes the data to be corrupted the way they are.
If -IOCS16 is changed from deasserted to asserted state in the middle of bus transaction instead of its beginning (normal case) you can get this effect.
Can you explain how that works (or doesn’t work) in detail? I can see that from the device’s perspective, it would still be a 16-bit cycle, so it won’t get out of sync. But what exactly does the chipset do? And is this some kind of known problem that affects certain devices/chipsets?
>Can you explain how that works (or doesn’t work) in detail?
Deasserted -IOCS16 actually generate two 8-bit transactions first on address+0 and than on address+1 on lower 8-bit of ISA bus (and i used this consciously for reading of LPT DATA+STATUS by one 16-bit IN for speed up for example). And 8 bit from address+1 shifts to upper 8 bit in the end of big (read) transaction.
That is when -IOCS16 is deasserted during whole transaction. But if it changes in the middle we (i suppose):
1. Get 16 bit on the bus in first reading but will ignore upper 8 bit.
2. Device thinks that it sends 16 bit and try to send next 16 bit on next reading
3. And we will get lower 8 bit and shift them to upper 8 bit
4. But asserted -IOCS16 prevents from normal second reading so we don’t get lower 8 bit from first word of data + lower 8 bit from second word in first 16 bit IN, than lower 8 bit from third word + lower 8 bit from 4th world in second 16 bit IN, etc, but the picture you really got.
Steps 3 and 4 are very specific for bus controller and device on the bus (and they interaction).
>And is this some kind of known problem that affects certain devices/chipsets?
Never hear.
I would try any “advanced chipset setup” settings that would slow down the ISA bus and see if that improves things.
Also a really short IDE cable could help.
Tried that, didn’t help.
Most ISA IDE adapters have buffer chips for first 8 bits (8 bit part of bus) but not for the 2nd bit in the 16 bit part of the bus. Perhaps weakish signal due to this difference?