Talk:PPU rendering

0=blank vs. 0=active

There are two different conventions:

0=active	0=blanking	Description
261 or -1	20	Pre-render scanline
0-239	21-260	Active picture
240	261	Post-render scanline
241-260	0-19	Vertical blanking

You're using the 0=blanking convention. But more often on the BBS and elsewhere on this wiki, I've seen 0=active. The PPU power up state appears to agree with 0=active, as do the (X, Y) coordinate displays in the debugger of FCEUX and Nintendulator and the VCOUNT register on the Game Boy ($FF44) and Game Boy Advance ($04000006). The 0=active convention makes it easier to consolidate discussion of NTSC, PAL, and PAL clone timing as well. --Tepples 20:15, 3 April 2011 (UTC)

Ahh, ok. I was just simply going off of what's in Brad Taylor's docs. The 0=blank method didn't make a lot of sense to me either, as does some of the other stuff in this doc (The shift registers make more sense if they shift left rather than right). I'll adjust this. --Drag 20:47, 3 April 2011 (UTC)

I think at some point, it would be worthwhile to document how the PPU outputs the vertical/horizontal sync signals. If for nothing else than to satisfy my own curiosity. --Drag 05:30, 6 July 2011 (UTC)

Garbage nametable byte

Before each sprite's patterns are loaded, at x=257, 259, 265, 267, ..., 313, 315, there is a garbage nametable fetch. Has anyone discovered a pattern to these fetches' addresses that, say, a mapper could use? --Tepples 16:07, 6 July 2011 (UTC)

I was going to ask the same question, what are the addresses of the garbage nametable bytes? I would like to know, too. It would be useful for this purpose, as well as if you are making a hardware clone or whatever and want it accurate. --Zzo38 (talk) 13:37, 17 March 2013 (MDT)

Out of date

Some of the timing information is out of date now (see forums.nesdev.org/viewtopic.php?f=3&t=9901). I'll update it once I get my account activated. -Ulfalizer (talk) 18:38, 15 March 2013 (MDT)

Delay between shifters shifting and drawing

As the notes in the diagram mention, there's actually a delay of two ticks from when the shifters shift to when the pixel is output. Looks like this is due to palette lookup. Here's a Visual 2C02 trace around the beginning of a scanline with the high and low pattern bits = 0x80 (so that the palette index is 3 for the first pixel and 0 for the rest):

hpos	vid_	tile_l	tile_h	pal_ptr
000	080	fefe	0101	00
000	080	fefe	0101	00
000	080	fefe	0101	00
000	080	fefe	0101	00
000	080	fefe	0101	00
000	080	fefe	0101	00
000	080	fefe	0101	00
000	080	fefe	0101	00
001	080	fefe	0101	00
001	080	fefe	0101	00
001	080	fefe	0101	00
001	080	fefe	0101	00
001	080	fefe	0101	00
001	080	fefe	0101	00
001	080	fefe	0101	00
001	080	fefe	0101	00
002	080	ff7f	8080	00
002	080	ff7f	8080	00
002	080	ff7f	8080	00
002	080	ff7f	8080	00
002	080	ff7f	8080	00
002	080	ff7f	8080	00
002	080	ff7f	8080	00
002	080	ff7f	8080	00
003	080	ffbf	c040	03
003	080	ffbf	c040	03
003	080	ffbf	c040	03
003	080	ffbf	c040	03
003	080	ffbf	c040	03
003	080	ffbf	c040	03
003	080	ffbf	c040	03
003	080	ffbf	c040	03
004	080	ffdf	e020	00
004	080	ffdf	e020	00
004	080	ffdf	e020	00
004	080	ffdf	e020	00
004	400	ffdf	e020	00
004	400	ffdf	e020	00
004	400	ffdf	e020	00
004	400	ffdf	e020	00
005	400	ffef	f010	00
005	400	ffef	f010	00
005	400	ffef	f010	00
005	400	ffef	f010	00
005	080	ffef	f010	00
005	080	ffef	f010	00
005	080	ffef	f010	00
005	080	ffef	f010	00
006	080	fff7	f808	00
006	080	fff7	f808	00
006	080	fff7	f808	00
006	080	fff7	f808	00
006	080	fff7	f808	00
006	080	fff7	f808	00
006	080	fff7	f808	00
006	080	fff7	f808	00
007	080	fffb	fc04	00
007	080	fffb	fc04	00
007	080	fffb	fc04	00
007	080	fffb	fc04	00
007	080	fffb	fc04	00
007	080	fffb	fc04	00
007	080	fffb	fc04	00
007	080	fffb	fc04	00
008	080	fffd	fe02	00
008	080	fffd	fe02	00
008	080	fffd	fe02	00
008	080	fffd	fe02	00
008	080	fffd	fe02	00
008	080	fffd	fe02	00
008	080	fffd	fe02	00
008	080	fffd	fe02	00
009	080	fefe	0101	00
009	080	fefe	0101	00
009	080	fefe	0101	00
009	080	fefe	0101	00
009	080	fefe	0101	00
009	080	fefe	0101	00
009	080	fefe	0101	00
009	080	fefe	0101	00
00a	080	ff7f	8080	00
00a	080	ff7f	8080	00

The shifters shift at h=2, the palette address changes at h=3 for the palette lookup, and the pixel is drawn during h=4 (as seen by vid_ changing).

It also looks like the shift registers are actually reloaded at h=9,17,25,... instead of at h=8,16,24,..., so that should be fixed. :/ -Ulfalizer (talk) 17:14, 5 April 2013 (MDT)

Does it fetch everything?

If at least one of the background or sprites is enabled, will it still fetch both even though only one is used? --Zzo38 (talk) 01:25, 18 June 2013 (MDT)

During rendering, the PPU's address bus is never idle. I don't know what addresses it reads if background is disabled, but I think the sprite reads from tile #$FF. (Visual2C02 can tell you the right answer) —Lidnariq (talk) 02:44, 18 June 2013 (MDT)

IIRC, disabling only one of them doesn't affect sprite evaluation and fetches at all, but only the final drawing stage (where sprite zero hit detection happens as well). I think you can re-enable sprite rendering in the middle of a sprite and have half of it draw fine. --Ulfalizer (talk) 08:56, 18 June 2013 (MDT)