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.