I was part of the Commodore 64 demo scene back in the 80s, and this technique was heavily used. You only had so many sprites available, limited color palette, c

I was part of the Commodore 64 demo scene back in the 80s, and this technique was heavily used. You only had so many sprites available, limited color palette, could only use one font (with a small set of glyphs), etc. By setting up "raster interrupts", which would execute code when the CRT reached a specific raster line on the 320x200 display, you could do all sorts of trickery. The raster interrupt would trigger after it rendered the first horizontal line, and then you could change the pointer to the sprite/font/palette/etc. for the duration of the next display line. A common effect that everyone would learn first was to simply change the background color, so that every display line was a different color, producing a rainbow background. In a sense, the [video] demo scene was almost entirely about this effect. How much could you do in the tiny number of CPU cycles available to you between the raster interrupt triggered at the end of one horizontal scan line, and the start of the next line, as the beam wrapped around? You could just barely execute about a dozen CPU instructions. Usually you'd flip a couple pointers that the video hardware would look at when it started rendering again, and then you'd pad in a couple no-op instructions so that the change occurred "off screen". This really happened in the margins of the CRT that were covered by a bezel, which meant that on some displays the transition really was invisible to the eye, but on others, there would be flickering at the edges as the background color changed. I used to test my demos on multiple displays to try to minimize the effect, having to shave off an instruction or two in order to make things look better.