Understanding Interrupt Priorities on the Sharp X68000

The Sharp X68000 feels responsive because its Motorola 68000 processor can react to several kinds of hardware events while software is running. Timers, serial input, sound hardware, display timing, storage devices, and expansion boards may all require attention. The interrupt system decides which request reaches the CPU, which handler runs, and whether a lower-priority event must wait.

Understanding that process is useful for more than writing an emulator. It helps when diagnosing missed timer ticks, repairing an expansion board, developing resident utilities, or modifying software that depends on precise video and audio timing. An incorrect assumption about interrupt priority can produce symptoms that look like faulty RAM, unstable hardware, or a broken peripheral.

The X68000 combines the interrupt facilities built into the 68000 with peripheral controllers that generate requests at selected interrupt levels. The exact device map and interrupt assignments can vary by hardware generation, system software, and expansion design, so the safest approach is to understand the architecture first and then confirm the details against the relevant technical documentation.

The 68000 Priority Model

The Motorola 68000 exposes three interrupt-priority input lines, commonly called IPL0, IPL1, and IPL2. Together they encode an external interrupt level from 0 through 7. Level 0 means that no maskable interrupt is being presented, while levels 1 through 7 represent increasingly urgent requests.

The current processor mask is held in the interrupt priority level field of the status register. A mask value of 3, for example, allows interrupt levels 4 through 7 to be accepted while blocking levels 1 through 3. An interrupt is recognized when its external level is higher than the current mask. Equal or lower levels remain pending until the mask is reduced or the active handler finishes.

This gives the X68000 a hardware-defined first stage of prioritization. A level 6 request outranks a level 4 request regardless of which peripheral produced it. The CPU does not compare device names, timestamps, or software preferences; it sees the encoded IPL level presented by the system’s interrupt logic.

Level 7 has special significance. On a standard 68000, it is generally treated as non-maskable, meaning the normal status-register mask cannot suppress it. Designers therefore reserve that level for events requiring immediate attention. An X68000 program should avoid assuming that every apparent high-priority event can be deferred safely.

Peripheral Sources Behind The Request

Most practical interrupt work begins below the CPU pins. A peripheral controller collects several internal event sources and asserts one external interrupt level. The Motorola 68901 Multi-Function Peripheral, usually called the MFP, is especially important in X68000 software and hardware discussions. It combines timers, serial functions, general-purpose input handling, and interrupt management in one device.

The MFP maintains registers for interrupt enable, pending status, in-service state, and masking. Its vector register supplies the upper portion of interrupt vector numbers, while the selected source contributes the lower portion. This allows a handler to identify the source through the vector supplied during interrupt acknowledge rather than inspecting every peripheral after entry.

An MFP interrupt level is therefore different from an MFP source priority. The external level determines when the CPU accepts the request relative to other system levels. Once the CPU has entered the MFP’s level, the MFP’s own priority rules decide which enabled pending source receives service first.

Other X68000 hardware can use separate interrupt paths or system-specific interrupt logic. Video timing, floppy and hard disk controllers, sound hardware, keyboard communication, and expansion boards may be connected through different controller arrangements. A board modification can also introduce a new source without changing the CPU itself, provided the electrical and software interface follows the expected interrupt protocol.

Vector Numbers And Interrupt Acknowledge

An interrupt level tells the 68000 how urgent a request is, but it does not directly identify the routine to execute. During interrupt acknowledge, the processor obtains an interrupt vector number. That vector points into the vector table, whose entries contain the addresses of exception and interrupt handlers.

The 68000 supports autovectors for interrupt levels 1 through 7. An autovectored device does not provide a unique peripheral vector; the CPU selects a standard vector associated with the interrupt level. This is simple and reliable, but a shared level may require a common handler to inspect device status registers and determine the source.

Vectored peripherals provide a more specific number during the acknowledge cycle. The MFP is designed for this style, making it possible to assign distinct vectors to timer events, serial activity, or other internal sources. The handler can then dispatch directly, reducing register polling and making multiple sources easier to manage.

A useful distinction is between the vector table and the interrupt controller. The table stores addresses, but it does not create priority. Changing a vector entry changes the destination of an accepted interrupt; it does not make that interrupt outrank another source. Likewise, installing a handler without enabling the source or clearing its pending condition does not produce a functioning interrupt path.

Layer	Main Responsibility	Typical Failure Symptom
Peripheral event source	Detects a timer, transfer, input, or timing event	No request is generated
Peripheral interrupt registers	Enables, masks, records, and prioritizes sources	Event remains pending or repeats
System interrupt routing	Converts device requests into CPU IPL levels	Wrong priority or shared-line conflict
68000 status register	Accepts or blocks maskable levels	Handler never runs at the current mask
Interrupt acknowledge cycle	Obtains an autovector or device vector	CPU enters the wrong handler
Vector table and handler	Executes software response and restores state	Crash, lockup, or missed future events

Nested Interrupts And Mask Handling

When the 68000 accepts an interrupt, it saves a copy of the status register and the program counter on the supervisor stack. It then enters supervisor mode and raises the interrupt mask to the level of the accepted request. This automatic mask change prevents equal- or lower-level interrupts from interrupting the handler immediately.

A higher-level request can still preempt the current handler if the hardware presents it and the handler has not raised the mask further. This is the basis of nested interrupts. For example, a level 6 sound-related event may interrupt a level 4 routine, while another level 4 event normally waits. The design is useful for timing-sensitive work, but it increases stack use and makes shared data more difficult to protect.

An interrupt handler should do the smallest safe amount of work at elevated priority. It can acknowledge the hardware, capture a byte or timestamp, update a ring buffer, and schedule more substantial processing for foreground code. Long disk operations, extensive graphics work, and complex allocation routines are poor choices inside a high-priority handler.

Returning with the correct exception-return instruction restores the saved processor state. A normal subroutine return is not sufficient because it would leave the saved status and program counter on the stack. Resident software also needs to preserve registers according to the expected calling convention and avoid changing vector entries or MFP registers without restoring them when appropriate.

MFP Internal Priority And Pending Events

The MFP’s interrupt registers are best understood as a pipeline. A hardware event first becomes pending. If its source is enabled and unmasked, the MFP can request service. When the CPU acknowledges the request, the MFP selects one eligible source according to its internal priority arrangement and supplies the corresponding vector information.

The pending bit and the in-service bit have different meanings. Pending says that an event is waiting. In-service indicates that the source has been selected and is currently being handled. Clearing the wrong register, or clearing a condition before the peripheral itself has been serviced, can result in repeated interrupts, lost events, or a handler that appears to run continuously.

MFP source priority is commonly arranged in a fixed order, with the lower-numbered source positions preferred over the higher-numbered ones. Software should treat that ordering as part of the controller design rather than assuming that the order in which events occurred will be preserved. If two timer flags are pending at the same time, the configured controller priority decides which vector is presented first.

The vector register’s layout also matters. A careless write can change the vector base for every MFP source, redirecting unrelated handlers. When debugging, record the original interrupt-enable, mask, vector, and in-service values before making changes. A diagnostic program that alters global interrupt state should provide a clean restoration path, especially when run under a resident environment.

Choosing Priorities For Hardware Projects

Priority selection should follow timing requirements rather than convenience. A source that must maintain a stable sample interval or synchronize tightly with display hardware may need a higher CPU level than a source that can tolerate several milliseconds of delay. Storage completion and keyboard input are usually more tolerant than audio clocks or carefully timed raster activity, although the correct choice depends on the program.

A higher level is not automatically better. Every elevated handler delays lower-priority work, and a frequently firing level 6 source can starve level 2 activity. If a handler spends too long with interrupts blocked, serial buffers can overflow, disk transfers can miss deadlines, and background software may appear frozen.

Expansion hardware should also respect electrical behavior. Multiple devices cannot simply drive an interrupt line in incompatible ways. Open-collector or otherwise appropriate signaling, defined inactive states, and correct acknowledge behavior are essential. A board that asserts a line permanently may prevent the CPU from returning to normal execution, while a board that releases it too quickly may generate intermittent failures that are difficult to reproduce.

Before selecting a level, map the entire path: device status bit, enable and mask registers, controller output, CPU IPL level, vector number, and software handler. Documentation gathered through the wider X68000 reference hub can help locate hardware manuals, development tools, emulator sources, and community notes that clarify model-specific behavior.

Debugging Interrupt Failures

A disciplined diagnosis begins by separating generation, routing, acceptance, and dispatch. First confirm that the peripheral event occurs and that its status bit changes. Next check whether the source is enabled and unmasked. Then inspect the system’s interrupt output and the CPU mask. Finally verify the vector table entry and the handler’s acknowledge and return sequence.

A logic analyzer or oscilloscope is valuable when the software view is ambiguous. It can reveal whether an interrupt line remains asserted, whether requests arrive at the expected frequency, and whether a modification creates excessive electrical noise. Register snapshots are equally useful: compare pending, in-service, enable, and mask values before and after a single controlled event.

Missed interrupts often come from an overly high CPU mask, a disabled source, or a handler that fails to clear the peripheral condition. Repeated interrupts usually indicate the opposite problem: the event remains asserted because the status flag was not cleared, the device was not read, or the controller’s in-service state was not completed correctly. Wrong-handler symptoms point toward vector-base corruption, an incorrect autovector assumption, or a conflict with resident software.

Testing should be incremental. Begin with one source and a minimal handler that increments a counter or records a timestamp. Add a second source only after the first is stable. Test both simultaneous events and sustained load, because priority bugs often remain hidden during isolated testing. Keep a record of the original system state so a failed experiment does not leave the machine with altered vectors or masks.

Practical Rules For Developers And Restorers

The following practices make interrupt work safer on original machines and modern expansion hardware:

• Document every register, bit, CPU level, and vector involved before changing system software.
• Keep high-priority handlers short, deterministic, and free from operations that may block.
• Distinguish pending, enabled, masked, and in-service states during diagnosis.
• Test simultaneous requests, nested interrupts, and long-running background activity.
• Restore vectors, MFP configuration, and processor masks when a utility exits or unloads.

The most reliable designs also expose a controlled fallback. A diagnostic mode can disable a new source, select a conservative interrupt level, or route events to a logging handler. This is particularly useful for a repaired power system or an expansion board whose behavior is still being characterized.

Interrupt knowledge connects hardware preservation with software preservation. A machine can boot correctly while still having marginal interrupt timing, an incorrectly restored MFP configuration, or a custom board that interferes with an original peripheral. Recording those details makes future repair work more repeatable and helps maintain compatibility with the software ecosystem.

Keep Exploring The X68000 Interrupt Architecture

The interrupt controller is a small part of the X68000, yet it links the processor, peripherals, operating system, and expansion bus into one timing-sensitive system. Once CPU levels, MFP source priority, vector delivery, and handler behavior are considered together, symptoms such as missed ticks or unexplained lockups become much easier to interpret.

For schematics, repair notes, hardware projects, and continuing preservation work, visit X68K.NET projects. Apply the priority model to one interrupt source at a time, document the results, and add your findings to the practical record that keeps the X68000 usable for the next generation of enthusiasts.