I came across this yesterday, at http://nesdev.com/6502bugs.txt
*If an interrupt occurs on a BRK instruction, the breakpoint is ignored.

I'm using BRK as a one-byte JSR to get to 6502. The PET ROM also pushes all the machine registers to the stack for me, and there's a corresponding ROM routine at $E600 that restores things before RTI

It's allegedly fixed in the 65C02 and beyond, but I have never heard of it before in my life. Does this mean that every time the jiffy clock IRQ fires off in my PET, it's like a bullet zinging by my code, and if I happen to hit a BRK instruction exactly then, it will process the interrupt instead of the BRK, and then crash into my Sweet16 code pretending it's 6502? Should I be doing SEI BRK all over the place instead of just BRK?

To my knowledge this is only true for an NMI interrupt. You can compensate by also checking the B flag in the NMI vector and if set process BRK after NMI was handled. I know, that contradicts that NMI handling should be as fast as possible.

For IRQ it is the other way round. The IRQ gets handled as BRK but since you haven't cleared the interrupt source IRQ fires again after RTI from the BRK handler. So the IRQ is only delayed.

more: http://visual6502.org/wiki/index.php?ti ... _and_B_bit

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

This problem is unique to the NMOS 6502. If any hardware interrupt hits during the execution of BRK, BRK will be forgotten and the hardware interrupt will take control—this applies to both /IRQ and /NMI. Page 30 of the 65C02 data sheet also notes this anomaly. Regarding the NMOS behavior:

Interrupt vector is loaded; BRK vector is ignored.

In the 65C02, this behavior has been corrected. Again, from page 30 of the data sheet:

BRK is executed, and then interrupt is executed.

The 65C02 behavior also applies to the 65C816 in either mode. Note that the 65C816's COP instruction is a software interrupt like BRK.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!