Feedback wanted on SVG PPU frame timing diagram

[ulfalizer]

Old version was a bit misleading. The sprite tile vram fetches still occur on the pre-render line. Added a note about sprite evaluation instead.

[Rid]

Hi ulfalizer,

I would like to thank you for your work on this diagram (and everybody who helped you of course)!
It will be very useful for people like me who don't speak english.

[ulfalizer]

Hi ulfalizer,

I would like to thank you for your work on this diagram (and everybody who helped you of course)!
It will be very useful for people like me who don't speak english.

No problem. Your English seems fine though.

[ulfalizer]

If the diagram looks correct now, perhaps it could be linked from relevant parts of the wiki. I could update the out-of-date pages while I'm at it.

[Bisqwit]

That is a very nice diagram.

[ulfalizer]

That is a very nice diagram.

Thanks.

[WedNESday]

That is a very nice diagram.

Biggest understatement since nesdev's conception.

[ulfalizer]

That is a very nice diagram.

Biggest understatement since nesdev's conception.

Glad you like it. I'm thinking about doing another one with all the cpu/ppu/ciram/cart address/data bus connections, since I'm still a bit hazy on some of the details of that.

[ulfalizer]

Talked to Quietust and did some more tracing in visual 2c02, and it looks like the secondary OAM clear and sprite evaluation is skipped on the pre-render line. Updating the diagram to reflect this.

This might also mean that it's possible for sprites to affect the rendering of the first scanline somehow.

[Plazm]

I'm just starting out, trying to understand.
Are you sure that the cycle (NT-> AT-> LBG-> HBG) should continue to tick 256 (32 cycles), and not to 240 (30 cycles)?
Indeed, in the previous line had been done two cycles.

[beannaich]

I'm just starting out, trying to understand.
Are you sure that the cycle (NT-> AT-> LBG-> HBG) should continue to tick 256 (32 cycles), and not to 240 (30 cycles)?
Indeed, in the previous line had been done two cycles.

There are a total of 34 BG tuple fetches per scanline. 32 in the active portion (h:1-256), and two at the end of the raster for the NEXT line (h:321-336). Of these 34 fetches, only 33 are ever actually used in rendering, the tuple at h:249-256 isn't necessary but some mappers rely on this fetch for timing purposes.

Each tuple takes 8 dots to fetch, in the following pattern (shown in relative clocks):

Code: Select all

+0: Name address is on the bus
+1: Name data is on the bus (read occurs here)
+2: Attr address is on the bus
+3: Attr data is on the bus (read occurs here)
+4: Bit0 address is on the bus
+5: Bit0 data is on the bus (read occurs here)
+6: Bit1 address is on the bus
+7: Bit1 data is on the bus (read occurs here)

The reason for the 2 cycles per fetch is due to the AD0-AD7 pins being multiplexed between address and data, as previously mentioned. During the first of the two cycles, something like $2010 would be seen, and during the second cycle something like $2055 would be seen. The data fetched is in the bottom 8 bits, while the top 6 remain "open bus" from the address.

[Plazm]

Of these 34 fetches, only 33 are ever actually used in rendering

Why 33? (in line 32 tiles)

[beannaich]

Of these 34 fetches, only 33 are ever actually used in rendering

Why 33? (in line 32 tiles)

To allow for fine horizontal scrolling. ((256 pixels + 8 pixel fine scroll) / 8 pixels per tile) = 33 tiles.

[Plazm]

Thanks a lot. Now, this section became clear to me. It also became clear why there is a two prefetch tiles, not just one.

[ulfalizer]

Here's an updated version that points out that the last tile fetch is unused and adds a note about fine x.

Edit: upper<->lower. I keep thinking right->upper for some reason.