Windows 95 Sound Blaster Emulation for MS-DOS

This article explains how Windows 95 enabled legacy MS-DOS games to output audio through Sound Blaster emulation without requiring a native restart. It covers how the operating system utilized Virtual 8086 mode, Virtual Device Drivers (VxDs), I/O port trapping, and DMA virtualization to intercept legacy hardware calls and route them through 32-bit protected-mode sound architectures.

The Legacy Hardware Challenge

MS-DOS games were designed around direct hardware access. Developers hardcoded routines that directly communicated with the Sound Blaster's physical resources—typically base input/output (I/O) port 220h, Interrupt Request (IRQ) 5 or 7, and Direct Memory Access (DMA) channel 1, along with port 388h for AdLib/OPL FM synthesis.

Windows 95, however, ran in protected mode with preemptive multitasking. Allowing multiple programs or DOS windows direct, unmediated access to physical sound hardware would cause system crashes and resource contention. Windows 95 had to make legacy games believe a genuine Sound Blaster card was present while routing the actual audio through the Windows sound subsystem.

Virtual 8086 Mode and Port Trapping

To run MS-DOS software alongside Windows applications, Windows 95 instantiated a Virtual DOS Machine (VDM) utilizing the x86 processor’s Virtual 8086 (V86) mode. In V86 mode, software executes with 16-bit real-mode addressing, but privilege levels remain restricted under the supervisor control of the Windows 32-bit kernel (VMM32).

When a DOS game attempted to read or write to audio hardware using x86 IN and OUT assembly instructions:

  1. Trap Generation: The CPU intercepted these privileged I/O instructions because the game lacked the execution privilege to modify hardware directly.
  2. Exception Handling: The processor raised a General Protection Fault (Exception 13), which was caught immediately by the Windows Virtual Machine Manager (VMM).
  3. Redirection to VxDs: The VMM looked up which Virtual Device Driver (VxD) had registered ownership of that specific I/O port range (e.g., ports 220h–22Fh).

The Role of Virtual Device Drivers (VxDs)

Windows 95 relied on audio VxDs—provided either by Microsoft or third-party sound card manufacturers like Creative Labs—to handle the intercepted calls.

  • Digital Audio Emulation (DSP): The Sound Blaster's Digital Signal Processor (DSP) accepted commands to play single-cycle or auto-init DMA digital audio. The VxD maintained a virtual state machine mimicking the registers of a DSP chip (such as DSP version 2.01 or 4.05 for Sound Blaster Pro and 16 compatibility). When a game wrote data or command bytes, the VxD decoded the commands and accumulated PCM audio samples into a protected-mode memory buffer.
  • FM Synthesis Emulation (AdLib/OPL): For music written for Yamaha YM3812 (OPL2) or YMF262 (OPL3) chips at port 388h, the driver redirected the trapped register writes to either a hardware-level FM synthesizer on the sound card or a software-based MIDI/FM translation engine.

Virtualizing DMA and IRQ

Audio playback on Sound Blaster cards relied heavily on DMA for uninterrupted sample streaming and hardware interrupts (IRQs) to signal when a buffer had finished playing. Windows 95 handled this through core system virtualization services:

  • Virtual DMA Driver (VDMAD): In a physical machine, the Sound Blaster coordinated directly with the motherboard’s 8237 DMA controller. In Windows 95, VDMAD intercepted the game's attempts to program the DMA controller. Instead of transferring data directly from conventional DOS memory to the sound card, VDMAD mirrored the transfer into system memory, where the sound card's native Windows driver could stream it safely.
  • Virtual Programmable Interrupt Controller (VPICD): Once a virtual audio block completed playback, the emulation layer called VPICD to assert a virtual IRQ inside that specific Virtual DOS Machine. The game’s interrupt handler was executed, prompting the game to queue the next segment of audio without knowing the transfer had been mediated by an operating system layer.

Bridging to Non-Sound Blaster and PCI Hardware

As the market transitioned from ISA cards to PCI sound cards (such as the Sound Blaster Live! or Ensoniq AudioPCI), the hardware no longer occupied the legacy ISA I/O ports or DMA channels.

In these configurations, the Windows 95 VxD architecture allowed manufacturers to provide purely software-driven emulation:

  1. The game wrote to virtual port 220h via V86 mode.
  2. The VxD caught the instructions, buffered the PCM data, and tracked the virtual Sound Blaster state.
  3. The VxD fed the captured PCM data directly into the PCI card's ring-0 driver buffer or the Windows audio mixing pipeline.
  4. The physical sound card played the audio using standard modern PCI DMA transfers, completely abstracting the physical hardware from the DOS game.

The MS-DOS Mode Fallback

Not all DOS games could be virtualized successfully. Protected-mode games utilizing non-standard DOS extenders or those relying on undocumented hardware behavior frequently conflicted with Windows 95's port trapping and memory management.

For these titles, Windows 95 bypassed its protected-mode emulation pipeline entirely via MS-DOS Mode. This unloaded the Windows GUI and kernel, re-initialized the machine into pure 16-bit real mode, and executed traditional real-mode DOS drivers (such as CTCM.EXE or manufacturer-specific TSRs) directly through customized AUTOEXEC.BAT and CONFIG.SYS profiles.