Ahhhh. That would be a good test for the emulator-specific ones I'm developing. A simple fix for the above is to "read" $2002 just before the end of the frame but without any of the usual side-effects that would usually occur. Your design seems sound to me. If I make progress on a lot of trick emulator-specific tests then you can put it to the test. I'm about to examine my design and come up with things to try to trick it.Disch wrote:The problem is... blargg's demo wasn't reading $2002 during the frame, so my time was never being predicted. $2002 wasn't being read until the next VBlank -- by which time my emu thought it was too early to predict anything (too early in the current frame).
UPDATE: I rewrote many of the tests and added a few more general ones, and added three emulator-specific tests. They should give more precise problem reports now, even if an emulator is really broken. Same archive location as the original:
sprite_overflow_tests.zip