When the MOS 6502 processor was modified into the Ricoh 2A03 chip for the NES, the BRK (Force Break) opcode was preserved. As on other 6502 family CPUs, the BRK instruction advances the program counter by 2, pushes the Program Counter Register and processor status register to the stack, sets the Interrupt Flag to temporarily prevent other IRQs from being executed, and reloads the Program Counter from the vector at $FFFE-$FFFF.
Thus a BRK can have any of several effects, depending on where the IRQ vector points:
- RTI instruction
- BRK behaves as a 13-cycle NOP: 7 for the BRK and 6 for the RTI.
- Invalid code or an infinite loop
- The game will freeze.
- Raster interrupt handler
- The raster will be triggered prematurely, causing incorrect scrolling.
- A system call handler
- Because BRK advances the Program Counter by 2 bytes, each BRK instruction can be thought of as containing a signature byte that the 2A03 itself ignores: BRK #$5A, BRK #$00, BRK #$FF. A program could decide which function to call based on this signature.
Like the PHP instruction, the BRK instruction pushes the processor status register on the stack with bit 4 set to 1. This way, the program can distinguish a BRK from an IRQ, which pushes the status with bit 4 cleared to 0.
Most NES games do not intentionally use BRK. Thus when you see a BRK in disassembled NES code, you can be fairly certain that the #00 value is either game data or unused, with a few exceptions.
|Addressing Mode||Assembly Language Form||Opcode||# Bytes||# Cycles|
- Hiryu no Ken Special uses the "system call" approach: BRK performs a subroutine call from one bank to another. Other games by Culture Brain may as well.
- Lizard by Brad Smith displays a register dump when BRK is executed.
- "BRK same as NOP in 2A03, right?" from NESdev BBS