Friday, 24 June 2022

Jim Menick's "Draw Poker"

 I already posted about Jim Menick's BASIC text adventure game "Space Derelict."  That program was an example program from his book BASIC Adventures and Strategy Games.  Jason Scott mentions that there was a version of the book for the Apple, but I worked from a scan of a variation for the TRS-80 line of computers.  I have now cleaned up the scan of his example listing for the "strategy" game component of the book, which is a variation of Draw Poker. The house rules for the game are:

  • $1 Ante
  • Minimum of (pair of) Jacks for opening
  • 3 raise limit
  • $5 bet limit
I don't know if these are standard rules, or idiosyncratic to this 5 person (including you) computer version of the game. The most interesting part is that the other 4 A.I. players, who (that?) are apparently designed with unique playing strategies/styles.  They each have names:
  • Marvin
  • Gerry
  • Walter
  • Betsy
It's a very detailed variation of Poker in BASIC.  It seems to handle all the basics of betting, passing dealing around among the players, betting raising, dropping out, etc.  If you drop out, the other players continue to play without you.  I'm not sure if the players are good players, but they are certainly good enough to beat me with my meagre card skills, including the occasional bluff.  

The program was very large.  I had to engage in another of my monumental "shrinking exercises:
  • First step, eliminate single command lines and pack multiple commands on lines as much as possible.
  • Second step, change as many variables as possible to single letter variables.
  • Third step, scan code for redundant/duplicated code, and then shift that to subroutines.
  • Fourth step, shrink and streamline messaging, which has to be done anyway to shrink a 80 X 24 game screen down to a 32 X 16 screen of the TRS-80 MC-10.
Before any of that could be done, I had to chase down all the typos and bugs from my transfer/typing of the game listing from a digital scan.  There were also some apparent errors in the listing, including a missing line at 28070 with a needed NEXT.  This was for the winner determining subroutine.  I think it just got dropped from being printed in the book.  There was also a reference to variable S5 at line 2642, which I think should be a reference to S5(X), since there is no other non-array S5 references in the code, and all the other references are to S5(X).  I switched it, hopefully it doesn't break something.

It is strange that there seems to be little preservation of the game available on the Net.  Like Frank DeCosta's BASIC programming "How-to" book for the TRS-80, I think the listings are simply too long for many people to have had the fortitude to actually type-in and fully debug the game back in the day.  Perhaps, this coupled with the minor printing errors, simply drove people insane, and so beyond Menick himself (and De Costa), few might have obtained working copies of the game.  It would seem that neither author distributed/published working copies of their games in other media than in book form for typing-in.

I'll continue to bug test and see if other errors emerge.  I have yet to fully test the routines triggered when players lose all their money and drop out of the game and what happens when the human player runs out of doe.  That will simply take some time of test play.  Of course, if there is anyone out there who wants to contribute to game testing, the 5CARD can be played here (at least for the testing phase):

Just select the game from the cassette menu, and then type RUN.

Please let me know if you find any bugs or have any comments on the abilities of the 4 A.I. players.

I got a Full House!

Wednesday, 15 June 2022

"Star Command Sigma" by ASCII 1982

I had noticed several screen shots of a game called "Star Command Sigma" for the NEC PC6001. It looked like a BASIC game-- a rendition of the classic "Super Star Trek"-- But since it was by ASCII,  a major software company from the early days of home computing in the 80s, I expected that it would be well done. So when I finally got an emulator working for the NEC PC 6001 and located a huge repository of software, I went looking for it.  I was able to list it to a file and get the source code. It was not hard to translate.

I have done other games from the NEC PC-6001 using James the Animal Tamer's Virtual NECTrek PC, which was a short lived North American variation of the PC-6001. The BASICs are similar Microsoft variations and the fact that they both use the Motorola MC6847 video chip makes things fairly straightforward.  The NEC uses LOCATE instead of PRINT@, but I just switch its two X and Y arguments to PRINT@X+32*Y, and get the same results. The NEC has some fancy graphics modes, such as the ability to define a virtual console/window on part of the screen, and some super sound generation. But I was able to translate most of this stuff in a downgraded way. One advantage of the MC-10 is that its screen printing and BASIC generally run faster. There is a speed sacrifice to be paid for all the NECs fancy abilities.

Here are some comparisons screenshots of the game working on the PC-6001 emulator and the Virtual MC-10.  They show some of the differences in how the two computer systems implement the MC6847:

NEC PC-6001
The NEC allows all the possible character colour layouts provided by the VDG, whereas the MC-10 can only easily access black on green text. The NEC also has an extended character set with lowercase and special symbols, such the degree symbol (little raised circle), which is used in the game.

You'll notice that the Klingon's are called "KLIMZONs" in the NEC variation. However, ASCII provide a variable for storing the name, so you can easily change it to Klingons. I guess they had to worry about copyright infringement, but they wanted customers to be able to easily switch  to full copyright infringement mode if they desired. You'll notice though that they still use and "E" for your ship (I wonder what that stands for?).

ASCII also embedded some strange characters at the beginning of each of the main menu item titles as they were listed in the DATA statements. These weird characters are processed when the titles are read in and combined in a single variable that reads "by ASCII."  I guess they were a little worried about copyright infringement of their own. It's kind of like Bill Gates multiple Easter eggs hidden in Microsoft BASIC, such as in the original Commodore BASIC for the PET, that can print out "Microsoft." If any one tried to pirate the code, Bill could just hit a few keystrokes and reveal the Easter egg message and claim ownership!  I thought of switching it to "JimG2022" or some such, but in the end, it's their program.  If they come gunning for me they can happily sell my version to the massive legions of MC-10 users out there!

The music is a bit of a mess.  First of all I don't read music.  Second, the MC-10 only has a simple SOUND command, and not the fancy PLAY command of the NEC.  Still I have butchered the notes listed in those PLAY commands to get some meagre semblance of the original musical refrains for the intro, win and lose screens. I had to be somewhat creative in the implementation of sound effects, but sometimes the program also used the simpler SOUND command, and in other cases I tried to take clues from the notes listed in PLAY commands.

The scrolling "window" allowed for by the CONSOLE command of the NEC had to be dispensed with.  Instead I went with a system of the top of the bottom half of the screen being used for commands, the middle for messages and help info, and the bottom line for combat messages. No scrolling is allowed.  Instead, as messages roll in, a small left pointing arrow appears in the bottom left corner.  When it does, you can hit a key to skip directly to the next message/event. Otherwise a brief pause will occur to allow the player to read the message before it is replaced or erased.

The game is very feature rich. There are options that I have not seen implemented in any other variation of the classic Super Star Trek game.  I wont go into complete detail here, but it is a very well-thought out set of command options that will make for a challenging set of tactical decisions as you try to destroy all the Klingons, Oh, I mean Klimzons. The enemies even occasionally shoot torpedoes back at you, which you can launch a counter measure against using the
direction keys.  The NEC used the STICK command to read a direction from the joystick, but I switched it to this keypad arrangement. Hit one of these keys just after the enemy launches a torpedo (or when the left pointing "continue arrow" message is displayed) and you might get lucky in destroying the incoming torpedo. The enemies even move during combat (and other times) so you will find that occasionally they warp out of the way of danger or new ships can arrive to complicate your life.

Below is a playthrough. I lose. I didn't realize that a feature that allows you to get energy from a star is "paid for" by sucking time off of your countdown timer.  If I hadn't been so greedy (and ignorant of how all the features are interconnected) I might just have won!  See if you can spot the moment of my fateful decision...

While investigating the game I also discovered that ASCII went on to make a fancier graphic character version for the MSX line of computers:

So the MC-10 now has a neat little game recovered from the early 1980s to help it to keep pace with the "big boy" systems of the 8-bit era. I wonder of Mr. Godai (listed in the title screen above) is the same programmer who made the version for the NEC?  If so, thank you Mr. H. Godai for a wonderful game.

I modified the title page to make the sigma look more like the original:

I also fixed up some of the more awkward "Engrish" phraseology, such "Torpedo is breakdown."  I changed this to "torpedo damaged" and modified "Klingon" to plural "Klingons" (etc.) on the status screen.  I still don't know what "Offensive cycle" means and what the number attached to it represents.  It's probably something like "threat level" or possibly, the number of combats you have had with Klingons, or something like that. If anyone has suggestions, I'd appreciate hearing them. Perhaps I'll change it if I figure it out.

I added plurals to the status report

Saturday, 11 June 2022

"Kagelien" from Micom BASIC Magazine Aug 1985

 Beware the "ShadowAlien!"

The following is what came out of Google translate when I downloaded and translated the Readme file that came with a program called "multi-game" for the NEC PC6001:

5. KAGERIEN (instructions)
Move yourself in 4 directions with the cursor keys so that you do not hit an enemy or a bomb (*).
Please take all the unpleasant. Enemies and bombs are displayed only on the left screen, and diamonds are displayed only on the right screen. It will not be. If you press the space key when the score is 100 points or more, you will lose 100 points and the enemy's movement
You can pause it. When the score reaches 500 points, one person increases, and after that, 1,000 points. One person will be added each time. In addition, there is a time limit for each surface, and even if this becomes 0, the number of people will decrease by one.
I will. When all of you die, the game is over. 
In any game, if you press the space key, you can play the same game and return.
Press the key to return to the menu screen.
At the end
At first, I intended to make everything original, but in the end, more than half were transplanted.
It has become. Next, I challenged the limits of N60BASIC !? Send the game I would like.
Micon BASIC Magazine August 1985 issue JR-100 "Four-handed Kannon" God Warriors, MSX
"KAGERIEN" Hiroshi Uwasawa, July 1987 issue Family computer "Rurumoppe"
Scramble Uko, February 1988 issue PC-8001 "Yanmo STONE" Minoru Yamamoto
<< Table 1 >> Main variables
S ..... Score
T ...... Time, number of times
R ...... Number of faces
X, Y .... Coordinates of the main character
V, W .... Move destination, move direction
I, J .... Loop
A$, D$, A, B. General purpose

My attempt to clean up these instructions resulted in this:

Use WASD keys to avoid enemy "@" or bombs "*", which are displayed only on the left side of the screen. Collect "$"s on the right side. When score is 100, pressing space clears bombs. 500 points = bonus man and after that, 1000 points is needed. There is a time limit for each round. You lose a life if you exceed it.

From what I can gather from the information provided in the Readme file, the game was originally made for MSX computers and published in Micom BASIC Magazine August 1985 (p. 83) under the name "Kagelien.  I think this was a combination of some Japanese word with "alien" since you can see the English word "alien" in the text and the MSX version uses a sprite that is clearly meant to represent an alien figure. The game seems to have been translated in 1988 to the NEC PC6001 and combined with 3 other programs to create the "Multi-game" program.  In the course of that translation the program seems to have been renamed "Kagerien" for reasons that escape me (or this might just be a tanslation error from the Japanese text file encoding). I separated the source for "Kagerien" from the other programs and renamed my version back to "Kagelien." I added a title page reference to the original 1985 Micom BASIC article, since I wanted to credit the original author of the game. However, that author's name is not apparent in the article.  Perhaps I will have my son Charlie try to decipher it from the Japanese characters.  He might also be able to provide something of the back story.

The game is very clever in its use of a split screen to provide greater tension and difficulty in what otherwise would be a relatively "slow BASIC game," although I did manage to speed it up to a point that I could add 3 levels of play using a slowdown loop. The necessity of having to split one's attention between two different screens means that despite the relatively slow movement of the enemy, you can easily become distracted and allow yourself to be killed.  The sound is minimal, but there must be something about the Japanese education system that produces a good level of basic musical awareness.  Most Japanese games I have translated don't just use indiscriminately selected sounds to indicate major in-game events, but always melodic tones.

Here is a video of the game before I renamed the program:

Charlie's Note:

I'm gonna guess the author's name is those 3 characters floating as a pair and a single up in the top left grey patterned area, 上沢   裕. According to and that's probably pronounced Uesawa Yutaka.

Uesawa(上沢) Japanese Last Name Meaning and Origins

Then that top left paragraph has the backstory: "in XXXX year, a certain astronomer discovered a star covered in diamonds, XX star (Japanese sci-fi is really big on these blanked out names/dates for its settings). A <something> was sent to the planet (probe, mission, colony?). Doctor D, the man who 'developed' the <something> (this word is used in the sense of software, but also of a nation. It might just mean he just develops i.e. works at a facility on the planet?), even though he had a map that could see anything, somehow there was... a shadowy ('KAGE', this is where the name must come from) gorilla-like alien...!"

I wish I could figure out that <something> character. It's a complex character that comes out blurry in the scan.

Addendum to addendum:

Or yea, that something is you. I see that now in the next paragraph. So whatever you are; a robot?


The game can be played here under the "Classic 8-bit BASIC games" menu item:

Monday, 7 February 2022

"House Adventure" by Anonymous: A TRS-80 Model 100 Game

Similar to my last post about "Space Derelict" I recently converted another interesting and obscure text adventure program, but this time as a response to a request from someone who had wandered into my text adventure page:
Jim, I've got one more random game request that one of my cousins remembers playing. We believe we found the code here - It's under the first section on the page, and is called "House Adventure". Any chance it's an easy one to post for play on your emulator?

I converted this program to Micro Color BASIC from source from the Club 100 Library of text adventures link mentioned above.  As in my conversion of Space Derelict, I ended up making a lot of modifications to the program to make it more coherent. But for this one I also made changes to make it more forgiving/winnable/playable.  I think it had an excessively brutal level of expectation of a player's willingness to restart a game after losing or being put in an unwinnable position. This level was only justifiable in a time when programs were rare and hard to come by. It also simply had some bugs. Both of these reasons were possibly why my contact's cousin had been so frustrated/fascinated by the game to want to return to it all these years later.  But also, there was a swan of a game waiting to emerge, which I think must have also been a part of his captivation. So I don't feel bad about altering this old program from its original form.

It was only after a lot of bug fixing and conversion work and lots of frustrating hours trying to solve the game (using peeks at the code garnered from the conversion process) that I discovered via a comment by Strident on the CASA Adventure forum, that Gaming After 40 had done a walkthrough of the game: "Adventure of the Week: House Adventure (1983?)".  I had already fixed many of the oddities that he also had noticed, but his post put me on to a few more. Here's a list of the main changes that I made (and can remember):
  • I fixed the strange illogical wrap arounds in the map. They didn't seem to add anything to the game play, and if they were there as a way to create a surreal atmosphere it didn't work for me. It just made me feel like there were errors in the map info.
  • I also changed the game so that the player has 60 moves with the flashlight, not just 40, which would allow for a fairer exploration of the basement. Also, if you end up in the dark, you die less quickly, providing you with some possibility of making it out from memory after the lights go out.
  • Bugs relating to floating-point numbers being generated by the random number calls are also fixed.  This and the weird room wrapping makes me think this may have been a botched conversion.  Also, the messages seemed to be formatted for something like a 32 X 16 column screen and not the 40 by 8 screen of the Model 100, which makes me think it may have started life as a TRS-80 Coco program (or possibly for the C64 or Atari game). But I couldn't find anything like it in the 4 Rainbow Adventure books. One thing that speaks to it being a Coco or TRS-80 Model 1 conversion, is that the RND calls typically take the form of N=RND(1)*4-1 for floors (0-3) or magic words (0-3) and N=RND(1)*9-1 for one of the 10 rooms (0-9) on each floor.  On a Coco you'd get such numbers by doing RND(4)-1 and RND(10)-1. There is also one instance of RND(1)*10-1 for random room assignment.  I think the programmer didn't really understand the nuances of Microsoft's various random number generation conventions, which were different between the version of BASIC on the Model 100, and that of the Coco and Model 1. The programmer really shouldn't have kept the -1 in there, since, for example, RND(1)*4-1 would only result in integer values between 0 and 2, thus omitting the last magic word as a possibility. Instead, I changed these references to generate consistent 0-3 and 0-9 ranges where appropriate.  In certain instances, 0-8 was needed, such as to omit the possibility of  assigning monsters to the elevators (room 9 on each floor).
  • I corrected a few spelling errors.
  • Now when carrying the aluminum dime into a phone booth you are guaranteed to be transported to one of the other booths in the house, and therefore notice the magical effect. I think "phone nook" or "phone vestibule" might be a more accurate description of these rooms (old mansions have these), but I left it as "phone booth."
  • You now have a 5 item carrying limit, instead of 4, which means the game is no longer an endless slog of to-ing and fro-ing. You have to keep hold of the flashlight and its batteries (for the basement), which eats two items and later the dime (for using the phone booths to get to the 3rd floor), which only left 1 item space under the 4 item limit. Since you must usually also carry one item to complete a task, and there might be multiple tasks and sometimes multiple items in an area, you would have to make multiple tedious trips into an area just to bring items out after solving a puzzle to gain access to them. Seemed ridiculous, especially when some items (like the batteries) go inside another item.  Even the crazy map wrap arounds made little difference in regard to this problem. In terms of possible shortcuts they might save you one or 2 moves at best.
  • The awkward formatting of the final victory message is fixed.
  • The monsters can sometimes be relocated to the Foyer, which is where you can drop items before getting the key and transferring them outside for your points. Sometimes you can lose simply because a monster gets shifted to the Foyer and then it prevents you from picking up any of the items, including potentially the item that allows you to banish the monster if you didn't notice the monster before dropping that item; or if you carried it directly outside (where items disappear at random). It seems a real shaft that you can inadvertently take items outside and then lose access to them (are people stealing them?) and then realize you need them again because a monster got shifted into a room with another item in it and starts protecting everything there. This forces you to store things in the Foyer, just in case, and then once you do this and are hauling items there (all the to-ing and fro-ing) only to realize that a monster shifted in, and you are now stuck because you have just dropped an item needed to banish that monster.  Also, the fact that the items can create a list so long that they actually scroll the screen adds to this infuriating possibility.  So I added a scroll pause routine when the item list for a room gets long.  But I wonder whether it would be better to simply prevent monsters being shifted to the Foyer. The author certainly seems to have delighted in finding ways to foil the player's (tedious) efforts to collect treasures. 
  • Now the 3rd floor phone booth will always transfer you to another phone booth, even without having the dime, so you can't get trapped on the 3rd floor before getting the dime. This can happen if you get there by discovering and testing out the magical words, which can zap you to random rooms. Text adventures shouldn't just be about meticulously recreating movement patterns learned after continuous arbitrary failures. They should be about figuring out clues and solving puzzles while exploring.
I was tempted to correct the use of a garlic clove to scare the Werewolf away, but I did find a single reference online to Eastern European beliefs about garlic warding off all manner of evil creatures including werewolves. So perhaps this is a clue about the ethnic background of the programmer.  But as Gaming After 40 suggests, this is not "canon" in terms of broader popular culture.  Garlic and sunlight  (and flashlights?) are for vampires, wolfsbane or silver are for warding off werewolves.

I also did a bunch of alterations to the arrays to consolidate them into one single multidimensional array to make the game save feature work on an MC-10.  So if you want to use that feature you will have to use Tamer's VMC10 emulator rather than the online MC-10 emulator, which doesn't support file saving.  Here’s a link to the VMC10 repo:

It contains all the MC-10 programs including all the text adventures displayed on my rare text adventure page:

It also includes HOUSE.C10, in the JimG directory in the “Cassette” directory.  You can just launch vmc10.exe from the directory that you unzip the repo to and then can play any of the files in the Cassette directory.  Type RUN to launch the game after CLOADing it.

My version of House Adventure should be more coherent and forgiving than the original, but it is still a  tough adventure. I have played it to completion (see the video above--spoiler alert), so I know that it can be resolved. If you need help, then the Gaming After 40 walkthrough on his blog will get you through. He also outlines many of the bugs and weirdness that you need to remedy to get the original program to run on the TRS-80 Model 100.

I'd like to thank my informant for putting me on to the game. Strident and the other archivists over on the CASA text adventure site realized the the game wasn’t catalogued when I posted about it, so his suggestion was helpful for bringing it to their attention.

HOUSE can be tried online here, although you won't be able to use the helpful game save feature (saving is not supported by the online emulator):

Jim Menick's "Space Derelict"

Strident over on the CASA Text Adventure archive was doing a little research into Jim Menick, an author of a type-in how-to book "Basic Adventure and Strategy Game Design" from 1984. He mentioned that the book was published for the Apple II and TRS-80, but that there didn't appear to be any playable version of the game on the archive or anywhere out there on the Net. There was also supposed to be a version for the IBM PC Jr. but the demise of that machine apparently took that edition with it.

Strident posted a place to get a scan of the TRS-80  version of the book: ... lications/

Garry, another frequent contributor to the Classic forum on CASA and a typer-in and fixer of games, already had the game in progress.  He noted that there weren't any copies of the Apple version of the book available in scanned form online, but that he had started converting the TRS-80 listing into working code.  It was specifically programmed for the TRS-80 Model 4, which presented some problems, as that was a rather unique later version of the TRS-80 Model 1 line.  For example, it had an 80 rather than 64 column screen.

I decided to take a look at the TRS-80 scan, and realized it was pretty clear. Most of the source code listing could be easily copied from the PDF without too many errors, so I undertook to convert it into an MC-10 program. But first I had to get it back into a readable form for its original TRS-80 Model 4 form as printed in the book. For those interested a fairly bug free version can be found (DERELICT1.TXT) on my Github.

However, if you want a fully debugged version, it would be better to dig up Garry's conversion.  Also, my version had to condense some of the descriptions in order to get it all to fit in 20K.  I don't think anything critical has been omitted and in some cases the descriptions are perhaps even a little clearer and more elegant (a conceit on my part, I'm sure, but hey, it was a lot or work converting the program).  However, I did make one stylistic change that actually takes a little more space, which was to get rid of all contractions in the robot's responses.  Real robots and Androids, as commander Data teaches us, don't use contractions.

Garry notified me of a couple of bugs from his early notes. "In line 13130, '3180' should be '13160'. In line 6570, '5760' should be '6760'." I had already found the 6570 bug but not the other one. I also found an error in 5950, where it should print the A$(19) message instead of the one listed.  Garry also found another bug he notified me of later on, which  prevented you dropping anything: "In line 6570, '6950' should be '6590'."  I had already fixed this bug in the midst of my rationalization of the code to shrink its size to fit in 20K for the MC-10.

We both ended up tearing out our hair because we couldn't get past one of the first puzzles.  You get fried going into a room in the early stages that you clearly need to get into (you can see into it from a prior room).  Turns out that you have to be carrying a pentagon and a crystal, which together form a telepathic device for opening doors.  You have to "think open" in rooms with locked doors while carrying both items.  This includes the room you get fried going into.  But by using the telepathic pentagon and crystal doors will open (or in the case of that room, disengage whatever safety device that is frying anyone who enters.  In other cases you must "click" the pentagon.

I realized there was a walkthrough provided by Menick on pages 21-22 of his book that describe this, but it was not entirely clear. He also provides a map, with numbered rooms.  To get into room 5 (the frying room) you have to THINK OPEN or SAY OPEN in room 11 (the one where you can see into 5). You have to be carrying the pentagon and the crystal you can get from room 7 (by clicking the pentagon) for this to work. Menick admits in his walkthrough that this "mind trick" is a bit of a devious puzzle, although there are some clues.  For example, when you carry the crystal into the hologram you get a subliminal message saying "THINK HUMAN."  But I think there might be an error with the messaging in room 11. Menick's walkthrough description indicates that the player should be able to LOOK OBJECT and see that the burnt metal thing in room 5 is a fried robot. I think this is supposed to be your warning to stay back, but it didn't work on my version. But I can't be sure if that was a result of my conversion hacking or not.  In any case, I fixed it in my version so that you can LOOK OBJECT and see the fried robot.

Despite its relatively small size as an adventure there are lots of puzzles in this game and (as was typical) more than a few sudden deaths.  Menick tried to provide many synonyms (some of which I had to remove to save space) but there are still a few guess-the-verb situations.  There is a lack of abbreviation for things like INVENTORY and the non-standard directions like NORTHEAST. 

There were a few elements of descriptions that Menick mentions in his walkthrough but which don't appear in the actual game, such as the climbing ropes in the exercise room. They're not in the description, but if you CLIMB ROPE, you die (clumsy robot?).  CUT ROPE will allow you to get piece of rope if you have found the knife, but all this serves no purpose, as the rope element is a red herring.  I added the ropes to the gym description in my version.

It was like Menick was still tweaking the code when it went to press, or perhaps he only hurriedly converted it from Apple BASIC. Strident mentioned that he found biographical info on Menick that indicated that he was primarily an Apple user. This seems likely as the TRS-80 code is quite simplistic, and as a result, a little bloated. It was tough getting it down to under 20K.  I had to convert the room messages being loaded from disk, which relied on creating a special data file, and simply make them all into DATA statements.

But on the whole, I quite liked the creepy space derelict story and the robot-at-your-command idea that Menick uses to allow you to explore the ship at a distance. When the robot dies you just get a chilling repeated "END TRANSMISSION" message. The bugs were not of the game breaking type, just annoyances that somewhat spoil an otherwise neat little game. For example, you could press the green button to open the door into the ship without having pressed the black button to close the outer door without triggering explosive decompression. Menick sets a variable AL=1 for when the outer airlock door is closed, but he doesn't use again. I changed that. Now its black before green and you're keen, green before black you ain't coming back. I know the ship has air because there are footprints in dust on the floor and things aren't floating in a vacuum, etc.

The book is a little turgid, but having written some turgid pedantic books myself I'm not going to be overly critical.  And most of the how-to books of the time were like this. The code was very simple, which is perhaps justified for its pedantic purpose. Multiple repeated IFs for everything, including the handling of every movement. I've seen games with 3 times as many rooms and messages but about the same byte count because not all of it was eaten up by program commands (so many IFs!). Still, a neat premise that actually works out well for a little 8-bit BASIC adventure of the time period. However, I think Menick is a better fiction author than an elegant coder, although he gets the job done.  And he does suggest in the book that it is up to the reader to take the programing further.  I think I've fixed most of its annoyances in my version, so I took his advice.

Thanks to Strident for the original suggestion and to Garry for all the debugging tips.

Now I might take a crack at his five person poker game in the second half of the book, which is a demonstration of the "strategy" part of his title.  Converting "Space Derelict" was a fun little exercise in bringing an old program back to life from digital oblivion.  Perhaps his poker program might demonstrate some interesting elements of early AI programming.  He does mention that he tried to give all of the opponents playing styles from different people he actually knew.  I'll keep you posted.  In the meantime if you want to help bug test/try out DERELICT it can be played in Mike Tinnes online emulator here:

If I can get hold of Menick, I will hopefully be able to arrange permanent access to the program from my site.

Friday, 21 January 2022

Debugging Old BASIC Games with Neat AI Opponents

It started with an email from Greg Dionne that he had triggered an error in my ACHESS program with these moves:

Choose "0"
Then do the following moves:
E2 E4
B1 C3
G1 F3
D2 D3
C1 C2

It gave a ?BS ERROR IN 4200.

This got me looking at the program again. First thing I did was rename and move AChess to CChess, since this title had been bugging me a little. I had initially called the the program AChess because it was written in Apple Integer Basic, but the programmer had titled the program "Computer Chess" so I thought I should rename it and put in renamed directory reflecting its internal title:

I think the error Greg noticed was a problem in the original program. It didn’t clear some variables used in the input routine until after the branch taken by the “OO," which left those variables in states that couldn’t be handled by the 4200 routine, which was called after the return from the input routine after an "OO" is entered, but before the initiation of the "castling function," which would set those variables to some specific values.  Or so I think after having tried to chase down the assignments of all the variables involved that were causing the error and comparing them to the original code. Nothing would seem to account for them being miss-assigned. But by simply zeroing them before the check for the input of “OO”, since they were zeroed right after that branch anyway for processing the input of regular moves, the problem went away. As I said, those particular variables would eventually be set to specific values by the castling routine, but before that routine was reached after the return from the input routine, flow had to get past a call to 4200 (basically a routine subroutine needed to display pieces in their designated new locations).

I was a little surprised that such an error might have existed in the code, since after a little investigation I discovered that the programmer Mark Watson had made the program back in 1978, and it had been distributed on a sample disk by Apple. He apparently was programmer who made contributions to AI and computer game development.  Perhaps Integer BASIC is more tolerant of array variables going out of range or something like that, so it might never have triggered a catastrophic error.  It was neat to discover that the code was an interesting contribution to early chess AI coding in BASIC.  Hopefully, it is a program more people will try out now.  My impression is that getting an Apple emulator up and running to run the early Integer BASIC can be a bit of a challenge, so it might be helpful have it converted to Micro Color BASIC.

In the midst of conversing with Greg about this minor bug, he also pointed out another in another program I had converted from a while back:

Hi Jim!...noted a few funnies in OTHO36.TXT
* line 1350 when using MID$ .. an extra ')' in front of the ",2".
* line 1440. extra parenthesis.
There were definitely typos there. Not sure if they were fatal in Coco BASIC, but in the MC-10 they certainly triggered errors under certain somewhat rare circumstances. I also found another error in line 1430.  The assignment of the array variable had a 9 instead of a right bracket for the array variable.  That definitely caused an error.  So I looked back at the original source (from the Coco archive) and all the errors were there in the original source.  So I decided to look at the code more closely, since I now suspected that my conversion had involved too little checking.

I found a few more quirks.  Not major errors, but obvious oversights by the programmer, probably just because he didn’t have the luxury of a full screen editor view of the code.  The message to display “THE COMPUTER WINS” for example, didn’t work.  The IF checked an incorrect variable.  Stuff like that.  Also, in two player mode, there was no win check for the two human players.  They would have to both agree when someone had won and then break out of the program and type RUN to start a new game. So I added a quit option so that players could more neatly begin another match.  I also modified the “THINKING” flashing message as I found it too flickery. I added some speed-ups, such as converting IF AND constructs to IF THENIF constructs.

OTHO36 is by Alain Dussault from 1982. It's an Othello game that plays a very strong game, at least from my limited experience as player.  Like CCHESS it is another interesting example of an AI opponent programmed in BASIC in the early days of 8-bit computing.  I really hope people will give it a try and that my edits might help folks to have a less frustrating experience with it.  They mostly involve dummy proofing.  For example, I discovered an error that I think would only happen if you triggered two consecutive input errors (move onto an existing piece, move to an invalid location) on the first move of the game. Unlikely and rare, but nice to get ride of it.

I hope I have actually improved these two neat programs, and not actually damaged them in some way.  They can be played here under the "Classic 8-bit Games" and the "Other 8-Bit Basic Game Ports" menu selections after you choose "Play Game":

Thursday, 13 January 2022

Galactic Hitchhiker by A. Knight (1980)

I've made a recoding in Micro Color BASIC (for the TRS-80 MC-10) of the text adventure "Galactic Hitchhiker" (1980) for the Compukit UK101.

Gareth Pitchford (I'm assuming it's him based on his avatar pic from on CASA and Facebook) gave me the idea in a post over on the CASA Adventure archive forum.  He noted that it was an important landmark game; one of the very first original British authored "home computer" text adventures.  Unfortunately, it was for a very early 8-bit computer system, the Compukit UK101, which was a unique variation of the Compukit line from America. As a fairly rudimentary system, it was a little more difficult of operate than later home computers, and modern emulation can pose some difficulties for the uninitiated.  He suggested that if I was looking for adventures to convert or "fix up", this might be a good one to try.  He was right.

He set me on to a page he hosts "8bitAG" with a write-up about the game and a walkthrough and map by benkid77:

Benkid's walkthrough provided me with invaluable information, especially the video.  I used Gareth's page to find my way to the hex file of the original program. I was able to download it and then convert the hex listing to ASCII characters, which produced something like this:




This gave me all the messages and room descriptions. Then I just had to use my go-to BASIC text adventure engine, "Tower of Mystery," which was provided as an example in Compute's Guide to Text Adventures (1984). It has all the standard commands for handling all the functions of most BASIC 2-word text adventures.  I just stripped out the "Tower of Mystery" stuff, and put in the room descriptions from the hex dump converted to DATA strings.  Then I just had to figure out the directional relationship (N/S/E/W/U/D) between all the rooms working from the video walkthrough provided by benkid. From that and the printed walkthrough I was able to come up with a map like this:

Obviously, the maps have had a lot of erasing and editing from my original crappy versions. The room numbers are mine, from the reprogramming process, but because I didn't disturb the original order too much (except for the first few room descriptions), you can discern the mapping of the author. The rooms are arranged in a grid (roughly 5X4) of 4 "levels" corresponding roughly to 4 main episodes/locales in the game.  Another interesting structure I stumbled across involved the scoring (although this may not correspond to the original). There appear to be 10 main puzzles/milestones in the game, which boil down to this list:
  1. OPEN DOOR (to get to the escape craft)
  2. CHOP TREE (to get to Gerb City)
  3. CHOP GERBICOP (to get the scarf)
  4. CUT FENCE (to get to the Spacetran)
  5. PUSH BUTTON (to escape the Spacetran)
  6. WAVE SCARF (to get rescued and taken to Gomeril)
  7. FEED GHOULIBRUTE (to get blaster to shoot Ranger)
  8. SHOOT RANGER (to get into the Time Corp building)
  9. DON'T PANIC (to get into the Time Machine)
  10. PULL LEVER to return to the beginning where you must GET TICKET and then get to the Starliner in time (to win).
Not sure if this corresponds to the original, but I like its simplicity and the fact that if you give each step a weight of 10, you get a kind of percent meter to gauge your progress to completion.

My reconstruction of the directional information is made just from posted walkthrough's and analysis of my evolving maps. There might be some differences in the original in certain areas where the walkthroughs didn't go. I invite anyone with in depth knowledge to try it and then let me know if they can find any major differences. HITCHHIK can be played here: 

In particular, I have simply speculated about the wandering that might be present in the "Desert of Grey Ash" map, particularly around rooms 51 and 49.  It was also just from the apparent arrangement of room numbers that I have put the "Theatre" (Room 15) from the City of Gerb where it is.  

It is also speculation on my part that there is a count-down on the first map, and that the player has a limited number of moves before the planet blows up.  This is currently set to 30 moves.  I'm not sure if this is a fair amount for a first-time player.  When you return to the beginning by way of the time machine you get 20 moves to get to the Spaceliner to complete the game.  I tried this, and if you make a mistake like forgetting to pick up the ticket, you wont make it back to the Lounge and then back to the Liner to escape before the planet blows.  Again, I don't know if this is fair, or even like the original.

There is also some guess work on my part about the deaths. The video walkthrough provides some hints about these, as do the messages from the original code.  But there is still some speculation involved on my part.  Some deaths might be missing.

In any case, I don't think any of my speculations are weird. They make for a pretty standard game like any of that time period.  So my version might not be a perfect recreation, but then again maybe a slightly altered version might not be that bad, especially for those wanting to revisit the game. But I still would appreciate any comments that might allow me to improve fidelity. Then again, many of the commentaries I read about the game, such as Renga in Blue's (who also provided a useful partial map), note that the original (probably because of memory limitations or because the genre was still so young) had some annoying traits. There was no LOOK command. There was no INVENTORY command.  There were no shortcuts for the directions. These have all been fixed.  An EXAMINE command has also been added, along with other niceties curtesy of the Tower of Mystery engine.

I hope some folks who wouldn't have had an opportunity to play this quirky game now will be able to try it. It's a wonderful parody/homage to the Hitchhiker 's Guide to the Galaxy franchise by Douglas Adams, with a little reference to Dr. Who thrown in for good measure.  Spike is Ford Prefect. Maurice is Arthur Dent. Marina is Trillian. You can get a taste for the sense of Knight's humorous take on these characters from the intro screen:

Enjoy.  And please comment.


I realized after watching my own video walkthrough that the Tower game engine was using the phrase "You see" as part of its description.  However, in the original game the references to the main character are always in the form of "I" references coming from Maurice, with the player being the "You" who is recommending actions to him as a helper per Spike's initial request to "help him" get home (or controlling him a la Scott Adams' "puppet" metaphor for the dynamic between player and character in text adventures). So, for example, Maurice refers in several places to "You" such as in the desert, where he asks "Have you got me lost?"  So I cleaned up all the references to "you" coming from the parser that were referring to the player, and switched them to "I" references, such as "I see" "I'm carrying" and "I can't", which refer to Maurice the character and what he is experiencing.  This convention is an indication that this text adventure is a very early one (for Britain) and that such conventions were still fluid.

I also added the ability to get an INVENTORY by typing "OPEN RUCKSACK" to be like the original and fixed a misplaced comment from Spike.  He says "Cool baby" when you are ejected into open space, rather than when you get to the final elevator, which had been a complete speculation on my part.  It's much funnier as a comment when Maurice is floating in open space.  I also fixed it so you die if you don't wave your scarf in open space, rather than simply being left in a room with no exits.


With the help of Gareth's page I finally got the Compukit emulator up-and-running and played through to the Desert region.  I was able to figure out the rooms in the 49-51 grouping.  I realized that I had left out and combined a number of room descriptions.  I was able to restore the original map, but I had to add 3 new rooms.  In the course of making that change, I was able to consolidate the repeating Desert description, so it used a single string for the initial part of all the desert room descriptions. This saved a bunch of memory, so I was able to go back and fix up some things and make some minor additions to the program.  I had been somewhat constrained because I was reaching the max of memory.  I noticed a misspelling of "corridoor," which I changed to "corridor."  I added a description to the EXAMINE function that notes that the axe is for chopping trees, since Renga in Blue had complained that there was no specific reference to TREE as an object in the game. I also made it deadly to try to kill the Jolly Gerb Giant or the Ghoulibrute, since there are plenty of warnings about Ghoulibrutes (and who attacks a giant!). I also made the Ghouilbrute disappear after you feed him, since I noticed that happened while playing the original. And I made Maurice's complaint that "the whole place is blowing up..." disappear after your reach the lift to the Starliner the first time. Seemed a bit excessive to have it repeated ever time you enter the room, and the original game removed it.  Anyway here's the new desert map: