Attempting to install Microsoft OS/2 1.21 will fail on many systems with the following scary looking error:
Pressing Enter as directed shows the following more detailed error message:
The initial boot phase, as well as the installation stage immediately before the FDISK error is shown, takes much longer than it normally should.
Some, but not all, OEM versions of MS OS/2 1.21 are also affected. Tandon and Compaq have the same problem, but Intel MS OS/2 1.21 does not. IBM’s OS/2 1.2 SE or EE likewise does not have this trouble.
The problem is usually caused by having a CD-ROM on a secondary disk controller (IDE or otherwise). But it’s rather more complicated than that, and any device on a secondary disk controller is more likely than not going to cause problems. The failure is triggered by a subtle bug in the MS OS/2 1.21 disk driver.
In OS/2 1.2, the disk driver is no longer in a separate DISK01.SYS module but rather built into the “mega driver” BASEDD01.SYS. The previously separate drivers, CLOCK01.SYS, DISK01.SYS, KBD01.SYS, PRINT01.SYS, and SCREEN01.SYS were merged into a single BASEDD01.SYS module. This no doubt saved precious memory, although it made problem analysis and fixing a little more complicated.
BASEDD01.SYS includes a standard PC/AT disk driver, but in MS OS/2 1.21 it also includes a driver for disks on the secondary controller. The standard driver works with I/O port base 1F0h, while the secondary driver uses port base 170h. These I/O port ranges were defined by IBM for the PC/AT; the IBM fixed disk controller worked with base 1F0h by default, but could be jumpered to respond at 170h instead.
The trigger for the MS OS/2 1.21 failure is that a secondary disk controller simply exists. Specifically, if I/O port 172h can be written and read (that is, the value written to port 172h can be written and then read back unchanged), MS OS/2 1.21 will almost certainly be unable to operate the hard disk.
If that happens when booting an already installed system, this familiar and rather misleading error message will appear:
Here is an outline of what MS OS/2 1.21 tries to do:
- Check if port 172h can be written and read; if so, go ahead
- Install interrupt handler
- Check CMOS bytes 1Bh and 1Ch; if 1Bh is zero, fail
- Attempt to initialize disk controller
- If anything failed, uninstall interrupt handler again
The logic where things go wrong is installing and uninstalling the interrupt handler. To install the handler, BASEDD01.SYS reads from port 1171h. That is not a typo–it is 1171h, not 171h. As far as I can ascertain, port 1171h is associated with the Compaq 32-Bit Intelligent Drive Array Controller, or IDA.
On typical systems, there is no port 1171h. Depending on the chipset, the I/O port address may be decoded as 171h or 1171h. In any case, BASEDD01.SYS uses port 1171h to determine the IRQ level.
On a typical PC/AT compatible, it will decide that the IRQ level is 14 (which is the same as the primary disk controller!) and install a handler for it. It also sets an internal variable, let’s call it DSK2_IRQ, to 14. This variable is used by the interrupt handler and passed to DevHlp_EOI (OS/2 device helper API) to clear the interrupt.
The CMOS byte 1Bh is quite possibly zero and the driver initialization will fail there. If not, it will very likely fail in the next step.
When things fail, BASEDD01.SYS sets DSK2_IRQ to zero and uses that value to call DevHlp_UnSetIRQ to uninstall the interrupt handler.
Readers have no doubt noted that the driver installed an interrupt handler for IRQ 14 and uninstalled a handler for IRQ 0, which was never installed! That is one part of the problem.
The other part of the problem is the interrupt controller that’s left behind. When the primary disk controller is used, it will trigger IRQ 14, yet the wrong interrupt handler is executed. But it’s worse than that. The first time the wrong interrupt controller is called, it will use DevHlp_EOI to clear IRQ 0 instead of IRQ 14. OS/2 will send an EOI to the master interrupt controller (PIC), but not to the slave PIC.
As a consequence, the slave PIC will think that IRQ 14 was never handled and the next IRQ 14 will be blocked at the interrupt controller level; the CPU will never see it.
After this unfortunate series of events, disk interrupts are completely out of action and the primary disk driver cannot function. After a few retries and timeouts, the driver gives up.
Interrupt Setup
After locating the Compaq IDA Technical Reference (not an easy feat), it turned out that I/O port 1171h is in fact the IDA Interrupt Configuration Register.
The fundamental flaw in the MS OS/2 1.21 disk driver is that it sets up an interrupt service before verifying that a controller with drives is in fact present. Once port 172h responds, the driver will set up an interrupt handler. And for reasons that are not at all clear, it defaults to using IRQ 14, which is the same as the primary disk controller.
After things go sideways, the driver incorrectly uninstalls the interrupt handler and destroys the IRQ value for which the driver was installed.
How Was This Missed?
The driver presumably worked on machines with an actual Compaq IDA controller on the secondary I/O address range. The driver also clearly works on systems with only the primary disk controller present.
The question is what happened on systems that had a secondary disk controller present, but not of the Compaq IDA kind. And the answer is that I’m not sure.
Such systems were probably not widespread, but they did exist. How well MS OS/2 1.21 was tested on such machines is questionable. It is also likely that the support for Compaq IDA was added relatively shortly before MS OS/2 1.21 was released and therefore not necessarily very widely tested at all.
It is almost certain that on an ISA system (not EISA as anything with the Compaq IDA would be, and certainly not PCI which didn’t exist yet), accessing port 1171h in fact accessed port 171h, which is the disk controller Features/Error Register. However, this register is written as Features register and read as Error register, which means that a value written to it is highly unlikely to be read back.
On such a system, the BASEDD01.SYS driver should default to IRQ 14 and should have the problem described above. I will also note that any strict IBM PC/AT compatible will fail the BASEDD01.SYS CMOS check because there will be no information about the 3rd/4th drive stored in CMOS bytes 1Bh/1Ch.
I strongly suspect that PC/AT compatibles with a secondary controller would fail to boot MS OS/2 1.21, but it is possible that Compaq machines might succeed.
At any rate, the problem was clearly incorrect error handling in an error path that was probably poorly tested before the release, if at all. The workaround is simple, make sure there is no secondary disk controller, such as a secondary IDE channel.
Addendum
The Compaq Deskpro 386/25 Technical Reference Guide (TRG) from 1988 reveals additional information. The Deskpro 386/25 may have been the first PC/AT compatible system with at least some BIOS support for a secondary disk controller. Two additional hard disks could be installed in an expansion unit (designed explicitly for ESDI drives) and used from DOS through an additional driver called EXTDISK.SYS.
The TRG documents CMOS locations 1Bh/1Ch as holding the additional drive types. It also notes that the secondary disk controller can use IRQ 14 (same as the primary!), and if it does, the driver software takes care to ensure that only one controller at a time has interrupts enabled.
The TRG also says: The hardware interrupt for the fixed disk drive controller shipped with an expansion unit can be selected with a switch located on the adapter. In addition, the interrupt can be changed via software through an I/O port. The configuration register is documented to be located at I/O port 11F1h; however, it is entirely possible that it was located at 11X1h where X was Fh for the primary and 7h for the secondary I/O address.
In light of the above, it is likely that the Compaq IDA was in fact designed to be backward compatible with the Deskpro 386/25, and the MS OS/2 1.21 BASEDD01.SYS driver was likely written to support the Deskpro 386/25. That however does not change the fact that as it was written, the driver was essentially guaranteed to fail on non-Compaq systems with a secondary disk controller.
It may however explain one thing–any machines with 3rd/4th hard disk tested by Microsoft with OS/2 1.21 would have likely been Compaq systems, and the trouble the driver caused on non-Compaq machines would have been missed.
NetWare Addendum
Some further information can be gleaned from Novell’s documentation. Needless to say, in the late 1980s, NetWare was probably the most likely user of as many hard disks as could be physically attached to a PC.
The NetWare 3.0 (1989) documentation explicitly states that the ISADISK.DSK driver supports a secondary controller. However, it also notes that “Currently, COMPAQ is the only known vendor that supports a secondary controller and drive(s).”
There are several Novell FYI articles stating the same thing: Secondary disk controller (at I/O base 170h) are only supported on Compaq machines because only Compaq machines can set up a 3rd or 4th drive.
For ESDI drives, Novell was apparently unaware that the IDENTIFY DRIVE command could be used on Compaq machines. That is somewhat ironic because as far as I can tell, the Compaq expansion unit that could hold two additional hard disks was designed for ESDI drives only. For MFM or RLL drives, there was of course no such option at all.
At any rate, NetWare needed to somehow discover the drive geometry, and it used the standard ROM drive tables. Therefore the CMOS bytes 1Bh/1Ch (a Compaq invention) had to be set, allowing NetWare to look up the drive parameters in the ROM drive table. This was in fact the same problem MS OS/2 1.21 tried to solve in exactly the same way, by looking at the CMOS.
Later, in the early 1990s, Novell came up with not just one but several alternative methods of discovering drives and drive parameters. For IDE drives, the driver used the IDENTIFY DRIVE command to obtain the geometry information. There were IDE drivers available for both NetWare 2.x and 3.x (IDE.DSK driver).
Another solution devised by Novell were “NetWare Ready” (NR) or CCM (Common Configuration Method) drives. These drives had a special sector set aside to hold drive information. This was sector 30 for NR and sector 2 for CCM drives, in each case on the first cylinder and first head. This method sidestepped the requirement for BIOS support, and would have been usable in non-Compaq machines or with drive types not supported by the BIOS.
This later caused trouble when NetWare disk drivers could determine drive information in a number of possibly conflicting ways (BIOS, CCM/NR, IDENTIFY DRIVE).
It is also notable that circa 1990, Novell supported at most two AT style disk controllers. The January 1992 version of IDE.DSK already supported up to four IDE channels. Compaq may have been the only OEM with at least some level of support for a secondary AT style disk controller usable with pre-IDE drives.
An e-mail from Blair Merrell at Novell to the ATAPI mailing list in December 1994 explains where the additional IDE channels came from:
Date: Mon, 19 Dec 1994 07:44:07 -0700
From: Blair Merrell <[email protected]>
To: [email protected]
Subject: Appendix-F, I/O Ports etc -Reply
Gentlemen:
Novell's decision to support ports 1F0-1F7, 170-177, 1E8-1EF, 168-16F,
and interrupts E,B,F,C,A came at a time when the secondary port was
barely supported by a few companies and the 3rd and 4th ports were
not even imagined. Plug and play wasn't even a gleem in its father's
eye. We negotiated with a board manufacture to build a board that
would support four ports, and these are the addresses that we mutually
selected. The ports and interrupts, by the way, can be mixed and
matched in any order by jumper selection on the boards and by
command line option in the driver. The terms 'primary', 'secondary', etc.
don't have any real meaning in NetWare.
It thus appears that Novell defined the so-called tertiary and quaternary IDE channels circa 1991. Further evidence may be found in this document from 1991.
Interesting!
What other OS:es, or third party drivers for OS:es, did support a secondary hard disk controller at the time?
Asking because I’ve always found it curious that it’s possible to set the controller to primary/secondary (and IIRC the same goes for the floppy part) but I’ve never even seen any way to use it with things that were available in the 1980’s, until this blog post (which shows at least an attempt at making it usable, although it didn’t work).
In particular the ways to use a secondary hard disk controller I know of is to either use a way newer motherboard, like a 486 or possibly late 386 with BIOS support for both controllers, or use a 1990’s or newer OS like Linux, Windows NT or whatnot, that lets you use both controllers even if BIOS ignores the secondary controller.
Were there drivers/software similar to the “large disk support” drivers, but for using two controllers?
Bonus annoying thing 1: I vaguely remember that an RLL hard disk controller I had back in the days still relied on the mothreboard BIOS for certain things even though it had it’s own BIOS, and thus couldn’t be set as secondary controller with a motherboard BIOS that only supports one controller.
Bonus annoying thing 2: My impression from back in the days was also that some non-MFM/IDE controllers used the same port range and/or something else that would collide, and if you got a hold of used hardware without the instruction manual you were stuck unable to reconfigure it to not conflict. That meant that in practice you had to put say a SCSI controller in one computer and an MFM/IDE controller in another computer, and transfer your files using Laplink or similar. (This was back in the days before the internet, before home networking and at a time “no one” knew of any manufacturer BBS:es or so here in Europe, and many didn’t even have a modem anyways).
Bonus annoying thing 3: I actually think it’s genuinely crap+++ of Microsoft and IBM to create MS/PC-DOS and the IBM AT and not include a driver that would allow you to use the secondary floppy controller. This is especially bad since IBM themselves created the need for three disk drives for a PC to be compatible with all disks (360k, 1.2M, 1.44M)
I think widespread BIOS support for secondary disk controllers only came circa 1994-1995, when motherboards with two IDE channels became common.
That does raise the question what the secondary address setting on the PC/AT disk controller was good for, since the AT BIOS had no idea what to do with it.
In the early AT days, I cannot imagine that it would have been physically possible to stuff three hard disks into the case. Too big, almost certainly not enough power. The Compaq Deskpro 386 Tech Ref (1986) documents the address jumper for the ESDI controller, and says: “This [secondary] address selection is available only for special circumstances and under normal circumstances should never be changed.” It clearly was not supported for normal operation.
The Compaq Deskpro 386/25 Tech Ref (1988) is the oldest I can find which clearly talks about some support for a secondary disk controller. It documents CMOS bytes 1Bh/1Ch for 3rd/4th hard disk drive type. It also mentions an EXTDISK.SYS driver that was apparently needed to use the secondary disk controller.
I don’t know about your controller, but: My WD1007 and WD1007V controllers do have a BIOS, but it can only be used to format a drive. It has no support for INT 13h. The motherboard BIOS must supply the actual disk driver.
Are you sure there was not a DOS driver to use a secondary floppy controller?
Probably this is of some use:
At this address are the Compaq Deskpro 386 Speficications: https://ardent-tool.com/media/PS2_MOST/ACROREAD/TSSFACT/TFSPC/COMPAQ/2005008.PDF
In Controller Boards has:
Description Assembly
Description: ESDI 300/600 External Bd. Assembly: 0001091: OEM Part: 115839-001 IBM Part: 93F8114
I think that is what Michal is talking about in the addendum.
It look that the same adapter is supported in Compaq Portable 386. Check the information (especially Chapter 10: Mass Storage Configuration) of this document: https://minuszerodegrees.net/manuals/Compaq/Compaq%20Portable%20386%20-%20Maintenance%20and%20Service%20Guide.pdf
P.S. It appears that support DOS and NetWare.
That IBM Part No. intrigues me, but couldn’t find anything.
Also:
COMPAQ DESKPRO 386 Personal Computer MAINTENANCE AND SERVICE GUIDE at this link: http://typewritten.org/Articles/Compaq/108033-003.pdf
Has “1.17 300-/600-MEGABYTE FIXED DISK DRIVE EXPANSION UNIT”
I think that if working mirroring disks explains why it uses the the IRQ 14.
Intel OEM MS OS/2… now there’s a release I’ve never heard of before. What drivers did it come with? (For example, Compaq’s OEM release came with a PM display driver for their 640×400 plasma display in the Compaq Portable III, which was similar to Olivetti but not identical, and not identical enough Compaq’s driver won’t work on an Olivetti implementation in an emulator.)
We had a machine (a PS/2 Model 25, an 8086-based machine that had two 8-bit ISA slotes in it) that had both two MFM controllers in it. The built in BIOS seemed to drive the MFM just fine. We needed more storage and got an RLL controller, complete with an external enclosure with the ribbon cables snaked into it. It worked, but it took a long time to boot. I’m guessing the secondary’s BIOS ended up “taking over” the primary controller from the system’s BIOS. The first MFM drive used the built-in BIOS; the add-on card had its own BIOS and somehow was able to find it was on the “secondary” range.
I have never spotted a PC/AT or similar with two original disk controllers in the “wild”. The BIOS certainly didn’t support this, and I’m not sure of any contemporary operating systems or DOS disk drivers that did, although it seems like a pretty trivial change to the BIOS to support it.
It was not completely uncommon to have a second hard disk controller. Most likely, the second controller would be a non-booting SCSI for use with an optical drive. Microsolutions Compaticard had all the required support to be a second floppy controller and a driver to match. I am not sure how 9 track tape controllers fit into the whole assemblage; whatever it was, it had to be fast at 9 mbps. I know 9 track did not have OS/2 drivers forcing a reboot to DOS every time a new tape arrived for updating the database.
IIRC, the Compaticard IV could work under OS/2 but only as the primary floppy controller. I know some SCSI cards would work as a secondary controller under OS/2 but I think those drivers started appearing around the time of OS/2 2.0.
The article says:
“The error occurs after the initial boot stage as well as the stage immediately before the error takes much longer than it normally should.”
Probably an editing error, even though that’s *technically* still a grammatically valid sentence? 🙂
Yeah, I’m trying to think of any contemporary PC/AT machines that had multiple (ST-506) disk controllers. There’s no reason the BIOS couldn’t have supported it, but it just plain didn’t. There’s certainly no standard way to store, for example, the drive types of the drives on the second controller in the CMOS. (As far as I know, the PS/2 didn’t either, although for some drive controllers like the Model 50’s MFM controller, it only supported a single 20MB drive size anyway.)
Somewhat related… standard ST-506 should have allowed 4 drives on a controller, but IBM neutered this for whatever reason and did the “cable twist” on the controller cable instead of using the drive select jumpers on each drive. Realistically, anyone who wanted to spend that much on drives wasn’t fooling around with bare MFM and invested in SCSi instead.
My first message didn’t appear or I forgot to press Post Comment, it was like this:
The Compaq Deskpro 386 Specifications list in Controller boards what I believe is what Michal is talking in the Addendum:
Description: ESDI 300/600 External Bd., Assembly: 0001091, OEM Part: 115839-001, IBM Part: 93F8114.
The IBM part intrigues me but couldn’t find anything with that part number.
The “ESDI External 300/600-Megabyte Fixed Disk Drive Controller Board ” is also supported in the Compaq Portable 386 and in the “Compaq Portable 386 Personal Computer Maintenance and Service Guide” in “Mass Storage Controllers” says that it could work with DOS and with NetWare, it could be configured with “Maximum Storage” 1.2 Gb, 4 300Mb disks, or Mirroring, it has some interesting diagrams there.
A the time IBM designed the AT, they might had intended to also create a future expansion chassis like the one for the PC/XT, but with 16-bit ISA and obviously using the AT rather than PC/XT case.
That would had made two controllers, both for hard disks and floppy disks, reasonable back in 1984. Two hard disks and one floppy in each enclosure would fill the enclosures assuming full height hard disks and half height floppies.
I have at least never head of any driver for using the secondary floppy controller in DOS.
Re backup/tape: At least some used interfaces only intended for streamers. Not sure if you refer to the large open reel backups or DC300/600/6150/6250 style tapes for nine track, but at least the latter were available either using SCSI or a dedicated interface that I think was called QIC-02.
Re going for SCSI for larger disks: That would had been true at some point in time when SCSI on PC had become a thing, and also when the computer in question was still in use at a business or similar. Right when the AT was new in 1984, and also when those computers ended up at hobbyists, it would had been reasonable to have more than two MFM drives. (I used two full height 5.25″ drives back int he days, one internal to the computer and one hanging off behind the computer…).
How much of the impetus for secondary IDE was for ATAPI CD-ROM drives, as Windows 3.1 32-bit disk access and MSCDEX don’t like to share control over the primary IDE controller?
I would say “huge”. Even apart from any trouble with IDE channel sharing, enough people had two hard disks and wanted a CD-ROM drive.
There is another factor, which is that stuffing 3-4 full height 5.25″ hard disks into an AT case was physically impossible. Stuffing 3-4 3.5″ hard disks 1″ tall into a tower case was not a problem.
Definitely an editing error, thanks. Not sure how I missed that when re-reading…
The circa 1988 Compaq machines are the oldest ones I’m aware of that had some kind of BIOS support for more than 2 hard disks. If I understood their Tech Ref correctly, the EXTDISK.SYS driver extended the INT 13h service to support (BIOS) drives 82h and possibly 83h. Maybe some newer systems had the BIOS support built in, that wasn’t entirely clear to me. Compaq definitely set aside CMOS locations 1Bh/1Ch for the 3rd/4th drive type.
At a guess IBM didn’t bother supporting 4 ST-506 drives on a single controller because it was not physically possible to install them into a PC/AT.
Totally agree about SCSI — the thing is that ST-506 drives were always very limited in terms of capacity because they were too dumb. People who needed lots of storage space were forced to buy ESDI and SCSI drives; ESDI could pack a lot more data on each track (initially 34 sectors vs 17 for MFM and 26 for RLL). SCSI could do that plus ZBR. IDE eventually caught up but that was much, much later.
Thanks for the NetWare reminder. I might have to go through my archive to see what was supported when, but NetWare may have been the first OS to support two or even three or four AT/IDE disk controllers.
So… NetWare 3.0 with ISADISK.DSK from August 1989 knows perfectly well that the secondary instance should use I/O port 170h and IRQ 15, but then it fails with “CMOS not set. Run SETUP.” Almost certainly looking for the Compaq style CMOS drive settings.
NetWare 2.0a from 1986 does not support secondary AT disk controllers, there’s only code to work with I/O base 1F0h, nothing touching 170h. The NetWare 2.0a documentation does not say anything on this topic at all — it seems to be written with the assumption that only one AT style disk controller configured to use the primary port range exists. For additional drives, NetWare had their own disk controllers and expansion chassis.
I wonder if the Compaq EXTDISK.SYS is locked to only work with Compaq hardware, or would work with any computer if you could store drive type in the cmos memory?
Nowadays we can always use XTIDE Universal BIOS (either as an option ROM or worst case load from disk), so it’s only of academical interest, but still.
A secondary controller for a CD-ROM didn’t need to interact with the BIOS at all, and before those were popular, they tended to use proprietary controllers (most of which were a “poor man’s SCSI” or a “poor man’s ATA” and providing essentially a packet interface to the drive, and often didn’t bother with interrupts, let alone DMA).
One of the dumber things about MFM/RLL which carried over to early IDE was the drive type byte… I’ve never fully understood why this couldn’t have been buried somewhere in sector 0 instead and established when a drive is formatted. As I recall, a few XT era controllers did this and burned up a whole cylinder to store this information. IBM really liked fixed geometry – they did it again with the PS/2 Mod. 50, because “why would anyone want an MFM drive bigger than 20MB?”
Guess what… other people had the same idea: https://www.t10.org/ftp/x3t9.2/document.91/91-101r0.pdf
Unfortunately I think it came far too late, when IDE more or less took care of the problem.
It amazes me how many people think you can’t put in an ATAPI device or a secondary IDE controller into something like a 286/386 because its “too old” or “lacks BIOS support”. I’ve fitted many an optical drive into such a machine as a slave device on the primary controller, or installed a secondary controller with no issues.
Hard drives are clearly an issue under DOS (they’d need a driver), but most of the cards came with an option ROM that added Int 13h support for the secondary channel along with much needed drive translation support.
Chris M.: I’ve had more than one dispute trying to explain that BIOSes need not know or care about ATAPI CD-ROMs until it was time for El Torito boot support, and that the correct BIOS setting for an IDE CD-ROM on a typical 486 is “not installed.”
>I have at least never head of any driver for using the secondary floppy controller in DOS.
There was more than one: 4floppy.bin, dc2.sys, etc
>How much of the impetus for secondary IDE was for ATAPI CD-ROM drives, as Windows 3.1 32-bit disk access and MSCDEX don’t like to share control over the primary IDE controller?
Using IDE cdrom drive under Win3.x 32-bit disk access on the primary IDE controller was tricky but possible. You had to tell dos cdrom driver to use PIO mode and switch to polling instead of using IRQ14.
@Josh Rodd:
At the risk of being nit picky or philosophical, I would argue that “secondary controller” isn’t appropriate to describe those non-IDE/ATA and non-SCSI CD-ROM controllers. They clearly aren’t hard disk controllers, and thus they are their own category, and since almost all computers have both a floppy controller and a hard disk controller, the CD-ROM controller would either be tertiary if you count any controller time, or primary if you count all controllers of the type “proprietary CD-ROM-controller”.
Then there is the possible issue of one of those CD-ROM-controllers maybe using the same I/O ports as a secondary MFM/IDE controller, but that could happen with any configurable card.
@Chris M:
There were lots of cards with add-on bios to use the secondary controller in computers that lacked BIOS support. But those tended to be cards intended for upgrading older computers, and they usually also added support for larger disks on computers lacking such support. However I’m fairly sure that the amount of such cards sold were way way fewer than the multi-I/O cards with two IDE, one floppy, two serial, one parallel and for some weird reason also usually a floppy controller. Those cards were in many 486 and late 386 class computers, and also many who had an older computer bought those cards when they upgraded to IDE. Another reason for buying one of those cards would had been dial-up internet becoming a thing and thus wanting 16550 compatible serial ports. Those multi-I/O cards had almost the same cost as a card with just two serial ports IIRC.
@Vlad Gnatov:
Interesting! If I ever end up being able to have a secondary floppy controller in a PC in the future I shall try one of those drivers.
Re ATAPI CD-ROM sharing the same interface as a hard disk:
I think this is 100% a clear example of how Microsoft were (and to some extent still are) so stubborn in whatever weird decisions they make on what they think is something they should support and what they should leave to others. I think they made a big mistake in not making their own ATAPI drivers both for DOS and for Win 3.x, and later Win 9x/ME. It got really stupid with the boot disks that Win9x could generate, that loaded 10-20 different ATAPI drivers that all used different vendors drives as dongles for the drivers. Compaq stepped in and created the CPQIDECD.SYS driver that works with all ATAPI devices. I can strongly recommend using that on any boot disks, unless you need support for some special feature (not sure if it supports multi session for example?).
Also it was bad that they didn’t really support drives >528M without third party drivers for 32-bit disk access (IDE/MFM 32-bit driver) in Windows 3.1x, and even worse is that the 32-bit file access (32-bit FAT implementation) also afaik struggles to run with larger disks even if you don’t use the 32-bit code for the disk controller.
In hindsight one of the best things with the move over to the NT based Windows series is that that more or less forced Microsoft to actually do their job in the form of making an ATAPI driver themselves.
Yeah, the proprietary CD-ROM controllers (or the “neutered” SCSI cards like you often came with scanners; one came with a UMAX scanner that was an NCR/Symbios Logic design… except the IRQ function was disabled. I guess it would send a request and then just poll) really count as an entirely separate kind of controller… but then again so would a secondary IDE/ATA port used entirely for a CD-ROM. The whole point was that the Int 13h BIOS wouldn’t be controlling it.
Windows 3.1 worked well with the contemporary controllers of its day, and hard drives in excess of 504MB/528MB weren’t very common in 1994. Same goes for controllers other than ST-506 type of controllers (from memory, the PS/2 ESDI controller worked with 32-bit disk access, but the PS/2 SCSI controller didn’t). (A handful of SCSI card vendors, etc. released 32-bit disk access drivers. These tended to be even buggier than the built in *WDCTRL. There were also a few vendors who released an EIDE32.EXE etc. type of driver that would let 32-bit disk access go past 528MB.)
There wasn’t any kind of coherent standard for LBA translation in that era, so it wasn’t really reasonable to expect Windows 3.1 to be able to support that, other than through vendor-specific drivers. Windows 95 was the solution to this, including a far more layered I/O subsystem some reminiscent of MS OS/2 1.2. The Windows 3.1 driver model was far too simple to even try to implement something like “32-bit CD-ROM access”. And people who ran Windows 3.1 wanted to exit to DOS to run applications and games anyway.
Fixing this from the ground up would have required a BIOS architecture with layers for the storage adapter card (SCSI, ATA, whatever), and then drivers for specific kinds of storage devices. IBM’s ABIOS actually implemented this. I can’t think of anything that used it other than IBM2ADSK.ADD and NT’s ABIOSDSK.SYS. But ABIOS meant rather heavy ROMs (128K for the base) and often an adapter card ROM as well.
The early ABIOS was also notoriously buggy. OS/2 tended to come with “updates” to the ABIOS to make it function better or fix nasty bugs (often data-corrupting ones), as did updates to reference disks.
But in retrospect, delivering ABIOS with the PC/AT would have been a better path, but I’m not sure at the time of the release of the PC/AT people had even really thought about the need for things like “bimodal code”. ABIOS was a reaction to the many problems of trying to write protected mode OSes for the PC/AT with its PC-compatible BIOS.
Ultimately, these problems were addressed again with EFI… but that didn’t take form until the mid-2000s, 18 years after the release of ABIOS.
A “fun” project would be to write an ABIOS for the PC/AT (you could probably crib most of the original PS/2 Model 50 implementation). I’m surprised OS/2 1.x wasn’t just implemented this way with an ABIOS shim instead of making a completely separate set of AT and MCA drivers, the latter of which often used ABIOS. The amount of driver code in OS/2 1.x and 2.x was breathtaking to behold.
Re “Neutered” SCSI cards: I remember that the Mediavision PAS-16 sound card could actually use disks with it’s SCSI interface using it’s default Windows 95 drivers. However the disks would then just have the FAT file system directly without a partition table IIRC. Really weird.
I admit that I don’t know anything about the API that MSCDEX uses to talk to vendor supplied drivers for CD-ROM hardware, but I can’t see why the Windows 3.1x 32-bit disk access IDE driver couldn’t also provide that type of interface to MSCDEX if it detects an ATAPI CD-ROM. Sure, ATAPI wasn’t a thing when Windows 3.1 was released, but I think that it would had been a good idea if Microsoft had released both a DOS ATAPI driver and an ATAPI update for Windows 3.1x. Also no matter if ATAPI existed or not, Windows 3.11 could had had a “viso9660.386” similar to the “vfat.386” that would be a 32-bit file system driver, but for iso9660 CD-ROM rather than FAT16. Also like how the 32-bit file access and 32-bit disk access has a straight 32-bit path between each other, my proposed contra factual 32-bit CD filesystem driver would also have a direct 32-bit path into the 32-bit disk access driver.
Re LBA and whatnot: I would think that the upgrade path would had involved larger disks for older systems that wouldn’t run Windows 95, but would run Windows 3.11. Also re LBA: It would had been great if Microsoft had set down the foot and forced all hard disk makers all PC vendors to agree on one way to do address translation.
Either way, it seems like Microsoft kind of solved auto detecting LBA translation somehow in FDISK in DOS 6? Or what does it do when it does some tests at startup? My impression is that it tests how the translation works, but maybe it just checks if the translation seems to be broken, but not how it works?
Either way, Microsoft could had supported having a regular DOS FAT16 partition that is max 528M, and added a new partition type that would also just be regular DOS FAT16 but intended to not be detected by DOS directly, but only by Windows 3.11 using both 32-bit disk and 32-bit file access.
Thinking about it, it would actually had made sense if Microsoft would had made Windows 3.1x so that it would be possible to just run the kernel and a DOS window (or multiple DOS windows) without starting the Windows GUI, in order to get rid of the need for say SMARTDRV in DOS and the 32-bit file access driver in Windows and so on.
Side track: I really wish that Microsoft would release parts of the source code for Windows for Workgroups 3.11. In particular the kernel parts and whatnot. Would be cool to retroactive implement things that didn’t exist back in the day, but could had existed.
But, even without source code or reverse engineering, there must had been a way to create your own 32-bit disk access drivers as like you wrote third party vendors did that. I don’t know how hard it would be to add a 16-bit real mode API thing to a .386/vxd driver in Windows 3.1x, but that would had been a way to let MSCDEX talk to ATAPI drives (on the same or a separate IDE/ATA channel).
Also since we nowadays have XTIDE Universal Bios as a “standard” way to handle more interfaces and larger disks, any retroactive 32-bit disk access driver for Windows 3.1x could just be made in a way that is compatible with XTIDE Universal BIOS and then just tough luck for anyone using anything else.
Also: Although it’s possible to load XTIDE Universal BIOS as a boot sector thing from floppy, it would be great to have it at least ported to exist as it’s own small partition on a hard disk, and/or possible a driver that can be loaded by config.sys (would perhaps be a bit hard to handle the boot disk though?).
I’m sorry to say that you’re showing your ignorance here, of both the technology and the history.
ATAPI simply was not a thing in the days of Windows 3.1. The CD-ROM drives on the market at the time used either SCSI or one of the several proprietary CD-ROM interfaces.
By the time ATAPI did become a thing (perhaps late 1994, but more like 1995), Microsoft was all about Chicago, Chicago, Chicago, eventually known as Windows 95. They simply were not going to put a big effort into enhancing Windows 3.1 (or 3.11 or anything 3.x).
Technically, ATAPI is very very different from IDE. Sure ATAPI support could have been added to the 32-bit disk access driver, but it’s more like another, almost completely different driver.
The vendor driver for MSCDEX was of course real mode code, so interfacing to it from protected mode would have been kind of pointless. Also compared to hard disks, CD-ROMs were not at all fast. It is highly questionable that after putting a lot of effort into a fully 32-bit CD-ROM driver stack, there would have been any noticeable difference. For Windows 9x the equation was different, because Microsoft tried to have a full 32-bit driver stack (and on typical systems they did).
10-20 different ATAPI drivers? Are you sure that’s not an exaggeration? Or do you have an actual example? Yes, there were ridiculously many OEM ATAPI CD-ROM drivers, but I’m not sure how that was Microsoft’s fault.
You are also forgetting that early ATAPI CD-ROM drives were not always compatible with the published ATAPI standard, and did not necessarily work with generic drivers. I am not sure exactly how much insight Microsoft had into these details.
Re ATAPI and DOS, again you’re completely ignoring the actual timeline. By the time ATAPI became a force to be reckoned with, MS-DOS was dead. Version 6.22 came out at the same time as the ATAPI 1.2 specification. What problem would Microsoft have solved by publishing some kind of add-on ATAPI DOS drivers, when OEMs already supplied their own? Having end users calling their drive vendor for support rather than Microsoft was a “problem” that I’m sure Microsoft didn’t want to “solve”.
>10-20 different ATAPI drivers? Are you sure that’s not an exaggeration? Or do you have an actual example?
Here is my reference collection of dos ATAPI cdrom drivers, up to 1997:
tar tf cddrvref.zip|tr ‘\n’ ‘ ‘
alpschgr.sys aoatapi.sys asus-cdd.sys atapi_cd.sys azi-cdd.sys btc-cdd.sys ch_ide.sys cpqidecd.sys d011v200.sys ecsc-cdd.sys gscdrom.sys hit-ide.sys ibmtpcd.sys iiide.sys ltnide.sys mtmcdai.sys nec_ide.sys oak-cdd.sys osp-cdd.sys sht-cdd.sys sjcdapi.sys sonatapi.sys sscdrom.sys taisatap.sys tatungcd.sys tb-ide.sys teac_cdi.sys torisan.sys toscdrom.sys tosh-cdd.sys
>You are also forgetting that early ATAPI CD-ROM drives were not always compatible with the published ATAPI standard, and did not necessarily work with generic drivers. I am not sure exactly how much insight Microsoft had into these details.
This and also ATAPI standard was vague enough and vendors were cheap enough to cut too many corners in the hardware and try to fix it in the driver. Like some cdrom devices can only use DMA single transfer mode or the default speed was locked to 2x on init and needed to be set explicitly or for some particularly slow device ata io wait was not 400ns max but 900 and I don’t even want to start about bus-mastering…
So it’s understandable that MS stayed clear of this mess… until Win95.
Sorry, I was not questioning that there were countless OEM ATAPI CD-DROM drivers, there certainly were! I was questioning whether Microsoft actually distributed a large number of them. The claim was: “It got really stupid with the boot disks that Win9x could generate, that loaded 10-20 different ATAPI drivers that all used different vendors drives as dongles for the drivers.”
All I know for sure is that on bootable Windows 98 SE CD-ROMs, there was one generic OAKCDROM.SYS driver.
>I was questioning whether Microsoft actually distributed a large number of them.
Ah sorry, I misunderstood then.
>The claim was: “It got really stupid with the boot disks that Win9x could generate, that loaded 10-20 different ATAPI drivers that all used different vendors drives as dongles for the drivers.”
It’s easy to check. I’ve grepped Win98SE cabs for /cd-rom|cdrom/i -“This program cannot be run in DOS mode” and excluded some obvious false positives like *.dll, *.vxd, *.txt.
The result is:
aspicd.sys – Adaptec SCSI cd-rom driver (needs one or more aspi*dos.sys helper drivers)
btcdrom.sys – Buslogic SCSI cd-rom driver (may need some helper drivers)
oakcdrom – generic ATAPI driver
>Windows 3.11 could had had a “viso9660.386” similar to the “vfat.386” that would be a 32-bit file system driver, but for iso9660 CD-ROM rather than FAT16. Also like how the 32-bit file access and 32-bit disk access has a straight 32-bit path between each other, my proposed contra factual 32-bit CD filesystem driver would also have a direct 32-bit path into the 32-bit disk access driver.
When MS did this you got Windows 95…
>I will also note that any strict IBM PC/AT compatible will fail the BASEDD01.SYS CMOS check because there will be no information about the 3rd/4th drive stored in CMOS bytes 1Bh/1Ch.
That’s why MS in ESDI_506.PDR uses these bytes for Compaq machines only.
Yes, BTCDROM.SYS works on top of BTDOSM.SYS. It’s the BusLogic equivalent of ASPICD.SYS and one of the ASPIxxx.SYS drivers.
I bet that was because by 1995, other OEMs started using those CMOS bytes for other purposes, often completely unrelated to hard disks. See e.g. here (the document regrettably does not document the Compaq usage).
Disk drivers for MS OS/2 1.21 as well as NetWare 3.11 look at CMOS bytes 1Bh/1Ch without making any attempt to check that the system is a Compaq. Which, in the case of NetWare, makes me wonder if there may have been other OEMs using those bytes in a manner compatible with Compaq.
Even with Win9x one of the reasons CD boot was never popular is that they used floppy emulation with a limited set of DOS CD drivers.
Were there different versions of the Windows 98 boot disks? I’m sure the one I tried attempted to load 10-20 different CD-ROM drivers, and they can’t all had been non-APAPI drivers?
You all already know this, but ATAPI is just SCSI over IDE/ATA, using the same mechanism as transferring data to/from a hard disk, but with different commands.
DOS and Windows 3.x lived on for a long while. I used to work at a place that only upgraded the last computers from Windows 3.x as part of the Y2K thing, and DOS was still used in year 2000, although it was on it’s way out.
Re deviations from the ATAPI/ATA standard: What provisions does other OS:es have to allow for those non-compatible CD-ROMs? I remember an earlier post on this blog that kind of concluded that NEC made a mostly ATAPI compatible 2x CD-ROM, but otherwise it seems like all 4x and faster CD-ROMs are ATAPI unless they are SCSI (or possibly built in in some non-PC device, like say a Playstation).
In particular I can’t ever remember reading about any problems with ATAPI CD-ROMs on other OS:es like for example Linux (where it would be easy to check the source code various versions of the Kernel) and AmigaOS (where the drivers were made by third parties that were small “bedroom” operations).
Re interfacing between protected and real mode: Windows 3.11 anyway had the abilities both to use 32-bit filesystem code with a real mode 16-bit hard disk device driver, and also use a 32-bit hard disk device driver with the DOS 16-bit file system code.
Thinking about this, it would probably had been a good idea if Microsoft kind of had teamed up with Adaptec and made a 32-bit ASPI API for Windows 3.x, and also expose that to 16-bit code. That way it would had been possible to either use a 32-bit CD-ROM driver or a 16-bit ASPI CD-ROM driver, and then either use MSCDEX or a 32-bit equivalent. Also it would had been easy to use other ATAPI devices.
And sure, Microsoft didn’t bother much about Windows 3.x at the time, but still.
This seems 100% to be a business-corporate decision making process that results in worse products. Like they could had released it as a free “beta style” update with no guarantees.
>I’m sure the one I tried attempted to load 10-20 different CD-ROM drivers, and they can’t all had been non-APAPI drivers?
This is with high probability some custom “Universal” boot image from third party.
And one half of them could be ATAPI really but on different ATA type controllers…
>This seems 100% to be a business-corporate decision making process
Of course. Businessmen sell products, not technologies. And they sold Windows 3.x for the first time and Windows 9x for the second.
I’m not entirely sure if Microsoft delivered bootable Win9x CD-ROMs. OEMs definitely did. And obviously OEMs could modify the boot process however they liked. So yes, there were different versions.
The question was not “can Windows 3.x interface 16-bit and 32-bit code”. Of course it can, and it does that all the time. The question was, does it actually make any technical sense for CD-ROMs. And I highly doubt that. You’re proposing to write a bunch of new 32-bit code, but you can’t actually get rid of any of the existing 16-bit code, so there has to be a really good reason to do it.
Once Windows 95 was nearing release (call it mid to late 1994), Microsoft was no longer interested in Windows 3.1 and even less interested in DOS. That’s completely normal.
MS did but not all of them were even bootable.
@SweetLow:
Sure, there could had been all sorts of 3l1t3 manipulated Win9x images floating around back in the days, but without any signs of some “3l1t3 scene” dude adding readme files with “cool character set usage”, I doubt that what I had was manipulated in any way. And I strongly remember more than a screen page full of CD-rom drivers attempting to load and failing until finally one of them worked, and that would be one with the same brand as the CD-ROM the computer had.
In theory most of them might had been non-ATAPI (and non-SCSI) ones, but i doubt that.
@Michal:
The primary reasons for having the driver talking ATAPI to a CD-ROM as 32-bit code would be to have it be part of the same driver that also talks to regular IDE/ATA hard disks, solving the issue of shared interfaces and whatnot. For the file system code, the primary reason would be to share the mechanism for cache that the 32-bit FAT implementation uses, but I would think that there would be a performance win when applications (including the regular file manager) reads directories over and over again when the user looks around to see what a disk contains, and/or applications reads many small files or whatnot.
Another reason MS may have steered clear of backporting FastDisk ATAPI support to Windows 3.1 is that it’s the same part of the code that’s affected by the 1024/16/63 limit, which they had already chosen to leave to third-party vendors to fulfill.
The thing is… the best solution was having the CD-ROM on a secondary IDE channel and then there was nothing to share.
You’re basically saying that Microsoft should have brought the entire IOS to Windows 3.x at a time when Windows 3.x was very much on its way out. Yeah, that was never gonna happen.
FDISK on DOS 6.22 works fine on larger drives because it uses DOS which then uses Int 13h to do C/H/S to LBA translation. It’s not LBA aware at all, and so it can’t use drives over 8.4GB (which cost around $3,900 in 1994), and FAT16 can’t make volumes over 2GB anyway. “DOS 7.1”, or more accurately the IO.SYS that came with Windows 95 OEM Service Release 2, did support LBA as did its FDISK.
A major problem with writing 32-bit drivers on Windows 3.1 was that they were typically written in assembler and were difficult to write. A driver like *WDCTRL would not only need to talk to the actual hardware, but would also need to intercept Int 13h/25h/26h calls (since DOS is still the one running the filesystem) and basically implement a “virtual device” BIOS. The same goes for VFAT.386, which had to intercept Int 21h calls and provide effectively a virtual DOS. Unlike drivers on modern OSes, these drivers also needed to be able to unload themselves so someone could quit and go back to DOS. Oh, and it also had to negotiate with SMARTDRV (which also hooked Int 13h or Int 25h/26h, I can’t quite remember which right now).
Nonetheless, WFW3.11 would have full 32-bit disk access and full 32-bit file access on a typical system of the day (and could use OEM drivers that replaced *WDCTRL).
DOS actually did have a layer I/O subsystem if that’s what you really wanted… in the form of ASPI drivers. Y0u could load (for example) ASPI4B.SYS (to interface to the IBM PS/2 SCSI adapter) – or ASPIATAP.SYS to interface to ATA, then ASPICD.SYS, then MSCDEX. You could also load ASPIDISK.SYS, which provided a DOS block driver for additional SCSI disks (I don’t think it provided Int 13h). And then guess what? You’re out of conventional memory.
BIOS implementations of El Torito booting were quite poor in the early days, which is probably why Microsoft didn’t bother to distribute a bootable CD-ROM. OEM systems were preloads anyway. And even once Microsoft distributed a boot disk with Win 98 SE, support for anything other than 1.44M floppy images was also pretty poor. Specifically, hard disk image was hit or miss across different BIOSes. (This would bring up another pain point of mine; there was very little support for SCSI booting El Torito, basically limited to a few enterprise machines where the SCSI interface was built in so the BIOS could support that out of the box.)
Pingback: Compaq EXTDISK.SYS | OS/2 Museum