So, I went over our Wiki article, The skinny on NES scrolling and gave it a pass to try and make it easier to understand, and give more practical instructions on how to scroll on the NES. I'd also appreciate a proof-read, and any corrections that need to be made.
I ended up wondering about a few things, which I mention on the discussion page:
1. When exactly does the Y scroll increment get done? Is this before / after / or concurrent with the reloading of v from t? I looked at the nintendulator source, and it seemed to be doing it on pixel 250, but that can't be right, can it? Wouldn't that Y-shift the right edge of the screen? Or is the last tile always already fetched by then?
A corollary of that is that, if I am thinking about this correctly, you should set the Y scroll value to be Y-1 when you make your writes, since it's about to be incremented. Is this correct? (I would like to add a proper explanation of this to the example/guide.)
Also, could someone with a good grasp of the Y scroll increment and wrap logic write it into the article? All we've got now are a bunch of statements from Loopy's document, which appear to be true, but require understanding of the increment behaviour to really know why they happen.
Attributes are another thing not really touched on by this document, though it's probably answered elsewhere in the wiki in PPU timing documents or something, but an explanation of how v gets mangled to look up attributes might be useful as well. Also, if attributes are fetched early in the scanline and can't be updated mid-scanline, this should probably be mentioned. (Tile fetch timing should also be relevant for the same reason.)
2. The fine x gets reloaded at the start/end of the line from a temporary register not listed in the document, doesn't it? If it didn't, it would be critical where exactly in the previous scanline you made the first $2005 write, which is not the case, as far as I have seen when trying it on the NES. Am I wrong about this?
Edit: Seems to be irrelevant, I may have been thinking about it wrong, but whether it's a reload or not, doesn't matter, we could call the reload register [i]x[i/]
3. Making scroll writes during hblank. Some threads have suggested this, but is it possible, and how? When I've tried to do scrolling in the past, I could never seem to get timings that accurate, so it was always necessary to pull it back from the right edge and accept some amount of glitching on the end of the line. Glitches like this seem to be very normal for games with split scrolling... can it actually be avoided? Is it bad advice to suggest timing it during hblank?
Edit: I've realized that you can't use hblank if only using $2005 to do X scroll, but theoretically the full 2006/2005/2005/2006 cycle should work fine in hblank, as long as it doesn't interfere with tile/attribute fetches... when do those happen?
I ended up wondering about a few things, which I mention on the discussion page:
1. When exactly does the Y scroll increment get done? Is this before / after / or concurrent with the reloading of v from t? I looked at the nintendulator source, and it seemed to be doing it on pixel 250, but that can't be right, can it? Wouldn't that Y-shift the right edge of the screen? Or is the last tile always already fetched by then?
A corollary of that is that, if I am thinking about this correctly, you should set the Y scroll value to be Y-1 when you make your writes, since it's about to be incremented. Is this correct? (I would like to add a proper explanation of this to the example/guide.)
Also, could someone with a good grasp of the Y scroll increment and wrap logic write it into the article? All we've got now are a bunch of statements from Loopy's document, which appear to be true, but require understanding of the increment behaviour to really know why they happen.
Attributes are another thing not really touched on by this document, though it's probably answered elsewhere in the wiki in PPU timing documents or something, but an explanation of how v gets mangled to look up attributes might be useful as well. Also, if attributes are fetched early in the scanline and can't be updated mid-scanline, this should probably be mentioned. (Tile fetch timing should also be relevant for the same reason.)
2. The fine x gets reloaded at the start/end of the line from a temporary register not listed in the document, doesn't it? If it didn't, it would be critical where exactly in the previous scanline you made the first $2005 write, which is not the case, as far as I have seen when trying it on the NES. Am I wrong about this?
Edit: Seems to be irrelevant, I may have been thinking about it wrong, but whether it's a reload or not, doesn't matter, we could call the reload register [i]x[i/]
3. Making scroll writes during hblank. Some threads have suggested this, but is it possible, and how? When I've tried to do scrolling in the past, I could never seem to get timings that accurate, so it was always necessary to pull it back from the right edge and accept some amount of glitching on the end of the line. Glitches like this seem to be very normal for games with split scrolling... can it actually be avoided? Is it bad advice to suggest timing it during hblank?
Edit: I've realized that you can't use hblank if only using $2005 to do X scroll, but theoretically the full 2006/2005/2005/2006 cycle should work fine in hblank, as long as it doesn't interfere with tile/attribute fetches... when do those happen?