Installing Windows 95 on SCSI in a VM

For the adventurous, it is possible to install Windows 95 in a VM configured with SCSI storage (hard disk, CD-ROM) attached to an emulated BusLogic HBA. This works in VirtualBox, but there’s a catch—the emulated PCI BusLogic HBA must have ISA compatibility disabled. If it does not, the installation will hang:

Windows 95 SCSI Installation HangAfter several minutes, there may be a blue screen complaining about inability to write to the hard disk.

Let’s start with the solution. In VirtualBox, the following needs to be run prior to starting the VM (split into two lines here for readability):

VBoxManage setextradata <vmname> 
 VBoxInternal/Devices/buslogic/0/Config/ISACompat Disabled

The problem is most likely caused by a bug in the BusLogic drivers shipped with Windows 95, although it might be more accurate to say that the drivers are not just clever enough. But what’s really going on?

ISA Compatibility on BusLogic PCI SCSI HBAs

Since the early 1990s, BusLogic produced bus-mastering ISA, EISA, and Microchannel SCSI host bus adapters (HBAs) compatible with the Adaptec AHA-154x line (the HBA with by far the best industry support in approximately the 1988-1998 period). BusLogic supported the odd 24-bit big-endian addressing scheme pioneered by Adaptec, but later extended it with 32-bit little-endian addressing which made BusLogic HBAs a good choice for systems with more than 16MB RAM.

In early 1994, BusLogic became one of the first vendors offering PCI SCSI HBAs, no doubt aided by BusLogic’s experience with EISA and Microchannel. The BT-946C was followed by BT-956C/CD, and finally BT-948, BT-958, and BT-958D.

BT-958 SCSI HBA

While moving the adapter to PCI did great things for performance, it caused a problem with compatibility. The BusLogic adapters could be used with various server and workstation operating systems (NetWare, SCO UNIX, ISC UNIX, Solaris, OS/2, Windows NT) either using generic AHA-154x drivers or BusLogic-specific drivers with 32-bit bus-mastering support.

Either way, software would typically look for the HBA at I/O port 330h or 334h. However, a PCI HBA will have its resources (including port address) configured by the system BIOS at a completely different port range and won’t be found by older drivers. BusLogic decided to slightly violate the PCI specification and optionally respond to I/O cycles at the old ISA-compatible addresses.

The BusLogic built-in adapter BIOS contains three settings for ISA I/O compatibility ranges: Primary (port 330h), Alternate (port 334h), and Disabled. The typical default address base for AHA-154x adapters was 330h, but some operating systems which supported AHA-154x also came with BusLogic drivers which by default used base address 334h.

In the older BT-946/956PCI  controllers, the default ISA I/O compatibility was Primary, while the later BT-948/958 had the compatibility disabled. Additional information can be found for instance here.

Seeing Double

In VirtualBox 4.3, the default setting is Alternate because this works well with various older operating systems. For old OSes with no PCI support, the fact that the HBA exposes two port ranges doesn’t pose any problem, since the PCI port range will be simply ignored.

For newer OSes, this doesn’t cause difficulties either—the typical strategy is to probe for PCI devices first, and the BusLogic driver disables the ISA compatibility range (if it was enabled). That is what for example Linux 2.4+ or Windows NT 4 do.

Windows 95 unfortunately falls right into a grey zone in between: It detects the PCI device and loads an appropriate driver, but does not disable the ISA port range. It also probes the ISA ports and loads the driver again. And that’s exactly the problem.

During installation, Windows 95 uses the PCI BusLogic miniport driver (BUSLOGIC.MPD), but later on probes ISA devices and loads a second instance of the BusLogic driver. That’s where things go wrong, since the drivers start fighting each other.

Brief analysis showed that roughly the following happens: The PCI BusLogic driver loads, installs interrupt handler, initializes hardware and functions properly; later the ISA driver loads, reprograms the hardware, and installs its own interrupt handler. At this point, the PCI driver is no longer able to communicate with the hardware.

Soon enough the PCI driver times out, resets and reprograms the hardware, and submits a command. Unfortunately the ISA driver receives the interrupt, and looks for work to do. But because the hardware has been reprogrammed in the meantime (mailbox moved to a different address) without the ISA driver’s knowledge, it finds nothing. The PCI driver keeps timing out and resetting the hardware, but the ISA driver keeps eating the interrupts and not noticing anything wrong.

Windows 98, VMware, Thoughts

In Windows 98, a similar but far much milder variation of this problem occurs:

Windows 98 Double BusLogicThe driver is loaded twice again, but the ISA instance fails to initialize and does not interfere with the PCI driver. The ISA driver can be simply uninstalled to get rid of the red X.

An attempt to reproduce this issue in VMware was not successful. VMware either does not support the ISA compatible port range at all, or if it does, it’s entirely undocumented and well hidden. As such, the conflict caused by doubled BusLogic driver cannot occur.

It’s unclear if this problem occurs on real hardware. It would have affected only a tiny number of users trying to install Windows 95 on one of the early BusLogic PCI HBAs, and very few people bought SCSI gear in order to run Windows 95 on it.

It’s probably worth pointing out that there is little to be gained from installing Windows 95 on SCSI. The OS is new enough to support ATAPI CD-ROMs, which would otherwise be the major reason for going SCSI (such as with OS/2 2.1 or Windows NT 3.1). Nevertheless, it can be an interesting exercise.

Windows 95 on BusLogicThe above shows a successful install of the original Windows 95 release in a VirtualBox VM with BusLogic SCSI emulation. The BusLogic ISA compatibility was disabled as explained at the beginning of this article.

Note: Windows 95 typically won’t run in VirtualBox with hardware virtualization enabled (because Windows 95 generally won’t run on faster CPUs). Disabling hardware virtualization usually works around this. The exact details may be the subject of another article.

This entry was posted in BusLogic, SCSI, VirtualBox, Windows 95. Bookmark the permalink.

7 Responses to Installing Windows 95 on SCSI in a VM

  1. slipstream says:

    Regarding the hardware virtualisation thing.. someone already fixed that and posted patch instructions..

    http://www.betaarchive.com/forum/viewtopic.php?t=29224

  2. Michal Necasek says:

    The “fast CPU problem” is irrelevant to this article and quite old. What I have not yet seen (but may have missed it) is detailed analysis of what the problem really is and what the patches do.

  3. Richard Wells says:

    The joys of dealing with 20 year old software. The tech notes that would have identified the problems for an install are gone as are most of the earliest patches.

    I did note with some amusement how patches prevented accessing an ISA SCSI address if a PCI SCSI address was found. I guess the developers never saw a real world system that had a fast PCI card for hard drives and tape plus an ISA card that handled slow SCSI devices like a scanner or Zip drive. Okay, Buslogic was not common and having multiple Buslogic cards in the same system would have been nearly unheard of but not the best solution.

  4. Sean McDonough says:

    This might explain why I found it absolute hell to get a 95 VM to recognise a virtual disk attached to the virtual SCSI controller (it was for installing MS Office 2000 on the VM, as I wasn’t sure if the primary IDE virtual disk had enough spare space on it) – and at least I was able to work with an already-installed OS, instead of having to have it properly recognise the virtual disk while installing.

    I did manage to eventually get it to recognise the SCSI disk… after taking multiple runs through Device Manager, extracting one of the .CAB files from the installation disk to a floppy image on a different computer, rebooting several times (the VM, not the host), and, on one occasion, crashing the VM (not crashing the OS installed on the VM, but crashing the VM itself, the kind that brings up the meditating guru). At which point Office 2000 promptly failed to install. Retrying the installation did not fix the problem.

    So now I have a virtual SCSI disk attached to a 95 VM, and nothing (so far) to do with said disk.

  5. MiaM says:

    Sean:
    Windows 95 also have some kind of strange behavior in that it treats some scsi disks as “big floppys” and wants to use them without a partition table, while other disks is treated like hard disks with a mandatory partition table. Maybe not relevant to what you stumbled upon, but worth knowing. I don’t know what triggers this. Atleast an old rather small scsi disk on the scsi controller of a MediaVision Pro Audio Spectrum 16 sound card behaves like a “floppy”.

  6. Michal Necasek says:

    Does Office 2000 even support Windows 95? I’d think that Windows 98 would be a much more natural match for it. Adding a BusLogic HBA to an existing Windows 95 VM is not something I tried though.

  7. Sean McDonough says:

    MiaM:
    That doesn’t sound like anything I was seeing; once I could get it to see the SCSI virtual hard disk at all, Windows (as far as I could tell) saw it as a hard disk.

    Michal:
    According to both Wikipedia (https://en.wikipedia.org/wiki/Microsoft_Office_2000) and Microsoft (https://web.archive.org/web/20150715055425/https://support.microsoft.com/en-us/kb/217883), yes, Office 2000 does indeed support 95.

    And once I gave up trying to install it on the 95 VM, I plugged the ISOs into a 98SE VM, and it worked like a charm.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.