Editing Intel 8259 (section)

== Programming considerations ==
{{essay-like|section|date=April 2025}}

=== DOS and Windows ===
[[Image:NEC D8259AC.jpg|thumb|NEC D8259AC, used on the original [[IBM Personal Computer|IBM PC]] motherboard.]]
Programming an 8259 in conjunction with [[DOS]] and [[Microsoft Windows]] has introduced a number of confusing issues for the sake of backwards compatibility, which extends as far back as the original PC introduced in 1981.

The first issue is more or less the root of the second issue. DOS device drivers are expected to send a non-specific EOI to the 8259s when they finish servicing their device. This prevents the use of any of the 8259's other EOI modes in DOS, and excludes the differentiation between device interrupts rerouted from the master 8259 to the slave 8259.

The second issue deals with the use of IRQ2 and IRQ9 from the introduction of a slave 8259 in the PC/AT. The slave 8259's INT output is connected to the master's IR2. The IRQ2 line of the ISA bus, originally connected to this IR2, was rerouted to IR1 of the slave. Thus the old IRQ2 line now generates IRQ9 in the CPU. To allow backwards compatibility with DOS device drivers that still set up for IRQ2, a handler is installed by the BIOS for IRQ9 that redirects interrupts to the original IRQ2 handler.

In the PC/clone family of platforms, the BIOS (and thus also DOS) traditionally maps the master 8259 interrupt requests (IRQ0–IRQ7) to interrupt vector offset 8 (corresponding to INT 08–INT 0Fh), and when present, the PC/AT’s slave 8259 is mapped to interrupt vector offset 112 (INT 70–INT 77h). This was done despite the first 32 (INT 00-INT 1F) interrupt vectors being reserved by the processor for internal exceptions.

This meant that, on later chips, handlers for lower-numbered vectors needed to differentiate between three causes:

* faults, exceptions, and traps caused incidentally;

* interrupts caused by IRQ or NMI, potentially including spurious IRQs; and

* deliberate calls from software executing INT, breakpoint, or indirect far CALL/JMP instructions, as might be used to interact with the BIOS, operating system, or device drivers.

Because of this, most operating systems that don’t make use of the BIOS will configure the interrupt controller(s) to avoid the reserved vector range entirely. In protected mode, the OS can restrict use of INT instructions to specific vectors only (e.g., Linux exposes INT 80h for system calls), and any attempt to use a disallowed vector will raise a protection fault.

This avoids some of the need for cause determination in interrupt vector handlers, although spurious interrupts and IRQ-sharing can still complicate matters. Fortunately, most peripheral devices can be queried with regards to outstanding IRQs, and if no source can be found an interrupt can be treated as spurious or ignored altogether.

=== Other operating systems ===
Since most other operating systems allow for changes in device driver expectations, other 8259 modes of operation, such as Auto-EOI, may be used. This is especially important for modern [[x86]] hardware in which a significant amount of time may be spent on I/O address space delay when communicating with the 8259s. This also allows a number of other optimizations in synchronization, such as critical sections, in a multiprocessor x86 system with 8259s.

=== Edge and level triggered modes ===
Since the ISA bus does not support [[level triggered interrupt|level triggered]] interrupts, level triggered mode may not be used for interrupts connected to ISA devices. This means that on PC/XT, PC/AT, and compatible systems the 8259 must be programmed for [[edge triggered interrupt|edge triggered]] mode. On MCA systems, devices use level triggered interrupts and the interrupt controller is hardwired to always work in level triggered mode. On newer EISA, PCI, and later systems the Edge/Level Control Registers (ELCRs) control the mode per IRQ line, effectively making the mode of the 8259 irrelevant for such systems with ISA buses. The ELCR is programmed by the BIOS at system startup for correct operation.

The ELCRs are located 0x4d0 and 0x4d1 in the x86 I/O address space. They are 8-bits wide, each bit corresponding to an IRQ from the 8259s. When a bit is set, the IRQ is in level triggered mode; otherwise, the IRQ is in edge triggered mode.

=== Spurious interrupts ===
The 8259 generates spurious interrupts in response to a number of conditions.

The first is an IRQ line being deasserted before it is acknowledged. This may occur due to noise on the IRQ lines. In edge triggered mode, the noise must maintain the line in the low state for 100 ns. When the noise diminishes, a [[pull-up resistor]] returns the IRQ line to high, thus generating a false interrupt. In level triggered mode, the noise may cause a high signal level on the systems INTR line. If the system sends an acknowledgment request, the 8259 has nothing to resolve and thus sends an IRQ7 in response. This first case will generate spurious IRQ7's.

A similar case can occur when the 8259 unmask and the IRQ input de-assertion are not properly synchronized. In many systems, the IRQ input is deasserted by an I/O write, and the processor doesn't wait until the write reaches the I/O device. If the processor continues and unmasks the 8259 IRQ before the IRQ input is deasserted, the 8259 will assert INTR again. By the time the processor recognizes this INTR and issues an acknowledgment to read the IRQ from the 8259, the IRQ input may be deasserted, and the 8259 returns a spurious IRQ7.

The second is the master 8259's IRQ2 is active high when the slave 8259's IRQ lines are inactive on the falling edge of an interrupt acknowledgment. This second case will generate spurious IRQ15's, but is rare.