Implement Simple Interrupt Handler for Timer or Keyboard

Topic Overview

Writing IRQ handlers

Hardware interrupts arrive as IRQ lines mapped through the PIC or IOAPIC into IDT vectors. A timer ISR typically increments a tick counter and sends an EOI byte 0x20 to the master PIC at port 0x20. For example, IRQ0 remapped to vector 0x20 fires ~18.2 Hz on the legacy PIT.

Handler skeleton

nasmCopy
Loading…

• Save state: Pusha or save only clobbered registers
• EOI: Required for PIC; APIC has its own EOI register
• Shared IRQs: Chain or check device status registers
• Keep ISRs short; defer heavy work to bottom halves

APIC vs PIC

ACPI systems may route IRQs through IOAPIC entries not covered by the classic 8259 sequence. The EOI pattern you learn on the PIC still illustrates the contract: acknowledge the controller so another edge can arrive. Use a volatile tick variable if C code reads it from the main loop while the ISR writes it. Mask IRQs during table edits to avoid executing half-installed handlers.

Why for this exercise

You will install a timer or keyboard ISR that updates a counter and acknowledges the PIC. This exercise requires IDT setup, EOI discipline, and IRET without leaving interrupts masked permanently.

Simulate a simple interrupt-driven timer/keyboard handler loop in C (same bookkeeping a real ISR performs, driven from stdin instead of hardware).

Input format:

• Line 1: N, the number of events.
• Then one event per line: "STI", "CLI", "IRQ0" (timer tick), or "IRQ1 <hex>" (keyboard scancode byte).

Requirements:

• Model the CPU IF flag: interrupts start disabled; only STI/CLI change it.
• An IRQ is delivered only when IF=1; otherwise print "<IRQ> blocked if=0".
• Delivered IRQ0: increment the tick counter, print "IRQ0 tick=<n> eoi=0x20" (EOI 0x20 sent to master PIC port 0x20).
• Delivered IRQ1: increment the key counter, print "IRQ1 key=0x<XX> eoi=0x20" (raw scancode byte, not decoded).
• After all events print the summary line "ticks=<t> keys=<k>".
• Exit code 0.