The CPU isn't really fast enough to fine-scroll large sections of the screen.
It runs at about 1mhz, and which means there are about 16,000 CPU cycles per frame. The CPU typically takes 3-7 cycles per instruction, so you have a maximum of 5600 instructions per frame.
The there is a useful "rotate memory left/right" instruction which takes 7 cycles. An unrolled loop of these could shift about 2000 bytes of memory left/right per frame. A 160x200 2bit color bitmap mode screen takes up 8000 bytes, so at the very least you can shift ¼ of the screen.
That might be enough for super Mario Bros, if you can be smart about empty areas.
Except, I skipped over a few things. To scroll 2bit graphics, you have to rotate twice. 14 cycles per byte, so we are down to ⅛ of the screen.
And such scrolling only works if each line uses the same 4 colors. To have more than 4 colors per line you have to shift the attribute bytes too, and deal with attribute clashes when a tile is halfway between two vic2 tiles.
You would be lucky to shift a sixteenth of the screen per frame, with zero time left over for processing gameplay and sprites.
> The CPU isn't really fast enough to fine-scroll large sections of the screen.
That's fine; it is not how you'd do it on the C64. Nor was VSP very common.
> The there is a useful "rotate memory left/right" instruction which takes 7 cycles. An unrolled loop of these could shift about 2000 bytes of memory left/right per frame. A 160x200 2bit color bitmap mode screen takes up 8000 bytes, so at the very least you can shift ¼ of the screen.
Nobody used bitmaps to for scrollers on the C64 (or indeed for most games). A game screen using character mode takes at most 2000 byes if you need to scroll the entire screen, including color RAM, which you wouldn't be doing as you'd spend some space on other things, like score displays etc., and putting more static decorations was indeed a common way of cutting down on the amount actually scrolled. Another way was to do level designs so that you did not have to scroll everything every time. E.g. by keeping some lines using the same colour, or fill part of the screen with sprites instead of characters.
To scroll the first 7 pixels in any direction then only requires updating a single register to shift the screen. This applies for bitmaps too, so there really are no circumstances where you'd bit-shift bitmaps to scroll.
For the 8th pixel you need to copy, but you don't need to complete the copy in one frame; you just need to outpace the raster-beam. So the moment it has rendered the first full line of text, you can scroll it; as long as you take care to not speed past the rendering, then you can continue following past. If you do this you have nearly two full frames to complete the copy, for about 1000 byes per frame.
It runs at about 1mhz, and which means there are about 16,000 CPU cycles per frame. The CPU typically takes 3-7 cycles per instruction, so you have a maximum of 5600 instructions per frame.
The there is a useful "rotate memory left/right" instruction which takes 7 cycles. An unrolled loop of these could shift about 2000 bytes of memory left/right per frame. A 160x200 2bit color bitmap mode screen takes up 8000 bytes, so at the very least you can shift ¼ of the screen.
That might be enough for super Mario Bros, if you can be smart about empty areas.
Except, I skipped over a few things. To scroll 2bit graphics, you have to rotate twice. 14 cycles per byte, so we are down to ⅛ of the screen.
And such scrolling only works if each line uses the same 4 colors. To have more than 4 colors per line you have to shift the attribute bytes too, and deal with attribute clashes when a tile is halfway between two vic2 tiles.
You would be lucky to shift a sixteenth of the screen per frame, with zero time left over for processing gameplay and sprites.