olddb wrote: ↑Mon May 24, 2021 10:44 pmSo I guess a have to use modulus % 240 to the vert scroll value?
That's one way to do it, but I personally prefer to maintain two separate scroll values: an "ideal" one, that wraps around normally at 256, and a special one that wraps around at 240. You basically apply the same transformations to both every frame, taking care to handle the special cases of the alternate value (whenever it lands in the 240-255 range, check the sign of the movement and fix accordingly, like in Controllerhead's example).
The two scroll values don't even need to be perfectly aligned at start-up (only the lower 4 bits have to match!), you can, for example, have ScrollY start at 66 and NTScrollY start at 2 - as long as they're both updated in sync, the upper bits of NTScrollY can be initialized to any value outside of the "forbidden zone". You can then use the "ideal" scroll for everything relative to the game world (reading the level map, calculating sprite positions, etc.) and the alternate one for things related to the PPU (setting the scroll, calculating NT/AT addresses for updates).
Also, bit $2000.1 with this setup is not used, right?
If the game uses vertical mirroring, then $2000.1 indeed doesn't matter. I still prefer to keep my code 4-screen-compatible whenever possible though, so I normally will still treat the background area as being 480 pixels tall, if processing the extra bit doesn't cost me much.