Alright, after (effectively) disabling the latch filter on my device, I was able to verify this using your poll-based dump.
----
I wanted to know what the difference was. First of all, the polling sequence done by the game is fairly typical. No non-standard polling, or weird clocks, etc. Each frame consists of: Latch, clock*8 player 1, clock*8 player 2, Latch again, clock*8 player 1, clock*8 player 2. Though the time when the polls appear within a frame changed wildly.
So I compared your poll-based dump, and my frame-based dump, by incrementing through each set of inputs on a frame by frame basis. Thus your dump should theoretically have two identical sets per frame, which should match the frame-based dump. Based on the
analysis here, I found the first difference.
I traced this moment back to roughly movie frame #2719. Which is the point where the player performs the first glitch of the run. Using onmemoryread/onmemorywrite in a lua script for memory address 0x4016, I found that on most frames, just as seen on hardware, 2 latches occur as described earlier. But on frames #2715 and #2716 of the emulator, only 1 latch occurs on each. I located where this was happening on hardware, and
it turns out that VSYNC occurs after the 1st latch's polling sequence, causing a short delay (~0.5ms) until the 2nd latch occurs, and is why only 1 latch appears on these frames on emu. Trying to change the latch filter to account for this, didn't work, and seemed to consistently change which frames get this collision..
----
If we think about frames as being wholly separate from each other, then theoretically the frame-based dump should have still worked. The reason it didn't in practice, is because the latch-filter is much too large for this odd case (which happens multiple times throughout the run), and a single value may not be sufficient. To me, this throws into question why some of us even bother using a latch filter at all. Perhaps in the past, it was necessary because emulators weren't accurate enough? Also makes me wonder if using a poll-based dump would allow me to verify TASes that have failed for me in the past.
I'm going to try to get a full game run of Tiny Toons working next, then probably Ninja Turtles if that works.
This isn't quite the last step for DMC games, as Time Lord still needs some edge cases worked out, but should be getting really close now.
After fixing numerous subtle bugs in IRQ/NMI handling, i finally have a run of tiny Toons that makes it to the end of the game on console.
The current run is here: http://tasvideos.org/userfiles/info/76487677575343984
Not submittable as a new run in it's current form as it's longer then the published run by a few seconds, and I think with some good luck manipulation it can be a few seconds shorter, but it's a baseline for now.
I believe the only remaining issues involve edge cases of disabling the DMC channel, getting really close to correct DMC emulation now.
Time Lord can now beat the second level on console due to implementing DMC IRQ delay that surprisingly went untested until now, so making progress there as well.
