These are in the vbl_nmi_timing tests.
6.nmi_disable #7 is 7) NMI should occur when disabled 2 PPU clocks after VBL
7.nmi_timing #3 is 3) NMI occurred 2 PPU clocks too early
It’s the 2nd that makes me think something very unhip is happening, because my V-blank is definitely not occurring any number of PPU cycles off.
In this document (taken using 7.nmi_timing, which suggests my NMI timing is off) I have printed every PPU cycle where V is set, every read to $2002, each read that results in suppression, and each NMI triggination:
https://www.dropbox.com/s/v8hltpq7r5flc ... g.txt?dl=0
V is set on 241,1 (with an NMI) and cleared on 261,1, and nothing can change these PPU timings. As the print-out shows, there are the correct number of PPU cycles taking place.
So this should mean the issue must either be:
#1: That the CPU has lost count of correct cycles while running the tests or;
#2: There is an edge case I am not covering such as a 2-cycle delay between something being set on the CPU/PPU and being seen by the PPU/CPU.
The problem with #1 is:
#1: My CPU passes all CPU tests, including all 2,550,000 of these: https://github.com/TomHarte/ProcessorTe ... in/nes6502
Every single opcode is verified to be completely cycle-accurate, and each cycle is verified to be correctly a read or write cycle, each read and write reads from or writes to the correct address, and all register and memory side-effects are known to be correct for every single instruction.
#2: It doesn’t seem to have any timing issues with the previous checks that the vbl_nmi_timing test ROM’s make. For 6.nmi_disable, I got stuck on previous error codes and had to make modifications to get past them. The modifications made sense and it seemed as if the whole test ROM was working perfectly fine. Until it gets to test #7 and refuses to succeed even though I definitely don’t disable NMI if $2002 is read on 241,3+. Rather, it appears in those cases that NMI doesn’t fire because the NMI flag is not set.
BUT I don’t have a working APU yet, so the only interrupt happening is for NMI. The APU interrupts didn’t seem to cause troubles in the previous checks for each ROM and I can’t imagine that the APU would be set to send interrupts during CPU cycle-timing operations.
Could it be a CPU cycle-timing issue?
An edge-case where some register read/write is supposed to be delayed by some cycles?
Why is the NMI flag disabled during most of the reads in the linked log file? For example:
Code: Select all
VBlank Set: 261, 0. Frame: 20
Write $2000 NMI ON: 240, 299. Frame: 21
NMI TRIGGINATED: 241, 1. Frame: 21
VBlank Set: 241, 1. Frame: 21
VBlank Set: 241, 2. Frame: 21
VBlank Set: 241, 3. Frame: 21
…
REad $2002: 240, 324. Frame: 22
NMI NOT TRIGGINATED DUE TO FLAG: 241, 1. Frame: 22
VBlank Set: 241, 1. Frame: 22
VBlank Set: 241, 2. Frame: 22
VBlank Set: 241, 3. Frame: 22
VBlank Set: 241, 4. Frame: 22
REad $2002: 241, 4. Frame: 22 <- The read doesn’t suppress NMI, but the NMI flag isn’t set.
Write $2000 NMI OFF: 241, 46. Frame: 22
L. Spiro