The Dual-Drive IDE Hell

I have perhaps inaccurate but very strong memories from my PC-building days (in the early to mid-1990s) that one of the most failure-prone and frustrating endeavors was trying to get two IDE drives working together on a single cable as a master/slave pair, or as Device 0/1 in the language of the ATA Standard.

It’s not that it was fundamentally impossible… but it was insanely random and unpredictable. No one could tell in advance whether any given pair of IDE drives would work. Mixing drive vendors seemed to increase the likelihood of failure, but using two drives from the same vendor was by no means a guarantee of success.

Various jumpers used for configuring IDE hard disks

There were two major reasons for why this was the case:

  • The whole thing started out as a giant hack, pretending that two separate IDE drives are really two drives attached to a single AT style controller.
  • The vast majority of IDE users only ever had one drive, thus not putting enough pressure on IDE vendors to get their act together.

Eventually, by the late 1990s, things did work reasonably well. The key ingredient was cable select and (barely) special cables which allowed all drives to be configured identically and work as either master or slave depending on their cable position. This was not exactly a revolutionary concept; PC floppy drives and ST506 interface hard disks used the same idea, using a twist in the cable, since the early 1980s.

But floppy and ST506 drives were much simpler to deal with: The controller had two (or in theory four) drive select lines to work with, and each drive responded only when selected. In the IDE world, things were much trickier because the two drives had to share the same I/O interface including hardware registers and interrupt lines, and therefore had to carefully cooperate to decide which drive should be responding to register accesses and how.

But it was even more complicated than that. To behave correctly, Device 0 has to act differently depending on whether Device 1 is present; if Device 1 is present, Device 0 has to let it respond to register accesses directed to it, but if there is no Device 1, then Device 0 has to respond to simulate a two-drive controller with no second drive attached.

The worst case is an IDE channel configured with only Device 1, because Device 1 has no way to know whether Device 0 is present, and therefore cannot respond for it. This scenario can be made to work, and it was somewhat common with ATAPI CD-ROMs, but host software has to be prepared to deal with it.

The way dual-drive IDE works is careful coordination between Device 0 and Device 1, hinging on the drive/head register (at I/O port 1F6h for standard primary IDE, 176h for secondary). In brief, both drives respond to register writes, but only the selected drive responds to writes to the command register. For read access and command register writes, only the selected device responds; in addition, Device 0 also responds for Device 1 when it knows there is no Device 1.

This carefully choreographed dance is also why seemingly trivial command overlapping can’t be done with IDE: The host cannot change the selected device while a command is executing (BSY or DRQ bits set in the status register), because this could lead to a situation where both drives believe they are active and both might respond to register reads or both try to deliver data, with predictably unpleasant results.

Configuration

In the early days of IDE, configuration was done solely through jumpers. There were typically three distinct settings, not just two: Master, slave, and single drive. (As an aside, the ATA standards used the Device 0/1 terminology from the beginning, while the drive industry stuck with the master/slave terminology for a very long time.)

The separate master vs. single settings were needed because there was not yet a standardized way for Device 0 to recognize the presence of Device 1, yet Device 0 needed to behave differently depending on whether Device 1 was there or not.

The original ATA standard defined a protocol using the DASP- and PDIAG- signals which allows Device 1 to advertise its presence (DASP-) and report whether its diagnostics passed (PDIAG-). Of course pre-standard drives didn’t necessarily support this protocol.

Many early IDE drives therefore had jumper settings that told the drive configured as Device 0 whether it should expect an ATA-compliant Device 1. This is perhaps one of the best examples of a setting that makes perfect sense to engineers yet is worse than useless to users: They have no way to tell whether a drive they’re trying to connect is ATA-compliant or not.

As a real world example, consider the configuration jumpers on Quantum ProDrive AT disks. These were all drives sold in the early 1990s; not only did Quantum change the jumpers on the drives several times (though not nearly as much as some other vendors), the drive behavior also clearly changed. That resulted in a fairly complex settings matrix just for Quantum’s own drives, with intricate details such as “Use the SS jumper alone only when the PD40/80 firmware EPROM is 7.0 or greater, otherwise use the DS jumper.” When a Quantum drive shared an IDE channel with another manufacturer’s hard disk, in many situations Quantum offered two possibilities of jumpering the Quantum drive, with no hint as to how one should choose the correct configuration.

Example: WD93044-A

The WD93044-A (made in 1990) is a good example of how such an early IDE drive may be configured. It has a block of three jumpers. When no jumpers are present, the drive is configured as the single drive in a system. Then there are separate jumpers for master and slave configurations.

And finally there is another jumper for “installation with a pre-existing Conner CP342 drive”. The documentation says: Configure the [WD93044-A] intelligent storage peripheral as the slave. Install jumpers on the J8 connector as shown below. The Conner drive must be configured as the master. This configuration presumes that you will use the LED on your WD93024-A or WD93044-A. However, if the host system requires a front panel LED, then configure the WD93024-A/44–A as the master and the Conner drive as the slave.

Say what?! That’s just stupidly complicated. And what if the drive is a Conner CP341 or CP344? Does the WD drive need to be set up the same way, or differently? And what does it have to do with LEDs?

The last question at least has an answer: The DASP- signal, in the words of the ATA standard, is “a time-multiplexed signal which indicates that a drive is active, or that Drive 1 is present”. Except, of course, it’s only time-multiplexed on ATA-compliant drives, not necessarily on pre-standard IDE drives such as the Conner CP342.

The single vs. master setting makes a visible difference to software with the WD93044-A drive. When it is jumpered as a master but there is no other drive, the WD93044-A waits about 5 seconds after a reset or EXECUTE DRIVE DIAGNOSTIC before it considers the slave drive to have failed. In addition, whenever Device 1 is selected, register reads return with all bits set because there is nothing responding. This leads to a situation where Device 1 may appear to be permanently busy, potentially severely confusing the host if it won’t switch away from Device 1 while it is busy (which it shouldn’t).

When the WD93044-A is jumpered as a single drive and Device 1 is selected, the status register reads as zero (indicating a drive that is not ready but also a controller that is not busy), which is consistent with an AT style disk controller with no second drive attached.

Jumper Zoo

Just to make things even more difficult, sometimes there is another complication: You have a drive, you know how it should be configured, but don’t have the right jumper. “Modern” drives (circa mid-1990s and later) almost uniformly use either classic Berg connector style jumpers with 2.54mm (1/10″) pitch and 0.64mm (1/40″) wide square pins, or smaller jumpers with 2.0mm pitch and 0.5mm pins.

But there are also drives which cleverly combined the two standards for 2.54mm pitch and 0.5mm pins, and those don’t work with either of the standard jumper types. Circa 1990 Conner and Quantum drives are known to have used these mongrel jumpers, and I failed to find any source of these jumpers in modern times, other than cannibalizing old drives.

Some drives (e.g. early 1990s IBM) also used jumpers that have the standard 2mm pitch but are very short, and cannot be used with typical jumpers. But the matching jumpers at least can still be sourced nowadays. On WD’s connector diagram, pin 39 is labeled as “-ACTIVE”.

An Afterthought?

Reviewing the initial high-level IDE description (a paper presented by Ken Hallam of WD at BUSCON East conference in Sep/Oct 1986) shows that there was no mention of attaching two IDE drives on a shared cable. Only the typical case with a single drive was considered. Pin 39 on the IDE connector was labeled “-ACTIVE” in the WD definition.

The very first IDE hardware, Western Digital’s WD1003-IWH adapter board, clearly reflects that thinking and allows attaching one ST506 style drive to an IDE connector. For this early implementation, two drives made no sense either logistically or in the intended use case (portable PCs with no room for second drive).

The Compaq DeskPro 386 Technical Reference (Sep 1986) is rather more interesting. In the chapter describing the fixed disk adapter, pin 39 is again labeled “ACTIVE-“, and described as follows: Active-low signal indicating that the fixed disk drive LED indicator is on and the fixed disk drive is being accessed.

But in the chapter describing the drives (in this case, a CDC Wren II with an IDE controller), we learn that the drives have a jumper that “designates the drive as C: or D:”, and a diagram shows two drives connected. Pin 39 is labeled “SLAVE PRESENT-” and described as follows: Active-low signal indicating to the host that a second drive is present.

Not only does this contradict the documentation of the connector on the adapter board that the drive is attached to, it doesn’t even make any sense. The “slave present” signal doesn’t indicate anything to the host, since the host has no way to read its value; it indicates the presence of a second drive to the other drive which needs to be aware of it.

It is possible or even likely that the option of connecting two IDE drives together was an afterthought, not initially considered when the IDE connector was specified. At the same time it clearly occurred to someone back in 1986 that it is possible, as long as the two IDE drives cooperate.

The Compaq 80286-Based Products Technical Reference from May 1987 reflects the evolving IDE definition. Pin 39 is labeled as “DASP-” (Drive Active/Slave Present) and described as follows: Time-multiplexed signal that indicates drive active or slave present. When the drive is executing a diagnostic command, this line is an output from a slave drive, and an input to the master drive indicating that a slave drive is present. At all times other than during diagnostics, this line is an output from both master and slave drives which is active when the drive is selected and being accessed (BSY is active), and is used to drive an activity LED indicator. This signal must be an open-collector output.

The May 1987 Tech Ref also shows jumper settings for both CDC and Conner IDE drives, and clearly indicates that it was possible to use two Conner or two CDC drives. It is not clear from the Tech Ref if it was possible to mix CDC and Conner drives on the same cable; the text suggests that it perhaps wasn’t.

It is notable that the CDC drives were clearly capable of detecting the presence or absence of a second drive, and thus only needed one jumper because there was no separate “single” and “master” setting. On the other hand, the Conner drives were different and required separate single/master jumper settings (and used three jumpers). It is plausible that the CDC drives used the DASP protocol from the very beginning and Conner drives did not.

At any rate, the mess and confusion is clearly as old as IDE itself.

This entry was posted in IDE, PC hardware, PC history. Bookmark the permalink.

19 Responses to The Dual-Drive IDE Hell

  1. Xelloss says:

    I must have been especially lucky, because in 1995 I added a Maxtor 245 MB drive to my system (sporting a Conner 41 MB drive) and the two worked together like a charm. I don’t remember which of the two I set as a slave: the only thing I know is that I had no configuration manual for the smaller drive. IIRC, the Maxtor drive used the same jumper configuration for “master” and “single”. Cable select was also possible, but I didn’t have a compatible IDE cable…

  2. Michal Necasek says:

    By 1995, drives were probably smarter about working with different kind of slave devices. At any rate it was always a lottery, not that it was impossible to hook up two drives together but it was much more complicated than it should have been. And configuration information was much harder to find back then, too.

    Most manufacturers eventually figured out that it’s best to reduce the number of options and put the instructions on the drive itself. Not sure who did that first, but I’m pretty sure it took years, I’ve never seen any early IDE drive with much of a hint as to how it should be configured.

    It didn’t help that many of the early IDE systems like the Compaq portables didn’t really support two IDE drives because there was no room for them. The original WD IDE paper never mentions the possibility of a second drive on the same cable either. Then again the Compaq DeskPro 386 Tech Ref from September 1986 is clear that it was possible to attach two IDE drives. However, this was always a function of the drives and not the host system.

    I added a section to the article describing the early history of dual IDE drives.

  3. Richard Wells says:

    A rather lengthy explanation of how the multiple IDE drives worked in practice is at https://www.t10.org/pipermail/t10/1994-January/000435.html The most relevant section is

    “Another “feature” of the MFM type controller was that if there
    was only one drive, a master, and the host selected the
    non-existant slave drive, all of the drive status bits would be
    zero (because there was not drive to assert any of the these
    bits). In the ATA world, this means that the master must respond
    with status of 00H if the non-existant slave drive is selected.”

    That seems to explain the benefit of having a single drive setting. There are other benefits to the single drive setting like reduced polling and being able to ignore spurious noise on pins that won’t be used in a single drive configuration. A long ribbon cable with few ground wires is a prime subject for interference from noise.

    The decision to reduce the pin count from MFM’s 44 to IDE’s 40 while adding functionality meant something had to give. MFM giving each of the four hard drives its own data cable ameliorated many of the potential problems. If two drives mistakenly respond to a command, the controller could simply ignore data sent by the wrong drive.

    The T10 email archive only goes back to 1994. Great if one wants to observe the early evolution of ATAPI but a bit late for the early days of IDE.

  4. Chris M. says:

    I always wondered why Western Digital had that “Single” jumper setting, now I know. Yet the only vendor that kept the “Single” position around was Western Digital. That photo of jumpers triggers me.

    I hated those little stubby ones like the grey one above. Tons of SCSI drives used them for some reason and those were more jumper hell than the IDE drives!

    Also, I have never come across a properly working cable for “cable select”. All the drives in my systems and that I serviced over the years as a tech were all jumpered for master/slave. SATA finally spared everyone from that mess, but it took WAY too long to show up.

  5. GL1zdA says:

    I’ve recently fought with many drives from the first half of the 90s. They had to work with an Aztech CDA 668-01ISE CD-ROM, what was a challenge in this case. For some reason the only way to do it was to enable a “legacy IDE” (not the SATA one, this was a 430FX board) option in SETUP (MR-BIOS).

  6. Michal Necasek says:

    Interesting, I have a number of IDE cables that probably date from the early 2000s and work just fine with cable select.

    Here’s a data point which probably shows that the cabling was problematic: Quantum for a very long time (maybe until the Maxtor acquisition) shipped drives jumpered as master/single by default, but their OEM drives were very often configured for cable select because the OEMs required that. It’s quite likely that the OEMs knew what cables they were putting in and could rely on them working, whereas random cables out in the field could not be expected to support cable select.

    SCSI is definitely a different ball of wax, many SCSI drives had way more configuration options than IDE ever had. There was the added complexity of needing to have the drive and HBA understand each other, and at least in my experience, SCSI termination was pure hell, mostly because the symptoms were very difficult to diagnose.

  7. Michal Necasek says:

    The T10 mail archives are great. But yeah it’s a shame they don’t go further back.

    I’m a little surprised that Hale Landis used the “master” terminology with MFM drives, there was obviously no such thing. There was just drive 0 and 1 and they were equals. I’m also pretty sure it would have been trivial to have only drive 1 on an old MFM controller, even if no one did that in practice.

    The discussion of BSY vs. DRDY is useful though; in the old MFM world, they were obviously separate because BSY was a controller signal while DRDY was a drive signal, but in the IDE world people sometimes get confused and forget that BSY and DRDY mean different things. You could even have an MFM controller with no drive attached at all, which can’t happen with IDE, although the same behavior may occur with an old IDE drive that doesn’t spin up.

  8. Michal Necasek says:

    Do you know what the “legacy IDE” option in the BIOS actually does?

  9. Richard Cranium says:

    A quick look around the Internet says that MR-BIOS v3.x was one of the of the few BIOSes that it fully supported tertiary and quaternary IDE channels, including booting from them. My wild shot in the dark is that the “Legacy IDE” option disabled that support, in case the BIOS started misrecognising other cards using IRQs 10 and 11 as IDE controllers.

  10. Michael Karcher says:

    ATA later shifted the support for missing drives from drive 0 to the host interface. As you correctly explained, a floating bus is read as “BUSY” and blocks conformant IDE drivers, so this situation needs to be avoided. In classic setups, the controller on drive 0 reports a non-busy controller for drive 1 if drive 1 is selected. This obviously fails in the drive-1-only configuration, as drive 1 isn’t designed to report a non-busy controller when drive 0 is selected.
    Instead, more modern ATA went a different route: The standard recommends to put a pull-down resistor on D7. Whenever a read is performed from the IDE bus, and no IDE drive drives the data line, we will see D7 (and only D7, usually) low, indicating “controller ready”. This also means that operating system should not only handle status “00H” as “drive missing”, but “7FH” as well.

  11. Michal Necasek says:

    Is that actually specified in ATA? Or one of the other documents? I could not find it although I’m almost certain that it’s specified somewhere. It is technically outside of the scope of ATA because that specifies the interface between the host and an ATA device.

    Intel’s ICH2 and later, but not the earlier ICH and PIIX chips, specify that “There is a weak internal pull-down resistor on PDD[7] and SDD[7].” I couldn’t find any explanation in the datasheet text as to why the pull-down is there, but the purpose is pretty clear.

    It is too bad that Western Digital defined the status register bits the way they did, because “nothing there” cannot be clearly distinguished from “BSY set, other status bits invalid”.

  12. MiaM says:

    The pull-down thing sounds more like a way to handle nothing connected at all though.

    Sure, at the time ICH2 were new there might had been some users who still had devices old enough that they didn’t comply with the master/slave DASP protocol but I doubt that those would had been what the ICH2 chipset aimed at. Possible people with newer devices incorrectly jumpered as slaves that were supposed to have a non-DASP-compliant slave but actually had no slave. But I think that it was rather a way to make auto detection of disks at boot time way faster. Semi-modern PCs seem to check each disk interface for any present devices at every boot, and that would had been extremely slow without the pull down resistor.

  13. Michal Necasek says:

    You have to remember that slave only/master selected means “nothing connected”. So yeah, it is meant to help with that case. It is less useful with “no drive at all” case because unless you can ascertain that the ICHx actually decodes the IDE addresses, it may not be so easy to tell if there’s something responding or not. But if the ICHx is decoding the IDE addresses and there is no drive then the pull-down will help.

  14. MiaM says:

    I’d assume that those who write drive autodetection code in the BIOS would only run that code at every boot if the built in IDE controller is enabled, or that would at least be the default behavior unless the user actively selects hardware ide interface disabled together with auto detection enabled. Although it would be great to have the option, that combination would be such a rare use case that it could well need the extra step to enable auto detection again.

    A qualified guess is that having auto detection and all interfaces enabled in the default bios settings saves the manufacturer or rather their resellers a bunch of support calls.

  15. Michal Necasek says:

    As long as computers had ISA slots, there was no such thing as “there is no IDE interface, no need to scan for disks”. The BIOS had no way to tell. Once systems only had PCI/PCIe add-on cards, the BIOS could actually find out.

    And yes, auto-detection made things a lot easier for users, hence fewer complaints to vendors.

  16. MiaM says:

    I’m talking about the auto detection some BIOSes run at every boot, and that could easily be enabled only when the on board IDE interfaces are enabled. If someone really want to add a separate interface using the same ports and have the skills to disable the on board IDE ports then they are probably also skilled enough to be able to manually run auto detection from within the setup.

  17. Michal Necasek says:

    In theory sure. In practice I’ve never seen such a BIOS. The reality is that 3rd party IDE controllers were quite common on many boards, even if they were probably exclusively PCI from about 1995 onward. I don’t think BIOS vendors bothered somehow automatically figuring out whether to look for IDE drives or not.

    The typical logic was to scan for IDE drives by default, but that could be disabled for individual drives. So the auto-scan could still be turned off, but the BIOS did not attempt to guess whether IDE drives might or might not be present.

  18. rasz_pl says:

    Something switched again in your WP instance and images stopped working over https

    Mixed Content: The page at ‘https://www.os…. was loaded over HTTPS, but requested an insecure image ‘http://www.os2mu….. This request has been blocked; the content must be served over HTTPS.

  19. Michal Necasek says:

    Hmm, I don’t see any obvious problems here with the latest Firefox or MS Edge. Going through HTTPS, images are showing up normally. Maybe more context might help?

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.