PC 8259A PIC Delivery: IRQ Mapping, Cascades, Masks, and EOI

On an original IBM PC or compatible machine, a hardware device does not call DOS INT 21h directly. It asserts an interrupt request line; the 8259A Programmable Interrupt Controller (PIC) prioritizes and masks requests, then presents an interrupt vector to the processor. The BIOS and DOS environment install handlers for conventional vectors, and device drivers or TSRs may hook them. Understanding these layers prevents a common diagnosis error: an IRQ number, interrupt vector, and software INT instruction are related concepts, not interchangeable names for one event.

The classic PC/XT used one 8259A with eight request inputs. The PC/AT added a second controller cascaded through IRQ2 on the master, exposing IRQ8 through IRQ15 through the slave. In the conventional real-mode mapping, master IRQ0-IRQ7 use vectors 08h-0Fh; the AT slave’s IRQ8-IRQ15 use 70h-77h. These are historical platform mappings, not guaranteed vector assignments for every later operating mode or emulator.

Follow one hardware request

An IRQ source asserts a controller input. The PIC compares the request with its mask and in-service state, applies its priority policy, and signals the CPU when the request can be acknowledged. The CPU saves its interrupt-return state and transfers control to the vector associated with that request. A handler must preserve whatever state its contract requires, service or acknowledge the device, and coordinate with the PIC before returning with IRET.

That path has separate responsibilities:

device assertion -> PIC request/mask/priority -> CPU interrupt acknowledge
                 -> vector handler -> device-specific service -> PIC EOI -> IRET

If a slave IRQ is active on an AT-style system, its controller signals the master through the cascade input. The handler and controller state must account for both PICs. An end-of-interrupt (EOI) sent to only the wrong controller can leave an in-service bit set or incorrectly release priority. The exact command sequence depends on the controller mode and interrupt source; use the 8259A and platform manuals instead of copying an isolated OUT instruction.

Vectors are not physical devices

The conventional assignments are useful for debugging: IRQ0 is commonly the timer, IRQ1 the keyboard, IRQ2 the AT cascade, and other lines historically served serial, diskette, printer, or storage controllers. Hardware configuration and later platform generations can change assignments. A driver may also use a software interrupt as an application entry point that has no direct relation to a hardware IRQ line.

In real mode, BIOS-installed handlers commonly occupy the conventional IRQ vectors. DOS applications should normally interact through documented BIOS, DOS, and driver interfaces rather than reprogramming the PIC. A TSR that hooks a timer vector is still interacting with a handler chain and PIC-owned hardware event; it does not own the controller merely because it owns a callback. See the separate TSR guidance for vector chaining and reentrancy issues.

PC/AT compatibility introduces another trap: IRQ2 was used as the cascade input, while systems may expose an apparent IRQ2 compatibility path associated with the former PC/XT line. Do not infer the electrical source from the label shown by a configuration menu. Verify the board, BIOS and driver documentation, and distinguish ISA-era assignments from PCI interrupt routing or virtualized interrupt controllers.

Masks and in-service state

The PIC’s interrupt mask register allows software to disable selected request lines. Masking a line is not the same as acknowledging the underlying device; the device may continue asserting its request. Unmasking can then cause service to occur immediately. Drivers must coordinate with the device’s status registers and controller mask state so that they do not lose an edge, storm on a level, or expose an uninitialized handler.

The 8259A also tracks requests being serviced. Priority and nesting behavior determine whether another request can interrupt the current handler. A non-specific EOI clears the highest-priority in-service level according to controller state; a specific EOI identifies a level. Automatic EOI and special nesting modes change the contract. Because a handler’s correctness depends on initialization mode, a hard-coded “always send this byte” recipe is unsafe without establishing controller configuration.

In a cascaded pair, a slave request involves both controllers. The controller-specific ISR/IRR read commands and EOI behavior are defined in the 8259A documentation. Spurious requests are another controller edge case: the expected service routine may not correspond to a still-pending real device request. Low-level handlers must distinguish these cases according to the datasheet and platform firmware contract.

Why reprogramming is dangerous in DOS

The PIC is global system hardware, not a per-process resource. Changing a vector base, masking a line, or issuing an EOI without owning the current state can break DOS timer ticks, keyboard input, storage interrupts, sound, or other resident components. A wrong EOI can cause repeated interrupts or freeze lower-priority work. A wrong vector base can collide with CPU exception vectors or handlers installed by firmware.

Do not run PIC initialization code from an ordinary DOS application. Such code belongs in controlled low-level firmware, a kernel, or a driver that owns startup and teardown. If the goal is to diagnose an IRQ conflict, first inventory the actual device configuration, interrupt vectors, driver load order, and platform/emulator mapping. Then change one documented setting at a time on a restorable test system.

For a driver that truly owns an IRQ, its lifecycle needs a safe acquisition and teardown protocol: mask the line before installing a handler; configure and clear the device; install the vector and controller configuration in the required order; unmask only after the handler is ready; acknowledge the device before EOI; and restore prior masks/vectors on every exit path. This is a design checklist, not a portable code recipe. DOS lacks process isolation that could contain a broken handler.

Diagnostic workflow

Identify whether the event is a CPU exception, software interrupt, NMI, or maskable IRQ.
Establish platform generation and controller topology: one PIC on PC/XT class, cascaded pair on AT class, or a virtual/modern controller layer.
Record the physical IRQ, vector mapping, device, and driver that claims it.
Inspect device-specific status and documentation before touching controller state.
Reproduce on a disposable system or emulator snapshot; do not reinitialize PIC state on a production installation.
Validate timer, keyboard, disk I/O, and any resident programs after a low-level change.

On DOS, INT 21h is a software operating-system dispatcher. By contrast, a hardware IRQ enters through the CPU interrupt mechanism after PIC arbitration. A TSR can hook a vector, and a driver can service an IRQ, but neither fact converts the event into a DOS system call. Keeping these boundaries clear makes logs and bug reports much easier to interpret.

Acceptance and compatibility limits

Before approving an IRQ-level change, document the exact controller model or emulation, initialization mode, vector bases, mask state, device acknowledgement sequence, EOI policy, and teardown path. Test nested and repeated requests, masked transitions, and the expected device state after handler return. Verify that periodic services such as the BIOS timer remain functional.

The 8259A remains useful when maintaining vintage hardware and understanding legacy DOS drivers, but many later PCs emulate or replace its behavior behind chipset logic. Intel’s controller datasheet defines the chip; IBM’s PC/AT technical reference describes one system integration. Neither document makes a low-level recipe safe on every clone, chipset, virtual machine, or later interrupt controller. Treat the exact hardware contract as evidence you must establish before changing shared interrupt state.

Related:

Sources: