nesdev.com

I noticed a strange bug in Mesen and Nintaco when running the game Spot.7z <Spot (U) [!].nes>. From the tile screen menu, choose: Select Options. The D-Pad or Select button should be able to move the cursor around the options menu, but they behave quite unresponsively. I did not notice this effect in other emulators.

Any ideas on what's special about this particular screen in this particular game regarding input?

Took a few minutes to check, but haven't figured it out. It works fine in PAL mode.
And most of all, it works fine when running the emulation at full speed instead of 60fps - and I simply can't make sense of that part.

Interesting. In fact, Nintaco also has the same issue; it works with PAL, but not NTSC.

HalfNES also appears to be affected.

The game is probably poorly written in such a way that updating emulated gamepad state only around a certain single point in a frame will cause input changes to be ignored by the game. Try updating state at NMI time instead of near line 0, or vice-versa, to check.

But, it's a loop. If the actual controller hardware is polled once a frame and that recorded state is made available to the controller ports at any time within the loop, how does it matter?

1: Game reads input port, checks for changes from previous state.
2: Emulator updates emulated gamepad state.
3: Game reads input port again to set previous state variables.

With various lengths of time passing between the steps.

At what (x, y) position do writes to $4016 occur in both emulators where the game works and emulators where it fails?

If the game polls the controller ports twice within the same frame and it only looks for changes between those 2 polls, then it would occasionally fail to detect even on real hardware.

Only rarely. Since the total polling routine takes about 30 scanlines you have about a 10% change of this happening on hardware. But in NEStaco there seems to be about a 100% chance, since trace logger indicates that a 'frame' starts at scanline -1 but at that point 1 of the 3 controller polls has already taken place.

It's actually more of a mystery how it ever accepts any input, since this seems like it should fail every time.

Also when I was using trace logger, sometimes the trace would start at random scanlines, I'm not sure why.

EDIT: I should be clear that I am referring to what is happening in NESTaco.

I think I finally understand what might be going on. Mesen polls the keyboard/gamepads every time it needs to update the NES controllers' state. There is no particular point in the frame where this occurs - however, since the frame is executed in a fraction of the time it takes on a real NES (e.g 2-3ms instead of 16ms), the odds of the input changing during the frame is pretty low. If the game expects the input to change between 2 points in the same frame, it's very unlikely that it would (the keypress would need to occur within that window). Odds are you are pressing the controller while the emulation thread is sleeping (between both frames) - this is probably why playing the game with no speed limit fixes the issue.

Sounds like a plausible hypothesis. Any idea how you are going to resolve this?

Can't say I really have any good ideas on how to solve this.
The obvious way to do it is to space out the frame's emulation across the whole 16ms, but Windows is not a real-time OS - you can only expect so much precision from sleeps (e.g not much at all). It would be pretty tricky to do this without potentially causing issues on some computers (the thread may take longer than expected to wake, causing the whole frame to be delivered late, etc.)

At the moment I'm tempted to just ignore the issue, unless it's something that actually happens in several games and hinders gameplay. Of course, this is all assuming that my assumption is correct in the first place.

Quattro Sports has the same problem.

There's probably a simple solution that will take care of Spot and Quattro Sports. The Spot options menu works in FCEUX and FCEUX is well-known for it's FM2 movie format. FM2 is a recording of input that is sampled only once per frame. Meaning, FCEUX is getting away with keeping the controller input values constants throughout entire frames. The likely difference, as mentioned earlier in this thread, is the point that the cached inputs are updated within the frame cycle. If only 2 known games are affected, then that seems like a reasonable engineering solution, even though it's not a perfect one.

Also, when I get a chance, I'll study the exact code to better understand how these games are doing their polling.