chitselb wrote:
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?
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.