Checking My List

Another week down and roughly one more left to go in the Retrochallenge RC2016/01 event. I got off to a bit of a slow start this month, but since then things have progressed well. It looks like things are shaping-up nicely for my port of Xmas Rush to the TRS-80 MC-10!

Time Is On My Side

One of my main concerns with this port has been the lack of a vertical sync signal available to the CPU on the MC-10. A direct port of the drawing algorithms from the CoCo version of Xmas Rush resulted in objects sometimes disappearing completely within certain vertical ranges of the screen. I considered altering the basic drawing algorithms in hopes of minimizing the screen problems, but that really seemed like a "band aid" solution at best.

The MC-10's Motorola 6803 CPU does have a hardware timer circuit, so precision timing is possible. The problem remains as to where (actually when) to anchor the timer settings. Since we know how long the screen is actively drawing and how long each frame lasts, we can derive the anchor point by interacting with the user. The timer is used to divide the screen into two periods, representing the active and inactive drawing times. A visual indicator is used to indicate the temporal position of the inactive period, and the user is asked to provide input that is used to relocate the inactive period until it's visual indicator is not visible. Once that temporal anchor is established, all that is required is to never miss a frame timer expiration... :-)

Watch Your Step

Xmas Rush uses a bitwise map to represent the scrubby trees that comprise the playfield terrain. At game time, that map is also used to generate a data structure used to detect potential collisions between that terrain and the player and snowmen. Converting the original 6809 code to 6803 code was a bit tricky, since the 6809 code made use of the extra index register available on that CPU. The conversion made a lot more use of the stack, reminding me of a Towers of Hanoi game gone terribly wrong... Anyway, I eventually managed to sort that out and objects were suitably constrained from moving across the tree-filled terrain.

With the player now moving about, it seemed like a good time to introduce the pitter-patter sound used during player motion. The CoCo version used the horizontal sync signal for timing square wave generation, but the MC-10 is as equally unhelpful for horizontal sync as it is for vertical sync. I had hoped that I could do some tricky hardware timer manipulations to use the timer both for the vertial sync emulation and for sound timing, but I couldn't seem to master that feat. Instead, the sound timing is based around cycle-counted loops representing horizontal sync periods. This proved to be satisfactory for all of the sound generation in Xmas Rush.

BTW, the pitter-patter sound is not a normal tone. Each up-down transition of the square wave is governed by the output of a linear feedback shift register (LFSR) used to generate pseudo-random data. In a very real sense, the pitter-patter sound is more of a noise than an actual tone.

Win Or Lose

It is important to be able to tell when the moving objects collide. This causes the player to lose when he collides with one of the snowmen, and it is a prerequisite for a win that the player must seize the evergreen tree. Xmas Rush does not have any special data structure for detecting sprite collisions. With so few sprites, it was easiest just to check each sprite position to see if it overlaps with the player.

A set of flags is used within the game code to indicate which snowmen are active and whether or not the evergreen tree has been seized by the player. These flags are used in the drawing routines to control what is drawn in a given frame. The "seized" flag is also used in coordination with the player's position to detect a "win" condition.

The last, big missing piece was the movement of the snowmen. Since the game loop erases and redraws every sprite during every frame, movement is nearly trivial -- just change the draw location and the object moves! Each of the four snowmen has its own movement strategy and a corresponding routine to implement that strategy. I won't divulge them here, but each strategy is fairly simple, and the snowmen can be manipulated into trapping themselves behind parts of the terrain as they pursue their personal strategy.

Anyway, with moving snowmen the game is largely complete. All that remains is integration of the timer calibration code into the main program, and a few odds and ends. This week should see a successful end to this project...I hope you will stay tuned!