just a little minor clarification

just a little minor clarification
by hatorijr on 2009-07-15 (#48902)

Hi, i recently started work on a NES emulator, which is coming along very well actually with only minor issues that i am sorting out as i go along.

what i am trying to clarify is not major stuff but it would greatly help me as i am coding this emulator so that i have as accurate emulation as humanly possible.

from all that i have read, a scanline lasts roughly 113 2/3 cpu clock cycles or 341 ppu cycles, except on odd frames(unless rendering is turned off) correct? also total ppu cycles per frame is roughly 89341 ppu cycles or 29780 2/3 cpu cycles correct? reason i ask is at these numbers, the total clock cycles after 60 frames does not add up to the speed of the cpu, its almost 3000 cycles short, is it safe to just leave those out without any real problems? as if some games have tight timing than i would think it would have a very negative affect on such games.

i would be very grateful for any answers to these questions someone could give me.

by Disch on 2009-07-15 (#48907)

Quote:
a scanline lasts roughly 113 2/3 cpu clock cycles or 341 ppu cycles, except on odd frames(unless rendering is turned off) correct?

Correct. All scanlines are 341 PPU cycles (or "dots" as I've grown accustomed to calling them -- curse you Anomie). Except for the "pre-render" scanline, which can be 340 or 341 dots. It's 340 dots on odd frames if the PPU is on, but when the PPU is off (or on even frames), it's 341 dots just like all other scanlines.

Quote:
total ppu cycles per frame is roughly 89341 ppu cycles or 29780 2/3 cpu cycles correct?

Your numbers are correct.

262 scanlines
* 341 dots per scanline
= 89342 dots. It's 89341 only if the pre-render scanline is short (odd frames)

89342 / 3 (3 PPU cycles per CPU cycle) = 29780 + 2/3 CPU cycles.

Quote:
reason i ask is at these numbers, the total clock cycles after 60 frames does not add up to the speed of the cpu

This is because the PPU does not run at exactly 60 FPS, it works out to about 60.1. The framerate can be worked out with the above numbers:

1789772.7272 <-- CPU clock rate
/ 29780.6666667 <--- CPU cycles per frame
= 60.098 <--- frames per second.

Quote:
its almost 3000 cycles short, is it safe to just leave those out without any real problems? as if some games have tight timing than i would think it would have a very negative affect on such games.

You must not remove cycles. If you want to get exactly 60 Hz, then your best bet is to slow down the CPU, but keep the CPU:PPU ratio the same. One side-effect of this is slightly lower-pitched audio, but it will not cause any oddities or timing issues in games.

by hatorijr on 2009-07-15 (#48911)

ok so i was right, those are the exact numbers i had, but the thing is, how can i run it at near 60.1 hz? thats what is confusing me i guess, one document i came across used a timing system where each frame had 50 more clock cycles per second than that, i guess to get around that issue but i would think it would directly affect the ppu sync as well.

i do appreciate you confirming my numbers, now to decide how to handle those last few cycles as liek you said, do not want to throw any away as i already set up my code to handle my cpu instructions going over my limit per frame.

just not sure what to do with the extra 2932 cycles i came up with as throwing those away will cause issues and i would like as accurate emulation as humanly possible.

by Disch on 2009-07-15 (#48915)

Quote:
ok so i was right, those are the exact numbers i had, but the thing is, how can i run it at near 60.1 hz?

The NES outputs the video signal to the television. It can set whatever framerate it wants within the TV's capabilities. I'm not sure how this works out exactly on a hardware level, but the PPU sends video retrace signals and whatnot to tell the television when to start a new frame.

Since the PPU runs slightly faster than the normal 60 Hz, this results in a slightly faster framerate (and I suppose you could say the TV is working harder than normal), but it's within the TV's abilities.

The most important thing for timing is CPU/PPU sync. You can tweak clock rates and refresh rates all you like, and the game's speed will change to match, but it will never cause emulation glitches. It's when you start changing the CPU:PPU ratio that things start screwing up.

Quote:
just not sure what to do with the extra 2932 cycles i came up with as throwing those away will cause issues and i would like as accurate emulation as humanly possible.

If you want accurate emulation just have your framerate be the ~60.1 Hz. You shouldn't have extra cycles and won't have to tweak your clock rates.

In my emulator, I sync to sound. That is, I know that when outputting 44.1KHz audio that one frame occurs (roughly) every 735 samples. So I generate audio "naturally" in my emulator, and watch my output buffer. When the output buffer has room for another 735 samples, I know it's time for another frame.

This produces the expected 60.1 Hz, and avoids sound sync issues.