The other day I had a pressing “need” to examine the behavior of Adaptec 154x and compatible SCSI HBAs and their DOS drivers. I found the hard way that the AHA-154xB does not work with Adaptec’s last DOS drivers from circa 1999. That includes the drivers still available for download (ASPI4DOS.SYS version 3.36), as well as the driver shipped with OEM versions of Windows 98SE (ASPI4DOS.SYS version 3.36S).
The error message is far from enlightening; effectively the driver acts as if there were no HBA at all.
Quite unsurprisingly, this problem has been noticed before. It has been also observed that ASPI4DOS.SYS version 3.35 works fine, as do older versions. But why is the 3.36 driver really not working with AHA-154xB?
First of all, it’s not because the AHA-154xB is not supposed to be supported. The README.TXT file in the latest driver package clearly lists Adaptec AHA-1540B/1542B as supported, together with the newer ‘C’, ‘CF’, and ‘CP’ variants. It’s obvious that Adaptec didn’t actually test the driver on an AHA-154xB board… which is not hugely surprising since the 3.36 driver is from December 1998, and the ‘B’ variant was obsoleted by the much more modern ‘C’ in February 1993. Six or so years later, Adaptec probably barely had any of the ‘B’ variants left.
Note that the even older AHA-1540A/1542A and the original AHA-1540 (with no suffix) are not listed as supported. Those models were probably never very widespread and were replaced in 1990 with a cheaper, more capable ‘B’ variant, which did sell in significant quantities.
The reason for the ASPI4DOS.SYS failure is quite interesting. The AHA-154x interface was relatively simple and well designed for the time (circa 1987), became more or less an industry standard, and therefore became the target of cloning (notably by BusLogic). In their own drivers, Adaptec wanted to distinguish its own boards from clones.
Both Adaptec and BusLogic drivers used the I/O port at offset 3 from the I/O base (e.g. port 333h for a HBA configured at I/O base 330h) as part of their clone detection logic. This register was not documented by either Adaptec and BusLogic, and therefore many drivers shipped with operating systems didn’t use it, but Adaptec’s and BusLogic’s own drivers did.
On the Adaptec AHA-154xB (and presumably older variants as well), the register actually does not exist. Reads always return FFh and writing has no effect. On the BusLogic HBAs, the register is always present, is writable by the host (but normally never written), and the high bit is set if the HBA is configured to support disks larger than 1 GB.
On the AHA-154xC, Adaptec changed the behavior and made the register return ASCII letters ‘ADAP’ in a round-robin fashion.
Needless to say, ASPI4DOS.SYS version 3.36 checks for this behavior. It does not assume a known initial state, and therefore expects that reading the register four times might return ‘ADAP’, but also ‘DAPA’ or ‘APAD’ or ‘PADA’. To work around the ambiguity, the driver reads the register four times, adds the values together, and checks if the sum equals 16h. If not, it declares the HBA ‘not an Adaptec’ and ignores it. And that is the bug—the check will fail on an AHA-1540B.
No known driver shipped with an OS reads the ‘ADAP’ signature. But for example Adaptec’s DOS-based SCSIFMT.EXE utility version 1.33 uses the signature to distinguish between the AHA-154xC and earlier variants.
ASPI4DOS.SYS version 3.36 incorrectly insists that the ‘ADAP’ signature must be present and therefore fails to work with AHA-154xB adapters. It is pretty clear why Adaptec didn’t catch the bug (the ‘B’ variant was rather old at the time), although it’s much less clear why the driver logic was changed in the first place.
It should not be difficult to patch out the ‘ADAP’ signature check from ASPI4DOS.SYS, but for an AHA-154xB one might as well use ASPI4DOS.SYS version 3.35 or earlier and forget that version 3.36 ever existed.