Page 3 of 6
Re: Feedback wanted on SVG PPU frame timing diagram
Posted: Tue Mar 12, 2013 6:38 am
by 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.
Re: Feedback wanted on SVG PPU frame timing diagram
Posted: Tue Mar 12, 2013 6:49 am
by 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.
Re: Feedback wanted on SVG PPU frame timing diagram
Posted: Tue Mar 12, 2013 6:58 am
by ulfalizer
Rid wrote: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.
Re: Feedback wanted on SVG PPU frame timing diagram
Posted: Tue Mar 12, 2013 11:53 am
by 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.
Re: Feedback wanted on SVG PPU frame timing diagram
Posted: Tue Mar 12, 2013 12:51 pm
by Bisqwit
That is a very nice diagram.
Re: Feedback wanted on SVG PPU frame timing diagram
Posted: Tue Mar 12, 2013 1:11 pm
by ulfalizer
Bisqwit wrote:That is a very nice diagram.
Thanks.
Re: Feedback wanted on SVG PPU frame timing diagram
Posted: Tue Mar 12, 2013 2:47 pm
by WedNESday
Bisqwit wrote:That is a very nice diagram.
Biggest understatement since nesdev's conception.
Re: Feedback wanted on SVG PPU frame timing diagram
Posted: Tue Mar 12, 2013 3:06 pm
by ulfalizer
WedNESday wrote:Bisqwit wrote: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.
Re: Feedback wanted on SVG PPU frame timing diagram
Posted: Wed Mar 13, 2013 12:20 am
by 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.
Re: Feedback wanted on SVG PPU frame timing diagram
Posted: Wed Mar 13, 2013 9:59 pm
by 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.
Re: Feedback wanted on SVG PPU frame timing diagram
Posted: Wed Mar 13, 2013 11:33 pm
by beannaich
Plazm wrote: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.
Re: Feedback wanted on SVG PPU frame timing diagram
Posted: Wed Mar 13, 2013 11:52 pm
by Plazm
beannaich wrote:Of these 34 fetches, only 33 are ever actually used in rendering
Why 33? (in line 32 tiles)
Re: Feedback wanted on SVG PPU frame timing diagram
Posted: Thu Mar 14, 2013 12:10 am
by beannaich
Plazm wrote:beannaich wrote: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.
Re: Feedback wanted on SVG PPU frame timing diagram
Posted: Thu Mar 14, 2013 12:48 am
by 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.
Re: Feedback wanted on SVG PPU frame timing diagram
Posted: Thu Mar 14, 2013 3:42 am
by 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.
