Graphics Mode
The Christmas tree on the title screen is drawn in a "semi-graphics" mode in which the low-resolution graphical glyphs are really just special characters, no different from numerals, punctuation, and letters of the alphabet. These are handy for a number of things, but they are generally not as flexible as the "high-resolution" graphics used for the main part of the game. Fortunately, switching to graphics mode is fairly simple to do.
The 6847 Video Display Generator (VDG) is configured through a collection of logic signals applied to its external pins. These can be wired a number of different ways, and even on the MC-10 some of the configuration pins are actually driven directly by the incoming video data. The rest are connected to a small register on the MC-10 motherboard. That register can be changed by writing to any address between $9000 and $bfff, although $bfff is the conventional address to use. Writing an appropriate bit pattern to this address is all that is required to change the graphics mode.
Coordinate Translation
With graphics mode engaged, we need some way to specify where graphics are displayed on the screen. For simplicity's sake, I designed Xmas Rush to use a simple 32x32 grid for placing objects on the screen. This alignment naturally matches the number of horizontal bytes for each line, avoiding the need for any mask-and-shift operations when writing data to the screen. The X- and Y-coordinate for each object is stored in a two-bye pair that can be easily manipulated using the double-accumulator operations (e.g. LDD, STD, etc) available on the 6803.
There is a bit of math involved in translating a set of coordinates on the 32x32 grid into an address for accessing the framebuffer. Of course, I already had 6809 code to do this on the CoCo. Blindly translating that to 6803 code for the MC-10 quickly provided satisfactory results.
Timing Again
From there, I quickly conquered the task of drawing the playfield. Xmas Rush uses a bitmap to describe the placement of all the bare trees that make-up the playfield. Translating the relevant 6809 code from the CoCo to 6803 code for the MC-10 again proved an easy task, allowing me to begin work on the fundamentals of constructing the game loop.
The CoCo version of Xmas Rush uses a graphics animation technique known as "double buffering". At any give time one buffer is displayed while the other is redrawn for the next frame of animation. Periodically a vertical sync event occurs. At that time the program changes which buffer is actually displayed, and work shifts to clearing and redrawing the previous buffer. This technique prevents ever displaying a partially drawn frame, and it provides a natural source of "real time" information for pacing the game.
The MC-10 provides no means for the CPU to observe when a vertical sync event happens, but it does provide an internal timing source that can be used for game pacing. My initial attempt to use this timing source as a substitute for the vertical sync event was disappointing, because I was resetting the timer based upon its current value (a moving target) rather than as an offset from the previous setting. A little fix stabilized the timing so at least the game can be paced correctly.
The current timing technique is still prone to showing some weird video effects, depending on the exact timing between the game and what the VDG is doing. I think that a manual, user-driven timing synchronization is possible. Alternatively, maybe just some random resets will be acceptable -- this would be similar to the "reset until this is blue" that was so common on CoCo games that used NTSC "artifact" colors.
In any case, there is still some work to be done adding player movement, snowman AI, and other missing game bits. This is a good start, but it needs a good finish. Do you want to see how it ends-up? Then you will just have to stay tuned...
