is it right to emulate 3 ppu cycles every 1 cpu Cycle?
Cos i emulate OpcodeCycle * 3, ppu cycles
thanks
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]
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)