NMI Timing, yours vs the old test #26
Description
Hey there,
Your release coincided with me getting back into an abandoned NES emulator from early/ mid 2023!
I was probably the first person to use your test suite on their emulator, before it blew up with your video release. I noticed that video drop hit hard!
half a mil views in 4 days! last I saw anyway. Congrats! I certainly hope its monetized :P
Now just a little non issue ramble,
I decided to look into the PICONES and found out that was a port of InfoNES across to that specific MCU. I also considered getting the rather expensive flash cart for the NES off ali express to make a cartridge (not a multi game one), but im guessing you could do it cheaply with an old cheapie game cart + EPROM? anyway, it would only be out of curiosity to run on some personal consoles as I used to run mod heavily / run a shop/ ebay shop and have plenty of variants. Unfortunately though, I do have to pass off my PAL toploader to a customer soon and won't be able to trial it on that. Also, InfoNES seems to be quite popular, so it definitely goes to show that there are popular emulators out there that are no where near accurate (it did terribly in tests). Before your video, i did try it on mesen and nintendulator. You never mentioned in your video, but I couldn't run it on nintendulator. It was crashing out, probably just some never used illegal opcode that he hasn't bothered to implement?
I'm hoping people run this on some of the more popular RETRON type emulator consoles as well!
I'm especially hoping to soon see results from the stupidly expensive, its not even obtainable anymore , FGPA NES rendition from Analogue! What was it called again?? the NT Mini NOIR? damn things stupidly priced these days.
Anyway, hello again :)
without going into technical details, and also noting I've been getting my ass absolutely handed to me in video timing tests! currently passing 4 of 7. One pass is a mighty strange hack, so i thought I'd check in with you, as it doesn't make much sense to me. But really, im here because of the 5th test that doesn't pass, and i thought maybe should?
First-
--- NMI at Vblank End ---
I noticed if i cleared VBL @ dot 0 of the pre render scanline, as opposed to dot 1, this one test passed, but then broke a bunch of others.
now, logging, logging, logging and more logging
For this test diag, i just dropped a logger in at scanline 260 checking for NMI edges generated during the test and noticed the last one your test / my emulator generated was at scanline 260, final dot 340 (which would be dot 341 with the zero indexing).
I believe your test expects vblank to be cleared at the very next cycle, which is dot 0 of the pre render scanline (I am calling this scanline 261), hence, moved by Vblank clear here and voila, test passes ...but breaks a bunch of others. So, now i have a hack that checks for NMI edges around the end of vblank, and if there are ones found, i clear VBL a dot early, if not, I clear at the normal dot 1. I think it has something to do with the skipped dot on odd frames with rendering as thats the only place (the logic to jump the dot) that I can reset the flag that indicates "lets clear vblank a dot early", this also makes no sense, but purely though trial and error, with my brain thinking it absolutely defies logic, it worked. (I should be able to clear that flag as soon as the code using it being set as a conditional executes, or anywhere after that in the same frame).
Now this ones likely on me, not the test, again ...worth a mention.
---- NMI Timing ---
Now the test I really want to check in on, NMI timing.
I alternate between your test ROM and some of the more classic ones. i.e. there are scanline tests you don't have and odd/even frame tests your suite is also currently lacking. A rather interesting one that reveals a NES has alternate pixel widths, and which square should actually be shaped as a square or not ....if you are emulating the pixel width correctly (I can't find any emulators that correctly present that square, but i threw in the extra setting on mine).
So anyway, I ran the other NMI timing test in there, knowing it would fail (as it failed on yours) and checked the output. I had a lightbulb in the brain moment, and decided i likely need to create NMI edges a dot early in the first vblank scanline, and, slightly going against NES hardware rules I generate an NMI edge if the PPUCTRL NMI bit is set at dot zero ...BUT not along with VBL bit being set in PPUSTATUS (actual NES hardware rule). Anyway, I'm going to cut to the chase here,
05-nmi_timing.nes now passes (from ppu_vbl_nmi)
your NMI timing test, it fails - devastated.
Your test result output from the test bytes RAM offsets
0050 03 02 02 02 02 02 02 02 02 02 00 00 00 00 00 00
Expected from source (tiny typo there):
TEST_NMI_Timing_Expected_Results:
; With a single CPU/PPU clock alingment, this will be off by 1, starting at the $02 instead of the $03.
.byte $03,$02,$02,$02,$02,$02,$02,$01,$01,$01,$01
Anyway, keep up the good work, I am led to believe at this stage, your test is a little more thorough perhaps? thought it might be worth checking.
now if the logic behind video timing tests was as simple as NESDEV explains
"
Reading $2002 within a few PPU clocks of when VBL is set results in special-case behavior.
Reading one PPU clock before reads it as clear and never sets the flag or generates NMI for that frame. -> done
Reading on the same PPU clock or one later reads it as set, clears it, and suppresses the NMI for that frame. -> done
Reading two or more PPU clocks before/after it's set behaves normally (reads flag's value, clears it,
and doesn't affect NMI operation). This suppression behavior is due to the $2002 read pulling the NMI
line back up too quickly after it drops (NMI is active low) for the CPU to see it.
(CPU inputs like NMI are sampled each clock.)
On an NTSC machine, the VBL flag is cleared 6820 PPU clocks, or exactly 20 scanlines,
after it is set. In other words, it's cleared at the start of the pre-render scanline.
"
video timing would have being finished weeks ago :)
