Monday, 10 July 2017

Wizard's Castle and Star Traders

David Ahl was one of the giants of the earliest era of  personal computers in the late 1970s and 80s. He edited Creative Computing magazine and published several major type-in program books such as Basic Computer Games, which sold millions of copies.

I thought he was the author behind a game I had in my collection (VENTURE.C10) for the MC-10 called "Castle Adventure." The title screen mentions his name:
The instructions mention a "Wizard Bergal" and a "Orb of Zot."  I don't know where I got this piece of code. Its been in my collection for quite some time, and might have been one of the programs I had from tapes for my original MC-10 from the 1980s. Recently I came across some discussion on the Net for a "classic" Basic game called "The Wizard's Castle" by Joseph Power. The discussion mentioned the "orb of Zot," which triggered my memory of Venture. However, as I explored people's discussion of Power's game and its influence I began to realize that it was a very different program from the one I had. For example, in Power's game there are flares that can be used to shine light into all the cells immediately surrounding the one you are in. Also, you can buy a lamp, but it never runs out of oil. You can also choose other equipment (and can find better equipment in the dungeon). People commented about the simple but interesting D&D like character creation (Hobbits, Elves, Human, etc.) and equipping choices in Wizard's Castle. Such features, along with others that occur while you are exploring, were completely absent from Venture:
Clearly the program in my collection was not the classic program by Power. I had to lay my hands on the source code of the original and take a look. I went to my standby go to source for source, software repositories for the original TRS-80. I easily found references to Power's Wizard's Castle. Once I had the source roughly converted (including removing a modification that simply revealed all the locations) it was obvious that its 8X8X8 multi-dimensional array blew the lid off the memory requirements of a standard MC-10 with just the 16K RAM pack expansion. I would have to do some cutting or figure out a way to organize the info into a less memory demanding form than 5 byte floating point numbers for each array element. I began to suspect that the "Venture" program I had was a significantly simplified version of the game that made space for the massive numeric array by removing many of the minor, more quixotic features, of the original. Sadly, these features were what gave the program much of its charm. If I was going to preserve these features, I'd have to be creative.

I realized that each location in the array only needed to store an ASCII character representing the different items in each room, "B" for books, "C" for chests, etc. All I needed was to create a string space so each item could be stored as a single byte character poked into that space. As I read more about Power's efforts to create the program for the 16K Exidy Sourcerer computer he developed the game on, he'd had to do a similar thing. In fact, he used a memory space used for storing user definable characters. When someone had ported the program to TRS-80 they had simply removed this stuff and substituted simpler integer numeric array references. But the subroutines for doing all the fancy "poking" were all still there for me to re-engineer back into place a routine for poking the memory into a string space using VARPTR command (to find the appropriate locations in that space).

Eventually I got the program pared down (removing spaces, creating long multi-command lines, etc) to work in a standard 20K of the MC-10 with RAM pack. I even had enough space left over to create a simple "castle" graphic to wrap around the presentation of the grid map. The parring down also helped with the speed of set-up for the map layout, which was quite long.  Here are videos of the first version and the final product. Notice the difference in the length of time for setup:

Having completed this conversion of a classic program to the MC-10 I went in search of another kind of classic game program that I have wanted for some time to add to my collection-- a "Space Trader" type game. I had been aware of a version of such called "Star Lanes" for a while, but I wasn't overly enthused by its "corporate" theme (company creation and share buying and trading). So it was a pleasant surprise to discover that the original granddaddy of such games, called "Star Trader" by Dave Kaufman, was less corporate in character, and more in keeping with the spirit of Issac Asimov's "Foundation" series of novels-- with its developed Galactic core planets, and wilder less developed frontier planets.

The only problem with getting a version of this program up and running was that there seemed to be nothing on the Net regarding running versions. The original source I was able to find was for some kind of DEC minicomputer (HP Basic?). It came in two parts that were run in a "CHAINed" fashion. The first set up basic parameters and variables, which were left in memory when the second program was loaded by the CHAIN command. The source also mentioned "loading the tape into the tape reader" (tape reel? paper tape?) as a means of saving and loading games in progress. Yikes! I could find some tantalizing screen shots of an Atari 8-bit Basic version by someone who had a tribute page for the program, but that page now existed only in "archived" format on the "way-back machine." Most of the links were broken, and I could find no reference to the program in any of the Atari software archives that I searched. So I had to work from the original source helpfully provided by a tribute webpage to the multiplayer on-line "Trade Wars" games that descended from the original program by Kaufman.

When I finally got the two programs merged and running and most of the bugs worked out, I noticed that there seemed to be something wrong with the economies of the various star systems. They did not seem to develop or change their demand for products in the way I expected. However, after combing my source for possible errors introduced during porting, I could find nothing that would explain the weird behaviour of their economies. I began to suspect that there was simply something wrong with the data used to define the subroutine calculating the productivity for each system. It seemed skewed towards high production of goods, which resulted in very low demand for new goods. So I went in search of the original publication of Kaufman's program.

Apparently the game originally appeared in the People's Computer Company (PCC) newsletter (later magazine) and latter in a book compilation What to Do After You Hit Return. I was able to get a PDF from the Net of the book, and sure enough when I looked at the DATA statements for the "econometric" data, it was different from the data listed in the on-line source code from the Trade Wars tribute site. Swapping in the data from the scan seemed to solve the problem--a fun little piece of retro-programming archaeology! I don't know why the values were changed (transcription error from the scan, weird considerations of a networked version?), but now there is a working version of the program for people out there to try. It includes a save to cassette tape feature, as opposed to (possibly) save to tape reel or paper tape. Here's a vid:
Rogers Cadenhead, one of the many commentator's on the Star Trader and its influence, discussed its history with David Ahl to get his perspective on the game. The following is a quote of Ahl's response:
As far as I know, the game Star Traders originally appeared in People's Computer Company (a newspaper/magazine) published by P.C.C. (an alternative education computer center) in Menlo Park, CA. (It's a bit confusing that the physical storefront computer center and the newspaper both had the same name.) The game also appeared in What to Do After You Hit Return subtitled "PCC's first book of computer games." PCC was a rather egalitarian organization, hence credit was only rarely given to the authors of the various games they published and there is no author credit affixed to Star Traders. So it could have been written by any one of the 40-50 people cited in the acknowledgements of the book. The game, written in "standard" HP Basic, is a monster and, unusual for the time (1973) has both a set-up module and a main playing module. Also unusual for the time, it had the capability of saving the playing data (1) from one session to the next and (2) for different users who logged onto other nodes of the timesharing system. It was this that allowed it to be a multi-player game with games often lasting a matter of weeks or months. The book had some interesting suggestions and ideas for extending and modifying the game to make it more interesting and longer lasting; I believe that over the years many (or most) of these have been implemented.
I can understand how on a timesharing system you could easily have rigged up an ad-hoc way to make the game one of the first multiplayer net-based games (tape reels or paper taps must have been replaced by electronic files at some point). You can save all the main game variables at the end of any round of trading at the prompt for picking your next planet to visit (i.e at the end of your turn). Early players could have organized games with other players on a system. All you would have to do is send the game data file to the other players or save it in publicly open file space. Then the next player could load the data file and continue with their turn and then re-save and so on for each player (it can handle up to 12). The only problem is that in the version of the code as I found it, when you re-load the data, the first thing the program asks for is the choice of next planet for the last player, since that player would have typed 'save' at the prompt instead of their choice. Either people modified the game so each player could enter the choice before saving the game data, or ad hoc solutions were worked out, such as sending a message mentioning one's desired choice to the next player. In fact simply sending a message with a planet name might have been the way players let other players know the file was available and it was their turn. Then they could simply enter it and continue with their own turn.

It's funny but similar systems could easily be worked out today for people wanting to play the game on the Web for "1970's" experience of early network multiplayer gaming. Just fire up the virtual MC-10 and save your game data "STRADATA.C10" file (the emulator will create this for you when you save) to Yahoo public file space or e-mail to a friend. Then text your opponent the name of your desired planet. They can download the file and load it up into the VMC10 on their computer running the game. A little clunky perhaps, but it would give you a feel for early network computer gaming.

Recently, I created a Google files site for all my MC-10 programs, including STARTRAD.C10, which contains WAV sound file versions of the programs. These sound files can simply be played with your original MC-10 plugged into the sound-out jack of your PC. I find a half volume setting seems to work best and make sure to turn of any "noise reduction" features in your player software. Of course, they can also be obtained as .C10 emulator files in my MC-10 zip compilation, which includes Tamer's great Virtual MC-10 emulator (VMC10.exe).

Monday, 22 May 2017

Galaxy Trek Adventure #1

Galaxy Adventure #1
I have already ported Howard Batie's second Star Trek themed text adventures for the Coco to the MC-10. The Coco program for his first adventure, which can be found in Hot Coco Magazine August 1983, was based on an original game for the TRS-80 16K by Randy Hawkins in 80 Micro (August 1982, pp. 174-184). In fact, the version I ported might be more akin to Mr. Hawkins' original, as I based it on some source code that I found for the TRS-80 Model 100, which might have come from the Model I version rather than the Coco version.  However, the fact that Batie's name is on it leads me to believe that it must be from the Coco version. I have source for the Hot Coco magazine version, but it's from OCR text of a scan of the article, and it was getting very tedious trying to get it into running form, so I switched to the source for the TRS-80 Model 100. I might still plunk away at the original magazine source, because Mr. Batie suggests in the article that there are some differences between his version and the TRS-80 Model I version, which might be nice to uncover. Also, the magazine version uses the technique of encoding all of the messages, so you can't cheat by looking at the source code.

There were a number of errors in the Model 100 source. Some of these problems are outlined in a Gaming After 40 blog post. I found others and corrected them. There was a big problem with how the game handled the button pushing for the impulse engines, that essentially allowed you to correct the orbit without having to solve the puzzle. GamingAfter40 suggests that the way to get rid of the Klingon guarding the Tribble on level 2 is to get the phaser, but really it was because he pushed the button for the engines on level 1 and triggered the bug (which moves the guards to the planet). The real way to get rid of the guards is to shoot all of them with the phaser. The phaser only self-destructs on the planet after you've done all the necessary shooting on the ship. There were also problems with beaming routines, that allowed you to beam down without Spock being present, but which indicate that he is present by the messages displayed. There were also some problems with how the score was accumulated.

I have bug tested the program pretty extensively and played it to completion a number of times. Here's a play-through for those who may have been frustrated by the game in their youth.


A D V E N T U R E    # 1



I also completed the clean up of two simple programs taken from OCR text of scans from Color Computer Magazine and Hot Coco Magazine. The first is a simple game called SPRINKS the second is a Mother's Day graphic and simple music demo called MOTHER:

Thursday, 11 May 2017

4 Mile Island Adventure: Update

4 Mile Island Adventure, not to be confused by another Basic adventure for a recent programming contest (in the 2000s) of the same name, was a text adventure made by Owls Nest Software for TRS-80 Color Computer and MC-10 in 1983. Ported the Coco version to MC-10. Made some changes in the save game routine. In addition to the object list of locations, it now also saves the following variables:
F,G,CF,TB,GB,CA (# of objects being carried), RT (reactor temperature), YO (present location), DO,NOT,DR,M
This means that you don't start fresh every time you save and re-load a game, which makes the game more challenging (as there is a countdown to meltdown).

Brief Outline:
The 'impossible' has happened! This area was devastated by a severe earthquake. The reactor has been severely damaged. The plant has been deserted. Only you can save the area from a major disaster! Your goal is to achieve a cold shutdown of the reactor at Four Mile Island. Alternative? Death!


Type CLOAD & hit ENTER. Select TOWER.​C10 in the JimG subdirectory of the Cassette directory. Type RUN...

Sunday, 30 April 2017

RetoChallange 2017: Graf Spee

Came across a neat game for the Sinclair ZX81. It's a World War II naval simulation. You play the role of the captain of the German battle cruiser the Admiral Graf Spee. You must destroy shipping and avoid being captured or destroyed. I have't got it working quite yet, but I have made substantial progress.  Here are some screens showing a little of what the game will look like.

 I still have to finish converting all the lowres graphics for all the ship types.

This is likely my last posting for RetroChallenge 2017. Thanks to John for organizing another competition for this year. Thanks to all the other posters. I'm still working through browsing all the projects. They are wonderful inspiration for further efforts in my own retrocomputing hobby activities. Good luck to everyone and I hope to see you all again next year!


Here's a video of the completed game:

Monday, 24 April 2017

RetroChallenge 2017: 4 Mile Island Adventure

Found another obscure adventure in the TRS-80 Color Computer Archive. This one's called 4 Mile Island Adventure. It's loosely based on the 3-Mile Island nuclear disaster. Everyone has fled and it's up to you to cold-shutdown the reactor.

Couple of weird things about the adventure. First the save routine seems to just save the objects array. It doesn't appear to store anything else, such as your location, the reactor temp, radiation level or how many items you're carrying (although this may be generated when you take an inventory).  So when you restore, you seem to start off at the beginning location, but you have any items you found previously.  Since you are racing against the reactor temperature going up, it seems like you can reset the clock by saving.  Don't know if this is important or unimportant, but I might change it.

There is a link in the archive to the manual by Owls Nest software. I can't find a link to the game in the CASA: Solution Archive, although there is a listing for a program of the same name written for a recent text adventure contest.

Since there's no listing, I'm working on solving it.

Friday, 21 April 2017

Retro Challenge 2017: Greg Hassett Adventures

I have finished porting two Greg Hassett adventures. "Atlantis" was ported from a Coco version. It was very buggy and the screen formatting was very weird. It also lacked save and restore routines. So I had to go back to the TRS-80 16K version and put them back in based on what I found in that source code. I have played it through using a walkthrough, so I hope it is pretty much bug free now.

I also ported "Enchanted Island." I used source from TRS-80 16K source. Working on Atlantis had prepared me well for Hassett's programming style, so this conversion went very fast.

After completing these two adventures, I realized from internal advertising that Hassett displays in them that he had set of adventures.
These messages get displayed at various occasions, such as when your character reads a newspaper, or at the end of the game. I realized that I had previously ported the others. So I went back and fixed them up to use a common visual aesthetic (eg. solid line demarcating main messages from input prompt). Now I have a set of six Hassett adventures:
  1. Voyage to Atlantis (ATLANTIS.C10)
  2. Sorcerer's Castle (SORCAST.C10)
  3. King Tut's Tomb (TUTSTOMB.C10)
  4. Enchanted Island (ENCHANTI.C10)
  5. The House of Seven Gables (GABLES.C10)
  6. Journey to the Centre of the Earth (JOURNEY.C10)

The House of Seven Gables

Journey to the Centre of the Earth

Sorcerer's Castle

Tut's Tomb with my own intro screen
They can all be found on my distro:

Sunday, 16 April 2017

RetroChallenge 2017: Dr. Livingston Adventure

I noticed a BASIC adventure "Dr. Livingston: The Search For" listed on Curtis Boyle's site. I have searched through many Coco archives, but I couldn't recall every seeing a copy of this game. I also found a listing for it under Gaming after 40 blog. It sounded like an interesting game, that was having a little fun with the famous story of the search for Dr. Livingston, who disappeared into the heart of Africa in the early period of European contact with that continent.

I also found a listing for it under the Interactive Fiction Database. The reviews were't very good, but I think this was because most people had played an unofficial version of it for the Commodore 64 that was a little buggy. Here's what I said for a review I wrote for the the database:
I have read the other reviews and can't but wonder whether some of the frustrations result from the versions they are playing. The parser is not so problematic in the TRS-80 versions of the program. These machines often ran in all caps mode (the original TRS-80 didn't have uppercase characters and the TRS-80 MC-10 never had them). Apparently there were also changes made to the puzzles in many of the unofficial versions. The TRS-80 version I ported remains entirely true to the original TRS-80 16K version.

There are some intentional inconsistencies to the movement in the game. I didn't find them all that bad (especially compared to some other games from the era). For the most part I think they were carefully chosen and meant to enhance the effect of being "lost in the jungles and savannas" of central Africa. To a large extent, I think this technique works successfully in this adventure, where the setting makes it appropriate to use. Once I had some mapping in place, it wasn't all that problematic and there is a kind of logic to the backs-and-forths.

There are some really charming aspects to the game. The quicksand graphic is a wonderful piece of TRS-80 chunky pixel 8-bit animation. If you die the program simulates a return to the basic command prompt, before surprising you with a resurrection to a restore point part way into the game (preventing a need for a complete restart).

The game is challenging and doesn't have any of the totally arbitrary deaths that are so common in games from this genera. I found the plot to be a nice balance between slightly humorous almost fantastical whimsy and an attempt to remain true to the Victorian mythology of the original quest for Dr. Livingston.

For fans of 8-bit Basic adventuring I would highly recommend this game. But for less hardy souls, it might be better to stay away from venturing into the dark heart of the Victorian imaginary.
I had asked if Curtis could put his hand on his copy, but it sounds like he's buried under a pile of original disks. He said he'd keep his eyes peeled. In the meantime, I put my hands on the original TRS-80 version of the source code and over Good Friday and this Easter Weekend I plunked away at converting it to Micro Color Basic. I don't think I have ever come across so many convoluted long IF-ELSEIF lines before. Some took a number of different stabs at it before I got them right. The really fun part was re-creating the graphic for the jumping character animation.

I ran into some snags at the end in the form of some strange behaviour with FOR/NEXT loops.  I think this might have been a result of the fact that like a lot of early programmers the author of this game use a lot of FOR/NEXT loops for searches which they exit ungracefully from the middle of using a GOTO statement when they find what they're looking for.  I always try to properly finish a FOR/NEXT.  Anyway, I fixed a few of these and started using my own variable for my additions to the program to avoid conflicts with the FOR/NEXT variables used in the original.  Another, difficulty with porting was the use in the original TRS-80 16K version of IF structures like this:


It's possible in original TRS-80 Basic to dispense with the THEN command.  In Micro Color BASIC this can only be done using the GOTO command. Others, like LET don't work.  Had to weed all these out.  Also the programmers had used DEFSTR to define a bunch of character string variables without dollar signs, another feature missing from Micro Color Basic. I think it is fully debugged now.  I have played it through to its end a number of times and in a number of ways.  Here's a vid of LIVNGSTN.C10. At the end of it you can see the effect of the fake "exit to Basic prompt" before it revives you to a restore point.  Very clever little effect that demonstrates the care lavished on the game by its original programmers, Carl Russell, Karen Russell, Ralph Fullerton, Becky Fullerton. (published in Softside, Vol. 2. no 12):

Thursday, 13 April 2017

RetroChallenge 2017: Tackle Penguin

Someone besides myself finds it interesting to scan through old Japanese Basic computer magazines looking for code to convert to an 8-bit computer with a Motorola MC6847.

Emerson Costa shared the following post on facebook:
A video of mine describing my odyssey in converting a type-in BASIC program found in an old Japanese magazine (1988), originally for Fujitsu FM-7/77, to my Brazilian CCE MC1000, based on CPU Z80 & VDG MC6847 & PSG AY-3-8910.
It's in Portuguese, but here is an abstract:
I describe the game mechanics and rant about some of the FM-7/77 BASIC instructions that write text and stamp images on the graphic screen.
I talk about how game logic is mixed with interface logic, and give an example of how I separated those things in my conversion (reading keys from the keyboard vs getting commands from the player).
I show a first version in text mode, and then go on to make it graphic (using MC6847's Resolution Graphics 6, which is set by MC1000's HGR instruction). Machine language comes into stage with routines to draw 8x8 characters/sprites on graphic mode, and remove keyboard beeping. A final section of the BASIC program is added to POKE the corresponding bytes into memory.
Sound is still lacking. The original program uses the PLAY instruction, MC1000 has TEMPO & SOUND instead. I studied them all instructions and came up with an HTML page with JavaScript code that translated PLAY strings into a series of SOUND commands.
Then the conversion is complete. Oof! 😅It should be easy to adapt the program to MC-10?
Emerson was very generous to provide some further conversion advice:
Some machine-specific info:
CALL 49158 -- Waits for a key to be pressed and released.
POKE 910,0 -- Avoids an annoying behavior of PRINT, just ignore it.

PEEK(483) -- ASCII code of last key pressed.
PEEK(485) -- 255 if a key is pressed; 0 if none.
POKEs after HOME -- Makes cursor invisible. Ignore.
POKEs at the end of program -- Machine code routine related to keyboard reading. Ignore.
The CCE MC-1000 is an interesting machine. It's got the screen of a Coco, the keyboard of an MC-10, and the Basic of an Apple II. It's a totally unique hybrid. The Brazilian government really fostered some interesting creativity in 8-bit computers with its protectionist policies. Anyway, with Ensjo's help I was able to get a version working for the MC-10.
Your penguin is an A
It's able to jump in the following ways:
                       A  to here
It can jump from here  A  up through the block (using the W key jumps straight up).
It can jump up and left or right using the Q and E keys.
             A to here using the E key         A  to here using the Q key
from here  A ■               or                ■  A  from here
You can also push blocks left and right if there is only one and there is open space for it to move into. Blocks don't fall if you push them off other blocks. But you will fall if you jump off a block.  Some weird physics, but it makes for a neat puzzle. I still haven't solved puzzle 1 yet, so the game has yet to be fully bug checked. If there are any puzzle fanatics out there who solve it, let me know.  I'll put the game up as it currently is in my distro:

The following is an update of my original attempt, with improved handling of the move sound and music interludes (I hope):

And here are some further updates to messaging and a demonstration of the Win music routine:

Tuesday, 11 April 2017

RetroChallenge 2017: X Rally Fixes

I have done some more tinkering to speed up the Basic part of the program (e.g. renumbering lines). The big change is now smoke only lingers for a few moves and then dissipates, which is more like the original. I think I am coming close to the definitive edition...
As well, I'm still finding the occasional bug regarding the walls, which I fix by changing the numbers in an numeric array representing the map. It uses the basic 4 number code for walls (and zero for open space):
    3  > ■  < 4
So if you hit a wall marked as 3 you will turn left and so on. It took a bit of trial and error to work out the proper system for such deflection. Hopefully I've sniffed out the last of idiosyncratic places that would let the enemy car "pass through walls." But if there's anyone out there who notices any....

Monday, 10 April 2017

RetroChallenge 2017: Cross Rally, Now with Added M/L Code!

Thanks to Darren Atkinson and Robert Sieg for volunteering to do some M/L coding to help me speed up Cross Rally. In this video you can see the latest version in which I have implemented Darren's USR routine. Its speed boost allowed me to add a permanent update of the mini-map with the enemy car's position relative to yours.  Also, the game will get slightly faster each round.

There is only about 400 bytes left, so I can't put in any REM statements with thanks to Robert and Darren, but I will try to acknowledge their contribution with a included text file of some sort in my distro:

This is a video of the demo that Robert worked up for displaying the Map info:

Sunday, 9 April 2017

RetroChallenge 2017: Cross Rally Complete (I Think)

Well I have added the final bells and whistles. The intro screen explains the basic keys of the game. Hopefully the rules are not too opaque. In brief, you must collect the 10 regular Checkpoint flags and then make your way to the Level Checkpoint flag. The regular flags appear on the mini-map on the bottom right of the screen, but the Level Checkpoint flag does not, so you must keep your eyes peeled for it while you rove. You can run over it, but it will not take you to the next level until you have collected the 10 regular flags. Completing the level faster adds a bonus to your score when you level up. There is also a special Bonus flag, which will give you an extra car. Be carefully when collecting these, as you can only have a max of 5 cars and if you run over the bonus with a full car complement, it will be wasted. You can also create a smoke screen (oil slick?) by hitting space. You only can do this 6 times per car.  The dark green bar labeled "F:" tells you if you have any left. You can run over these smoke puffs without any problem.  Avoid the rocks. They're as deadly as the enemy car. Pressing the "C" key or the "B" key will flash the current location of the you and the enemy car.  It would be nice to have this continuously updated, but it would slow down the game too much.  You have to make some sacrifices when you make a game in Basic. When you exit the game it will report the last score and the highest score.

Here's a video of the original for comparison purposes.

This project is for Retrochallenge 2017. For more info about retro-programming projects see:

Saturday, 8 April 2017

RetroChallenge 2017: X Rally (Cross Rally)

Well, it's a game now. Just have to fix up a few more fiddly bits and maybe add smoke and some point bonuses. Might be a possibility someone will take my offer on the Yahoo group to program a slightly speedier screen rendering routine for refreshing the map on screen. Right now I use a bunch of MID$ print commands.  If that were possible, it could possibly be even speedier. I guess we'll see.

I suspect this will be my major effort for RetroChallenge 2017. Hope I can get it finished.

Friday, 7 April 2017

RetroChallenge 2017: Rally X

Found a really neat site listing Basic programs for the NEC PC-6001. One of the games called "Car Rally," written by Maiden Artist, looked liker a good prospect for porting or re-programming for the MC-10.  Apparently he had ported it from a Pocket Computer version of a classic arcade game Rally X rally.  It used semi-graphics 6 mode.

You must collect flags.
While avoiding an enemy car.
And watching the map on the right side of the screen that indicates where the flags are.
You can release smoke to block the enemy.

The game is over when the remaining fuel runs out. If you collect all the flags you can go to the next stage, but the number of enemy vehicles will increase.

I have been working on a version that uses strings for the map and the MID$ function to display the section you are. Its pretty speedy so far but I have yet to add the enemy care and its search algorithm. Hopefully I can keep the code tight enough to keep the speed up with the tracking added.  I'm going to use the VARPTR function to poke the obstacles directly into the map strings, and maybe even the moving enemy car too. Here was the test of concept:
Here is an update with the routines added to prevent hitting walls.
Next, enemy car tracking and collision detection.  The routines to randomly place flags in the maze and plot their locations on the little map.

Friday, 31 March 2017

Sokoban Update

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:

Curse of the Undead

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.

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!


Aerojam for the Commodore 64
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:
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:

Microdeal's Five-Part Adventure Series

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 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:

1: Mansion, 2: Jerusalem, 3: Williamsburg, 4: Ultimate, 5: Castle Dracula

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:
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:
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:
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”
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:
2 CC=CC+(CC>255)*(CC-255):NEXT:M$="":RETURN
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.

Castle Dracula with its funky cursor

Thursday, 30 March 2017

Caves of the Unwashed Heathen

By Paul Shoemaker for the TRS-80 Colour Computer
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

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


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.


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.


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: