|Original Pet Version||My TRS-80 MC-10 Version|
My programming project was based entirely on this PET video provided by K. Moser and a few screenshots I was able to scrounge from the net. It took a while to draw out a representation of the original track layout and to settle on a standard format for the corner/switches. To do this I used my handy DRAW.C10 utility, which I have modified to "print" the screen to a text file using the VMC-10 emulator. This feature allows me to quickly sketch low res graphics screens and then transfer the characters constituting that screen into strings or DATA statements using a Windows text editor.
After getting the basic rail lines sketched out it was just a question of working out an algorithm for 64 X 32 set/reset graphic "trains." This task turned out to be much simpler that I thought. All I had to do was check in the direction that the pixel was going for a white rail pixel or pixel the color of the train itself (because of the artifact color effect the rail could alternately be turned to the color of the train). If no "rail" pixel was present then the program checks to either side of the obvious pixel in the direction being traveled (i.e. sense if a curve is occurring). If so, then it moves the train pixel to that location. Finally if no locations are available in the direction one is currently travelling (either straight ahead or to either side of the pixel straight ahead) then check if there is a rail pixel to either side of the current pixel. If so, then it changes to moving in a new direction of the pixel being sensed (i.e. changes from a horizontal to a vertical direction or vice-versa). If no such pixels are found, than that train has hit a dead end...
When this simple algorithm turned out to work effectively to move a pixel "train" around the track, then it was just a question of multiplying the number of pixels to run up to six trains and adding the track switching for each letter pressed. Due to the artifact effect of low res graphics on the MC-10, each train is always two pixels in width because colors can only be set for each 32 X 16 character position, so a 64 X 32 rail position to either side of the train pixel will always also be set to the train's color. positions behind the train get set back to the rail color of white. At the end of all train moves checks are made to see if any of the trains colors have been reset to the colors of other trains (i.e. a collision has occurred).
It took some fiddling to get the starting points worked out. I don't think in the original that this is completely random, as this would too easily lead to situations where it was impossible to avoid train collisions. From what I could see from Moser's video, it looked like there were some standard starting locations and that the other trains all started moving to the right, except for the player's train. After much trial and error I was able to work out a set of locations that would allow the player the possibility to complete any round with up to 6 trains. On the lower number of trains, however, I left some randomness in placement of the trains, to add some challenge. I don't know if the real game is like this. I do not have a Pet emulator setup to allow me to try the original program. I would greatly appreciate any input from Pet users who have played the original about the starting locations of the trains (other than the player's train).
Some may wonder why it is necessary to recreate an already existing program. Why not just fire up a PET emulator and play the original? This is not satisfactory to me for three reasons. One, I like Basic programming more than playing games. Two, I like contributing to the software collection of my favorite (but in its day neglected) 8-bit computer, the TRS-80 MC-10. Finally, having my son (and his friends) "beta test" my programs allows me to share my love of 8-bit computers and to re-live those long lost days of my youth when simple programs like this one, could fascinate kids like me for hours.