Well I've made another (possibly final) entry to Allen Huffman's 4K TRS-80 Color Computer Challenge. This program is a game idea I have been toying with since I first posted about it back in February 2013. It basically grew out of an attempt to represent the figure of an airplane pointing in 8 possible directions using only the chunky block graphics of the MC-10 (and as Allen suggested, probably inspired by Air Combat for the Atari). Here is the initial sketch I made using my simple but handy graphics program "Sketch."
I had also originally planned an elaborate graphic for the title screen:
However, this was obviously a no-go if I was going to make a game that could fit into 4K. However, I was able to wedge in the simple 8 direction plane graphics and the skyline of London (my apologies to any Londoners out there if it is a complete miss on accuracy). The game is much simpler than the one I had originally envisioned, which would have involved flack bursts and enemy planes that shot back. In the version I did create a single enemy plane travels back and forth from a random starting point on either side of the screen. However, I think that the game is probably much more playable than it would have been if I had not been constrained by the 4K limit. That limit really enforces a rigorous simplicity that probably results in a faster and more challenging BASIC game. But you be the judge. Here's a video:
The planes are less flickery in the real thing. The frame capture rate at which the Cam Studio software I use to create my videos is probably set too low to capture the animation accurately, but unfortunately the VMC-10 emulator is such a resource hog that I have to keep the rate low to prevent both programs from slowing each other down excessively.
I have submitted a variety of programs to Allen Huffman's 4K Color Computer Programming Contest. These programs were originally designed to run on the Radio Shack MC-10 with 16K ram pack. I had to "condense" many of them quite a bit to get them to work on the 4K CoCo since it provides even less RAM (2343 bytes) to BASIC than even the MC-10 without the 16K ram pack (3142 bytes). Some of the programs use the speedup poke 65495,0. This will always be located in line 0, so make sure to change this poke to poke 65497,0 if you are going to try to run these programs on a Coco 3.
Farfall is a text-mode arcade game based on John Linville’s Fahrfall. This game was already 4K, so I just tightened up the code a little bit and switched the key sensing peek routine so that it worked on a Coco 1. Whether a key is being pressed can be sensed directly on the MC-10 by looking at the result of PEEK(17023)ANDPEEK(2). If a key is being pressed the result will be the ASCII value of the key, otherwise the result will be zero. On the Coco you must look at a number of different memory locations that constitute a "keyboard rollover table." For example, PEEK(345) will return 255 if no key is being pressed and another value if the Space Bar is pressed. The table for all the keys is held at peek locations 338-345 (these represent different collections of keys on the keyboard). You can either search this table for the specific values returned by the key you are checking for (which don't correspond to ASCII values), or you can search the whole table for any change from the default 255 value and then check PEEK(135) to find the ASCII value of the last key pressed. However, it should be noted that in the Coco 2B Tandy modified the ROM so that the values of the table were not reset automatically after keys were released. To save space (and speed), and since the Coco 1 doesn't do this, I do not reset these values. So if you run these programs on a Coco 2, moves will continue even after you stop pressing keys. The Coco 3 returned to the original method.
JimVaders is a text-mode Space Invaders style game, with a stationary mother ship that makes a random appearance. The game speeds up as you go. This was already 4K ready. I had designed it to fit into limited memory when someone on the Yahoo MC-10 group mentioned that they only had an MC-10 without the 16k ram pack. The ram pack is essentially the "standard" way to run an MC-10, either in its real or emulated form. However, MC-10s often turn up in junk shops or on the Net without this essential item. People pick these computers up because they look cute and retro and then discover that they also have to track down the much more difficult to locate ram pack if they are to be able to run any descent software. They then become frustrated and their interest wanes. I thought it might help keep some of these folks involved in retro-computing with the MC-10 if I made some games that worked for its most basic layout.
Lander is a version of the classic Lunar Lander done with the 64×32 block graphics. Unlike my original version I had to remove the random and changing Earth generation routine (which was a quixotic feature that I quite liked) and all the instructions. Prompting had to be minimized and I had to scour the net for a line drawing routine that only uses integer math, since Micro Color BASIC lacks math functions like SIN and COS. I found the Bresenham algorithm, which nicely fit the bill.
Tetris is a version of the classic falling block game. It was one of my earliest programs for the MC-10. However, I abandoned working on it after John Dionne made an excellent machine language hi-res graphic version for the 20K MC-10, which included human voice and sampled sound effects! As a result, I always had a sense that it could have been improved so I appreciated the opportunity to return to it to see if I could whittle it down to 4K. However, with all its DATA statements detailing the orientations of all the blocks which had to be loaded into a fairly large array it was too large to fit in a 4K Coco. So I used the technique I developed to eliminate the redundancy of loading DATA statements into large array variables for text adventure info described in another of my blog postings. The result is that the program must be loaded in two chunks. You must first load and run the program file T1.BAS and then load the data file T2. If working from a real cassette T2 obviously should be saved after T1. Just leave the tape play button on as you run T1. To create the T2 data file on a real Coco or emulator use the TDAT.BAS file. Use Space and B keys to rotate blocks clockwise or counter-clockwise. G2048 is a 4K version of the current hit 2048 game (web-based and iPhone/Android). The original game is open source and so I used the posted JAVA code as reference to make it play like the original. I also had to find an alternative to the LOG function, which I had used in the original to calculate the changing colors, since there is no LOG function in Color BASIC.
R1.BAS
R1.BAS Loading Demo
Rail like Tetris is loaded in 2 parts. Load and run R1.BAS first. Then load data file R2. After that a prompt will appear. This is for the number of trains you would like to control. There is no error checking so make sure to enter only a number between 1 and 6. Use the RDAT.BAS program to create the R2 data file on a real Coco or emulator. The object of the game is to maneuver the blue train in the upper right to the yellow siding in the bottom left. Press the letters to curve or straighten the track at that point. If trains collide or run out of track the game is over. The prompt will reappear for how many trains you would like to control. This game is a port of a game originally for the Commodore Pet. Here’s a link to my blog posting detailing my production of the original for the MC-10.
AST4K.BAS
Asteroid Storm is a game that someone on the Yahoo MC-10 group described as a cross between Frogger and Asteroids. You must maneuver your ship from left to right across a moving asteroid field. However, your reverse thrust engines are broken. But don't despair, pressing the Space key will deploy limited shields to help you escape difficult situations, that is, if you haven't used them up already! This program uses a circle drawing routine for low res block graphics to create asteroids of various sizes. Then it basically snips the top line and prints it at the bottom of the screen to create the illusion of a moving field by taking advantage of auto screen scrolling. As levels are completed new asteroids are added to the field creating more challenge. Along the way you can collect replacement ships (up arrows) and extra points (@).
"Rail" is a Basic simulation/game program based on a Commodore PET program by Chris Torkildson originally published in Issue 19 of Cursor Magazine. Here are YouTube videos of the original program and my version re-programmed for the TRS-80 Micro Color Computer:
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.
For Retrochallenge 2015 I ported to Microsoft Micro Color Basic Will Crowther's original Fortran source code for what became "Colossal Cave" or "Adventure." The new basic source code should be easily shifted to other Basics. I have fixed and finished certain uncompleted elements in the code and changed a few things to create a few additional challenges to provide a more complete game experience of what was obviously an uncompleted "work in progress."
I re-coded the program into Basic from the Fortran source code and data file that Crowther's wrote for the PDP-10, which was recovered a few years back from old backup tapes. This is not the classic "350 point" version created by Don Woods by the addition of many novel elements to Crowther's original source. My version contains only the numeric room movement info and the room and event text descriptions of Crowther's original game, reputedly written to entertain his children in the wake of a marriage breakup in the mid 70s.
I had to wedge it into 20K of my favourite 8-bit the TRS-80 MC-10, so some of the descriptions got “edited” a little, but I was able to transfer the map info from the data file into Basic DATA statements, so it's a fairly accurate rendition of the original map. I only made a very few tweaks where directions were quite clearly messed up or to eliminate a few NE, NW, SE and SW (diagonal) directions. In reconstructing the game play elements I was greatly helped by Renga in Blue's "Observations about Crowther's original Adventure".
Will Crowther 2012
I have also added a few new commands. The SCORE command will tell you how you're doing and if you have won. The HELP command will provide some rudimentary aid. The UNLOAD command will perform the same function as the more standard "drop all" command of other adventures. The QUIT command not only quits but prompts whether you would like to save the progress you have made. You are also prompted each time the program is run if you wish to load a previous game. The same file name "COLOSDAT" is used for each save, but in the TRS-80 MC-10 emulator (VMC10.exe) you can save the resulting virtual cassette file to any file name you like in order to differentiate between different saves. Just remember that when loading and prompted to "Press Play" you must select the file name containing the desired virtual "COLOSDAT" cassette file.
Download VMC10_073D.zip for the Virtual MC-10 emulator, which includes the game in the JimG sub-directory of the cassette directory. To play the game load the file "COLOSSAL.C10" after typing CLOAD and hitting <Enter> in the emulator. Virtual cassette files can be loaded via the File menu of the emulator. Then just type RUN <Enter>
I was also greatly aided by Neil Morrison of the TRS80MC10Club group on Yahoo. Neil uploaded a PDF to the group of a simple text adventure program "Tower of Mystery" used as an example in a Compute's Guide to Text Adventures (1984). Here's a description of the program from that book, which fittingly contains a story reference to the original Adventure:
Tower of Mystery is a BASIC program designed to illustrate some of the concepts of adventure programming and to serve as a starting point for writing your own adventure programs. The object is to enter an old factory building where the world's only remaining copy of Adventure is reputed to be stored, and to leave with a tape containing a copy of the program. I was able to modify this very useful program to do most of the work of text entry and analysis. I just had to modify its verb list and items and re-code the sections for each of these commands to handle the event and room descriptions of Crowther's program. I also had to add routines to handle the ongoing interaction of the dwarves, who show up periodically, and item and resource management of food, water and light, which were lacking from the Tower of Mystery. As mentioned above, I had to largely "normalize" NE, NW, SE and SW directions, since there were so few of them and it would have required too much modification of the Tower of Mystery text adventure engine's basic N, S, E and W direction handling. Using Renga in Blue's descriptions of the puzzles and other game challenges, and by examining Crowther's original source, I was able to recreate what I believe is an essentially accurate presentation of all the original game elements.
As I worked on the rooms in the Bedquilt (“Under Construction”) area of Crowther's original code I really could sense where his patience with the project petered out (sometime in 1975 or 1976) so I also ended up adding a few unique elements of my own to “complete” an unfinished work just begging for completion. I can understand what tempted Don Woods to make his additions in 1977 to create the classic 350 point version.
That being said, I did not like some of the more surreal fantasy elements that Woods added. Crowther's original version has a more austere set of locations, but they have a feel of realism that is absent from the classic version's chaotic hurly-burly of branches. Also, there is clearly a sense that Crowther's fantasy elements (Hall of the Mountain King, nasty little dwarfs, wandering into a cave) were drawn from a single classic narrative source, such as the story of Peer Gynt, rather than a hodgepodge of fantasy cliche's. I tried to respect this integrity in the few additions I made to fill out Crowther's obviously abandoned work.
Don Woods helped Crowther overcome the problem of the game's unfinished nature by significantly expanding the complexity of the cave and by adding improved scoring and win subroutines. It's this latter version which is normally referred to as "the original adventure." In homage to this latter title I have also made my re-coded version worth 350 points, although these points only represent six 50 point treasures. Only five of these treasures are present in Crowther's original. I have added one treasure and one puzzle and a few new threats to help add new challenge to the adventure. I have also slightly changed the operation of some of the magic of the original to prevent old hands from simply applying their prior knowledge.
Enjoy!
*Spoiler Alert * The following short video demo contains spoilers, so proceed at your own risk:
If you' want to know more about the history of Crowther's Colossal Cave Adventure, including the cave it was based on, see "Somewhere Nearby is Colossal Cave: Examining Will Crowther's Original 'Adventure' in Code and in Kentucky" by Dennis Jerz of Seton Hill University (Digital Humanities Quarterly, Summer 2007, Volume 1 Number 2). For a long time the original code was thought to be lost but Jerz was able to arrange its recovery from an old backup tape of Woods' student account. Jerz's analysis shows that Crowther's original program was a game and not simply a spelunking simulation as is commonly thought. It included magic words and other fantasy elements. If you want to compare my re-coded version to the original Fortran program someone has got the original Fortran source running under modern Fortran compiler conventions.
