It is currently Sun Oct 22, 2017 5:05 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: ppu timing...
PostPosted: Wed Jun 08, 2005 12:39 am 
Offline
User avatar

Joined: Tue Dec 21, 2004 8:35 pm
Posts: 600
Location: Argentina
is it right to emulate 3 ppu cycles every 1 cpu Cycle?
Cos i emulate OpcodeCycle * 3, ppu cycles

thanks

_________________
ANes


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 08, 2005 5:23 am 
Offline

Joined: Sat Nov 13, 2004 6:25 am
Posts: 96
Well, AFAIK this is the most accurate scheme for emulating the NES. If I'm not wrong, you do this on that way so.. yeah, that should do it. Anyway, does anyone know if the order matters here? I mean, is it better to run first the CPU and then PPU or viceversa the other way?[/quote]


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 08, 2005 7:27 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
On NTSC, yes -- there are 3 PPU cycles to every 1 CPU cycle. However on PAL systems, that ratio is different -- there are 3.2 PPU cycles to every 1 CPU cycle.

What I do, is I keep what I call a "Master Cycle" rate, which I time everything in.

I multiply all CPU cycles (when in NTSC) by 15
I multiply all CPU cycles (when in PAL) by 16
I multiply all PPU cycles by 5

For example, NOP -- which is normally 2 CPU cycles, takes 30 cycles in my emu when in NTSC, and 32 cycles when in PAL.

I keep a timestamp for the CPU, PPU, and pAPU. As I run the CPU (which should run ahead of everything else -- to answer Muchaserres' question), I tally up all the cycles the CPU executes into the CPU timestamp var. When something is done which could influence the action of the PPU (change in mirroring, CHR swapping, writing to/reading from a PPU reg) -- I "catch up" the PPU -- meaning I temporarily pause my CPU emulation and switch to PPU emulation, where I emulate the PPU for as many cycles as needed, until the PPU timestamp reaches the CPU timestamp.

I do a similar deal with the pAPU. Run the CPU first, then when something is done that could change the pAPU's state (like a register write, or read, or something like that), I 'catch up' the pAPU. Since the pAPU is part of the CPU on the actual machine, it uses the same cycle base (15* for NTSC, 16* for PAL)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 08, 2005 4:55 pm 
Offline
User avatar

Joined: Tue Dec 21, 2004 8:35 pm
Posts: 600
Location: Argentina
thats is a good method.

_________________
ANes


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 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