Blargg's 7.nmi_timing.nes test

My emulator is still experiencing problems with NMI timing and I'm comparing it to Nintendulator's log to better understand the issues.

Here's a snippet of Nintendulator's log for 7.nmi_timing.nes:



The CPU in my emulator runs one CPU cycle at a time as opposed to advancing by the cycle length of each instruction. (It is based on this link.) And, for testing purposes, I can advance the PPU by 3 PPU cycles (for NTSC) before advancing the CPU by 1 CPU cycle or vice versa.

Nintendulator could print each statement just prior to the first CPU cycle of each instruction or immediately after the first CPU cycle. Meaning, it could print out the statement before the opcode fetch or after it. The effect is the same as running the PPU 3 cycles in advance of the CPU or after it.

The BIT instruction takes 4 CPU cycles to complete and it starts on PPU cycle 330, toward the end of the scanline, just before PPUSTATUS.7 is set. The read from the immediate address ($2002) occurs on the fourth CPU cycle. The break down should happen something like this:



According to the NTSC PPU Frame Timing Diagram, PPUSTATUS.7 is set on PPU cycle 1 of scanline 241. How is that captured by BIT?

Correct me if I'm wrong, but I think these tests assume a certain PPU-CPU alignment. It could be the case that no emulator will ever get all the tests to pass without also simulating those alignments (and the reset behavior that selects between them). To my knowledge, no emulator even attempts to emulate more than one alignment.

Nintendulator and Nestopia consistently pass all of Blargg's NMI tests. And, a real NES supposedly can pass them all also.

In my emulator, Battletoads stage 2 freezes at random points due to an occasionally missed sprite 0 hit. I'm pretty certain it's a consequence of NMI timing since it fails Blargg's tests. At that point in the log, my emulator has yet to set PPUSTATUS.7. I do not understand why Nintendulator set it even after studying its source code.

It's a matter of PPU timing - if it's clocked before or after a CPU read/write. Yes, it does a difference.

Does Nintendulator run the CPU one CPU cycle at a time or does it jump ahead by the number of cycles in each instruction? The way the source is organized seems to suggest the second option, but I could be reading it wrong.

AFAIK, it does cycle by cycle, and the NTSC PPU runs for 3 cycles at each CPU memory access (read/write). It has, however, a frameskipping feature, but no clue if related.

I think I finally understand how Nintendulator produced that output. The CPU drives the PPU and APU. Every CPU cycle is associated with a memory read or a memory write. The CPU updates the PPU and APU in the read and write functions just prior to the memory access. It is structured in this unusual way because of the DMC transfer, which must wait for a read cycle. In addition, this CPU design avoids the need to maintain a state machine; instead of tracking the instruction cycle, it just counts the number of memory accesses after an instruction completes for timing purposes.

The scanline cycle number printed out in the log is the last PPU cycle that executed, not the next PPU cycle to be executed. So, the sequence behaves as follows:



To produce the same logs, I would have to modify my CPU to execute in that sequence. I am currently using a state machine. Nintendulator's CPU design likely runs a lot faster.

See?

I transformed the state machine in my CPU implementation into the model used by Nintendulator. And, I subsequently was able to compare logs to patch the NMI issue. My emulator now passes all the vbl_nmi_timing test roms.

I moved onto the ppu_vbl_nmi tests. It currently fails 07-nmi_on_timing.nes. But, Nintendulator fails as well in exactly the same way:



WTF?

It's a perfect timing about setting the VBlank flag 1 cycle before/after NMI enable ($2000 write). Plus, you can't set NMI on PPU cycle 0 (right after the 341th cycle).

After patching the NMI issues, my emulator still experiences problems with Battletoads stage 2. It does not seem to freeze any more, but occasionally the player and the enemies become invincible; neither can attack each other, rendering the stage unplayable after that happens. Also, in The Simpsons: Bart vs. the Space Mutants, the status bar at the bottom of the screen shakes.

My emulator seems to pass all the NMI and sprite 0 hit tests that Nintendulator passes. Can anyone suggest a test ROM that I should try?

So, what was the problem?


Are you sure about NOT allowing presses like up+down or left+right?



I'm quite positive it's related with MMC3 IRQ timing.



Nope. Mine has the same problems... and I'm looking for something more precise for testing.

Interesting. Actually, I did not add such a check. What makes you think there is a connection?

Edit: I just ran some tests. Pressing up+down in the Wookie Hole (stage 2) kills the player instantly. Pressing left+right creates the invincibility state that I described above. Also, I see that the wiki lists this as a known issue. Zepper, I think you might have solved one of my problems! Thanks.

Edit 2: With that check in place, Battletoads stage 2 runs fine. Thanks so much. As for what I did to the NMI issues, I only got it to perform as well as Nintendulator as mentioned above. And, that was achieved by making my emulator generate the same log format and then doing repeated diffs. The source code for Nintendulator provided many answers. For the Simpsons, I think it uses MMC2, not MMC3. I'll investigate the possibility that it is a mapper issue rather than an NMI issue. Thanks again.

Edit 3: Further testing revealed that it can still freeze. Nonetheless, this solved a contributor of the problem.

I stand corrected: MMC1. But, more importantly, it is not an MMC3 issue.

Yup. My emu has the same problem of shaking the scorebar. It's probably related with sprite zero hits (Battletoads misses sprite zero hits, freezing the game).

In the latest beta version of Nintendulator, the status bar at the bottom on the screen in The Simpsons - Bart vs. the Space Mutants shakes as well. But, it doesn't in the latest official release.

Edit: Furthermore, the Wookie Hole (stage 2) of Battletoads freezes in the latest beta release. I can't pinpoint the change that broke these 2 games, but I found that delaying the sprite 0 hit flag by 1 PPU cycle prevents the status bar in The Simpsons from shaking. That is, it is almost as if the sprite 0 hit flag has an intermediate latch that delays the PPU register $2002 (PPUSTATUS) update by 1 PPU cycle.

Edit 2: With the intermediate sprite 0 hit flag latch in place that delays the PPUSTATUS register update by 1 PPU, it passes all the sprite 0 hit tests, including the timing related tests.

Edit 3: Battletoads still freezes even with that change.

@ Quietust

If you get a chance, please test Battletoads stage 2 and The Simpsons - Bart vs. the Space Mutants in the latest beta of Nintendulator.

It works, but here these tests have failed - 5. left clipping (#2) and 11. edge timing (#2).

I think I found a way to fix both games in the latest Nintendulator beta. The MemGet function is organized like this:



I moved the final operation to the top:



Here's the actual modified code:



I have not been able to freeze Battletoads stage 2 after this change. And, the status bar no longer shakes in The Simpsons - Bart vs. the Space Mutants.

I did not modify SetMem. In fact, if I reorganize SetMem in an analogous way, the freezing problem reappears.

With that change, it passes all the Sprite 0 Hit tests. (@ Zepper: Ignore what I said about the sprite 0 hit latch theory.)

However, Nintendulator still does not pass all of Blargg's NMI tests. But, the prior version never was able to pass all the tests anyway.

Edit: It looks like I spoke too soon. That changes makes Battletoads far more stable. But, after a dozen runs through the Wookie Hole, it finally froze. I wonder if the older version of Nintendulator also has this issue.

I continued to play around with the Nintendulator source versions trying to further understand what change made the beta less stable. In the current release (Nintendulator 0.970), the coarse X increments occur every PPU cycle % 3. Whereas, in Nintendulator 0.975 Beta, it was adjusted to PPU cycle % 7, making it more authentic. Perhaps, more significantly, the Y increment was changed from PPU cycle 251 to 255. Both are shifted by 4 PPU cycles. Consequentially, the increments happen at least 1 CPU cycle earlier in the current release.

The Battletoads and The Simpsons issues are both sprite 0 hit related. And, this slight timing difference is the only explanation I can find for why the beta appears less accurate. As noted earlier in the thread, this may have be fudged to some extent since CPU and PPU cycles cannot execute simultaneously.