I wrote this very quick/simple visual test as a very rough start. This generates a sprite 0 hit, waits a configurable number of cycles, then writes $2001 to set the greyscale flag, giving a visual indication of where that occurs. This is intended to give a rough estimate of where emulators think the horizontal blank is, and maybe try to shed some light on the question "how much can I trust an emulator with hblank timing?
In this initial rough test, I determined where the first and last "off-screen" delay settings appear:
Code: Select all
My NES/Famicom: $13-$29
FCEUX New PPU: $10-$28
Nintendulator: $12-$28
nestopia: $13-$28
So, I mean this is hopeful looking at least. In general emulators seem to agree where the end of hblank is relative to a sprite 0 hit, at least at the CPU cycle granularity. I think Nestopia and Nintendulator are very close to each other, like maybe 1 pixel different at either end, and both seem to show the change about 2 pixels later than my NES. (The CPU cycle counts above exaggerate the difference slightly, but I'm not sure how accurately I can measure pixels visually on my TV at the moment.)
FCEUX's New PPU has an 8-pixel granularity on its rendering, so I think that mostly accounts for the difference in its low delay value (i.e. the appearance of the write is delayed up to 8 pixels anyway, 2.6 cycles).
My NES and Famicom appear to be consistent with each other.
In the debuggers, however, the FCEUX's "pixel" value seems to be about 25 higher than Nintendulator's "tick" value, and I don't know why. I'm not sure if this is just a different numbering convention or what... will have to investigate.
So that's just one quick test trying to see if there's much variability between emulators. It could easily be adapted to investigate whether the timing consequences of other effects diverge, scroll changes, palette changes, etc. (i.e. things which may have their specific timings emulated differently) the source is included if you want to modify it for different tests.