nesdev.com

My emulator contains a table of instruction cycles, but it failed to account for the 7 cycle overhead needed to handle IRQ/NMI requests. We might want to add a note to the wiki to alert future emdevs.

http://www.6502.org/tutorials/interrupts.html#1.3

Sadly, accounting for these extra cycles did not fix my Micro Machines timing issue.

This may also be relevant.

Of course. ^_^;; My emu is also cycle-precision accurate. Nintendulator too... and both with the same problem.

There is still something wrong with the timing of my emulator. It sets NMI_occurred at dot 1 of scanline 241, but it intentionally delays the NMI until dot 150 of that scanline (~50 CPU cycles after it probably should be executed). Without that delay, the text boxes in Marble Madness do not get rendered correctly. I also found other minor glitches appear in games without that exact delay. I assume I'm not accounting for 50 CPU cycles somewhere and a few games start counting cycles from the start of NMI.

I compared my CPU emulation against the nestest log. All the values match perfectly. I was really hoping the timing would be off. Now, I'm a bit stuck.

How was the nestest log generated? FCEUX's trace log does not appear to contain cycle timings. If I had a way to make a log like that from an emulator that properly renders the text boxes in Marble Madness, I could compare it against a log from my emulator.

I can provide a log (using my emulator) if you want. ^_^;;

That's greatly appreciated.

I'm trying to think of the best way to capture this. I am interested in the rendering of the text boxes in Marble Madness that appear at the beginning of the stages. I'm not exactly sure how we can sync this up properly. Maybe start recording as soon as the text box appears and stop shortly afterwards. I might be able to sort it out from there.

Further analysis shows that my emulator is failing to account for about 40 CPU cycles. Specifically, it should take 40 CPU longer from time that NMI occurs to the time that it renders those text boxes on the next frame. I don't know if it means that the CPU is suspended for 40 additional cycles or if the timing of some of my instructions are off. But, as mentioned, my timing matches the nestest log file. So, it might be some overhead outside of instruction timing such as the 7 CPU cycles that I discovered were necessary for NMI/IRQ handling.

The widely circulated nestest log is from Nintendulator.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi

Hmm... In my emulator, the text box is glitched in the left side.
Mind you to try Rad Racer 2 and take a screenshot of the road?

Yikes!

That screwed up image above turned out to be a MMC3 mirroring issue.



According to threads on this forum, Rad Racer II should have 4-screen mirroring. I hardcoded that as a test and it produces a clean road with and without my 40 CPU cycle NMI delay hack.

The MMC3 docs do not mention how to configure 4-screen mirroring. I'll have to research that further.

Edit: The iNes file flags 6 specifies that it is a four-screen VRAM game. I modified my MMC3 mapper to not allow the game to control the nametable mirroring when the file specifies four-screen.

One more thing. Here's an image with my 40 CPU cycle NMI delay hack:



And, what happens without it:

Thank you for reporting this omission. It has been corrected.

Wow! That was fast. I don't know if there is a better way to do this. But, if the ROM is marked as MMC3, that flag is probably the only information available to make the determination.

FCEUX 2.2.2 provides better trace logging that includes instruction CPU cycles. I started recording when the text boxes appear at the start of the first stage of Marble Madness and I compared that log against a log from my emulator.

When I delay the NMI handler by 40 CPU cycles, not only does it fix the rendering, but every instruction matches up between the logs cycle-per-cycles. Each frame ends with a spin lock waiting for the next NMI:



Consequentially, delaying the NMI handler by 40 CPU cycles ultimately results in that spin lock spinning 13 fewer times.

If I remove the NMI handler hack and let NMI take place on dot 1 of scanline 241, the text box rendering gets screwed up, but still every instruction matches up between the logs cycle-by-cycle until it reaches the sprite 0 hit test at the bottom of the frame. Marble Madness appears to use a sprite 0 hit test to hide the last few scanlines, presumably to conceal graphical artifacts that would result from vertical scrolling.

In this case, the loop that is waiting for the sprite 0 hit test absorbs the difference. In fact, if I add a hack to delay setting of the sprite 0 hit flag by 40 CPU cycles, then the logs once again fully match up. This suggests that the CPU instruction timings are correct, including things like OAM DMA stalls.

How could the rendering be out of sync with the processor by 40 CPU cycles if the timings are valid?