The Creature that Ate the 24th Annual "Last" Chicago CoCoFEST

The people of the Glenside Colour Computer Club decided to host an event celebrating the 50th anniversary of the development of BASIC. The Dartmouth Time Sharing System (DTSS) version of BASIC was the origin of the language and Kip Koon organized a programming contest to celebrate this historic beginning. He put out a call for people to try to write (fun/game) programs in Dartmouth BASIC on a DTSS Simulator. I got the simulator and began to play around with the language.

I learned a couple of surprising things. First, this earliest version of BASIC didn't originally have an INPUT command. This was because the programs were not interactive, but meant to be run on the main network hub and the result output on a teletype device. Second, the size of programs was quite limited, something less than 6 KB. Third, there was very limited string capabilities. Basically you can print literal strings, but you don't have string variables, or any string handling. So even though an INPUT command had been added to the simulator's implementation of the language, it would be hard to make a game that only used input of numbers.

My first thought was to make a version of the classic Star Trek game, since it only used numbers for input (1. Shields 2. Photon torpedoes, etc). However, the variation that I programmed ran up against the program size limit.  My program was too large to fit into the DTSS. So, I moved on to thinking about other concepts.  The ubiquitous "Hunt the Wumpus"-like game ideas seemed to be the only thing to be practical (small memory, number input).  It was very challenging to think up anything entirely new.

I have enjoyed recently watching some of the episodes of "Tabletop" with Will Wheaton. He's of a similar age to me and a similar degree of geekyness. I grew up playing combat simulation board games like Blitzkrieg, and so the thought occurred to me of trying to create a simple board game simulation for the DTSS BASIC game contest. I had run across the Epyx game, "Crush Crumble Chomp" back when I was doing my port of "Temple of Apshai" to the MC-10. I knew it was a variation of a classic Board game, so I went and looked it up.  The game was called "The Creature that Ate Sheboygan."

The game was originally designed by the brilliant board game designer Greg Costikyan. Although the project grew to such a size, far beyond the 6KB limit of DTSS, and for reasons of wanting to add some nifty graphics to represent the various different monsters (in purple below), or Kaiju as the Japanese call them, I decided to switch back to working on it in Micro Color BASIC. Still, with enough space, I think the resulting game could in principle be done completely in Dartmouth BASIC. In essence it only uses simple keystrokes and numbered directions for input. The main action takes place on a 16 X 16 grid, using only simple characters to represent the elements making up a map of the City of Sheboygan.  Other than that, the game is all about combat tables and game rules and applying the results of simulated dice throws to the tables and rules.

Anyway, after a week of putting a push on in hopes of having it ready by the weekend of the Annual "Last" Coco Fest, I have produced a variation of the game that I believe faithfully captures all the elements of the original with only a few compromises to help the AI that I was able to implement to play the "human" side of the game.

I send greetings to all the The 24th Annual "Last" Chicago CoCoFEST goers. I hope no giant kaiju comes down the turnpike and eats Chicago!

The game and the VMC10.exe MC-10 Emulator to play it can be downloaded here or on the Javascript MC-10 Emulator. Just load the SHEBOYGN.C10 file after typing in CLOAD and hitting ENTER. Then type RUN and hit enter.

Coco Version of SHEBOYGN.BAS

A link to the Coco specific version can be found in my coco compilation zip on the JGGAMES10.DSK

You can press the "H" key during the *MONSTER MOVE* phase to receive some help about playing the game.

During your turn as the monster (M), when the other pieces (see right pic above) are stationary, you can choose (ASWZ) to move or (D) destroy stuff, (F) breath fire, (X) make a web, (C) scream sonically or hit (SPACE) to do nothing. You get a number of moves based on your abilities and your strength. At the end of your turn you can attack nearby enemy units by choosing a direction number or hit 0 to refrain from attacking. When you are prompted for a numeric value you can hit space to scroll through the range of options before hitting (ENTER) to initiate the action. Basically you want to destroy as much as possible to get to a certain level of destruction (based on your level of difficulty). You must defend yourself against the aggressive units and "eat" the civilians. All attacking units have certain ranges and certain movement characteristics.Troops, for instance can travel through/in buildings. Units within their relevant ranges wil pool their attacks on you each round. If you lose enough power and strength, you can be defeated by the measly humans.

"Overtake" another 4K Game for Allen Huffman's Contest

I've made another 4K game for Allen Huffman's programming contest. It's called "Overtake" and it is a car racing game. I've also submitted a 10 Line version of it to the NOMAM BASIC programming contest in Germany for a retro event there.

1 DIMK(128),P,G,V,R,D:K(9)=1:K(8)=2:K(94)=3:POKE65495,0:M=1024:FORR=1TO18:R$=R$+CHR$(143):NEXT:FORR=1TO10:R$=R$+CHR$(175):NEXT:FORR=1TO18:R$=R$+CHR$(143):NEXT
2 FORR=1TO32:W$=W$+CHR$(201):NEXT:Y$=CHR$(174)+CHR$(207)+CHR$(173):O$=CHR$(174)+CHR$(191)+CHR$(173):B$=CHR$(175):C$=B$+B$+B$:GOTO3
3 V=1:P=-10:G=50:S=0:PRINT@480,"SPEED"200-G;:FORD=1TO50:FORT=14TO0STEP-1:PRINT@T*32,MID$(R$,V,32);:R=2-RND(3):V=V+(R<0AND(V+R)>0)-(R>0AND(V+R)<16):NEXT
4 P=P+448:PRINT@496,"DIST"INT(D);:ONRND(2)GOTO5:R=P-(RND(5)*32)-256:IFPEEK(M+R)=175ANDPEEK(M+R+2)=175THENPRINT@R,O$;:PRINT@R+32,O$;
5 IF(PEEK(344)ANDPEEK(343)ANDPEEK(342)ANDPEEK(341))<>255THENONK(PEEK(135))GOSUB8,9,10
6 PRINT@P+32,C$;:P=P-32:IFP<0THENNEXTD:PRINT@0,W$;"SCORE";S:PRINTW$;:END ELSE IFPEEK(M+P)<>175ORPEEK(M+P+2)<>175THENSOUND1,1:G=50:PRINT@485,200-G;
7 PRINT@P,Y$;:PRINT@P+32,Y$;:FORZ=1TO G:NEXT:S=S+(50-G):GOTO5
8 PRINT@P,B$;:PRINT@P+32,B$;:P=P+1:RETURN
9 PRINT@P+2,B$;:PRINT@P+34,B$;:P=P-1:RETURN
10 G=G+(G>0):PRINT@480,"SPEED"200-G;:RETURN

I use some speedup techniques I've never used before. These involve doing checks and additions in the same line/command by using the logical operators and relying on the fact that they return either a zero (False) or -1 (True). If you are only moving by increments of 1, then you can efficiently use what these operators return to not only do boundary checking, but also, at the same time add or subtract a 1 if the check is okay. I suppose you could also multiply the result by another number to do additions for move increments other than 1, but it is especially efficient with movements of just 1 and helps avoid the use of lots of IF statements, which although generally fast commands, can when used in large numbers really slow down execution. So I have a command like this:

10 V=V+(R<0AND(V+R)>0)-(R>0AND(V+R)<16):program flow continues

This line basically adds or subtracts a random number (R) to one section of the track location unless that will put the track too far left or too far right on the screen. In the past I would have had multiple IFs like this:

10 IFR=-1ANDV+R>0THENV=V-1:GOTO 30
20 IFR=1ANDV+R<16THENV=V+1
30 program flow continues

The new way also saves having to use multiple lines on the MC-10, which was also helpful for my 10-Liner programming contest entry code (see above).

I also had some recent comments on my NBLITZ about how to avoid flicker in BASIC game animations.  I'll repeat my comments here for others who might have missed them.

Just make sure you remove all unnecessary spaces and pack lines as tightly as possible using colons (See my post here for advice on the few places you must leave spaces in for the Coco). I also find it is important to resist the temptation to stop working on a program's basic structure once you've got it basically working in terms of the animation. There are usually many ways to improve the logic and make the flow of a main loop more efficient. For example, if you're doing repetitive calculations in your animation loop, put them in a variable at start up, or do a pre-calculation loop at startup and store the results in an array. Then just consult the variable rather than do a calculation in your animation loop. Also, although in NBLITZ I use the SET command to display the planes, I don't use RESET to clear them. Instead, I have two large strings filled with CHR$(128)s (the black sky character) and the little graphic of London characters for the bottom of the screen. I just print these two strings @0, and they clear the entire screen to the background of black sky and city skyline (except for the very bottom left position, which I just pre POKE to the right color character at startup). Then I just redraw the planes in their new locations. This is much faster than RESETing the individual pixels of each plane or having complicated procedures to POKE them to black.

Also, in NBLITZ I originally checked that the location of my plane did not go beyond the boundary of the top, left, right or bottom of the screen, but I was also checking for any collisions with other planes or the city at the bottom the screen.  So I was eventually able to remove the bottom bounds check since the city effectively blocks any movement towards that boundary. There's always some temptation when programming to leave such redundancies in, especially in the old days (or even still today) when you had to use to kludgy EDIT and LIST commands to make any changes. By programming using a good line editor like WordPad, such editing awkwardness is overcome. Here's a video showing the advantages of using the VMC-10 emulator and its quicktype feature to make quick and easy changes to one's BASIC source before "quicktyping" it in, which takes just a few seconds, and running it:

Retrochallenge 2015/01: Night Blitz

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.

Retrochallenge 2015/01: 4K Color Computer Programming Contest Entries

Farfall

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 (@).

 
These programs can be found in my Color Computer program compilation ZIP file. They are contained in the JG4K.dsk file in the ZIP.

Retrochallenge 2015/01: Rail--Switch the Railroad

"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.

Retrochallenge 2015/01: Will Crowther's "Adventure" Ported to 8-Bit Basic

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 "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 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.

Ant also has an interesting blog on the mainframe game development system "Wander", which apparently preceded Colossal Cave (1974). He helped recover it from digital possible destruction. Another victory for retrogame "archeology" of such a concept makes sense. See John Aycock's book of that name: https://www.springer.com/gp/book/9783319300023.

Source code for my BASIC version of the game can be found here (the highest numbered "COLOSSAL" file is the latest version)

https://github.com/jggames/trs80mc10/tree/master/quicktype/Text%20Adventures/Colossal

It can also be played on the Internet Archive:

https://archive.org/details/colossal_202405

Space Trek by Jake Commander

Here are a few comments about the code I modified for the MC-10 (on Github) of Jake Commander's "SPACE TREK" originally published in Color Computer Magazine (May 1983). Each comment refers to the code snippet just above it. My MC-10 version has removed all ELSE commands and changed all PLAY commands to simpler SOUND commands. Also, all string assignments using the special poke routine at the beginning of the program and all uses of the STRING$ command have been replaced by literal strings, since graphic characters can be input directly from the MC-10's keyboard. All PRINT USING commands have been replaced by combinations of INT, STR$ and MID$, RIGHT$ or LEFT$ commands to format numeric output.

1 C1=1:C2=32

2 IFMID$(M$,C2,1)<>""ANDMID$(M$,C2,1)<>" "THENC2=C2-1:GOTO2

3 PRINTMID$(M$,C1,C2-C1):C1=C2+1:C2=C1+31:IFC1<=LEN(M$)THEN2

4 RETURN

The above is my 32 character word-wrap routine. I use it for all printed messages instead of inserting spaces in them. It's also more flexible when it comes to messages that change length, such as when you have STR$(numvar) numeric data being concatenated with a string.

420 GOSUB1650:H=H+1:IFH<150THEN390 

If others want to port this code they will need adjust the speed of the game because of differences in their machines from the original Coco version.  Change the 150 value above to something higher if your machine is slower or something lower if your machine is faster. This is the countdown for the "pings" of the view screen, as in the original Star Trek show.

580 GOSUB650:FORH=1TON:GOSUB660:ONZGOTO590,595,594 

590 NEXTH:IFF=0THEN640

591 H=H-1:GOTO620

594 TM=H:H=N:NEXTH:H=TM:GOTO680

595 TM=H:H=N:NEXTH:H=TM

The ON/GOTO in line 580 is in the middle of a FOR/NEXT loop.  As far as I can tell, the jumps to 595 and 594 originally simply jumped out of the FOR/NEXT loop never to return. I just hate not closing NEXT loops on principle, and they can occasionally cause problems if they occur too often, so I added a temp (TM) variable and lines 595 and 594 to gracefully exit the loop before proceeding on to the original GOTO lines.  I use the TM variable to re-assign the value of the NEXT loop to the variable after completing it properly, just in case the program relies on knowledge of what the value of the loop was.

920 FORI=1TO3:IFC=K(I,1)ANDD=K(I,2)THENK(I,3)=-1:X=C:Y=D:R=320:GOSUB1560:I=3

930 NEXT:GOTO970

There was a rare problem where a photon torpedo hit would seem to register twice (two explosions in a row).  I think this may have been a result of not gracefully exiting the for next loop as soon as the "hit" Klingon is found (why keep searching for hits on the other Klingons?).  So I added I=3 after the torpedo is found to have hit one of the 3 Klingons that can be in any Quadrant.

950 GOSUB1580:PRINT@320,;:M$="WELL DONE! STARBASE DESTROYED!":GOSUB1:B=B-1:BT=BT-1:M2=4:X=C:Y=D:GOSUB1550

951 PRINT@352,;:M$="THE EXPLOSION HAS THROWN YOU OFF COURSE":GOSUB1:GOSUB1350:PRINT@320,;:C=RND(...

I changed the word "DAMAGE" to "EXPLOSION."  It seemed to make more sense. Also, I added a pause (GOSUB1350) and a PRINT@ statement after the message, since occasionally more messages might follow that fill the screen beyond the 16 line limit of the MC-10.

1090 PRINT@320,"LAST BATTLE-CRUISER DESTROYED!":GOSUB1700:PRINT"THE ";U$;" IS SAVED!!":GOSUB1700:SOUND75,5:SOUND80,5

1091 PRINT"YOUR EFFICIENCY RATING ="INT(K7/(T-T0)*1000):END

I added a call to line 1700 for a little noise/music when you win.  It seemed anti-climatic otherwise. Line 1700 in the original listing seemed to be an orphan anyway, so I tweaked it for a more congratulatory sound.

1100 CD=0:AF=0

1110 A=0:GOSUB380:PRINT@217,"OPT?  ";

1120 GOSUB390:IFA>6THEN1120

1130 IFA$=CHR$(13)THENONA+1GOTO330,1290,1150,1160,1170,1280,1140:GOTO1120

1131 PRINT@249,B$(A*2+17);:PRINT@281,B$(A*2+18);:GOTO1120

1140 A=0:AF=0:FORJ=1TO8:FORI=1TO8:CC=INT(Z(I,J)/100)...

1141 POKE16424+A+(I-1)*2,CC+112:POKE16425+A+(I-1)*2,Z(I,J)-CC*100-O*10+112-64*O:NEXT:A=A+32:NEXT:O=0:GOTO1110

1150 O=0:AF=0:FORA=40TO266STEP32:PRINT@A,Y$;:NEXT:PRINT@41,"STATUS REPORT:";:PRINT@106,"KLINGONS ="KT;

1151 PRINT@138,"STARDATES="INT(T0+TT-T);:PRINT@170,"STARBASES="BT;:GOTO1110

1160 IFK=0THENGOSUB1620:GOTO1110

1161 AF=1:CC=U:A=V:FORF=1TO3:IFK(F,3)<0THEN1270

1162 TM=F:F=3:NEXT:F=TM:W=K(F,1)...

1170 AF=0:PRINT@384,"ENTER START AND END CO-ORDINATES":PRINT@320,;:INPUT"(X,Y,X,Y)";CC,A,W,X

When in the computer OPT mode, if you select TORPEDO DATA and then select any other options besides GUIDED TORPEDO, you garble the variables used to store your TORPEDO DATA. So I added the AF (auto fire) variable switch to all the Computer options to turn off the GUIDED TORPEDO fire option if you don't select it right after selecting the TORPEDO DATA option. Now GUIDED TORPEDO will only work if you select it after selecting the TORPEDO DATA opt.

1281 IFAF=0THEN1300

This line is the one added to the TORPEDO subroutine to prevent firing (and possible infinite loop) unless the AF variable is set to 1.

1360 FORZZ=H*.25+1TO1STEP-1:POKE49151,64:SOUND255,1:NEXT:RETURN 

The above poke just switches the screen of the MC-10 to orange from regular green to give a flickering screen effect when you are hit.

1520 T=T+.5:PRINT@64,INT(T);:GOSUB1500:IFT>T0+TTTHEN1060

This is the stardate countdown. It used to read T=T+1, but since the Coco is slower than an MC-10, I had to have it count more slowly (by .5s) or the game expected you to play at too high a speed to be fair.

1550 GOSUB1580:S(X,Y)=0:G(L,M)=K*100+B*10+S:RETURN

1560 K=K-1:IFK<0THENK=0:SOUND100,20

1561 GOSUB1550:GOSUB1420:PRINT@R,"KLINGON AT"STR$(INT(X))","RIGHT$(STR$(INT(Y)),2)" DESTROYED";

I added the check in 1560 above to prevent the problem mentioned above of double explosions from torpedo hits on some Klingons.  If the hit registered twice the K variable could go to a negative number which really messed up the modification of the 3 digit number (i.e. 100s, 10s, 1s) calculated in 1550 used to store each Quadrant's info G(Klingons, Starbases, Stars).

1640 ZZ=PEEK(17025):PRINTLEFT$(BL$,16895-(PEEK(17024)*256+PEEK(17025)));:POKE17025,ZZ:RETURN

The peeks in this routine above 17024 and 17025 are simply the way for the MC-10 to determine the screen location of the current cursor location (0-511). It is used to print blanks of a particular length from that location to the second last position of the screen (i.e. to clear the message area but not print in the bottom right corner so as to cause a linefeed moving the entire screen up).

1700 FORX=50TO70STEP5:SOUNDX,1:NEXT:RETURN

This line was an orphan in my listing of the program. So I modified it and use it in the win routine to provide a little sound.

And there are always tweaks and modifications that cry out for implementation...

1285 C=CC:IFRND(10)>9THENC=C+.5:IFC>=9THENC=1

For example, I changed the GUIDED TORPEDO routine to misfire on a 1 in 10 chance, just to moderate this lazy option. There has to be some disadvantages for relying on computers for everything!