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), making the "effective" resolution 252x240. 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. By the way, you guys obviously are not used to work with technical documentation. Text should state facts only once, not 3 or 4 times sparkled around and using a different wording. If examples should be given to complement the text, they should be graphical, not textual.Bregalad (talk) 01:41, 21 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)
- In this particular case, the Wiki describes this once, inadequately, and in the wrong place (clock rate??). That's probably on par with most technical manuals I've read, but most technical manuals are crap, and they have a very different target than our wiki (and often don't have the advantage of hypertext). Examples can be very useful to understanding, I have no idea why you came up with the bizarre idea that examples should be graphical only, but some graphical illustrations of how the PAL video is displayed would be very helpful. - Rainwarrior (talk) 11:31, 21 May 2015 (MDT)
- It's briefly covered in Overscan#PAL, it looks like, and that's actually an appropriate place for it. - Rainwarrior (talk) 11:35, 21 May 2015 (MDT)
- Thank you. If you find duplication, the first step is to figure out which shall be authoritative for each fact. For example, Myths and Errata are duplicative by their nature, but they link to the primary page for each fact. So I have added a note in Clock rate that the behavior is fully described in Overscan#PAL. --Tepples (talk) 10:37, 22 May 2015 (MDT)
- It's briefly covered in Overscan#PAL, it looks like, and that's actually an appropriate place for it. - Rainwarrior (talk) 11:35, 21 May 2015 (MDT)
- I don't think a moderate amount of duplication is necessarily bad, except when they get out of sync. Hyperlinks are very helpful here. The issue with it being at clock rate was one of obscurity. (i.e. how would anyone know to look in clock rate to find that information?) - Rainwarrior (talk) 23:55, 22 May 2015 (MDT)
- Well ideally the example should be graphical especially when talking about graphics. That makes sense, I don't think it's a "weird idea". An explaination like "a sprite with colour $12 will hit on a background with colour $32" or whathever is hard to understand and makes absolutely no sense for those who aren't already familiar with the NES palette. Even for me who am familiar with the NES palette this makes few sense: Why those values? Since the palette does not matter at all, I don't see why adding palette values is useful in any way, it is just downright confusing and stupid.Bregalad (talk) 01:27, 22 May 2015 (MDT)
- I agree about that. Calling out two random example values like that was very strange to me, almost like it was suggesting there was something special about them. That whole sentence was a bit wonky to me (starting with the ambiguous term "pixel values") and I revised it the other day. Do you have thoughts on the current version, or what a suitable explanation graphic would look like? - Rainwarrior (talk) 00:01, 23 May 2015 (MDT)
- I don't understand the relevance of "AND to 0". Is this some common confusion about sprites that I've never heard of? The best way to guide someone to a unit test would be to make one and link to it. - Rainwarrior (talk) 12:26, 23 May 2015 (MDT)
- Does what you call "3 or 4 times sparkled around and using a different wording" have anything to do with what Koitsu calls "provide multiple phrasing" in Nesdev wiki talk:Manual of Style/RFC 2119? --Tepples (talk) 19:45, 26 May 2015 (MDT)
- No. Koitsu gives the explanation about attribute tables in his own document, nestech.txt, as an example. Attribute tables is not the easiest thing to explain, yet he does it very gracefully in my subjective opinion. First he explains what area it covers in term of pixels, tiles and metatiles, then he makes a graphical representation of the thing. This is both extremely clear and concise, and is a great example on how technical documentation should be done.
- On the other way, saying, with only text, "A non-transparent sprite pixel will collide with a non-transparent BG pixel. For example if sprite pixel 1 collides on BG pixels 0, there is no collision. If sprite pixel 0 collides with BG pixel 2, there is no collision. But if sprite pixel 1 collides with BG pixel 3, there is a collision. Oh and if sprite pixel 3 collides with BG pixel 2, there is also a collision. If palette entry is %xx and the other palette entry is %yy, there is still collision. But guess what? If palette entry is %zz, there is also a collision (etc....)"
- This is terrible because 1) it's long, 2) the examples are meaningless, 3) you assume the reader is a 3 years kid who cannot understand the original claim. "Nontransparent sprite with nontransparent BG" should be enough, given the "nontransparent" is proprely defined. All the rest is garbage, except a possible graphical example (in this particular case, the concept is so easy to understand that it's fully optional).
Bregalad (talk) 03:43, 27 May 2015 (MDT)
I'd really like something more authoritative (such as a photograph of a TV with a ROM that demonstrates the missing columns). The only thing I've been able to find is Bregalad blankly asserting that this is true: [1] —Lidnariq (talk) 12:24, 21 May 2015 (MDT)
