Backgrounds, Scrolling, and Attribute Tables

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Backgrounds, Scrolling, and Attribute Tables
by on (#5612)
I'm writing a test nes program to better understand the nes itself. I have already one tile, which draws ok to the screen. I played a bit with the attribute tables to understand them. Now I have a few question.

First, when writing to both attribute tables, table #1 seems to have priorty over #0, but when I only write to table #0, that has priorty. Is this correct?

Secondly, when scrolling, I first read $2002(I think), and then write to $2005. I believe this is more of an offset(i.e. setting $2005 for the horizontal to 5, then(after reading $2002 again) setting it to 6 results in it being offset by 6, not 11). But when I constantly increment the offset(i.e. inx stx $2005), the screen does scroll, but the tile(s) get funky. Except for in Nesticle, which is inaccurate, to my understanding.

What am I doing wrong with this, what do I need to do, and why?
Thank you for the time and effort, and I apoligize if this is a frequent noob question. :oops:

by on (#5620)
I don't know what you mean about attribute priority. Maybe it's the mirroring setting you use, if you set to horizontal then writing to table 0,1 does the same thing (or 0,2 for vertical).

Write $2005 in vblank (usually in the NMI routine). After the code is done messing with $2006/$2007 for that frame. If by constantly updating the scroll, you mean several times per frame (and during the visible part of the frame), then yeah that'll scroll parts of each line of the screen individually.

by on (#5650)
Just to move a little further than Memblers already did:

The nametables of the NES don't have priorities, since they do not overlap. You may have an issue like that on a SNES or a megadrive, where there are multiple background planes, but the NES has only one plane. One nametable is always besides the other one, never in front or behind. Maybe you're expecting the wrong thing to happen? Explain us what you did and what you expected to happen so we can trace the problem.

As for the scrolling thing, the value you write is an absolute displacement value. If you write "6", the screen will off by 6 pixels. If then you write "11", the screen will be off by 11 pixels, with no recollection at all of the old value of 6. The X scroll register can be changed during rendering, but Y can't. Again, if you could explain exactly what are you trying to do, we might have a better opinion on what's wrong...