How MS-DOS 6.22 Manages Sound Hardware IRQs

In MS-DOS 6.22, the operating system does not actively manage sound hardware Interrupt Requests (IRQs) because it lacks a unified sound architecture or Hardware Abstraction Layer (HAL). Instead, MS-DOS operates in real mode and delegates direct hardware control to individual applications, requiring games and software to manually detect, hook, and handle sound card IRQs by interacting directly with the system's Interrupt Vector Table (IVT) and the 8259 Programmable Interrupt Controller (PIC).

The Absence of Native Sound Drivers

MS-DOS 6.22 is designed around simple input/output systems (via INT 21h and BIOS INT 10h/16h) primarily suited for text, disk storage, and basic peripheral operations. The operating system provides no native sound API. Consequently, audio devices such as the Sound Blaster, Gravis UltraSound, or Roland MPU-401 operate without intermediate OS-level driver management during execution.

The BLASTER Environment Variable

Because the operating system cannot query or mediate sound card settings, it relies on a standardized MS-DOS environment variable to pass hardware parameters to running applications. Configured in AUTOEXEC.BAT, the BLASTER variable informs software of the hardware resources assigned via jumpers or PnP utilities:

SET BLASTER=A220 I5 D1 H5 T6

In this string, the I parameter (e.g., I5) explicitly tells the application which hardware IRQ line the sound card is configured to trigger. The operating system merely stores this string in memory; it does not configure the hardware or allocate the interrupt itself.

Hooking the Interrupt Vector Table (IVT)

When an MS-DOS application starts, it initializes audio by hooking into the CPU's Interrupt Vector Table located in the first kilobyte of memory (0000:0000 to 0000:03FF). Hardware IRQs are mapped to specific interrupt vectors via the dual 8259 PIC architecture:

  • Master PIC (IRQs 0–7): Mapped to CPU Interrupts 08h through 0Fh. For example, IRQ 5 maps to Interrupt 0Dh.
  • Slave PIC (IRQs 8–15): Mapped to CPU Interrupts 70h through 77h. For example, IRQ 10 maps to Interrupt 72h.

The application saves the existing address found at the designated interrupt vector and writes the memory address of its own custom Interrupt Service Routine (ISR) directly into the IVT.

Programmable Interrupt Controller (PIC) Interaction

Once the ISR is installed, the application must interact directly with the 8259 PIC using raw I/O port instructions (IN and OUT):

  1. Unmasking the IRQ: By modifying the Interrupt Mask Register (IMR) on port 21h (Master) or A1h (Slave), the application enables the specific IRQ line so the CPU can receive signals from the sound card.
  2. Interrupt Service Routine (ISR) Execution: When the sound card finishes processing a Direct Memory Access (DMA) audio buffer, it raises the IRQ line. The CPU halts current execution and jumps to the application's ISR, which refills the audio buffer or triggers the next audio block.
  3. End of Interrupt (EOI): Before exiting the ISR, the application must write an End of Interrupt command (20h) to port 20h (and port A0h if using an IRQ on the slave PIC). Without this manual acknowledgment, the PIC will block all subsequent hardware interrupts, freezing system audio and input.

Application Teardown and Vector Restoration

Because MS-DOS 6.22 does not track resource allocations per process, failure to clean up hardware states leads to system instability. When an application terminates, its shutdown sequence must mask the sound IRQ on the PIC, write the original interrupt handler back to the IVT, and silence the sound card's DSP. If an application crashes or fails to restore the original interrupt vector, subsequent hardware interrupts will point to invalid or overwritten memory, resulting in a total system crash.