I made a version of the classic puzzle game Sokoban back in 2013. I used some ASCII maps I came across for an OS9 text version I found for the Coco. Because of the limitations of the MC-10 screen I could only use puzzles that would fit on the 20X16 space I had designated on the left hand side of the screen for displaying them. That meant that only the first dozen or so of the maps from the original game would easily fit, after that I had to pick carefully the maps that would fit from the more complex higher levels. I remember at the time that I was able to decode what most of the ASCII characters used to encode the maps represented. There were the boxes, the home bases where the boxes had to be pushed to, the starting point for the character and the walls. But there was also another kind of character that I couldn't figure out. These special characters only appeared on the higher level maps. I didn't play the game well enough to have got high enough in level to know what these special codes were for, so I just left them as blanks. But it always niggled at me that I hadn't properly completed the program.
Well jump forward a few years and the thought struck me that I should be able to find more information about Sokoban on the Net today, including possibly on-line "solver programs" that would help me to check whether the program was working properly on those higher level maps. I had recently used a Minesweeper solver program to help me check whether my Sweeper program (for the 10-Liner programming contest) was working properly. I like programming, but I'm actually not very interested in logic puzzles, so it greatly eases the burden of testing to be able to have a program that will help you complete a puzzle. Well I didn't find a solver program but I did find videos of people solving all the classic maps for the game:
Puzzle Map 50 was one of the maps I had included in my version for the MC-10. When I viewed the video I was able to see that the strange characters I hadn't been able to figure out back in 2013, where just boxes that were already placed on home bases at the start of the level (the reverse Os in the picture below).
New 2015 Version
You can see that in my old version I had left these out.
Old 2013 Version
Another feature that I had regretted not adding to the program was the ability to take back the very last move. Without that feature, one simple slip of a finger could ruin a whole level. On the very high levels this can mean possibly hundreds of wasted moves. So I added the feature to help avoid annoying players too much (if there ever are any besides myself). I was also able to improve the animation of the little warehouse worker dude. Robert Sieg created a little click sound routine using just POKES and PEEKS, which I added as the footsteps for the guy, rather than the excessive SOUND commands I formerly used, which are simply too loud and annoying.
I was able to fix all the maps with the special characters in them by looking for images of the maps on-line. In the course of doing that I was also able to add the original map numbers to the 25 "levels" that I included. So the player can now know which of the original maps they are playing on the MC-10 version.
I committed to blogging about my recent projects for RetroChallenge 2017 and the last two "snow days" here in Cape Breton have allowed me write about the projects that I most wanted to write about. I know that I'm early, but hey when the weather cooperates with you in Canada, you've got to take advantage! And I'm not sure if I'll be able to post in April--I'm a university professor and that's end of term and exam period for me. So in case I can't find the time for more posting, I'll thank John and the other participants for another fun contest this year. I'm sure I'll be able to find time to read about the other projects over the coming month, which will be a fun distraction from marking. For more information about the challenge click here: http://www.retrochallenge.org/2017/03/rc201704-open-for-entrants.html?spref=fb
I know that what I mostly do is port old code from around the Net to the MC-10. But occasionally I feel the urge to make something new. I got the inspiration for my game "Curse of the Undead" by stumbling across a website that had these two interesting images drawn using just text graphics.
Curses of the Undead
I'm attracted to such images because their ASCII text graphics can often be easily translated into lowres graphic images on the MC-10. With that in mind I set out to make some simple graphic streetscapes like those in this Linux text game described as "Your 3D Zombie Apocalypse in ASCII!" The author offers a zombie apocalypse adventure for the Linux console. Apparently he dubbed it “Curses of the Undead” because it used the standard ncurses library used for manipulating the console screen under Unix systems,
The game play sounded very simple with the player basically just responding to a sequence of decision prompts as he navigated a section of town being swarmed by zombies. After I got the street scapes drawn, I though I would try to cobble together a simple 3D engine that would allow you to navigate the streets of a city on your MC-10. I've worked on a number of 3D systems now for ports and original program, so I'm familiar with the basic principles for plotting your view based on the direction you are facing. It came together pretty quickly. Then I had to make some kind of game out of it. I had a number of standard simple zombie swarming text games, where the player gets two moves for the every one move of a bunch of simple X/Y coordinate tracking zombies.
Zombies
One thing I had always thought about such games was that they were always a little short. It usually didn't take long for you to trick the zombies to track into whatever obstacles were spread around meant to kill them (the white blocks in the above). I thought it might be nice to extend this kind of play by placing it in a virtual setting, so that one had to succeed at a sequence of encounters. And adding some animation and perhaps a weapon or two to spice things up a little would be nice too.
So I translated the game play of these standard zombie tracker games to the different street locations you move to using the 3-D engine. You must destroy a total of 60 zombies spread randomly throughout your neighbourhood to rid it of the zombie menace. To aid you, I also have supplied your character with a shotgun, but it only comes with 3 bullets initially. You must find more ammo as you move around. I also animated the fires that you can lure the zombies into to destroy them. But beware of hitting these fires yourself because they can cause you injury. Three brushes with the flame and you will join the zombies in death, but not the still mobile kind.
You might notice in this early version of the game that one mistake I made was listing how many zombies you had "killed" at the end of each game. Oops. Changed that to "destroyed" in the final version. Don't want to mess with the classic "guilt free" destruction that lies at the heart of the zombie motif. No live people were harmed in the making of this game!
This game was originally published as a type-in program for the Commodore 64. The book was Mind Moves--Strategy Brain Games for the Commodore 64 and it was published in 1984 by Dilithium Press. The authors and programmers were Phil Feldman & Tom Rugg. It was John W. Linville our illustrious contest host who provided the impetus for the port. He knew I share his interest in type-in books and magazines and sent me a link to a PDF of the book. Areojam was the first program listed in the index. It looked like a lot of fun and a good prospect for a port.
Bridge to sector traffic controller. Entering control territory. Do you read? Request permission to dock Do you read?
In the game you are a futuristic "air traffic controller" in charge of multiple spacecraft traveling through a busy spaceflight corridor. You command these ships from your control console. Action is fast. You must make quick and accurate decisions to get everyone through safely and efficiently. Here are the rules as described in the book:
RULES
The action takes place on a major east/west artery with traffic flowing in both directions. (It's not clear that compass directions like east and west have meaning here in outer space but, what the heck, we claim poetic license.) Spacecraft enter from either end, must stop for refueling at the south-central dock, and exit at the opposite end from where they entered.
There are two classes of ships-- manned craft (yellow and green) and drones (blue and red). It's particularly important that you process the manned ships efficiently. The playing field is subdivided into square sectors. Only one ship can be in any sector at a time.
You command each ship's direction of movement (Space Bar). When you feel all are oriented properly, it's time to issue the movement command (Enter key). However, you have only a limited time to do this. The ever-present clock on your console ticks away. You must issue a movement command within a prescribed time, or one will be issued automatically. (After all, spacecraft can't just sit around for too long.)
New ships enter the arena regularly. The expected arrival time of the next ship is shown on your console so you can plan for it if you have the time to check. After docking for refueling, each craft must leave in its intended direction through a proper corridor. So you have to position ships correctly for exit too.
If things get too cluttered, you can zap a ship (D Key) from your territory as a last resort (no telling where it goes). This is a costly option, but it sometimes is necessary to avoid worsening problems. It also leaves space debris where the ship was, rendering that square dangerous for awhile. This is particularly troublesome near the dock, since all ships must pass through that region.
Speaking of space debris, that junk can also appear randomly. It must be the funny weather in space. Needless to say, a ship-to-ship collision is big trouble. We can hardly bear to talk about it. If a manned ship is involved, there goes your promotion.
To move the cursor (a reverse asterisk) you use the regular WASZ MC-10 direction keys. Hitting the Space Bar rotates the ship your cursor is over. When you have all of them rotated the way you want you can issue the move command by hitting the Enter key, or wait until it is triggered automatically. However, it is to your advantage not to waste time as this is reflected in your score.
The game made extensive use of the TIMER function built into most Microsoft versions of basic but unfortunately not included in Micro Color Basic. So I put out a call to the machine language coders in the MC-10 Yahoo group for someone to create a functional equivalent as a USR routine. Darren Atkinson responded with a wonderful little M/L timer function that mimics the functionality of TIMER. Thanks Darren! He saved a version of it in the UTILS directory of my "G-Soft" files directory on Yahoo.
Besides that hurtle it was a fairly straightforward port. I just had figure out the somewhat bizarre Commodore system of rendering graphics on the screen and translate these into roughly equivalent shapes using the lowres graphic characters of the Motorola 6847 chip. Of course getting all of it to fit on a 32X16 screen versus the 40X24 screen of the 64 took some adjustment, but I think it came out pretty well:
Here is the original again for comparison:
The nifty grid is absent, but I don't think its particularly necessary. Otherwise, all the other messages have been jammed into the lower 4 lines of the MC-10's screen. The space station with its docking ports for refueling is the white square at the bottom of the main display. You can see how the ships look more solid when they have a load of fuel.
So thanks gain to John for the suggestion and to Darren for the M/L TIMER function for the MC-10. Here's a video of the game doing its thing:
A while back I ported "Ultimate Adventure" by Phil Edwardson from a version for the Dragon 32 computer. I think I was attracted by its name. If it was truly "the ultimate" adventure, I wanted a version of it for the MC-10.
Unlike many of the adventures I have ported I couldn't find a walk-through by someone who had completed it to use to test for bugs. This was probably because this adventure contains a lot of random elements, including the location and effect of mysterious "portholes" that can transport you to different locations, but which can sometimes malfunction.
Although I was aware that the game had been distributed by Microdeal, a British company that did a bunch of ports of Coco software to Dragon, I wasn't aware that it was part of a five part series. That was until I got a message from Sudders on the Solutionarchive.com forum for classic text adventures.
"I'd just like to play the 5 games in this series. I think a couple that I have [that you made] are already ported."
It turned out that I had already done the "Adventure in Colonial Williamsburg" along with "Ultimate Adventure." Sudders was interested in the Mansion, Jerusalem and Castle Dracula adventures that were also a part of the series. In looking into it further I discovered that many of them had been published first in CLOAD Magazine and were only later licensed and distributed by Microdeal and numbered as follows:
I was able to find the Dragon version of "Jeruslalem Adventure" and using the XROAR emulator LLIST a text version of it to a file on my PC. Here's the batch file I use to run XROAR so that its printer output (such as LLISTing) goes to a text file:
xroar -lp-file "lprint.txt"
The standard routine for porting text adventures from Coco or Dragon involves getting rid of ELSE commands and replacing them with different Basic structures. For example a typical ELSE command like this:
10 IF A<B THEN 50 ELSE 60
can be replaced by:
10 IFA<BTHEN50
11 GOTO60
Notice that all the spaces are removed to help conserve memory. Structures like this are tougher:
10 IF A<B THEN A=A+1 ELSE B=B+1:C=C+1
But you can use a structure like this:
10 IFA<BTHENA=A+1:GOTO20
11 B=B+1:C=C+1
20 REM continue flow
Something like this:
10 IF A<B THEN 50 ELSE B=B+1
can be replaced with something like this:
10 ON-(A<B)GOTO50:B=B+1
This later variation can be particularly useful if you are hard pressed for extra line numbers. This later problem can be eased by using the RENUM command before exporting the original program to a text file.
The next step in porting an adventure is to make sure all the program lines are under 128 characters long. I just adjust my text editor to a window width that indicates where this break is. The process usually only requires breaking lines at a colon and putting the rest on a new line. However if the line is a super long IF statement you might need to create an IF that calls a subroutine at the end of the program where the various commands after the THEN can be broken into separate lines.
Of course POKES and PEEKS to screen memory have to be shifted from 1024 to the 16384 screen start address of the MC-10. I also like to use my simple 2 line word-wrap routine to replace any PRINT statements that might have strings that are longer than the 32 character screen. I often spend a bit of time weeding out such possible lines, or sometimes I just replace almost all the PRINT statements with a call to my subroutine. This involves assigning the string to M$ and then GOSUBing 1. Line 1 is where I usually stick the word-wrap routine. I have created a macro in MS word to help with this process.
The final stage involves cleaning up possible preexisting bugs in the program (which I sometimes discover), spelling mistakes and adding features just for the hell of it. For example, sometimes adding the function of using just N,S,E,W characters by themselves for movement is nice if the program requires full "GO WEST" etc. commands.
In the case of Jerusalem adventure, one aspect that I wanted to "fix" was its portrayal of "ARABS." If you wander out of the Jewish quarter, for example, you get attacked and killed by "an Arab." The instructions originally stated:
"YOU MUST EXPLORE THE CITY WHILE OUT-MANEUVERING ARABS THAT(sic) WILL KILL YOU IF YOU COME INTO THEIR QUARTER OF THE CITY."
In the age of Trump, I didn't want to contribute to the stereotyping of a group or to the oversimplification of the conflict between Palestinians and Israelis. So I added a graphic title page to acknowledge this conflict. I also changed the instructions to identify the main character as an Israeli. Now, if you wander into East Jerusalem you find yourself "in the middle of the Intifada" and get "hit on the head by a stone," which ends your adventure.
New Intro Screen
I couldn't find a copy of Castle Dracula in the Coco or Dragon archives so I had to get a copy of it for the Commodore 16. Then using the WinVICE emulator I listed the program to a text file on my PC. Here are the instructions I consult to remind me how to do this under WinVICE:
Settings->Peripheral Printers... (Shift-Command-P in Mac)
Select 'Unit #4' tab, check 'Use IEC Device,' Printer Emulation: File output
Select Driver: ASCII, Output: Text, Device: #1 (defaults)
In 'Printer Output Files and Commands' at the bottom of the dialog, 'File #1' specifies the file that will be created.
OPEN 4,4
CMD 4,”name”
LIST
PRINT#4
CLOSE 4
Because of the 40 column screen width of the Commodore, replacing PRINT statements with a call to my word-wrap routine is especially important. I also added a "background story" introduction screen. This was likely supplied by the original accompanying magazine article or instructions that came with the tape from Microdeal, but it's a useful addition for those who might only come across the game as a tape file for the VMC10 emulator. Here is that introduction as it appear in the program along with my word-wrap routine (lines 1-2) that formats it for the 32 character screen:
1 ZZ=1:CC=32:FORCC=CCTOZZSTEP-1:Z$=MID$(M$,CC,1):IFZ$=" "ORZ$=""THEN?MID$(M$,ZZ,CC-ZZ):ZZ=CC+1:CC=ZZ+32:IFZ$=""THENCC=0
2 CC=CC+(CC>255)*(CC-255):NEXT:M$="":RETURN
6001 M$="YOUR COMPUTER HAS PLACED YOU IN AN IMAGINARY WORLD SET IN A LITTLE VILLAGE IN TRANSYLVANIA. "
6002 M$=M$+"YOU PLAY THE PART OF BARON VON HELSING, WHO IS ON A TOURING HOLIDAY WITH HIS WIFE.":GOSUB1
6003 M$="AFTER STAYING ONE NIGHT IN A SMALL INN, YOU WAKE TO FIND YOUR WIFE MISSING AND NO-ONE HAS SEEN HER.":GOSUB1
6004 M$="YOU GET THE IMPRESSION THAT THE MYSTERIOUS CASTLE ON THE HILL IS INVOLVED, "
6005 M$=M$+"BUT NONE OF THE LOCALS WILL EVEN TALK ABOUT IT!":GOSUB1
Castle Dracula used a special line input subroutine that created a funky cursor. Turns out that cursor can be easily reproduced on the MC-10 with a simple POKE17026,3. So I added this cursor to all five adventures to provide a visible cue of their membership in the 5 part adventure series by Microdeal.
First--a disclaimer. The title of the game is not mine. I wish no offence to any neo-pagans or others out there who might be concerned about the old pejorative term "heathen" used by some Christians against religious competitors. The title of the game, I am quite sure, is meant by its author Paul Shoemaker, as tongue-in-cheek. The game is a straightforward dungeon crawler in the D&D Tolkien tradition, but there is also a certain irreverent cheekiness directed towards the genre. Besides the title, this irreverence takes the form of a number of funny minor elements included in the game. For instance, in the original you descend into the caves by way of an elevator. Also, one of the enemies you occasionally encounter is a smiling little round green fellow called "the guide guy," who is clearly a rendition of the round character from the Sci Fi novels (and the box art for the text adventure game version) of The Hitchhikers Guide to the Galaxy. There is a message below him that reads "Don't Panic!" However, the game is also filled with the standard dwarfs and magic users, as well as a host of vile monsters from the depths, who conceivably represent the "unwashed heathen" opponents of our "noble" paladin.
Adjustments to Stats and Spell Handling
But nobility might not be the adventurer's sole motivation. The dungeon is riddled with "chests" that contain gold as well as weapons and armour (of various pluses). I have modified the original game to put some especially richly supplied areas of dungeon levels 2, 3 and 4 behind a locked door. I cannot help but feel that Shoemaker originally intended this feature to be included. There are isolated areas on each of these levels that are especially packed with treasure but with only one passage leading into them. The original game instructions mention a non-existent ability to use the "K" key to kick doors, but in the game as I found it none of the doors actually prevent movement. Also, there is a second level "knock" spell included on the list of spells, but it did not actually do anything except print the message "this cannot be used at this time." I think this is an equivalent of a "work in progress" sign. Shoemaker must have ran out of steam in his gargantuan programming project.
New Graphic Routines
And gargantuan it certainly was. The original consisted of a collection of half a dozen disk based programs that run each other in sequence. Part of the reason for chaining these programs together is, I think, a result of a certain limit of the TRS-80 Colour Computer that the MC-10 doesn't have. For the Coco to get lowrese graphic characters on the screen you have to either print them using the CHR$ or STRING$ commands, or poke their ASCII values directly into screen memory locations. In either case, this requires large amounts of numeric data, not to mention the commands to get each value to the screen. In the MC-10 you have the ability to input graphic characters directly into strings just like any other character. Imagine having to use "PRINTCHRS$(74);CHRS$(73);CHR$(77)" every time you simply wanted to print "JIM" on the screen and you get the picture of how unwieldy using lowres graphics on the Coco can be. I was able to use MC-10's easier use of lowres to allow me to combine all of the programs into only 2: "INN" for generating and managing characters and CAVES to allow the exploration of the 4 dungeon levels. In addition I was able to use the nifty CLOAD*ArrayVar command of the MC-10 to store all the data for each of the levels, and also the data of the characters (with the Level One map data). This way you only have to load one file after loading and running the CAVES and not a separate file for the character data.
Doors and Keys Added
I have modified the level data now to also include info on one locked door for each of the three lowest levels. These doors prevent direct access to the most treasure rich areas. Now you will have to rise to the skill level 2 to achieve the Knock spell, which I also have added, which gives you a chance (based on your intelligence) to open locked doors. Or you must search enough chests on a level until you find a key to the "main treasure area" for that level. I have also modified the routine for assigning the number of spells to adjust depending on your intelligence. This is normal procedure in D&D type games and is the reason high intelligence is a prerequisite for being a magic user. In the original version of CAVES intelligence didn't seem to determine anything. Now a high intelligence increases the speed at which you gain new spells and your ability to use at least one of those spells (Knock). I also found that Wisdom didn't seem to play a role. I was little concerned that the number of random encounters per level seemed low (long gaps were possible) so I also increased the chance of the number encounters based inversely on your Wisdom level. My reckoning is that if you lack wisdom you will tend to blunder more noisily around dungeons and therefore attract more monsters. It's not a major adjustment, but I felt it was important to try to give all the traits some role rather than simply being there for show.
Simplifications
The game had to be simplified. Certain features had to be removed to help it to fit into the 20K of the MC-10 with expansion pack. The instruction screen (with its redundant mention of "K" for kicking doors) had to go, as did the ability to back up a space. I also removed the subroutine to adjust the time delay for the display of messages and the formal quit routine. When the game ends, you must type RUN to get things going again. Here are the remaining key commands for the MC-10 version:
W = Move forward (to go backward you have to first turn around using A or S) A = Turn Left S or D = Turn Right M = See a map for the level (your position is indicated in blue) Space = Toggle between Stats and Inventory screens
The screen drawing routine had to be condensed to a single routine using an array to change the look direction and results. In the original there were simply 4 completely different routines, even though they did essentially the same thing. I just needed to set up an array with different offsets to search the right X/Y values based on the direction you are facing to boil it down to one routine. I was also able to replace multiple IF commands with a more direct ON/GOTO commands to branch in multiple ways based on a single variable.
Explosion
Shoemaker had a nice explosion graphic for spells which involved saving the data for an area on the screen, printing the explosion and then putting back the original graphics from "behind" it. It was a bit slow and used an unwieldy number of variables. I was able to simplify it greatly so that it only used the "scratch" variables I had designated for basic tasks in the program. I also added it to the routine when a chest occasionally explodes when you open it.
Variable Use
Reusing variables is a good technique to save memory. I had to use it quite a lot because as it turned out there is only around 400-500 bytes of space free after CAVE initially runs and assigns its primary variables. I've tested it pretty extensively but you just never know if there are conditions and areas of the program that will call for new variable assignments that can push the program into an Out of Memory (OM) error. I spent a lot of time streamlining the program to remove unnecessary variables, commands, spaces between commands and line numbers. Cramming as many commands per line separated by colons can save a lot of memory. Liner numbers take more memory than a colon.
Monsters
Because of this streamlining and because the graphics can be printed directly, the program runs much more quickly than the original. The slightly higher Basic execution speed of the MC-10 also helps a bit. Now when a monster appears it snaps onto the screen, instead of being painstakingly drawn line-by-line. I adjusted the way monsters are selected to appear for each level. The original simply selected from the lower half of the 16 monster types for levels 1 and 2 and then added the possibility of also encountering the upper half for levels 3 and 4. It loaded the graphics for the monsters from a disk file, but I was able to translate them into characters and put them into DATA statements.
The original code also went through a convoluted process of reassigning numbers for each monster before selection based on level, so I think there must have been a lot of adjustment and experimentation by Shoemaker before he settled on their strengths and which would appear on lower and higher levels. I was able to eliminate all this swapping of values. Then I simply ordered the data for the monsters in terms of their stats (dexterity, damage, armour, treasure). Now the monsters are selected in groups of 4. At level one you can encounter monsters 1-4, level two--monsters 1-8, level three--monsters 1-12 and level four--monsters 1-16. Actually, I have made it so "the guide" guy (who is very weak and obviously just meant as a humourous annoyance) can very occasionally appear on any level.
This now means you can only encounter the 3 most powerful "boss" monsters if you are on level 4. I think by the main title screen and the stats that the super boss is meant to be the Dragon. There is no win routine as such, but I think one can claim that if they have risen to a high enough skill level to defeat the Dragon, they have effectively beaten the game!
I noticed that there were graphics for two additional monsters on the disk file, one particularly nice one for a Giant Mantis, which were listed as numbers 17 and 18. But by the Basic program code I could discern no possible way that these graphics could ever be selected. Since I was pressed for space, I left them out, but I wonder if there is some special routine, perhaps somehow buried in the machine code, or the logic of the Basic code that has somehow escaped me, that can trigger these graphics. Maybe they were for different versions of more advanced levels or for future versions of the program. Or perhaps, again, Shoemaker simply ran out of steam in his development of the program. The mantis (which was really nicely drawn) reminded me of the boss you find in the Temple of Apshai classic RPG, which is another program I ported and blogged about for RetroChallenge back in 2014.
Dungeon Screen drawing.
The original also used special machine language USR routines to draw all of the 3-D dungeon screens. Obviously Shoemaker had to use machine language to avoid the slow crawl of re-drawing each move using CHR$ and STRING$ commands. It also would have allowed him to save memory. Once again, I was able to accomplish these goals in ordinary Basic because the MC-10 allows direct input of graphic characters. I used my own drawing program (SKETCH) to redraw all the elements. I just issued the USR commands after breaking out of the original Coco program (running on VCC) to display each element: USR(1)-USR(18). I then redrew it on the VMC-10 using a special version of Sketch and printed each to strings. With these in hand I could just use ordinary PRINT@ to get them where they needed to go on the screen. I replaced the "elevator" routines with simple stairs-up and stairs-down graphics. Originally I thought this would help me save memory, but I'm not sure it actually does. It makes the dungeon a little more like a real dungeon, but it loses a little of the whimsy of Shoemaker's original. However, over the course of the porting project I grew to like the images I had made, so I kept them in.
Wrap Up
I hope the changes I've made have helped improve this amazing program by Showemaker. I hope that he wouldn't be offended by my changes and the use I have made of his work. I tried to look him up on the Net, but was unable to find anyone who was obviously the same person who created this classic RPG for the Coco (and now for MC-10). If anyone can put me in touch with him, I would really appreciate them letting me know, so I can contact him and thank him for his wonderful contribution to the Coco and retro-computing community.
And thanks to the Highretrogamelord for making me aware of the original:
In most of my animated programs you will find a tight main FOR/NEXT loop around line 20, with common subroutines above it, something like this
0 CLS:DIMK(255):K(8)=1:K(9)=2:K(94)=3:K(10)=4:GOTO20
1 IFA-1<0THENNEXT:GOTO22
2 PRINT@A+B*32," ";:A=A-1:NEXT:GOTO22
3 IFA+1>31THENNEXT:GOTO22
4 PRINT@A+B*32," ";:A=A+1:NEXT:GOTO22
5 IFB-1<0THENNEXT:GOTO22
6 PRINT@A+B*32," ";:B=B-1:NEXT:GOTO22
7 IFB+1>14THENNEXT:GOTO22
8 PRINT@A+B*32," ";:B=B+1:NEXT:GOTO22
20 FORZ=1TO65000:PRINT@A+B*32,"X";:REM SOME ENEMY ANIMATION AND COLLISION DETECTION
21 ONK(ASC(INKEY$+"*"))GOTO1,3,5,7:NEXT
22 REM GAME OVER
24 END
This is a simple example of how you can use NEXT to return from subroutines. Since key input in an arcade game can be quite intense, you want to shave off every micro second possible in your main loop. NEXT:GOTO20 might some more kludgy than a clear RETURN but the GOTO20 part is almost never reached and the NEXT returns directly to the first command after the FOR/NEXT loop definition at the beginning of line 20. Using a FOR/NEXT loop saves you a GOTO in every iteration of the loop and all the scanning it requires to find its line number! Not to mention the interpreter having to scan for RETURN (a six letter command) rather than NEXT (a four letter command) for each subroutine call. Also, for each subroutine call you don't have a RETURN and then a NEXT (or GOTO) command to get back to the beginning of the loop. You accomplish both with the one NEXT from your subroutine.
Allen Huffman recently posted on his blog about a unlicensed Dr. Who game he bought for the Coco back in the 1980s. He was a little disappointed back then when the game arrived and he discovered it was written in BASIC but I'm not disappointed today. Looks like another possible porting project for the TRS-80 MC-10! Thanks Allen! I've written in the past about one Dr. Who themed text adventure game I ported to the MC-10 from the original TRS-80
DrWho
I thought it would be useful to write a little about some other more recent who-themed additions to the MC-10 software library.
There is my adventure called "The Doctor," which involves navigating an overhead 2-D maze. You have to trick the very dumb Darlecs to chase you and then trigger reactors and exit the screen, leaving them to be blown up.
Doctor
There is also another text adventure taken from a Sinclair Spectrum type-in game called "Time Slider." I believe it is from Your Computer magazine, which was a general home computer magazine in Britain in the 80s. Because it covered all 8-bit computers, it sometimes had games for the Dragon 32 (i.e. British Coco), especially in the 1982-1984 period. I just stumbled across Time Slider (the article title) which had a listing of "Time Switch" (the title used in the program itself). I called the version I created for the MC-10 "Slider" because I already had program called Switch. Probably should have used the filename "TSWITCH" but I prefer complete names. It's a thinly veiled Dr. Who text adventure, which again tries to avoid copyright infringement. I added a little graphic of a blue box at the end to overcome any such confusion.
Here's another 10-Liner Basic Programming Contest entry for 2017. Info about the contest can be found here: http://gkanold.wixsite.com/homeputerium/basic-10liners-2017. In addition to my entry of a 10-liner version of Mine Sweeper and the Monteiro Challenge, I have completed a simple flight combat simulator called "Combat Arien."
There were lots of other entries along similar lines in the contest. It's unlikely mine will impress, given the greater power and graphics of 8-bit systems like the Atari and others.
Interceptor
Space Ranger
A contest like this, which involves a bunch of classic 8-bit home computers spanning the entire 1980s reminds me that my beloved MC-10 was based on the TRS-80 Color Computer (Coco), which was a system built on hardware from before the late 70s. In particular its graphic chip, the Motorola MC6847, was a particularly early graphic chip for home computers. Don't get me wrong, I love this neon green wonder. I also appreciate how well Tandy worked at maintaining compatibility across its whole Coco line right into the 1990s. The Coco 1 (1980) was a contemporary of the VIC20. The Coco 2 (1982) was a contemporary of the Commodore 64. The Coco 3 (1985) was a contemporary of the Atari ST. Yet each of these machines was able to run the software from the earlier machines. The VIC20, for example, wasn't around in 1985 running a multi-user, multitasking operating system. But a Coco 1 (upgraded to 64K) could. And the MC-10 was a part of this venerable family.
The program was based on some code from a type-in book for the Matra Hachette Alice. I was browsing through it and saw that it was a flight combat game. I had seen the other games for the contest and I had been wanting to make an updated flight shoot-em-up game for some time. But I was really disappointed when I saw what the game code produced.
The program has the idea of the four white blocks to make a cross hair, but other than that the plane is just two blocks connected by a dash. And the sky is orange! The plane leaves behind a trail of cyan coloured blocks as it jigs around the orange sky. One shot on the plane brings victory and the end of the game, but the plane moved in increments of two, which makes its flight extremely jerky and erratic. I kept the basic gun shots converging on the target idea and the 4 block cross hair, but replaced just about everything else. The book "102 Programmes Pour Alice et TRS MC/10," which can be found here: http://alice32.free.fr/documentation/102-programmes/102-programmes.djvu
See page 166 for the original. Here's my code in short and long form:
0 CLS6:A=5:B=14:HT=0:TI=0:SH=0:N=15:POKE17026,6
1 PRINT@32*A+B,"ÞØÜ";:TI=TI+1:U=A:V=B:A=A+2-RND(3):B=B+2-RND(3):K=PEEK(2)ANDPEEK(17023):GOSUB7:IFK=32ORN<15THENGOSUB3
2 A=A-(K=90)+(K=87):B=B-(K=83)+(K=65):GOSUB7:PRINT@238,"ÏßÏ";:PRINT@302,"ÏßÏ";:GOTO1
3 PRINT@32*N+23-N,"Ù";:PRINT@32*N+N+7,"Ö";:PRINT@32*N+23-N,"ß";:PRINT@32*N+N+7,"ß";
4 SH=SH+1:N=N-1:Q=PEEK(9)AND128:POKE49151,0+Q:POKE49151,128-Q:IFN>7THENRETURN
5 IF(U=7ORU=8ORU=9)AND(V=13ORV=14ORV=15ORV=16)THEN?@32*U+V,"ÞÿÜ";:SOUND100,1:HT=HT+1:IFHT=5THEN8
6 GOSUB7:N=15:GOTO1
7 A=A-(A<0):A=A+(A>15):B=B-(B<0):B=B+(B>28):PRINT@32*U+V,"ßßß";:RETURN
8 ?@0,"YOU GOT HIM! ":SOUND219,9:SOUND241,7:SOUND200,9:SC=INT(10000/(TI+SH)):IFSC>HSTHENHS=SC
9 ?@16,"SCORE"SC:PRINT"HIGH SCORE"HS:PRINT@48,;:INPUT"HIT enter";M$:GOTO0
10 REM USE A,S,W,Z TO STEER
20 REM SPACE TO FIRE
30 REM 5 HITS TO SHOOT DOWN
P.S. Part of the reason I had my eyes peeled for a simple flight shoot-em-up game was I had been thinking for some time of a game that would re-create the experience of being a tail gunner in a Lancaster Bomber. I envisioned something with guns that would range up and down and left and right with their fire converging at a certain point. You would need to slew your guns to bring them to bear on a moving target. The target would look like the one in Combat Arien, although I think I had the idea that it would come closer and move farther back. I did create a game with some of these features, but I added a moving star field and it turned into my game Warbirds:
However, the original "Lancaster Turret" idea is still stuck in my head. The reason it did, besides the fact that my dad flew as a Bomb-aimer in a Handley Halifax bomber, is that his younger brother was a tail gunner in a Lancaster. His plan was shot down over France during the D-Day landing bombing campaign. He's now buried in Buran-sur-Oise Communal Cemetery. The recent 100 year anniversary of Vimy reminded me of him. I'd like to dedicate this game to his memory.
