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.
Interesting find! If anyone patches out the check it would be interesting to know which other manufacturers card the drivers would work with.
Sorry that this probably is a repeat of what I’ve been saying many times before, but: If you ever feel like investigating how some other driver is locked to specific hardware you could have a go at all those ATAPI DOS CD drivers that all were locked to the vendors own hardware (except CPQIDECD.SYS). 🙂
Another thing that might be worth examining is how those “EIDE” ISA cards (by Promise IIRC?) locked their bios to their own hardware. Although today it would mostly be of academical interest to know how they did it, back in the days before XTIDE Unversal BIOS it would actually had been useful for vintage computer enthusiasts to be able to use a copy of the BIOS of those cards with any generic IDE card (using for example the boot rom socket of a network card to hold the BIOS chip).
If you can tell me exactly where to download the relevant binaries, I can have a look.
Does this also affect the MCA only AHA1640?
I have no idea. Maybe? It does use ASPI4DOS.SYS as well, but the detection logic may be different. I can’t test that myself.
I have fuzzy memories that I encountered problems with the AHA-1640 and loading an ASPI driver. This was a long time ago though and I basically gave up on using the card in a Model 50Z. I have no way to reproduce it now though as I no longer have Microchannel machines to try the card in. I still have the card if I ever encounter another MCA machine.
Forgot to reply, sorry.
I think that more or less all the drivers I’m thinking about are included when you tell Windows 98 to create a boot disk. The one that tries to load loads of different cd-rom drivers, each vendor locked to the vendors own atapi cd/dvd units.
Not that there would be much benefit, if any, as compared to running the non-vendor locked CPQIDECD.SYS from Compaq, but it would kind of be interesting to once and for all “crack” those vendor specific drivers and prove that a Mitsumi driver actually would work with a Panasonic CD-ROM and vice versa, if you can get the drivers to load.