PPU render timing basic questions

[Petruza]

Source: Brad Taylor's NTSC 2C02 tech ref
(This post implies NTSC)

I finished the CPU emulation, and heading now towards the PPU.
I'm finding the PPU render timing really complex, so I want to know if I understand it at least roughly so I can start to figure out how to implement it.

So What I understand is this:
Each CPU cycle equals 12 PPU cycles, CPU runs at 1.79 Mhz and PPU at 21.47 Mhz.
The source of timing in my emulator are the instructions that are being executed, so for each CPU cycle executed in its instructions, I advance the PPU renderer 12 cycles.
Each pixel takes 1 PPU cycle, so each scanline takes 341 PPU cycles including hblank.
There are 262 scanlines including vblank period, so a frame occurs every 89342 PPU cycles.
89342 / 12 = 7445.17, so each 7445.17 CPU cycles are executed, I trigger an NMI.
What I never saw in a doc is when I have to start counting down to the first NMI, so I guess it's from the first ever cycle executed by the CPU, that's the first cycle of the first instruction at the RESET address.

Is this right? did I get something wrong?
Thanks!

[Disch]

Each CPU cycle equals 12 PPU cycles, CPU runs at 1.79 Mhz and PPU at 21.47 Mhz.

No.

1 NTSC CPU cycle = 3 PPU cycles
1 PAL CPU cycle = 3.2 PPU cycles

In order to work with these ratios, I employed a "master cycle" system, where:

1 NTSC CPU cycle = 15 "master cycles"
1 PAL CPU cycle = 16 "master cycles"
1 PPU cycle = 5 "master cycles"

Basically you multiply passing CPU cycles by 15 (or 16 if emulating PAL), and multiply passing PPU cycles by 5... then your timestamps are using the same base.

The source of timing in my emulator are the instructions that are being executed, so for each CPU cycle executed in its instructions, I advance the PPU renderer 12 cycles.

That's a slow way to do it, but yeah that's the basic idea.

Each pixel takes 1 PPU cycle, so each scanline takes 341 PPU cycles including hblank.

Yes... but "HBlank" is kind of a subjective term.

The PPU is actively performing fetches, and updating counters and stuff during the first 340 cycles of every scanline. It only draws pixels for the first 256 cycles.

There are 262 scanlines including vblank period, so a frame occurs every 89342 PPU cycles.
89342 / 12 = 7445.17, so each 7445.17 CPU cycles are executed, I trigger an NMI.

You have the right idea, but your numbers are a bit wrong.

341 * 262 = 89342 PPU cycles per frame
89342 * 5 = 446710 "master cycles" per frame
446710 / 15 = 29780.667 NTSC CPU cycles per frame

Basically your CPU is running way too slow.

What I never saw in a doc is when I have to start counting down to the first NMI

IIRC the frame starts some time into VBlank. I don't remember exactly where. blargg wrote a test ROM on it I think.

Is this right? did I get something wrong?
Thanks!

For the most part you understand it correctly. Your numbers were just a little off.

[Petruza]

The source of timing in my emulator are the instructions that are being executed, so for each CPU cycle executed in its instructions, I advance the PPU renderer ** cycles.

That's a slow way to do it, but yeah that's the basic idea.

So what would be a better/faster way?

I like your idea of master cycles, I'll use it.

I guess I'll start the rendering loop together with the first CPU instruction, and having rendering disabled by default, until the program turns it on.
I guess that although rendering is turned off by the program, the vblank countdown is not altered, right?

[tepples]

1 NTSC CPU cycle = 3 PPU cycles
1 PAL CPU cycle = 3.2 PPU cycles

In order to work with these ratios, I employed a "master cycle" system, where:

1 NTSC CPU cycle = 15 "master cycles"
1 PAL CPU cycle = 16 "master cycles"
1 PPU cycle = 5 "master cycles"

On NTSC, 1 CPU cycle is 12 master cycles and 1 PPU cycle is 4 master cycles. The only CPU with a divide by 15 is Dendy, a famiclone popular in Russia, or any famiclone based on a similar chipset, and its ratio of 15/5 was chosen to equal the 12/4 ratio of an authentic Famicom or NTSC NES yet still output PAL video. But only mappers that depend on cartridge pin 37 (SYSTEM CLK) can tell the difference between 12/4 and 15/5.

Yes... but "HBlank" is kind of a subjective term.

The PPU is actively performing fetches, and updating counters and stuff during the first 340 cycles of every scanline. It only draws pixels for the first 256 cycles.

HBlank as used in descriptions of NES hardware is any part of the scanline that is not dots 0-255.

[Disch]

On NTSC, 1 CPU cycle is 12 master cycles and 1 PPU cycle is 4 master cycles.

Hence why I put master cycles in quotes.

They're not real cycles, they're just a fabricated timestamp system to keep everything in the same base units.

12/4 doesn't work well with PAL, whereas 15/5 does.

HBlank as used in descriptions of NES hardware is any part of the scanline that is not dots 0-255.

But in other descriptions it's time similar to VBlank where writing to the PPU is safe. Of course the NES has no such time between scanlines because it's always busy fetching.

[Petruza]

HBlank as used in descriptions of NES hardware is any part of the scanline that is not dots 0-255.

But in other descriptions it's time similar to VBlank where writing to the PPU is safe. Of course the NES has no such time between scanlines because it's always busy fetching.

So no writes to VRAM can be made between scanlines? at least scrolling writes can be made, or at least that's how I always thought mid-frame scrolling effects were made.

Even if I don't get PPU timing totally accurate, games that don't use mid-scanline or mid-frame effects other than sprite 0 hit test, will work well anyway, right?

[Disch]

So no writes to VRAM can be made between scanlines? at least scrolling writes can be made, or at least that's how I always thought mid-frame scrolling effects were made.

Yes. $2003, $2004, $2007 are all offlimits during rendering

All other $200x regs can be accessed at any time.

Even if I don't get PPU timing totally accurate, games that don't use mid-scanline or mid-frame effects other than sprite 0 hit test, will work well anyway, right?

Yes you don't have to be super accurate for most games to run. But the more accurate you are, the less chance of visual glitches and shaking status bars.

[tokumaru]

But the more accurate you are, the less chance of visual glitches and shaking status bars.

Although some games made back in the day did include such "features" when running on actual hardware.

[Petruza]

Each CPU cycle equals 12 PPU cycles, CPU runs at 1.79 Mhz and PPU at 21.47 Mhz.

No.

1 NTSC CPU cycle = 3 PPU cycles
1 PAL CPU cycle = 3.2 PPU cycles

I'm confused, so why does the NTSC PPU run at 21.47 Mhz which is 12 times the 1.79 Mhz of the CPU ?

[blargg]

The PPU pixel rate is not 21.47 MHz; it's 3 times the CPU rate for NTSC, and 3.2 times for PAL.

[tepples]

The NES PPU can display twelve distinct hues. The hue signal generator (see NTSC video) needs a clock signal with twelve edges for each cycle of the color subcarrier, which in the case of NTSC is 3.58 MHz. So the master clock is always set at six times the subcarrier's frequency, which provides the desired signal with six rises and six falls. Only the hue generator uses this clock signal directly; it is divided down by 4 (NTSC) or 5 (PAL) before it hits the rest of the PPU.

[Petruza]

Ok, so the 21.47 Mhz is some sort of video clock signal I shouldn't care about.

[blargg]

It depends on how accurately you're emulating the PPU. As I mentioned in another post, the fact that it's running at 21.47 MHz affects the various synchronizations it powers up in relative to the CPU.

[Petruza]

Ok, but 21.47 Mhz means that something occurs once every 21,470,000 th of a second. We already stated that that are not PPU cycles, so what are they?

[tepples]

They are master clock cycles.

Depending on the phase of the moon at power-on, the CPU clock (master/12) can be delayed by 0, 1, 2, or 3 master clock cycles from the dot clock (master/4). This can cause a program that depends on certain edge cases to behave differently from one reset to the next.