CPU interrupts

Detailed interrupt behavior

The NMI input is edge-sensitive (reacts to high-to-low transitions in the signal) while IRQ is level-sensitive (reacts to the signal level). Both are active low. NMI is polled every CPU cycle (to be able to detect transitions in the middle of an instruction), while IRQ is usually polled during the second-to-last cycle of an instruction (two cycles before the opcode fetch). The polling happens while φ2 is high, so the status of the interrupt lines on the falling edge of φ2 (at the end of the second-to-last cycle, just before the last cycle) matters. If the polling operation detects that the interrupt line has been asserted, the next "instruction" executed is the interrupt sequence. The point where IRQ is polled is also the point where the CPU will register a pending NMI, making NMIs behave similarly to IRQs w.r.t. the behaviors discussed below. (More specifically, any signal on the IRQ line that would trigger an IRQ would also trigger an NMI on the NMI line, barring obscure analog effects.)

Some other references will say interrupts are polled during the last cycle of an instruction. This is true when talking about the internal signals that go high in response to changes on the interrupt pins, but these are delayed relative to the value on the pin, representing the interrupt being detected during φ2 of the preceding cycle.

If both an NMI and an IRQ are pending at the end of an instruction, the NMI will be handled and the pending status of the IRQ forgotten (though it's likely to be detected again during later polling).

The interrupt sequences themselves do not perform interrupt polling, meaning at least one instruction from the interrupt handler will execute before another interrupt is serviced.

Delayed IRQ response after CLI, SEI, and PLP

The RTI instruction affects IRQ inhibition immediately. If an IRQ is pending and an RTI is executed that clears the I flag, the CPU will invoke the IRQ handler immediately after RTI finishes executing. This is due to RTI restoring the I flag from the stack before polling for interrupts.

The CLI, SEI, and PLP instructions on the other hand change the I flag after polling for interrupts (like all two-cycle instructions they poll the interrupt lines at the end of the first cycle, while changing the flag during the second cycle), meaning they can effectively delay an interrupt until after the next instruction. For example, if an interrupt is pending and the I flag is currently set, executing CLI will execute the next instruction before the CPU invokes the IRQ handler.

Verification and testing of this behavior in emulators can be accomplished through test ROM images.

Branch instructions and interrupts

The branch instructions have more subtle interrupt polling behavior. Interrupts are always polled before the second CPU cycle (the operand fetch). Additionally, for taken branches that cross a page boundary, interrupts are polled before the PCH fixup cycle (see [1] for a tick-by-tick breakdown of the branch instructions). An interrupt being detected at either of these polling points (including only being detected at the first one) will trigger a CPU interrupt.

Interrupt hijacking

The MOS 6502 and by extension the 2A03/2A07 has a quirk that can cause one type of interrupt to partially hijack another type if they occur very close to one another.

For example, if NMI is asserted during the first four ticks of a BRK instruction, the BRK instruction will execute normally at first (PC increments will occur and the status word will be pushed with the B flag set), but execution will branch to the NMI vector instead of the IRQ/BRK vector:

Each [] is a CPU tick. [...] is whatever tick precedes the BRK opcode fetch.

Asserting NMI during the interval marked with * causes a branch to the NMI routine instead of the IRQ/BRK routine:

     ********************
[...][BRK][BRK][BRK][BRK][BRK][BRK][BRK]

In a tick-by-tick breakdown of BRK, this looks like

 #  address R/W description
--- ------- --- -----------------------------------------------
 1    PC     R  fetch opcode, increment PC
 2    PC     R  read next instruction byte (and throw it away),
                increment PC
 3  $0100,S  W  push PCH on stack, decrement S
 4  $0100,S  W  push PCL on stack, decrement S
*** At this point, the signal status determines which interrupt vector is used ***
 5  $0100,S  W  push P on stack (with B flag set), decrement S
 6   $FFFE   R  fetch PCL, set I flag
 7   $FFFF   R  fetch PCH

Similarly, an NMI can hijack an IRQ, and an IRQ can hijack a BRK (though it won't be as visible since they use the same interrupt vector). The tick-by-tick breakdown of all types of interrupts is essentially like that of BRK, save for whether the B bit is pushed as set and whether PC increments occur.

IRQ and NMI tick-by-tick execution

For exposition and to emphasize similarity with BRK, here's the tick-by-tick breakdown of IRQ and NMI (derived from Visual 6502). A reset also goes through the same sequence, but suppresses writes, decrementing the stack pointer thrice without modifying memory. This is why the I flag is always set on reset.

 #  address R/W description
--- ------- --- -----------------------------------------------
 1    PC     R  fetch opcode (and discard it - $00 (BRK) is forced into the opcode register instead)
 2    PC     R  read next instruction byte (actually the same as above, since PC increment is suppressed. Also discarded.)
 3  $0100,S  W  push PCH on stack, decrement S
 4  $0100,S  W  push PCL on stack, decrement S
*** At this point, the signal status determines which interrupt vector is used ***
 5  $0100,S  W  push P on stack (with B flag *clear*), decrement S
 6   A       R  fetch PCL (A = FFFE for IRQ, A = FFFA for NMI), set I flag
 7   A       R  fetch PCH (A = FFFF for IRQ, A = FFFB for NMI)

Notes

• The above interrupt hijacking and IRQ response behavior is tested by the cpu_interrupts_v2 test ROM.
• For more quirky behavior related to VBlank NMI's from the PPU, see PPU frame timing.
• The B status flag doesn't physically exist inside the CPU, and only appears as different values being pushed for bit 4 of the saved status bits by BRK and NMI/IRQ.
• For a more technical description of what causes the hijacking behavior, see Visual6502's writeup.