PPU render timing basic questions

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

User avatar
Petruza
Posts: 311
Joined: Mon Dec 22, 2008 10:45 pm
Location: Argentina

PPU render timing basic questions

Post by Petruza » Sun May 16, 2010 8:35 am

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!

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Re: PPU render timing basic questions

Post by Disch » Sun May 16, 2010 8:48 am

Petruza wrote: 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.

User avatar
Petruza
Posts: 311
Joined: Mon Dec 22, 2008 10:45 pm
Location: Argentina

Re: PPU render timing basic questions

Post by Petruza » Sun May 16, 2010 9:04 am

Disch wrote:
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
Posts: 22052
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: PPU render timing basic questions

Post by tepples » Sun May 16, 2010 9:07 am

Disch wrote: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.

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Re: PPU render timing basic questions

Post by Disch » Sun May 16, 2010 9:16 am

tepples wrote: 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.

User avatar
Petruza
Posts: 311
Joined: Mon Dec 22, 2008 10:45 pm
Location: Argentina

Re: PPU render timing basic questions

Post by Petruza » Sun May 16, 2010 9:33 am

Disch wrote:
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?

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Re: PPU render timing basic questions

Post by Disch » Sun May 16, 2010 9:50 am

Petruza wrote: 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.

User avatar
tokumaru
Posts: 11858
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: PPU render timing basic questions

Post by tokumaru » Sun May 16, 2010 10:09 am

Disch wrote: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.

User avatar
Petruza
Posts: 311
Joined: Mon Dec 22, 2008 10:45 pm
Location: Argentina

Re: PPU render timing basic questions

Post by Petruza » Mon May 17, 2010 6:11 am

Disch wrote:
Petruza wrote: 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 ?

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Mon May 17, 2010 6:26 am

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
Posts: 22052
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon May 17, 2010 6:32 am

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.

User avatar
Petruza
Posts: 311
Joined: Mon Dec 22, 2008 10:45 pm
Location: Argentina

Post by Petruza » Mon May 17, 2010 7:20 am

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

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Mon May 17, 2010 9:45 am

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.

User avatar
Petruza
Posts: 311
Joined: Mon Dec 22, 2008 10:45 pm
Location: Argentina

Post by Petruza » Mon May 17, 2010 9:59 am

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
Posts: 22052
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon May 17, 2010 11:59 am

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.

Post Reply