The other day I asked myself a seemingly trivial question: What was the first ATAPI CD-ROM drive and when was it available? Given that ATAPI was a major technology which instantly obsoleted all proprietary CD-ROM interfaces and made SCSI much less desirable, one might expect that there would have been some press releases touting the advantages of the new technology, articles describing the whys and wherefores, but… nope. There is nothing.
In 1993, CD-ROM drives used either SCSI or one of several proprietary interfaces, the major amongst those being Matsushita/Panasonic, Mitsumi, Philips, and Sony. In 1995, the proprietary interfaces were effectively gone and most new CD-ROM drives used the ATAPI interface. Something clearly happened in 1994, but exactly what, when, and how—that’s something of a mystery.
There are reports that Philips showed their CDD-300 CD-ROM drive with “new IDE interface” (e.g. ATAPI) at the CeBIT ’94 expo in March 1994. When the drive started shipping is unclear, but it was certainly in 1994.
Further digging showed that NEC was another early vendor of ATAPI CD-ROM drives. Establishing the timeline is again very difficult, but in June 1994 there was a Linux kernel patch to support the NEC CDR-260. Its author seems to have been completely unaware of the existence of ATAPI, but that’s perhaps not surprising since the ATAPI 1.2 specification was only finalized on June 10, 1994, although a draft was available in February of that year.
Too Old to Work?
There is a possibly misleading Microsoft KB article (KB131499) claiming that the “NEC CDR-38, NEC CDR-250, CDR-260, CDR-260R, and CDR-260GW CD-ROM drives are incompatible with the ATAPI specification version 1.2”.
Another Microsoft KB article (Q121547) brings more detail: The NEC CDR-260 drive “follows the ATAPI A1.8 specification, which is a pre-release specification that has not been ratified by the ATAPI council”. The article further adds: “NEC also manufactures the CDR260R CD-ROM drive, which does conform to ATAPI 1.2 specification and works with Windows NT version 3.5. Starting in November 1994, Gateway 2000 began shipping the CDR260R rather than the CDR260 in its computers.”
Note that the two articles contradict each other: KB131499 claims that the NEC CDR-260R is not compatible with ATAPI 1.2, whereas Q121547 explicitly states that it is.
The NEC CDR-260 was apparently an OEM drive and no real documentation exists. What is interesting is that photos of an NEC CDR-260 made in July 1994 show a jumper selecting between “8-bit bus” and “16-bit bus”. ATAPI is inherently 16-bit just like ATA… then again there are specialized 8-bit ATA variants.
Now, if there were CDR-260 drives built the first half of 1994, that would explain why those drives weren’t compatible with the ATAPI 1.2 specification which was officially published in June 1994. It’s also no wonder that Windows NT wasn’t the only operating system that didn’t like those drives. NeXTSTEP 3.3 release notes explicitly list the NEC CDR-260 and CDR-273 as unsupported.
Linux source code offers some clues too. The NEC CDR-260 is clearly mostly a standard ATAPI drive but several relatively minor differences prevent it from working with normal drivers.
Examining NEC_IDE.SYS
Another indirect source of information is the NEC_IDE.SYS device driver for DOS (required for MSCDEX). The OS/2 Museum has an NEC_IDE.SYS file dated 2-18-94, size 21,669 bytes. This driver does not work with modern ATAPI drives, but shows something interesting:
Rev A1.7 quite likely corresponds to a pre-release ATAPI specification, but notice how there is absolutely no mention of NEC, only Oak Technology OTI-011.
Analyzing the driver shows that it cannot work because it issues the ATAPI Soft Reset command (code 08h) and expects that when the command completes, the drive will set the DRDY and DSC bits in the ATA status register, just like an ATA hard disk would.
The ATAPI 1.2 or even ATAPI 2.6 specifications are not 100% clear on this point, but suggest that the bits should probably not be set. ATA/ATAPI-6 is unambiguous and says the DRDY and DSC bits will be clear, just like after ATAPI device power-up, in order to “hide” ATAPI devices from old ATAPI-unaware drivers for ATA hard disks.
A newer version of NEC_IDE.SYS from April 1995 works:
It’s notable that the newer driver handles the standard ATAPI behavior (status register bits clear after ATAPI Soft Reset) as well as the old NEC drive behavior (DRDY and DSC set). It is highly likely that the driver was designed to handle both old pre-standard drives and newer ATAPI 1.2 compliant CD-ROM drives.
But again… why does a more or less standard ATAPI driver for an NEC CD-ROM drive only mention Oak Technology OTI-011 and nothing else…
Oak OTI-011
So what exactly was the Oak Technology OTI-011 chip? There is not much information available. Unusually, in place of datasheets, bitsavers only has several patents related to the OTI-011 chip. That is not great, but does show fairly clearly what OTI-011 did.
Note that in the late 1980s, Oak Technology developed OTI-012, a CD-ROM controller chip with no IDE/ATA support. The OTI-011 is a successor chip (no, I don’t know why the Oak numbering went backwards) developed in 1992-1993 which combined the functionality of OTI-012 with a built-in ATA interface, suitable for implementing an ATAPI CD-ROM.
The OTI-011 required an external microcontroller and DRAM and was expected to be connected to a DSP which delivered the raw bits from a CD-ROM. The OTI-011 decoded sub-channel data and raw sector data, and was capable of performing the additional error correction and detection needed for CD-ROMs. The host interface of OTI-011 implemented ATA task file registers in hardware and set up ATA/ATAPI command processing for the attached microcontroller. The OTI-011 chip itself implements very little of the ATA protocol itself; the external microcontroller’s firmware does the hard work.
The patents describe what the OTI-011 chip did in terrible mangled lingo, but don’t provide any background information. Normally there would be no public information about the development of a chip… but in this case there is, thanks to lawsuits that Oak Technology (later Zoran) initiated in the late 1990s and early 2000s.
There is an U.S. International Trade Commission document which supplies a surprising amount of historical information, and also establishes a fairly detailed timeline, since that was required for establishing the validity of US Patent 5,581,715 (aka ‘715 patent).
We learn that Oak Technology achieved “considerable commercial success” with the OTI-011 chip because it solved an important problem (attaching a CD-ROM drive to the ATA bus) before others.
Oak Technology, namely Phil Verinsky, conceived of the OTI-011 chip “no later than April 21, 1993” while “the date of the ATAPI specification is June 10, 1993. There is no evidence that the ATAPI specification or any earlier version of it was communicated to Oak before the April 21, 1993, conception date.”
Note that the official ATAPI 1.2 specification is dated June 10, 1994, but the above refers to Western Digital’s “ATAPI CD-ROM Standard: Proposal for Working Draft” document from June 10, 1993.
We learn that in early 1993, Mitsumi worked with Oak Technology on a CD-ROM drive attached to the ATA bus but not utilizing ATAPI. It appears that this project didn’t really go anywhere.
In April 1993, there was a sales agreement between NEC and Oak concerning the not-yet-completed OTI-011 chip. It is almost certain that NEC was Oak’s first customer and likely the first user of the OTI-011 chip. This fits with other known facts, namely that NEC shipped ATAPI CD-ROMs before the ATAPI 1.2 standard was finalized.
The OTI-011 chip taped out on July 22, 1993, was quickly corrected and taped out again on July 29, 1993. Given that information alone, it’s near certain that OTI-011 chips were made in 1993, but it’s much less clear if any CD-ROM drives based on those chips were shipped in 1993.
We also learn the versions and dates of several unpublished early ATAPI specification drafts:
- Revision A1.4, dated Aug. 17, 1993, 141 pages
- Revision A1.5, dated Aug. 28, 1993, 158 pages
- Revision A1.6, dated Sep. 10, 1993, 174 pages
- Revision A1.7, dated Oct. 18, 1993, 176 pages
- Revision A1.7B, dated Nov. 2, 1993
Note that revision 1.7B was almost certainly the last one before SFF took over the ATAPI project.
Under the SFF heading, ATAPI 1.0 and 1.1 drafts were made available but very quickly replaced. Revision 1.2 was the first widely used ATAPI standard.
NEC CDR-260
The OS/2 Museum was able to obtain a functioning NEC CDR-260 drive with a February 1994 manufacturing sticker (February 1994 was when the draft of ATAPI 1.2 was made available). Sure enough, the drive is… interesting. That starts with the drive jumpers which according to the label provide an option to switch the IDE interface into an 8-bit mode (see photo at beginning of article). What good that might be… nobody knows, since there is no documentation.
Looking inside the drive, one very unsurprisingly finds an Oak Technology OTI-011 chip (lower right corner):
Linux detects the CDR-260 drive, but is a bit confused about the drive’s name. It turns out that the model name is not byte swapped in the data block returned by IDENTIFY PACKET DEVICE, but Linux expects that it will be, so it ends up getting scrambled. This is the exact same problem that certain old IDE drives had. Unsurprisingly, the problem has been noticed before. It is worth mentioning that the ATAPI specification makes no suggestion that the ASCII strings embedded in the IDENTIFY PACKET DEVICE response should be byte-swapped, but “everyone” expects them to be.
What’s much worse is that after inserting a CD-ROM, the drive “falls off the bus” with many errors and many reset attempts. Linux is effectively unable to read anything.
But the drive is not dead. In DOS, the NEC_IDE.SYS driver (dated 08/11/1994, size 24,824 bytes) works just fine. The drive can read CD-ROMs without trouble. Interestingly, the previously mentioned older NEC_IDE.SYS driver (dated 02/18/1994, size 21,669 bytes) appears to find the drive but then says that it’s not ready.
The working NEC_IDE.SYS driver appears to detect this particular model, or rather detects NEC (by definition ATAPI) drives with firmware version lower than two; the drive in question reports firmware revision 1.01. Such old NEC drives are then treated specially by the NEC_IDE.SYS driver.
A survey of various operating systems confirms that yes, the NEC CDR-260 is unusual. As mentioned above, Linux has workarounds for it, but clearly not sufficient. Solaris mentions the CDR-260 explicitly, and special-cases the CDR-260 and a few other drives to only transfer one sector at a time.
The ATAPI driver in OS/2 has by far the most complete support for these drives. The author clearly had the elusive ATAPI revision 1.7B specification in hand. The OS/2 driver translates a number of SCSI commands and converts the SCSI mode page information returned by the drive from the ATAPI 1.7B format to the published ATAPI 1.2 specification. There’s also the following comment:
The 1.7 spec indicates that the completion status only relies on the DRQ bit being 0. If we are in 1.7B compatibility mode and the DRQ bit is 0, set the reason variable to IR_COMPLETE.
I suspect that might be the why Linux doesn’t work with this drive and why Solaris only reads one sector at a time. From reading the ATAPI mailing list, it is very clear that as late as December 1993, some important low-level details of ATAPI were still in flux. If the NEC CDR-260 drives really conform to the pre-SFF revision 1.7B of the ATAPI specification, it’s not surprising that software written for ATAPI 1.2 and later has trouble with them.
The NEC CDR-260 drives were also found in NEC’s own PC-98 machines. This blog post (Korean) shows a drive with a “CDR-260(PI)” designation on a Japanese label and much the same electronics as the one pictured above. The OTI-011 chip visible in the blog photos was made in week 46 of 1993; there is a high likelihood that NEC shipped the CDR-260 drives before the end of 1993, though perhaps only in Japan.
Other Early Entrants
As mentioned above, Philips/LMS was another early supplier of ATAPI drives. Examining DDATAPI.SYS driver from August 1994 that shipped with CM-207 drives (and likely others), it is apparent that the driver is very unlikely to work with generic ATAPI CD-ROMs. The DDATAPI.SYS driver expects that the Sector Number register (typically at I/O port 1F3h or 173h) changes its value in a certain way. Yet the ATAPI specification leaves said register more or less completely unused and does not define any behavior for it.
That is a hint Philips started implementing their ATAPI drives well before the ATAPI specification was finalized. It is possible that the Sector Number register has some vendor specific meaning on Philips drives, but it’s also possible that the register had some defined function in unpublished drafts of the ATAPI specification.
Note that Philips did also produce integrated ATAPI CD-ROM controllers (e.g. SAA7380), but there is no evidence that such chips existed before 1996.
Cirrus Logic was, together with Oak Technology, an early ATAPI chip vendor. The CL-CR3400 may have been available in 1994, but unlike the OAK OTI-011, it was only an ATAPI interface chip, not an integrated CD-ROM controller. Only the follow-up chip, the Cirrus Logic CL-CR3410 (1995) integrated both the ATAPI interface and a CD-ROM decoder.
Mitsumi was another early vendor of ATAPI CD-ROM drives with the FX001DE drive. So was Sony with CDU-55E and CDU-55D drives. If this document is to be believed, all those drives were available in 1994 and did not fully conform to ATAPI 1.2.
Secret Society
It’s not a coincidence that even industry insiders called ATAPI a “secret society”. According to Dal Allan, ATAPI “went public” in October 1993, and became an SFF project (before moving to X3T13 in 1996). But work on ATAPI probably started sometime in 1992 when, again according to Dal Allan, It was Compaq who told WD “You and the CD-ROM guys get together and give us a CD attached to the second ATA connector.”
ATAPI became sort of tied into Western Digital’s EIDE, although it is unclear if Western Digital sold any ATAPI related products. It is however clear that WD lent its significant expertise when figuring out how to make ATAPI devices coexist with IDE hard disk on a single cable without upsetting the BIOS or driver software (a puzzle that was still being solved just before ATAPI 1.2 was completed).
Until late 1993, ATAPI development was driven by Western Digital but done in secret, with confidential drafts of the ATAPI specification circulated amongst a handful of companies. From the Oak Technology related litigation we know that ATAPI A1.3 specification was dated June 10, 1993. We don’t know any dates of the earlier versions, but it is unlikely that A1.3 would have been the initial version; it might however been the first version seen outside of Western Digital.
Conclusion
We still don’t know who shipped the first ATAPI CD-ROM drive and when. The pre-1994 drafts of the ATAPI specification remain as secret as they were back in the day. That is a shame, because properly supporting certain old drives (such as the NEC CDR-260) would require the ATAPI 1.7B specification.
We did find out that Oak Technology was an important player in the early ATAPI CD-ROM drive evolution, and that ATAPI CD-ROM drives were made in early 1994, perhaps even in late 1993, before the earliest ATAPI standard (revision 1.2) was finalized. These drives tend to be incompatible with standard ATAPI driver software, but work with the DOS drivers that these drives shipped with.
Another thing worth mentioning is that internal Zip drives shipped with three interfaces: SCSI, IDE (not ATAPI) and ATAPI.
I remember that OS/2 at the time could support SCSI and IDE, but had problems with ATAPI drives. Later versions had an updated driver and could support the ATAPI drive.
This is in contrast to the DOS world, where the IDE version required proprietary Iomega driver software and the ATAPI version “just worked”.
See also https://en.wikipedia.org/wiki/Zip_drive#Interfaces
It sounds like those Zip drives behaved like standard hard disks (with removable media). That was not going to really work for CD-ROMs due to the different sector size and the additional functionality CD-ROM drives needed (audio playback). I believe this was tried for CD-ROMs (making them look like IDE hard disks) but didn’t really get anywhere.
That’s an issue that has returned later to plague DVD-RAM: most drives
represent them as CDs (like the other media they support), obstructing
the direct access they’re designed for.
How did this work w/ MO drives…? Did they use ATAPI?
At least Fujitsu DynaMO drives used ATAPI (or SCSI). Because ATAPI is largely SCSI over ATA, it’s very flexible and can support all sorts of devices.
The ATAPI Zip drive method of handling ARMD by hiding the first 32 sectors and falsifying the boot record was wild. I was glad Iomega dropped the A: drive functionality from the final revision of the ATAPI Zip drive; it always seemed like a chance to suffer data loss when transferring disks between systems.
Don’t forget SATA optical drives (one of the first was Plextor) and why they lagged behind SATA hard drives.
What about the history of the secondary IDE channel and the CMD640/RZ1000 etc…
I always assumed they lagged because there was no point to it, optical drives couldn’t get near the data rates of hard disks. In other words, switching from PATA to SATA did not solve any problems for optical drives. And in fact moving hard disks over to SATA probably simplified things for optical drives, since they didn’t need to share a cable with anything anymore.
Or was there more to it?
I did always wonder if anybody ever produced an adaptor that would allow an “arbitrary” SCSI device to connect to an ATA bus as ATAPI.
I have seen a few places where ATAPI code seems to support things other than optical/removable drives (e.g. hard drives and scanners), but I’m not sure if that’s the result of basing the implementation on existing SCSI code (or OSs presenting ATAPI interfaces as SCSI controllers) or if such things ever existed (possibly by way of an adaptor).
There were ATAPI tape drives for sure. Basically pretty much any kind of a storage device was ATAPI except for hard disks, since there was no point making those use ATAPI.
I’ve never seen a SCSI to ATAPI adapter. I believe it should be technically doable, the problem is that it might be more expensive than a SCSI HBA.
The low level ATAPI protocol is really generic; a SCSI CDB goes in, data goes in or out. ATAPI as such does not care what the commands are or what data moves across the bus.
Would it be possible for you to upload these two versions of NEC_IDE.SYS somewhere?
I remember seeing early 1990s speculations that future hard drives would switch to ATAPI to avoid the size limits of ATA.
The biggest problem I had with ATAPI Zip 100 drives is that you couldn’t disable write caching on them in Windows 9x (the box was checked and greyed out). You basically had to wait for “lazy” writes to complete.
The delay of optical drives on SATA was likely lack of demand and/or waiting for AHCI. Early SATA was a bit chaotic at the OS level until AHCI came along. Intel ICH5 systems had that weird channel assignment thing in the BIOS to keep Windows 9x happy. The SATA ports could appear as a 3rd legacy IDE controller. Add-on cards just showed up as SCSI drives.
Certainly. See here.
At this point, I wonder where one could obtain an IDE/ATA specification from that period. Because on my emulator, that old NEC_IDE.SYS behaves even worse – it attempts to send command A0 (Packet Command) to an IDE hard disk (after sending command 08 (Software Reset)) and then complains about it being not ready when that returns with the DSC, DRDY, and ERR bits set. How exactly does it tell hard disks apart from CD-ROM drives?
OK, it turns out the driver is pretty dumb and basically does this – only checks either primary (default) or secondary (with /P:170 /I:15) (but it may be able to use tertiary or quaternary IDE as well, I haven’t yet tried), and it assumes it’s a single-channel device that ignores the drive select bit of the Drive/Head register. I was able to work around that by setting the CD-ROM to secondary master, and adding a second CD-ROM to secondary slave. I also made it set the DRDY and DSC bits on command 0x08 (WIN_SRST) as needed.
Also, that command is not supported by non-ATAPI devices at all. It’s specifically ATAPI reset. A hard disk will likely respond with an aborted command instead. This is further confirmed by the ATA-1 draft specification from 1994 that I was able to find in the end, that doesn’t mention the command at all.
But that turned out to be irrelevant in the end at all, since the driver is for single-channel (!) IDE controllers, so it just assumes that it’s talking to a CD-ROM drive conforming to the ATAPI A1.7B specification.
It is also worth noting that the driver appears to support IDE DMA using an ISA DMA channel (the default appears to be DMA 3), which is another peculiarity of whatever controller it appears to be designed for.
There’s a way to tell the driver to check device 1 (slave) with ‘/P:170s’ etc. I could not find any documentation but I did find usage examples.
I know from reading the ATAPI mailing list that coexistence with hard drives on a single channel was something that was not finalized until just before the ATAPI 1.2 draft was completed (February 1994). So if the old driver is really bad at handling an IDE disk and a CD-ROM on a single IDE channel that makes a lot of sense.
We know that the CDR-260 drives were shipped in Gateway 2000 machines but I have no idea how exactly those were configured. There is anecdotal evidence that some of those machines had Intel Plato (Premiere/PCI II) motherboards. The TPS for the Premiere/PCI II says that primary IDE is handled by RZ1000 (yay data destroying bugs!) while the secondary is handled by a 37C665 Super I/O chip and it is a “Type-F DMA capable secondary IDE interface”. Whether that actually worked in practice is anyone’s guess.
As for IDE specs, you want either late ATA-1 drafts or early ATA-2. You’ll also find Seagate/Conner/WD drive manuals from the era.
The thing is, with the simple /P:170, the driver first writes E0h to port 176h (secondary IDE Drive/Head register), which means set device to slave (bit 4 set), and expects to get a response to command 08h.
Perhaps an absent slave with a present master should report the master’s status register instead? I’d need to check my .TXT files from my probing of my old PC’s real IDE controller again to see if that’s the case.
ATAPI Revision 1.2 about command 08h:
The ATA software reset mechanism, SRST, (bit 2 in the Device Control Register) cannot be used for ATAPI Devices, be-
cause resets issued by the ATAPI driver would also reset any attached hard disk and vice versa.
To solve this ATAPI defines an ATAPI Soft Reset command using a reserved ATA opcode which could be decoded by
the interface controller hardware. The ATAPI Soft Reset command shall be “executed” by dedicated hardware as op-
posed to firmware, and the Drive Select bit will be used to qualify the one Device that will accept the ATAPI Soft Reset
command. Only the ATAPI Device that is selected will be reset by the ATAPI Soft reset command.
So this confirms that command 08h is ATAPI-specific (and device control soft reset is not used by ATAPI, at least in revision 1.2).
Also, I was wrong – E0h means bit 4 is clear, so master. And in fact, the driver works fine without a slave device, so it doesn’t need a single-channel IDE controller. So I stand corrected on that.
It looked to me like the ancient NEC_IDE.SYS driver might be able to handle two CD-ROM drives on a single IDE channel, but it’s really not good at handling an ATA disk/ATAPI CD-ROM combination. That sounds less crazy if it was intended for use in machines where the hard disk was on primary IDE using some kind of local bus interface and the CD-ROM was alone on secondary IDE.
The note about executing ATAPI Soft Reset in hardware is interesting. Attempting to use my CDR-260 drive with “normal” ATAPI device drivers caused the drive to hang badly enough that the ATAPI Soft Reset command was not enough to recover from it.
The master needs to respond for a nonexistent slave device, but it should not present its own status register. IIRC it should return zero on the nonexistent slave device’s status register reads. This is explained in good detail in newer ATA standards (version 5 or 6), in the older specs it was not that clear.
Old drives needed the “single” jumper to do this. If they were configured as master and there was no slave, they would just not handle the slave register accesses at all.
Thanks for the detailed article! It reminds me one annoying headache back in the days. I had bought a Pioneer 4x CD-ROM drive for my family IBM PS/1 (model 2133, the tower version). It worked fine generally but there was an annoying bug in Windows 95: Whenever the drive encountered a scratch or similar on a disk (which you could hear when it was trying to seek etc.). Windows 95 would bluescreen with an error in ESDI_506.PDR (I don’t remember the exact error message) which was terribly annoying since it could happen at any time during a game played from disc etc. I tried thousands of things but my skills were not for really debugging such an issue back then. Only thing I found that worked was to let Windows 95 fall back to real-mode access for the drive but this came with a prohibitive slowdown of the whole system. I never managed to fix it but eventually I got a Pentium II 😉
Thinking about it, I wonder if WD created “EIDE” as a marketing program to combine several ATA/IDE idea together.
That is exactly what EIDE was. According to WD’s materials, EIDE included the following: Support for higher capacity drives via BIOS CHS translation or LBA support; Fast transfer rates (PIO 3, Mode 1 DMA); Non-IDE peripherals, i.e. ATAPI CD-ROMs or tape drives; Support for more devices via secondary IDE interface; Plug and Play and OS support.
Most of those items were quite independent of each other.
Semi related and I was reminded of it during the short era of DOS CD burning software. ATASPI drivers were a thing.
I must have missed ATASPI, probably because my first burner was a Ricoh SCSI model.
Looks like ATASPI was a Future Domain invention. Here’s their presentation from 1995: https://www.t10.org/ftp/t10/document.95/95-141r0.pdf
Oh, the joys of early CD-ROMs. I find it interesting that they gave up on the idea to have a CD ROM being able to act as a read only hard drive. Compare with workstations from that era that used special SCSI CD-ROM drives where the firmware in the CD-ROM drive were able to let the computer read the CD-ROM as 512 byte sectors, even though the physical media had 2048 byte sectors. For a read-only device this would be more or less trivial to implement (especially if slow speed can be tolerated). Sure, a PC didn’t have the ability to boot from anything else than the first hard disk at the time, but if that feature had been included in ATAPI then I would assume that most PCs would had gained the possibility to boot from any IDE drive.
Thinking about it, a possible reason for them giving up on that feature might had been the 528MB limit. In order to stay compatible with BIOS/DOS any such CD could only had used the first 528MB which would likely had been a bad thing at the time.
Re sharing the same IDE interface/cable: I remember the advice to avoid sharing a hard disk and a CD ROM drive on the same cable. “Everyone” in the PC world gave that advice in the 90’s. In addition to the problems outlined in this article and the comments, hard disks back then didn’t always have an easy time cooperating on the same IDE interface either. I would say that as a rule of thumb things will just fork for CD-ROM drives that are at least 4x speed, and for hard disks that are around 500MB or larger. That seems like the point in time where devices finally complied to the standards.
Re the 8-bit interface mode on the CDR-260: Could the idea had been that CD-ROM would be an upgrade that people would had bought for their XT class machines? Windows 3.x were starting to gain market but if the people working on what became ATAPI had been doing their work for say two or three years it would likely had seemed like an obvious thing to do. Even in the really early 1990’s an XT class machine were seen as decent for many tasks and they were still sold new. Or could it had been something that WD did push for in order to make CD-ROM drives compatible with existing interfaces?
Re SATA optical drives: A reason for optical drives switching to SATA would had been to get rid of the PATA/IDE interface on (at the time) new computers. (My personal anecdote from about 2008 was that I bought an almost new motherboard for a low price due to the PATA/IDE ports being broken (manufacturing problem I would assume) and in order to use that I had to buy a new optical drive with SATA.
Re EIDE:
Which was the first computer bios, add-on card that had firmware support or operating system that had support for two had disk controllers or two floppy controllers?
The original documentation for the 1984 MFM hard disk + floppy controller for the IBM AT already has jumpers to select 1Fx/17X for the hard drive and 3Fx/37x for the floppy controller. (It seems like the floppy controller for the IBM PC and XT didn’t have any such jumpers, they were hard coded to 3Fx).
So the concept of having two controllers were around way before IDE were invented.
Was that part of EIDE just formalizing that there should actually be two ports and any PC BIOS and loadable drivers should support those two interfaces?
Bonus: were the add-on EIDE cards with built in BIOS ever reverse engineered? I’m fairly sure that the Promise cards had some kind of built in hardware dongle functionality that prohibited their BIOS from running with other controllers (say for example a burnt copy of the BIOS in the boot rom socket of a network card and a cheaper biosless EIDE interface card).
Promise sold a card called the DriveMAX which was literally an 8-bit card with a LBA replacement ROM on it. For modern use, there exists an open source alternative in the XTIDE Universal BIOS. There are versions for AT machines: https://www.xtideuniversalbios.org/
The second controller BIOS support seems to have appeared around late 1994, whenever chipset vendors started integrating dual channel PCI controllers (PIIX, CMD640 etc.) Tracking BIOS cores is somewhat easier and would reveal exactly when.
No, the 528M limitation was not the reason why CD-ROM drives don’t pretend to be hard disks. The 32M limitation was. You have to keep in mind that CD-ROM technology arrived in the era of PC DOS 3.1/3.2, certainly well before DOS 3.31/4.0. Back then, the more relevant limitation was 32M DOS partition size. MSCDEX was a way to get around that limit, but once you had MSCDEX, there was no point pretending a CD-ROM had 512-byte sectors.
At the time Atapi arrived DOS had overcome the 32M limit though.
Having a CD-ROM reader pretend that it’s a hard disk (close enough for a non-CD-aware firmware to be able to boot from it) is just about how the reader communicates with the host, not the format on the disks.
If ATAPI had been around before DOS 3.31 / DOS 4 a bootable CD could had contained one bootable partition that is max 32M and then any other partition(s), either also using FAT or any other file system. And yes, I know that the PC world seemed to be somewhat set to use partition tables on fixed disks and not use partition tables on removable disks, but still. (USB sticks afaik uses partition tables).
As a side track I haven’t tried hooking up a “workstation” SCSI CD-ROM to a bootable PC SCSI controller. Would be interesting to see if it would be possible to just burn a bootable PC hard disk image on a CD-ROM and boot off that. Unless the BIOS on the SCSI controller somehow actively avoids any device not identifying as a hard disk it should work. It’s likely that the SCSI card BIOS would avoid anything else than a hard disk though.
Sure, when ATAPI showed up, the 32M limit wasn’t an issue, but at that point no one was crazy enough to throw out all the existing CD-ROM software. Making CD-ROMs look like hard disks was a problem rather than a solution if the BIOS/OS didn’t expect the medium to be removable.
USB sticks may or may not have partition tables, there’s something people call a “large floppy mode”. I think it came from Zip and LS-120 drives. It’s something that is a matter of convention, i.e. an inconsistent mess.
I’m pretty sure most SCSI HBA ROMs only made SCSI hard disks look like BIOS hard disks, not any other device. But at least some HBAs must have optionally supported that. One thing I can say with certainty is that x86 Solaris all up until Solaris 10 GA had a 512-byte boot sector at the very beginning of the installation CD. What systems that actually booted on I don’t know, but it was there starting with Solaris 2.1 which came out in 1993, well before El Torito or ATAPI. The fact that you never heard of that is I guess a testament to how useful it was 🙂
Why would you throw out existing ISO 9660 support?
The way workstations handle it is that when booting from CD they treat the CD like a (slow) hard disk, but when the OS is booted up it supports both the OS native file system and partition tables as well as ISO 9660.
A PC could do the same, i.e. have a MBR and whatnot on a CD and boot from that, and when booted be able to read both “MBR CD’s” and regular ISO 9660 CDs.
Re Solaris: Perhaps the idea was to be able to boot from an image raw copied from a CD to a hard disk? I don’t know if that was generally a thing people did, but it seems like a decent option at the time when CD-ROMs were rare and expensive.
(Anecdote: Reminds me of my early Linux installations. I had a DC6150 tape with the files for a Linux distribution stored as a tar archive (or perhaps a zip or lha archive), but no already running Linux system. I managed to get some DOS software running to read out the contents of the tape to a FAT partition, but the different long file names clashed. I managed to select the files that were needed to make a bootable system, boot from that, extract the archive from the tape within that bootable system to a separate ext2 partition, and rerun the installation pointing it to that ext2 partition and finally ended up with a complete system).
The issue is that bootable CD-ROMs only make sense if the BIOS supports it. SCSI CD-ROMs were always a minority, so what would be the point? Once the system BIOS had support for CD-ROMs (ATAPI), pretending that the CD-ROM is a hard disk didn’t really solve any problems. El Torito did a decent job of making CD-ROMs look like bootable hard disks.
Intel’s Batman’s Revenge and Plato boards might have been among the first with two IDE channels onboard. They had RZ1000 controllers which only provided one IDE channel, but there was another on a Super I/O chip. The Batman’s Revenge (Premiere/PCI) board was out in 1993 and used AMI BIOS. Pinning down exact dates is difficult but rev 5 of the Batman BIOS (1.00.05.AF1) is dated 11/30/1993. The boards must have been out in late Summer or early Fall 1993, and several OEMs (Gateway 2000, Ambra among others) used them. A quick survey suggests that two IDE channels onboard were not common at the time.
ETA: I’m confused as to which board is Batman, and which board BIOS 1.00.XX.AF1 applies to. Batman’s Revenge aka Premiere/PCI ED definitely had two IDE connectors in either very early 1994 or late 1993.
Later: On second look, 1.00.XX.AF1 almost certainly is Batman, although at least some versions of the board had the 2nd IDE connector missing (there was room for it on the PCB but no pins).
So… I rescued this Technical Product Specification from a Word document.
This ought to be the original Batman board, October 1993. If I’m reading the document correctly, there is only one IDE connector on the board, but the BIOS actually handles both primary and secondary IDE if one is added. That implies the BIOS support for dual IDE channels existed closer to mid-1993 rather than late 1994, although it may not have been common yet.
Apple did the whole “treat a CD-ROM like a hard drive” thing. Almost all Macintosh CD-ROMs are either a raw HFS file system or a bridged HFS-ISO9660 discs in the case of multiplatform software. Apple Partition Map was even supported and I have some really funky CD-ROMs that have both HFS and ProDOS (Apple II) partitions on them.
The Vision QD6580 is a dual channel IDE VLB controller from 1993. It has an interesting feature that I don’t recall seeing elsewhere: a jumper needs to be installed to handle any IDE devices that are not hard drives. I think some other VLB controllers also had dual IDE at the time but the spec sheets I can find are for later revisions of the chips from 1995.
The CDROM Macs had a large ROM. I think the Sun 386i also had a large ROM but I can’t find a good reference as to the size. Were an IBM PC to have an equivalent ROM in 1986, that would increase the cost of a PC by about $500. MSCDEX was about the limit of what could be added to the PC platform without pricing computers out of the market. Of course, choosing a cheaper solution at the beginning made later solutions more complex.
I have a Winbond EIDE controller card that came in the same WD box as the 540 MB hard drive so it is the first EIDE controller. It did not work with ATAPI CD-ROMs when I tested it but it has 25 undocumented jumpers that might have changed that.
@Richard Wells, re: ROM size limitations
That actually reinforces me impression that IBM might’ve well been
toying w/ the loading of BIOS extensions from disk. Me guesses that
increasing ROM sizes might actually have put an end to that.
(Me understands that Macintosh development followed a trajectory of ever
increasing ROM sizes, but then again they appear to have been more or
less committed to eventually including the entire `kernel’ in ROM from
the start.)
IBM did load BIOS extensions (for some definition thereof) from disk on many PS/2 machines. But not in any PC/XT/AT compatible systems.
Flash ROM seems to have taken care of that, as it was both sufficiently big and rewritable.
Could you check what chip exactly your Winbond EIDE controller has? There might be datasheets.
I can only guess that the QD6580 had some “read ahead” like many controllers of the era, and it might have been hardcoded for 512-byte sectors.
Another issue with CD-ROMs and why MSCDEX exists is that the interface to CD-ROM drives was anything but standardized. In the old days, every vendor had their own controller cards, and the driver had to come from somewhere. The drive vendors were probably not inclined to put a ROM on their controllers if they could avoid it.
The point I’m aiming at is that it would had been fairly simple to implement bootable CDs at the time “CD over IDE” were first discussed. The two things required would had been to let CD readers present themself as something siminar enough to a hard disk that the BIOS wouldn’t need much extra code, and the BIOS would need to be able to boot from other device than the first hard disk.
Sure, at the time it probably wasn’t a big issue to need one or two floppies to boot enough to be able to continue read from CD, but in practice we ended up with bad things like Windows NT insisting on installing itself on a FAT file system unless you had a pre made NTFS partition. (Sure, this can be blamed on a number of things, but lacking proper ability to format NTFS partitions could most likely be blamed on the boot floppies not having enough room for a kernel with the ntfs format function built in).
So it seems like it took the PC market about nine years from the first controller capable of being jumpered as primary (1Fx) or secondary (17x) (the original AT MFM controller) to some motherboard BIOS or extension card BIOS being able to automatically add those disks accessible via BIOS.
I still question if there were anything else that could use a secondary controller before that? Could OS/2 do that? Could early Windows NT versions do that? Could XENIX do that? Any other OS?
Re mscdex:
Well, every file storage needs a file system driver and a device driver for the physical interface. The strange thing imho is that the atapi standardisation people and the PC market didn’t somehow cooperate to make one atapi dos driver to fit all atapi compatible drives. I wounder how much extra we consumers ended up paying for every cd-rom manufacturer to produce their own driver? Probably not much but likely at least something. Compaq at least did the second best by making their own driver (CPQIDECD.SYS) that would work with any cd-rom reader, but that driver was of course Compaq-branded and could of course not be used by any other company. Back in the days it was a great thing to use on generic boot disks instead of the silly “cd-rom boot disk” that for example Windows 98 could generate, which tried loading an incredible number of different drivers.
The trouble is that “CD over IDE” came rather late in the life of CD-ROMs. When CD-ROM drives first appeared, they were often used with XTs, not even AT-class machines! At that point, there was zero chance of pretending that CD-ROM drives are hard disks on the hardware level. SCSI came closest, but that was never exactly standard in the world of PCs. IDE didn’t even exist at all.
Also I don’t think in the 1980s there was any real interest in bootable CD-ROMs (for PCs). The operating systems just weren’t that big, so why bother. Windows NT and OS/2 2.1 could both install from CD, but required boot floppies. As long as it was just one or two floppies, it wasn’t such a big deal.
OS/2 could use secondary IDE drives circa 1990. So could NetWare I believe. I’m not sure about Xenix but it would not have taken much to support it I’m sure. One thing to keep in mind is that before 3.5″ drives became widespread, having more than two hard disks in a typical machine was not practical.
Why there was no universal ATAPI CD-ROM driver is a great question. Especially since many of the existing drivers were pretty universal. Early on, it’s clear that the ATAPI drives were not that standard and needed custom drivers (goes for Philips and NEC for sure). There were lots of variations too, related to whether the drivers could do anything but PIO, or support fast PIO modes, what I/O ports and interrupts they supported, and so on. In the end I think there simply was no one who would have provided a universal driver, and it was at a time when DOS was on the way out, so the vendors didn’t focus on it too much. They just needed something.
The card that shipped in the Western Digital Hard Drive Upgrade Kit was the DTK PTI-227 using the Winbond W83757F. Much of the documentation* of the W83757 series indicates that it is a VLB chip; this card is for ISA but about 20 of the 100 pins on the Winbond chip are not connected. Oddly, it looks like the card was manufactured in mid-92 but the hard drive it came with wasn’t available until late 93.
* The manuals I found were updated ones from 1995 which indicate support for ATAPI. I did find a reference for the card but nothing there indicates ability to change ATAPI status. It was a bit strange that the card has a jumper set to indicate only one drive attached since the whole kit was intended for users to add a second drive to an existing system.
Numerous hard drives and multiple controllers were common in the S100 side of the market. For a long time, IDE drives didn’t make sense in the server role being limited in both capacity and speed. A single SCSI drive (or even ESDI for awhile) could exceed any collection of IDE drives and only cost a little more. The VLB controllers and the relatively large and fast WD IDE drives changed things for the gaming customer who could get by with less than a gigabyte but needed more than what MFM offered.
The 2048 byte sector made CD-ROMs cheap since they could use the standard CD logic only modified slightly to handle error correction. The initial 512 byte models that went to the mini and workstation markets had different logic boards and were incapable of reading audio CDs or 2048 byte sector CDs. That wouldn’t fly in the consumer market where the CD-ROM was pushed to convert the computer into a music system with an upgrade price less than the typical CD player. Later boards were able incorporate logic for both big sector and small sector CDs but it took time before the cheapest chips could include both.
Before a standard gets through a few years of updates, bespoke drivers are the way to go. ATAPI had its share of unclear passages that devices handled differently. Making a driver specific to the CD-ROM concealed any mistake and none of the companies involved could afford to scrap thousands of drives because the standard driver didn’t accept them. I mean even IBM with its comparatively unlimited resources didn’t scrap the Model 30 floppy controller chip.
The OAK CD-ROM driver that came on Windows 98 boot disks seems to be pretty much universal. I can’t say I’ve encountered too many drives that didn’t work with it (outside of way newer SATA drives). There were also other 3rd party drivers that were somewhat less universal (VIDE-CDD.SYS), but took much less memory.
The Windows 95 OSR2 boot disk (driver files dated Sept 1997) that came with a Dell machine has several ATAPI drivers on it. This one has a “NEC” driver (renamed OAK OTI-011 driver), a HITACHI driver (for CD and DVD-ROM drives), and a Toshiba driver. It also had limited PCI SCSI support with Adaptec ASPI8DOS.SYS. I know the early DVD-ROM drive that came in 1997 Dell machines only worked with the Hitachi driver.
One thing that always annoyed me about the OAK driver is that it clearly supported PCI DMA mode. How the heck was that enabled? I could never get it out of PIO mode.
The W83757 datasheet I found says that it is an ISA super I/O chip. The DTK PTI-227 documentationlines up with that. The W83757 does very little for IDE (unlike the Winbond VLB IDE controllers) and I can’t see why it would have trouble with ATAPI to be honest.
I should note that High Sierra and ISO 9660 presume 2K or larger sectors. Of course a driver can pretend there are 2K sectors even though the drive reads 512-byte sectors.
I agree that the early not-quite-standard ATAPI drives quite possibly precluded the possibility of a standard ATAPI driver for DOS. Once vendors had a solution, they had little incentive to ditch it. At the same time, the fact that there are a dozen or so different drivers which do 99% the same thing seems just silly.
“My personal anecdote from about 2008 was that I bought an almost new motherboard for a low price due to the PATA/IDE ports being broken (manufacturing problem I would assume) and in order to use that I had to buy a new optical drive with SATA.”
ICH8 removed PATA completely anyway.
The funny thing about that is there were even Intel motherboards with ICH8 and a 3rd-party ATA controller onboard.
More than two hard drives were physically possible with 5.25″ half height drives (like an ST-225). Example configurations could be three half height hard drives and one floppy in an xt class case, four hard drives + an expansion box containing the floppys, or for that sake four 5.25″ half height hard drives and one floppy in an AT class case (with 2+3 half height places). The reason for this kind of never happening was likely some due to that going for full height at least doubled the capacity and/or that even a used drive were worth so much that it got moved on to another computer when the hard disk were upgraded to a larger disk on one computer (unlike today when a used hard disk seldom changes owners – either they end up being a secondary disk in the same computer or they end up collecting dust).
I never knew that there were actual CD-ROMs (the disks that is) that used 512 byte sectors, and that there were drives for that format.
I know for sure that for example a DEC RRD 42 reads regular CD-ROMs and you can burn any bootable DEC or SUN operating system on a CD-R using regular 2048 byte sectors, and the computer will boot off that drive requesting data in 512 byte increments. Was 512 byte sectors on physical media something that the RRD 40 could use? The only thing I remember from back in the days is that it was said that the RRD42 were a better choice than RRD40 for anyone interested in semi-vintage workstations.
According to this list
https://www.ultimate.com/phil/pdp10/dec.disks
the RRD40 is an Laser Magnetic Storage LMS CM 210 and Wikipedia just states that it has a proprietary LMS interface and “no audio” but nothing about 512 byte sectors. (DEC apparently made their own interface boards, both to SCSI and their own disk inteface)
https://en.wikipedia.org/wiki/Laser_Magnetic_Storage_International
Re CD-ROMs for Macintosh: I’ve stumbled upon discs that contained data in a HFS file system and also had an empty ISO 9600 file systems. Tricky to read on a non-mac. There were at least two different file systems for Amiga that could read both HFS and ISO 9660. The one that generally were the best choice did auto detect and prefered the ISO 9660 part so no use on those disc. The other one could be forced to HFS mode by holding a key while the file system gets mounted (i.e. while inserting the disc) so the disc could be read.
I struggle to see the value of the ATAPI standard if the drives don’t comply fully. Was there even some mandated minimum set of abilities for a drive to be eligible to be called ATAPI?
Btw re CD-ROM on an XT – how about the undocumented 8-bit mode on your NEC 2x CD-ROM reader?
Re my motherboard with broken PATA/IDE ports: Funilly it had two different sets of SATA ports, iirc one set based on the general chipset and another set based on some additional chip. IIRC an optical storage unit did work best with a port from one of the sets while a hard disk did work best with a port from the other set. Btw it was a Gigabyte motherboard if that’s of interest.
What I remember (and a quick check of Linux-IDE confirms) was that the third party PATA controllers about 15 years ago required major redesigns to the existing drivers.
Unlike other issues, this does not require my eyes to read tiny print.