PPU scanline cycles question

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
PPU scanline cycles question
by on (#41139)
So I spent last weekend getting a PPU working. I can now see some basics, but I still have a way to go. Much thanks to all you guys who have contributed so much solid information.

I am trying to figure out the proper behaviour for each PPU cycle of a visible scanline.

I checked the wiki and it has some very detailed information about sprite evaluation, but I am unclear as to how normal background rendered happens.

Here is what I have read:
- There are 341 PPU cycles per visible scanline (theres an anomaly on the 20th scanline, which I assume is the scanline BEFORE the visible scanlines start and only affects NTSC)

- Each pixel is 1 PPU cycle. So is this the first 256 cycles?

I assume yes based on the following conversation between Disch and Quietrust a long time ago:
0 based
PPU X address is incremented no earlier than every 3rd cycle on the scanline (3, 11, 19, etc)
PPU Y address is incremented on cycle 251
PPU X address is reset on cycle 257

I dont completely understand the "3" or why Y increments before X unless part of those cycles are in setting up a buffer of some sort.

Is there interleaving between background rendering, and sprite evaluation for the next scanline, or are both done (in some cases) on the same PPU cycle? (I assume yes)

I am a little confused by some of the wording on the wiki for sprite evaluation
http://www.nesdevwiki.org/wiki/NES_PPU# ... evaluation

It says:
Cycles 64-255: Sprite evaluation
On even cycles, data is read from (primary) OAM
On odd cycles, data is written to secondary OAM (unless writes are inhibited, in which case it will read the value in secondary OAM instead)

So by my math, there are 96 reads and 96 writes. ??? That number seems weird. There are 64 sprites max, there are 8 sprites (so 32 bytes) max per scanline. Is this a reflectection of both those numbers?


Also, I dont fully understand the state machine listed afterwards.
Are all the sprites evaluated each cycle for a partcular pixel? Maybe my problem is that the evaluations shouldnt be per pixel, but per tile.

Al

by on (#41141)
Quote:
Edited 2 times


Quote:
- Each pixel is 1 PPU cycle. So is this the first 256 cycles?

yeah it is rendered every cycle from scanline 1-240 for 240 scanlines.

For the X increment and Y increment part, you can find more info on brad taylor's doc. The outline is that the NES fetches the tiles at cycle 0, get pattern address at cycle 1, get attribute address to render on cycle 2, then after it gets the attribute and it increases the X scroll for the next evaluation, this is cycle 3. On cycle 4 it uses the pattern address it gets in cycle 1 to render. On cycle 5 it gets the low chr data for rendering, on cycle 6 it gets the hi pattern table address and on cycle 7 it gets the hi pattern table data. It is restarted at 8 and do it until 32 tiles have been processed (256 pixels). The Y scroll gets incremented because at cycle 251 the last X scroll on the scanline has incremented and ready to process the tiles for the last 8 pixels of the scanline.
Im not sure of the reason why X scroll is reset at cycle 257. The last tile should be done processing at cycle 255, since 8 cycles are needed to process a tile, so I am not sure why it doesn't happen on cycle 256.
It also gets 2 extra tiles at the end of a scanline for the next scanline due to the NES rendering a pixel every cycle.

As for Background and sprite interleaving http://nesdevwiki.org/wiki/Sprite_priority this explains how the bg and sprite interleave.

About the read and writes, the number of read and write cycles is more than what is really needed since let say the sprite slot for visible sprites are in 57-64, so it'd be (2*56) for sprites processing not in range, then (2*56)+(2*4)*8 since 3 read and write to fetch the data associated with the sprite found that is in the scanline. it'd be around 176 cycles.
So I don't think the number of read and writes correspond with how many sprites there are. The weird evaluation phase I think kind of implies that, though it might be another reason, this is just speculation on my part.