Talk:PPU OAM
An observation from a PPU die image - the 2 large blocks at the upper-right (the horizontal strip between them is the address decoder) are the PPU OAM. It is arranged in 8 groups, one hooked up to each CPU data bit (i.e. the ones used for $2000-$2007 - the actual pins are along the upper-right corner of the die). The groups hooked up to D0/D1/D5/D6/D7 are 9 bits wide, while the ones hooked up to D2/D3/D4 are only 7 bits wide. One row in each group appears to be used for secondary OAM, while the other pairs of rows store the actual sprite data - since the flags byte does not contain any actual data in D2-D4, the corresponding rows are absent (and thus contain only 3 pairs of rows instead of 4 pairs); indeed, what appears to be a 4->9 decoder at the top of the die (just to the left of CPU D7) looks to convert the bottom 3 bits of the SPR-RAM address (and possibly the top 9th bit) into enables for offsets 0-7 and secondary OAM (for 8-15), and the enables for offsets 2 and 6 are not connected to D2-D4. --Quietust 18:23, 11 January 2011 (UTC)
- In fact, the 4->9 decoder at the top also explains behavior I've seen elsewhere, where setting $2003 to a nonzero value would use the value of the upper 5 bits (instead of all 0s) to fetch the first two sprites (and cause the first one to trigger sprite #0 hit)... --Quietust 18:29, 11 January 2011 (UTC)
Perhaps this page could be renamed to something like "Sprites" and have some of the priority and evaluation stuff merged into it. A separate page just for the memory area seems a bit arbitrary to me. -Ulfalizer (talk) 05:05, 28 March 2013 (MDT)
One part of it says "It has not been determined whether the PPU actually drives these bits low or whether this is the effect of data bus capacitance from reading the last byte of the instruction (LDA $2004, which assembles to AD 04 20). "
This is not factual information and adds noise to the page. Has it been determined since this was edited in? Bregalad (talk) 08:19, 20 May 2015 (MDT)
PAL horizontal overscan masking?
The wiki currently says "[A sprite 0 hit will happen even if it is during] The PAL PPU blanking on the left and right edges at x=0, x=1, and x=254."—what PAL PPU blanking on the edges? Did I miss something? (maybe add a citation in the article?) —Lidnariq (talk) 21:06, 20 May 2015 (MDT)
- It's the "Side borders" row in Clock rate. --Tepples (talk) 21:41, 20 May 2015 (MDT)
- Doesn't that mean that the visible width is 260 pixels on PAL, with two pixels of black on both sides, not that the visible area is 256 pixels of which the NES blanks two pixels on each side?—Lidnariq (talk) 22:51, 20 May 2015 (MDT)
- No. The left and right 2 columns are always black in PAL (even if the background colour is not black). Since everything is so badly worded and so confusing on this wiki it's no surprise there is no consistency how this phenomena is called and how poorly it is doccumented.Bregalad (talk) 01:41, 21 May 2015 (MDT)
