It is currently Sun Jul 15, 2018 11:17 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 31 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Sat Mar 07, 2015 4:47 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 772
Location: New York, NY
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.


Top
 Profile  
 
PostPosted: Sat Mar 07, 2015 6:03 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3124
Location: Brazil
Of course. ^_^;; My emu is also cycle-precision accurate. Nintendulator too... and both with the same problem. 8-) :roll:


Top
 Profile  
 
PostPosted: Sat Mar 07, 2015 7:14 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 772
Location: New York, NY
Zepper wrote:
Of course. ^_^;; My emu is also cycle-precision accurate. Nintendulator too... and both with the same problem. 8-) :roll:


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.


Top
 Profile  
 
PostPosted: Mon Mar 09, 2015 9:59 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 772
Location: New York, NY
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.


Top
 Profile  
 
PostPosted: Mon Mar 09, 2015 6:02 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 772
Location: New York, NY
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.


Top
 Profile  
 
PostPosted: Mon Mar 09, 2015 7:15 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3124
Location: Brazil
I can provide a log (using my emulator) if you want. ^_^;;


Top
 Profile  
 
PostPosted: Mon Mar 09, 2015 7:30 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 772
Location: New York, NY
Zepper wrote:
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.


Top
 Profile  
 
PostPosted: Mon Mar 09, 2015 9:35 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3090
Location: Tampere, Finland
The widely circulated nestest log is from Nintendulator.

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


Top
 Profile  
 
PostPosted: Tue Mar 10, 2015 7:24 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3124
Location: Brazil
zeroone wrote:
Zepper wrote:
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.


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?


Top
 Profile  
 
PostPosted: Tue Mar 10, 2015 8:07 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 772
Location: New York, NY
Zepper wrote:
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?


Image

Yikes!


Top
 Profile  
 
PostPosted: Tue Mar 10, 2015 10:10 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 772
Location: New York, NY
That screwed up image above turned out to be a MMC3 mirroring issue.

Image

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.


Last edited by zeroone on Tue Mar 10, 2015 10:50 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Mar 10, 2015 10:31 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 772
Location: New York, NY
One more thing. Here's an image with my 40 CPU cycle NMI delay hack:

Image

And, what happens without it:

Image


Top
 Profile  
 
PostPosted: Tue Mar 10, 2015 10:39 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20249
Location: NE Indiana, USA (NTSC)
zeroone wrote:
The MMC3 docs do not mention how to configure 4-screen mirroring.

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


Top
 Profile  
 
PostPosted: Tue Mar 10, 2015 10:49 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 772
Location: New York, NY
tepples wrote:
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.


Top
 Profile  
 
PostPosted: Wed Mar 11, 2015 6:00 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 772
Location: New York, NY
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:

Code:
$FC5A:4C 5A FC  JMP $FC5A


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?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 31 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group