How MS-DOS Manages Sound Card DMA Interrupts

In MS-DOS 6.22, the operating system does not actively manage audio hardware or Direct Memory Access (DMA) interrupts through an abstracted kernel audio subsystem. Because MS-DOS operates as a single-tasking, real-mode environment, it delegates low-level hardware communication directly to applications. Sound cards, such as the Creative Labs Sound Blaster, rely on the system's Intel 8237 DMA controller to stream audio data from system memory and use the Intel 8259 Programmable Interrupt Controller (PIC) to notify the CPU when a buffer transfer completes. The execution, signaling, and servicing of these interrupts occur through direct hardware manipulation rather than MS-DOS internal drivers.

The Role of MS-DOS 6.22

MS-DOS 6.22 provides basic file, disk, and character-device I/O routines via software interrupts such as INT 21h. It does not include an audio driver layer, a mixer, or a standardized sound API. When a game or digital audio program runs, it bypasses the MS-DOS kernel to communicate directly with hardware I/O ports, interrupt lines, and DMA channels. The only administrative role MS-DOS performs in this cycle is providing interrupt vector management services through INT 21h, AH=35h (Get Interrupt Vector) and INT 21h, AH=25h (Set Interrupt Vector), which programs use to hook and restore the Interrupt Vector Table (IVT).

The DMA Transfer Mechanism

To play digitized sound without consuming massive amounts of CPU cycles, audio hardware relies on the system's 8237 DMA controller (typically DMA Channel 1 for 8-bit audio or DMA Channel 5 for 16-bit audio). The host application sets up a continuous playback cycle using a technique called double-buffering:

  1. The software allocates an area of conventional memory (below the 1 MB boundary) aligned to avoid 64 KB physical DMA page boundaries.
  2. The application programs the 8237 DMA controller with the memory address, page register, transfer mode (single-cycle or auto-initialize), and buffer size.
  3. The application writes commands to the sound card's Digital Signal Processor (DSP) I/O ports (such as base port 220h) to specify sample rate and initiate DMA playback.
  4. The sound card requests byte-by-byte or word-by-word transfers from the DMA controller directly to its internal digital-to-analog converter (DAC).

Interrupt Generation and the 8259 PIC

The DMA controller itself does not directly trigger the CPU interrupt for the audio stream. Instead, the sound card's onboard DSP monitors the incoming DMA stream. Once the predefined block size has been transferred, the sound card asserts its assigned Interrupt Request line (typically IRQ 5 or IRQ 7).

The signal reaches the Intel 8259 PIC, which prioritizes the request and converts the hardware IRQ into an interrupt vector index:

  • IRQ 0 to 7 (Master PIC) map to CPU interrupts 08h to 0Fh. For example, IRQ 5 maps to INT 0Dh.
  • IRQ 8 to 15 (Slave PIC) map to CPU interrupts 70h to 77h.

The Interrupt Service Routine (ISR) Execution

When the CPU receives the interrupt signal, it halts its current execution thread, pushes the flags and return address onto the stack, and jumps to the address stored in the IVT at 0000:0000h corresponding to the triggered interrupt. Because the running software hooked this vector at startup, control flows directly into the application's custom Interrupt Service Routine (ISR).

The ISR executes the following sequential steps to process the event:

  1. Acknowledge the Sound Card: The ISR reads a specific I/O port on the sound card (for example, reading 2xEh for an 8-bit Sound Blaster interrupt or 2xFh for a 16-bit interrupt). This read operation clears the hardware interrupt state on the DSP, allowing it to deassert the IRQ line. Failing to read this register leaves the IRQ high, preventing future interrupts.
  2. Buffer Swapping and Refilling: The ISR flags the main program or immediately writes new PCM audio data into the half of the DMA buffer that was just played, ensuring uninterrupted continuous audio output.
  3. End of Interrupt (EOI): The ISR signals the 8259 PIC that interrupt handling is complete by writing an End of Interrupt byte (20h) to the PIC command port (20h for the Master PIC, and A0h followed by 20h if handling an IRQ on the Slave PIC).
  4. Exit: The routine executes an IRET (Interrupt Return) instruction to restore the CPU flags and program counter, returning execution to whatever task MS-DOS or the application was performing prior to the interrupt.