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

Converting from MC-10 to Coco and Dragon

=====>

Part of the difficulty I have in porting programs from the MC-10 to Coco and Dragon is that Coco and Dragon Basic needs spaces in certain places that the slightly later rendition of Microsoft Basic used on the MC-10 does not require. Specifically:
ONNGOTO100 must become ONN__GOTO100
FORA=BTOCSTEPD must become FORC=A__TOB__STEPC
IFA=BTHEN must become IFA=B__THEN
IFA=BANDC=D must become IFA=B__ANDC=D
IFA=BORC=D must become IFA=B__ORC=D
PRINTATAB(10)B must become PRINTA__TAB(10)

An important programming technique for getting speed in my games for the MC-10 is to remove ALL spaces and to stick to single letter variables.This is fine on the MC-10.It requires absolutely no spaces anywhere. Every space just wastes tiny increments of time. I have some macros in MSWord now that help me with some of these replacements, but not all.I also have macros for changing the directly entered graphic strings to CHR$ equivalents, but there is always cleanup and unforeseen complications...

In terms of the key polling routine I have to change this for the MC-10:
20 ONK(PEEK(2)ANDPEEK(17023))GOSUB2,3,4,7

to this for the COCO:
14 ONK(PEEK(135))GOSUB2,3,4,7:RETURN
20 POKE345,255:POKE344,255:POKE343,255:POKE342,255:POKE341,255:POKE340,255:IF(PEEK(345)ANDPEEK(344)ANDPEEK(343)ANDPEEK(342)ANDPEEK(341)ANDPEEK(340))<>255THENGOSUB14

and this for the DRAGON:
14 ONK(PEEK(135))GOSUB2,3,4,7:RETURN
20 IF(PEEK(345)ANDPEEK(344)ANDPEEK(343)ANDPEEK(342)ANDPEEK(341)ANDPEEK(340))<>255THENGOSUB14

The multiple pokes in the Coco routine are for the benefit of CocoBs, which have a slightly different way of handling the rollover table that does not reset it. The Coco1 and Coco3 don't need such pokes, but it is too difficult to be bothered having multiple versions and they're not bothered by the pokes. The Dragon, however, is bothered, so I have to take all the pokes out for it. I also have to change the values of the K array to those of the arrow keys on the COCO/DRAGON rather than the codes for ASWZ.

MC-10 "Arrow" Diamond	Coco Arrow Keys ASCII Values	Coco Rollover Table peek
A=65	LeftArrow=8	343
W=87	Up Arrow=94	341
S=83	Right Arrow=9	344
Z=90	Down Arrow=10	342
SPACE=32	Space=32	345

Any special peeks or pokes must also be converted. Such as those which provide the current cursor location of the MC-10 17024 and 17025 (136 and 137 for the Coco), which I use quite a bit.

POKE49151,64 (MC-10) must be switched for SCREEN0,1 (Coco). The MC-10 uses a special CLOAD*A,"FILENAME" command to store numeric arrays to tape (in this case array A). This has to be replaced with the following code for a Coco with a disk drive:
6800 GOSUB10003:PRINT"SAVING":OPEN "O", #1,"DATA/DAT":FORC1=0TO150:WRITE #1,A(C1):NEXT:CLOSE#1:GOSUB10001
6840 GOSUB10003:PRINT"LOADING":OPEN "I", #1, "DATA/DAT":FORC1=0TO150:INPUT#1,A(C1):NEXT:CLOSE#1:GOSUB10001

or this code for a DRAGON using tape:
6800 GOSUB10003:PRINT"SAVING":OPEN "O", #-1,"DATA":FORC1=0TO150:PRINT #-1,A(C1):NEXT:CLOSE#-1:GOSUB10001
6840 GOSUB10003:PRINT"LOADING":OPEN "I", #-1, "DATA":FORC1=0TO150:INPUT #-1,A(C1):NEXT:CLOSE#-1:GOSUB10001

Finally, I usually include Zephr's nifty speedkey and speedup poke sensing subroutine for the Dragon and Coco
10000 IF PEEK(65535)=27 THEN DS$="Y":GOTO10001 ELSE CLS:INPUT"CAN YOUR COMPUTER HANDLE DOUBLE SPEED (Y/N)";DS$:IFLEFT$(DS$,1)<>"N"ANDLEFT$(DS$,1)<>"Y"THEN10000
10001 IF LEFT$(DS$,1)="Y" THEN IFPEEK(65535)=27 THEN POKE65497,0 ELSE POKE65495,0 
10002 RETURN
10003 IF PEEK(65535)=27 THEN POKE65496,0 ELSE POKE65494,0
10004 RETURN
10005 ' ENABLE DRAGON SPEEDKEY
10006 IF PEEK(65535)<>180 THEN 10008
10007 IF PEEK(269)+PEEK(270)<>1 THEN POKE65283,52:POKE256,116:POKE257,1:POKE258,81:POKE259,126:POKE260,PEEK(269):POKE 261,PEEK(270):POKE269,1:POKE270,0:POKE65283,53
10008 RETURN
10009 ' DISABLE DRAGON SPEEDKEY
10010 IF PEEK(65535)<>180 THEN 10012
10011 IF PEEK(269)+PEEK(270)=1 THEN POKE65283,52:POKE269,PEEK(260):POKE270,PEEK(261):POKE65283,53
10012 RETURN

I also change the typical Coco RANDOMIZE function:
R=RND(-TIMER)
to the following on the MC-10
R=RND(-(PEEK(9)*256+PEEK(10)))

Anyway, I am currently working on porting a dozen or so of my latest MC-10 programs to Coco and Dragon, but it is a lot of fiddly tiring work (not as fun as the original programming challenges), so my progress is slow. I've done BIGRED, SWELFOOP, and DICEWARS for the Coco. I'm currently working on Temple of Apshai. Here's what I plan to do:

JGGAMES10.DSK:
BIGRED
SWELFOOP
DICEWARS
SEAWAR
FLAPPY
DIGGER
CRAZY8S
SHUFFLE
GOFISH
HEXAGON
DOTS

JGGAMES11.DSK:
APSHAI

JGGAMES12.DSK:
PIRATE1
CASTADV1

JOURNEY

MORLOCKS
SORCERY
ORIENT
ADVENT1
DRWHO1
PTREAS
ORAN
CHATEAU1
NINJA
PIRATE1
MANTICOR