Oh, that. Yes, the age-old thing that I used to do in my own (old) code because I assumed the NES did it like the SNES. :/ Anyway, I didn't know that's what "the NMI cancelling reading" referred to. Makes sense now. Thank you! :-)rainwarrior wrote:If you read status from $2002 on the same cycle that the NMI hits, the NMI flag is cleared before the interrupt happens and it's "cancelled", and the read also returns a 0 for vblank status.
It's the reason why you can't really use a bit $2002 polling loop to time a frame, it will only reliably wait "at least" one frame, but if you're unlucky it'll be more.
NOP interrupt polling
Moderator: Moderators
Re: NOP interrupt polling
Re: NOP interrupt polling
Code: Select all
; A taken non-page-crossing branch ignores IRQ during
; its last clock, so that next instruction executes
; before the IRQ. Other instructions would execute the
; NMI before the next instruction.
I just assumed that mixing of IRQ and NMI in Blargg's source comment was a typo. I treat them the same in the branch opcodes anyway.koitsu wrote:Wow, this is the first I've heard of IRQ and NMI differing in behaviour, particularly tied to specific opcodes (re: how the underlying opcodes are implemented in silicon). Yikes.
Re: NOP interrupt polling
No, it wasn't. Did you read the entire test source code? Here's the FULL description...JonteP wrote:I just assumed that mixing of IRQ and NMI in Blargg's source comment was a typo. I treat them the same in the branch opcodes anyway.
Code: Select all
; A taken non-page-crossing branch ignores IRQ during
; its last clock, so that next instruction executes
; before the IRQ. Other instructions would execute the
; NMI before the next instruction.
;
; The same occurs for NMI, though that's not tested here.