The raster register keeps an eye on the television's refresh, so it moves down the screen from top to bottom; if the code waits until raster position $50 and alters the screen above that point, the changes won't be visible until the the raster passes that area again during the next frame. The scroll loops in that block of code i posted race against the raster and redraw parts of the screen it's already covered so the movement is seamless, if the timing is messed around so they start earlier, there'll be "tearing" where bits of the next frame are drawn in too early in the upper third of the screen.stardust wrote:My understanding: screen update before raster #$50 will not show until next raster line, so character level scroll in hidden by #$50
It's only hidden in the sense that raster position $00 is in the upper border.stardust wrote:and register level scroll is hidden by #$00.
It can theoretically be done without a second buffer on the C16 and i suspect a couple of games actually do so in a reduced area because they're desperate for RAM. Just about any scrolling is best handled with two buffers on these machines and, if there's enough memory for two blocks of 2K for display buffers, the TED chip can be repointed to flip between them so the job of copying from one to the other can be spread out over a number of frames.stardust wrote:Then scroll up, left, right have no problem. just out of curosity, scroll down also need update the screen from upper part using a temporary buffer ?
i know how NES scrolling works and it's a very different beast to the C16; there's a lot more brute force copying of data involved with all of the Commodore 8-bits.stardust wrote:Do you know how NES and Genesis scrolling work? are they the same?