Scrolling Engine

Well, it's been a while!  Despite the boredom and isolation that came along with the COVID years, I didn't do much that was very impressive in terms of retro programming during that time. In a cruel twist of fate, the boredom (and an ongoing spat with another CoCo media figure) seems to have robbed me of inspiration during that time.  Despite that, I did manage to produce a little technology demo to demonstrate scrolling a full graphical background on a CoCo. Some have asked for more information on how this was done. If that interests you, then please continue reading!

So Much Work

Scrolling a background image with the 6847 VDG is not by itself a huge technical problem. All that is required is to move a lot of data from where it starts to a new location. For a CG3 (128x96) screen that means 3 KB or 3072 bytes of data moved for each frame of video. Many video chips roughly contemporary with the 6847 provided hardware support that allow (usually at the expense of some memory usage) for the illusion of movement by changing the source of the video data between frames. The SAM/VDG combination used in the CoCo offers a rudimentary version of this, but the frame-to-frame jumps would be too coarse and the memory demands too great to be useful by itself for smooth animation.

So Little Time

With no useful hardware support available, brute force must be used to copy bytes around in the video buffer. Computers are fast, but not infinitely fast. How much time do we have? And how long does it the 6809 take to copy 3072 bytes? The VDG generates just under 60 video frames per second. With the normal 0.89 MHz clock speed of the CoCo, that leaves us less than 15000 clocks to move the data for each frame. Unless the CPU can move one byte in five clock cycles (which it cannot), then there is just not enough time.  Even at just 30 frames per second, we still wouldn't be very close.

Switch Things Up

The 6847 generates video output at just under 60 frames per second, and the SAM/VDG combination used in the CoCo does offer a "screen flip" capability. Combining those two details allows us to "double buffer", or to draw in one buffer while the other is used as the display source and then to switch between the buffers. Using two buffers effectively halves our video frame rate but doubles the amount of time available for video data movement and gets us back to a manageable 30 frame updates per second.

Blast Away

One unique feature of the 6809 CPU architecture is the User stack. This provides an efficient means for moving data, particularly when combined with the System stack and used for what is colloquially known as "stack blasting". This feature allows for moving up to 8 bytes at a time in as little as 26 cycles for just two instructions. This would potentially allow us to move a frame's worth of data in roughtly 10000 cycles (depending on the actual code implementation). My implementation depends on some looping and is not quite that efficient. But it does suffice to keep the video update well within the 30 frame per second limit while leaving a generous amount of time available for doing something else (e.g. handling I/O or implementing game logic).

Single Source

The two buffers mentioned above are merely tools for keeping the display looking correct and up-to-date. But both buffers are completely ephemeral. A third buffer is kept for rendering the actual video frame. This buffer is the source for the stack blast copies described above. since both of those buffers will be overdrawn almost immediately, any "permanent" change to the display needs to be done in this "render" buffer. Consequently this is the perfect place to draw any static background items (e.g. anything to be scrolled).

I think that mostly covers it. I originally implemented this back in the Summer of 2020, so hopefully I am not overlooking any big details. But I believe the main points are covered. This technique gets the job done, and it has a few advantages that I hope to exploit in the near future...stay tuned!