How Amiga 600 Manages Peripheral Interrupts

This article explores the technical architecture behind the Commodore Amiga 600’s interrupt handling system. It details how the Enhanced Chip Set communicates with the Motorola 68000 CPU to manage peripheral requests efficiently. Readers will learn about the specific registers involved, the prioritization of hardware signals, and the software routines required to acknowledge and process these interrupts without system instability.

The Commodore Amiga 600 relies on a sophisticated collaboration between its central processor and its custom coprocessor chips to handle input and output operations. At the heart of this system is the Motorola 68000 CPU, which operates alongside the Enhanced Chip Set (ECS), comprising Agnus, Denise, and Paula. Unlike standard computer architectures where the CPU polls devices for status updates, the Amiga uses a hardware-driven interrupt system. Peripheral devices such as the disk drive, serial port, audio channels, and vertical blanking signals generate hardware signals that pause the CPU’s current execution flow to service urgent tasks.

Interrupt generation begins within the custom chips, which monitor the status of various hardware components. When a peripheral requires attention, such as a disk drive needing data transfer or a audio channel requiring a new sample, the custom chip sets a specific bit in the INTREQ (Interrupt Request) register. However, setting this bit alone does not immediately interrupt the CPU. The system must also have the corresponding bit enabled in the INTENA (Interrupt Enable) register. This dual-register system allows the operating system or application software to mask specific interrupts, ensuring that only high-priority or expected events trigger a CPU exception.

Once an interrupt is requested and enabled, the custom chips assert an interrupt line to the Motorola 68000 CPU. The Amiga architecture primarily maps these custom chip interrupts to the CPU’s hardware interrupt level 2. Upon receiving the signal, the CPU completes its current instruction, saves its state onto the stack, and looks up the appropriate address in the interrupt vector table located at the beginning of system memory. Each type of interrupt has a dedicated vector, directing the processor to the specific Interrupt Service Routine (ISR) designed to handle that event.

The Interrupt Service Routine is responsible for identifying the exact source of the interrupt and performing the necessary data transfer or state change. Crucially, the ISR must acknowledge the interrupt by writing to the INTREQ register. This acknowledgement clears the request bit, allowing the custom chip to signal future events. Failure to properly clear the interrupt request can result in the CPU being trapped in a loop of repeated interrupts, leading to system hangs or crashes. This handshake mechanism ensures that the hardware and software remain synchronized during high-speed operations.

In addition to the custom chips, the Amiga 600 utilizes two Complex Interface Adapter (CIA) chips to manage slower peripherals like the keyboard, mouse, and parallel port. These CIA chips can generate interrupts independently of the custom video and audio chips. They are capable of triggering different CPU interrupt levels, allowing for a hierarchy of priority where time-critical video operations take precedence over slower input device polling. This layered approach to interrupt management allows the Amiga 600 to maintain smooth multitasking performance despite the limitations of its 1990s-era hardware.