More than Two Hard Disks in DOS

Investigating the rather odd behavior of the Microsoft OS/2 1.21 disk driver led me to Compaq and their EXTDISK.SYS driver. While experimenting with various setups, I realized that DOS versions older than 5.0 do not support more than two hard disks exposed by the system’s BIOS, and will in fact quite likely hang early during boot-up if there are “too many” hard disks.

This seems to have been one of the many things that “everyone knew” back in the day, similar to the fact that DOS versions older than 3.3 may hang while booting from disks with significantly more than 17 sectors per track.

As was the case with the “too many sectors per track” problem, the issue with “too many hard disks” was missed for years simply because no one had a PC with more than two hard disks. This was a technical rather than architectural limitation. While the IBM PC/XT and PC/AT BIOS implementations were limited to two hard disks, the INT 13h interface as such was not.

In the days of full-height 5¼” drives, it simply was not feasible to install more than two hard disks into a PC, especially when a 5¼” floppy drive was also required. Even the big IBM PS/2 Model 80 (1987) with a tower case could only house two full-height 5¼” drives. There might also be trouble with the power supply, as the PC hard disks of the time were not designed for staggered spin-up and a standard AT power supply might have trouble spinning up four drives at the same time.

Sure, there were half-height hard disks, but who wanted four drives in the first place? People who needed to maximize the storage capacity… and the most obvious way to do that was buying a large capacity drive, which in the 1980s was inevitably a full-height 5¼” monster. Like my 1988-model 650 MB ESDI drive, for example.

Yes, there were solutions like the NetWare DCB which supported many drives, but those were only usable by NetWare and did not expose the drives via INT 13h.

Two things happened circa 1988. One was Compaq releasing the Deskpro 386/25 with an expansion unit option, a system which supported up to four hard AT-style disks (that is, the expansion unit housed up to two ESDI drives accessible via the PC/AT hard disk style programming interface, which may be called WD1003 or WD1010 or several other things). The other development was Adaptec releasing the AHA-1540/1542 SCSI HBA, and there were perhaps other SCSI vendors as well.

Compaq supported up to four hard disks, Adaptec in theory up to seven. In any case, it is apparent that both companies ran into the same problem with DOS, and solved it in a very similar manner.

Compaq simply did not expose the drives in the expansion unit through the BIOS at all. DOS users needed the EXTDISK.SYS driver, and users of other operating systems (such as OS/2 or NetWare) needed a custom driver.

Adaptec was in a more complicated situation. The AHA-154x was an add-on card which could be installed in a PC/AT compatible machine (the AHA-154x did not work in older systems because it was a bus-mastering adapter) that already had one or two AT style drives. The AHA-154x BIOS keeps the total hard disk maximum to two. In practice that means that if there are two SCSI hard disks attached to an AHA-154x (which also includes AHA-154xA and AHA-154xB, but not necessarily newer models), the Adaptec BIOS may add zero, one, or two drives to the system, depending on how many hard disks there are already installed. In any case, the total won’t be greater than two.

For DOS users, Adaptec offered a combination of ASPI4DOS.SYS (ASPI driver for the AHA-154x) plus ASPIDISK.SYS (DOS hard disk device driver). Adaptec’s ASPIDISK.SYS was functionally very similar to Compaq’s EXTDISK.SYS and allowed DOS users (especially users of DOS 4.x and older) to utilize more than two hard disks.

DOS Bug

The bug is quite visible in the MS-DOS 4.0 source code. In MSINIT.ASM (IO.SYS/IBMBIO.COM module), DOS calls INT 13h/08h and stores the number of disks in the HNUM variable. No attempt is made to validate the value returned by INT 13h.

Further down in MSINIT.ASM, DOS sets up the hard disks, calling the SETHARD routine for each drive, but it will not set up more than two. Trouble will start near the SETIT label, where the DRVMAX variable may end up with a number much higher than the number of drives that SETHARD was run on.

Eventually, disaster strikes in the $SETDPB routine in the DOS kernel. The code near LOG2LOOP label attempts to calculate the cluster shift for the FAT file system, but gets stuck in an endless loop because the BPB for a drive was never initialized and contains zeros.

This bug is present in every DOS version with hard disk support before 5.0, that is, in DOS 2.0 up to and including DOS 4. In my experiments, all these DOS versions hang when booting on a machine that exposes four BIOS drives. MS-DOS 4.01 from April 1989 still hangs, and so does Russian MS-DOS 4.01 from February 1990.

It is clear that the bug went unnoticed or at least unfixed for a number of years simply because PCs with more than two hard disks were extremely rare to nonexistent.

DOS 5.0

It is likely that DOS 4.0 (1988) was released just before PCs with multiple hard disks became a thing. By the time Microsoft started working on DOS 5.0 in earnest in 1990, EXTDISK.SYS and ASPIDISK.SYS were certainly well established, and the problem must have been known.

MS-DOS 5.00.224 Beta from June 1990 (the oldest DOS 5.0 beta I could test) does not suffer from the bug described above, and shows four hard disks exposed by the BIOS in FDISK.

Further related work was done in August 1990 with the following comment:

M011 8/07/90 CAS    msinit.asm  rewrote lots of spaghetti code
                    msbio1.asm  used for initializing hard drive
                                partitions.  fixed bugs 2141, 2204,
                                1866 and 1809 and prepared for
                                zenith/etc. support

The above is an excerpt from an MS-DOS 5.0 OAK (OEM Adaptation Kit). The first entry in the relevant file (MSBIO.TAG) is dated 7/17/90 which leaves open the question of who actually fixed the problem with more than two hard disks and when, since it must have been fixed by June 1990.

There is another rather curious data point:

The above screenshot shows that Japanese IBM DOS 4.05/V does not hang and FDISK correctly shows four hard disks. Here’s the boot screen of said DOS version:

This shows that the fix made it into at least some DOS 4.x code base. However, the system files in IBM DOS J4.05/V are dated October 1990, decidedly newer than the MS-DOS 5.00.224 Beta.

SCSI HBAs

In any case, the fix was well known to SCSI HBA vendors. Starting with the AHA-154xC, Adaptec offered an option for “BIOS Support for More Than 2 Drives (MS-DOS(R) 5.0 and above)”. When this option was disabled, the BIOS keep the total number of hard disks to no more than two, just like AHA-154xB and earlier. When enabled, the Adaptec BIOS would expose all the hard disks it would find as BIOS drives 80h, 81h, 82h, 83h, 84h, etc.

BusLogic adapters offered a more or less identical setting to solve the identical problem.

When this setting was enabled, DOS 5.0 and later no longer needed ASPIDISK.SYS or any other vendor specific driver. DOS itself could directly use the BIOS to access all hard disks in the system (limited by the number of available drive letters).

I believe clone BIOSes with support for more than two IDE hard disks generally started appearing only since 1994 or so, and assumed (not unreasonably) that the user would be installing DOS 5.0 or later. In the worst case, the BIOS could usually be set up to not detect the 3rd and/or 4th hard disk. It was the SCSI HBAs that were prepared to deal with trouble.

APAR IR86346

Completely by accident, the puzzle of the DOS fix was solved while I was looking for something totally unrelated. In an IBM announcement letter from October 1990, the following sentence jumped out at me: DOS 3.3 and 4.0 support up to two fixed disks in a system. DOS 4.0 supports up to seven fixed disks when corrective service diskette (CSD) #UR29015 is installed.

I happened to have CSD UR29015 on hand, so I looked at the included documentation. The README file states: APAR IR86346 requires DOS 4.0 to be installed with NO MORE THAN two fixed disk drives before installing corrective service. Once corrective service is installed, you can attach the additional fixed disk drives.

In the APARLIST file there’s a table which includes the following entry:

CSD      APAR      KEYWORD   COMPONENT ABSTRACT
-------  -------   --------  --------- -----
...
UR27164 IR86346 ABEND IBMBIO DOS 4.0 hangs with more than 2 hardfiles
...

Yep, that’s exactly the observed problem! With more than hard disks, DOS 4.0 and older simply hangs.

There’s also a table of fix releases in the same file (excerpted):

    ...
    CSD   UR25066    05/10/89
    IFD   UR25788    06/07/89
    IFD   UR27164    09/25/89
    IFD   UR27749    10/11/89
    ...

CSD UR27164 which (was the first to include the fix for APAR IR86346) was released on September 25, 1989. The previous CSD from June 1989 did not include the fix.

The documentation does not lie and with CSD UR29015 applied, IBM DOS 4.0 has no trouble booting up and seeing four hard disks:

That clarifies the timeline a lot. MS-DOS 4.01 from April 1989 could not possibly contain the fix. IBM fixed the bug sometime in Summer 1989, which is why IBM DOS J4.05/V includes the fix. Microsoft’s Russian MS-DOS 4.01 was likely branched before mid-1989 and the fix was never applied.

And this also explains why the earliest MS-DOS 5.0 betas don’t have the problem with more than two hard disks, even though there is no record of Microsoft fixing it. Because Microsoft didn’t—IBM did, a few months before the work on MS-DOS 5.0 started.

The only minor remaining mystery is who opened APAR IR86346. It could have been an external customer, although both the Adaptec AHA-154x HBA and the Compaq Deskpro/25 were designed to protect against DOS hanging. Then again, perhaps some other SCSI HBA was not quite so careful and could trigger the hang with multiple hard disks.

It is also possible that the bug was discovered and internally reported when IBM was working on its own SCSI adapters, released in March 1990 together with the first wave of PS/2 machines with SCSI drives.