UPDATE: I updated the code to optimize the routine that copies the buffer into color memory. Thanks to @ArneChristianRosenfeldt for pointing out some naiveties of my previous implementation. NOTE on color buffer: In the video, I forgot to mention the reason why, during the scrolling of the 7 pixels, I copy the color memory into a buffer (instead of scrolling it directly at the eighth pixel). The reason is that, otherwise, I would have to scroll the colors from bottom to top. Without the buffer, if I did the opposite (for example) copying row 1 into row 2 and then row 2 into row 3, etc., by copying row 1 into row 2, the latter gets overwritten, and therefore in the next step (2 -> 3), I would copy incorrect data! On the other hand, if I start from the bottom by copying row 22 into row 23 and then row 21 into row 22, there is no problem. You might wonder, why is it not okay to copy from bottom to top? The reason is that the raster beam is like a tsunami that rushes like the wind! Unfortunately, when it restarts drawing the background, the CPU has not yet completed all the work of scrolling the colors! However, by scrolling them from top to bottom and starting ahead of the raster beam (when it is at the beginning of the bottom border), the first rows it encounters will have already been completed, and the CPU will still manage to complete the last row before it's reached! This technique is called "racing with the raster beam," which is not applicable if we were to reverse the order of scrolling the colors because the first row reached by the raster beam will be updated last by the CPU!

Thank you so much for the English language version. You are just brilliant at explaining Commodore 64 programming.

A very good explanation. Thanks a lot for the time and effort you put into these tutorial-videos!

For many years i used smooth scrolling on C64 screen, but then an UFO beamed me up and ejected me on the x86 alien planet with a new command prompt. After learning the alien language i made a new vertical smoot scroller for the vga text screen with 8x16 font size for up and down scrolling.

If I recall correctly on the Amiga for smooth horizontal scrolling you had to create 2 additional screens. One either side of the main display in order for the hardware scroll to work. (All 3 displaying the same image) I once tried one screen which was 16 pixels larger on both sides. Both sides hidden behind the border. When scrolled and a fresh column of 16x16 were drawn behind the border, the scroll went crazy.

What I like about this method is that it works even better on TED (plus4). There you have a 1.8 MHz CPU in the lower/upper border and 4 useful pages for both the characters and colors. So for all direction scrolling we can waste a lot of memory and have 3 other pages half prepared if the camera moves close to a point where both scrollX and scrollY can wrap around... We should really squeeze every cycle out of the memCpy to at least bring this down to filling thirds of the other page with the scrolled versions. Then we only have to copy 3/2 characters. This is probably the reason why many games have a character status bar at the bottom: This thing just reduces the character count in the scrolling area to just make it work. So no need to use sprites for this as in non-scrolling games. I admired the status overlay using sprites on NES, but really it is just due to the limitation of the hardware. If you scroll on NES, the status appears in the playfield. EGA is similarly stupid. Status screen at 0 can appear on the lower edge of the screen, but then you have to place your Xenon2 playfield besides it and waste half of the video memory .. although EGA would store sprites there, like in a time when the ISA bus was considered fast and games actually read from vram ...

Am I correct in saying this approach works because the screen will scroll regardless of player input? Conversely, if the camera is directly or indirectly controlled by the player, the screen must be scrolled on command. What are solutions for this condition? Edit: I thought about it a bit. If a hardware scroll gets close to 0, it can start to build the backbuffer preemptively, even if it is never realized due to the camera being moved in the opposite direction before the buffers should be swapped. In my case, the background graphics can change. I guess I need to ensure changes get propagated to both the front and back buffer.

Hi there! I cannot seem to open the ScrollDown.gmk64 file, which Assembler is it compatible with?

I wonder if the repeated lda {ColBuf}+40*0,x sta {COLMEM}+40*0,x inx could be generated at runtime, like we do for webpages or Wolf3d did for the column renderer. Also why waste 2 cycles on inx here, but not here: lda {VIDMEM0}+40*0,x sta {VIDMEM1}+40*1,x lda {VIDMEM0}+40*1,x sta {VIDMEM1}+40*2,x ah got it. The second example does not fit into one byte. But a general generator would probably generate code without INX for both. I wonder why you don't align to 256 byte pages for the color buffer scrolling to save another cycle? Like you would copy 216 bytes inside a page and 40 bytes cross a page with x starting at 0 again to prevent the carry. Is the 6 important here? This does not seem to be Sonic the Hedgehog. You scroll max 8 pixel per frame.

the ai voice is awful :(