"La Guerre du Feu" by Sanyo (1984-1985): A Text Adventure CRPG Combo

I received a really neat email from David Kilpatrick about my latest game port and translation project for the TRS-80 MC10:

------ Original Message ------

Hi Jim 

When I prompt Google Gemini 2.5 Flash chat AI with this:

"Provide non spoiler instructions for playing this game:" and then paste in the contents of "Firwar11.txt", I get:
 

This is a text-based adventure game written in a dialect of BASIC, likely for an older computer such as the TRS-80 Color Computer or a similar 8-bit machine. The core objective is to find a fire and bring it back to your village. The instructions below are based on an analysis of the code and are non-spoiler.

---

Gameplay Instructions

The game operates by having you type commands in response to prompts. The game world is a grid-based map, and your primary actions will involve moving around this map and interacting with your environment.

• Movement: You can move in four cardinal directions: NORTH, SOUTH, EAST, and WEST. You can type the full word or just the first letter (N, S, E, W).
• Interaction: The game will prompt you with "WHAT NOW:". This is your opportunity to type a command. The code supports a variety of commands, including:
  • GET or TAKE: To pick up an item. You must specify the item you want to take, e.g., "TAKE AX".
  • FIGHT, KILL, or ATTACK: To engage in combat. You'll then be prompted to specify which item you want to use, e.g., "FIGHT WITH SPEAR".
  • HUNT: To hunt for food.
  • EAT: To consume food you have collected.
  • DRINK: To drink from your flask.
  • FILL: To refill your flask with water.
  • SLEEP: To rest and recover.
  • HIT, STRIKE, or SCRAPE: These commands are related to crafting or creating something.
  • LOOK or EXAMINE: To get a description of your current location.
• Inventory and Status: The game has a system for managing your health, hunger, and thirst.
  • The game keeps track of your health and other stats in the background.
  • Hunger and thirst increase as you travel. You will be alerted when your character is hungry or thirsty. If these needs are not met, your character will eventually die.
  • Meat is a resource you can collect, likely by hunting.
  • You have a flask that can hold water. The game will tell you when it is full or empty.
• Goal: The main quest is to find the fire and return it to your village. You start in the village and must explore to find it.

---

Tips for Playing

• Pay attention to the text: The game provides all the necessary information through text. The descriptions of locations and your character's status are crucial.
• Manage your resources: Conserving food and water is critical to survival.
• Explore and experiment: Some objects or actions may not be obvious. Try different commands in different locations.
• Survival is key: Your main priority is to stay alive by managing your hunger, thirst, and fatigue. Death is a real possibility.

Thought you might be interested, if you don't already experiment with Gemini or ChatGPT.

Does it sound okay to you?

It doesn't mention a save feature though.

Cheers

 

David

Here was my response (edited):

That is soooo cool. Especially considering that there is so little (as far as my research has shown) about the game on the Net. Thanks. I suspect it's LLM training is drawing on some "generic advice" about "two-word parser" text adventures and integrating that somewhat with the  details available from the source. For example it states "You must specify the item you want to take, e.g., 'TAKE AX'" (neat-- it has definitely processed the Github source code). But this is originally a French language text adventure (It doesn't seem aware of that) and the French doesn't really work well in the two-word parser mode. For example, commands aren't usually grammatically put in a simple definitive verb-noun form (I think), but really require different definite or indefinite articles, injunctive conjugation of the verb, not to mention common polite two-verb forms for some actions. As such the French have a somewhat difficult time with the "two-word" format (not to mention that they simply don't like to bow to "anglicisms"). So, the game is actually a "one-word" parser. You input an injunctive verb. Then the game prompts you for a noun and responds. It also knows that you have an inventory, but doesn't recognize that it is simply always listed on screen.

With those qualifications made, I have to say that Google Gemini did a pretty bang up job at describing the game and providing basic instructions for how it works.

So AI has saved me from some writing drudgery. But as I have found with most of my own experience with LLM systems, it often makes subtle mistakes and has blind spots, such as the lack of awareness about the origins of the game. So I'll describe that stuff here.

The game was originally for the obscure (market failure in France--perhaps also in Japan) Sanyo PHC-25. There is a small amount of French software for the PHC-25 that I have come across:

http://www.phc25.com/collection.htm

I haven't been able to locate any Japanese stuff, but if folks out there know of any, please let me know. The reason the PHC-25 is useful for my projects is it uses the Motorola MC-6847 video chip (a Japanese variation of it), which is the chip used in the MC-10. So text and graphic screens are essentially compatible. I have done other conversions in the past, such as "Citadelle: The Shield of Oran."

The BASIC is also very similar to the MC-10's Microsoft variation. However, to use graphics commands on an MC-10 you need access to the MCX-SD or MCX-128 add-on pack. These add Coco BASIC graphic commands so hires screen stuff can be done. The entire game is in Color Graphics Three (CG3) mode. The fact that this is a graphic text adventure is another detail missed by Gemini.

I had to do some conversion of commands from Sanyo Basic v1.3 to Microsoft, but they are very close in most respects. The first big hurdle was that Sanyo Basic has a RESTORE (line number) feature, which Coco Extended BASIC doesn't have. So I had to count up all the DATA elements for the various data lines referenced for terrain graphic elements, and then create a subroutine to quickly read all the elements just before that line. This created a very excessive delay in drawing the tent, so I PEEKed and stored (as part of the startup screen delay) and restored that specific item's DATA read location.

The second big hurdle was that Sanyo Basic has built in text rendering for hires screens, whereas Coco  Basic does not. Instead I had to use DRAW commands and a subroutine for placing messages on screen of the right size and spacing. This required the most conversion, since the PHC-25 could just use regular LOCATE and PRINT commands for messages, whereas I had to set variables and GOSUB a bunch of subroutines instead.  I had to scale my text routine so it as closely matched the size of original as possible.  However, I think the original program used a slightly narrower font in the horizontal, which I couldn't get my routine to exactly match, so it had a couple of extra lines to work with. This required some condensing and re-formatting of messages for my version.  For example, I had to print 3 of the inventory items in a different color font (red) and list them on lines with other items.

Once that was done, I just had to use my old high school French and Google translate to convert all the commands and messages. There are always some challenges. In this case the word which I translate as FLASK was a little obscure. I think "OUTRE" means something like "skin," as in "wineskin." But I wanted a familiar term in English, which suggested a rustic form of container, but that was not too obscure or long since space for text on screen is at a premium given the font differences. "Flask" seemed to strike a good balance.

Then I just had to figure out playing the game so I could bug test it. The author of the French web page mentions in his comment on the game that he never was able to complete it:

LE jeu d'aventure pour le Sanyo.
Vous êtes un homme préhistorique et vous devez ramener le feu au village. Le chemin sera semé d'embûches. Personnellement, je n'ai jamais réussi à finir le jeu vivant :)

Translation:

THE adventure game for the Sanyo. You are a prehistoric man and you must bring fire back to the village. The path will be fraught with pitfalls. Personally, I never managed to finish the game alive :)

I also found this to be the case. I kept dying from exhaustion, or thirst or hunger. Exhaustion (from lack of SLEEP) was particularly difficult.  As much as I would try to EAT and DRINK and SLEEP regularly it didn't seem enough, and when I started doing these actions, it seemed like the opponents I met would become particularly difficult to defeat. The SN, SB and SS variables in the following code refer to your level of eating, drinking and sleep. You start at zero. If you rise above certain levels (10, 8 and 30), you starve to death, die of thirst, or die from exhaustion.

30250 IFSN<0THENEX=EX+SN:SN=0

30256 IFSB<0THENEX=EX+SB:SB=0

30258 IFSS<0THENEX=EX+8*SS:SB=0

When you do the actions of EAT or DRINK, an amount 5.1 gets subtracted from these counts. The lines of code above are meant (I think) to reset you to zero if amounts go below zero and penalize you for being excessive by subtracting the amount you went under zero from your EX (experience). This is, I think, meant to be an encouragement for being judicious in these actions and not just "pounding" down the food and drink (if available) and sleeping to excess. I switched the starvation and death by thirst levels to both trigger at above 10. They count up by 1 per turn. Sleep counts up by 2 or 3, and I left the trigger at above 30.

You might also notice that the penalty routine doesn't reset the sleep variable SS to 0, but resets the thirst variable to zero if you sleep excessively.  I think this was a simple typo, so I fixed it:

30258 IFSS<0THENEX=EX+SS:SS=0

The real problem was with the SLEEP routine. Whereas the first two actions would subtract 5 when done, sleeping would only subtract 2 or 3 (in a 6 turn cycle of "nighttime" and "daytime"-- indicated by the color of the sky-- yellow for day, blue for night). This meant the effect of sleeping was very limited, and encouraged doing multiple "sessions" of it.  But each SLEEP also increases the food and drink counts by 1 (I guess one is usually hungry and thirsty after sleeping), so you also need to do more of these actions if you slept multiple times. But doing too much of any actions, again, can degrade EX.  Also, notice that the penalty for excessive sleep is *8 (times 8 the amount you went under zero). The EX variable plays a role in hunting success (which you need to eat) and combat success, which helps make areas safe to drink. So I found I would easily fall into a terminal spiral of needing these resources but not being able to get enough sleep before death occurred. Once entered into, it seemed impossible to get back to a healthy equilibrium.

This dynamic was further exacerbated by the warning routines for sleeping and drinking. These warnings only trigger if SN=8 or SB=5 exactly:

30230 IFSN=8THENCLS:LOCATE0,10:PRINT"VOUS AVEZ FAIM" ELSE IFSN>10THENCLS:LOCATE0,11:PRINT"VOUS ETES MORT   DE FAIM":GOTO40000

30240 IFSB=5THENCLS:LOCATE0,10:PRINT"VOUS AVEZ SOIF"ELSEIFSB>7THENCLS:LOCATE0,11:PRINT"VOUS ETES MORT      DE SOIF":GOTO40000

So you would only get a single warning for each. But once you eat or drink, a decimal amount was subtracted, which means you would get no more warnings until you ate and drank to below zero, which would reset the count to zero but result in a EX penalty. Here are the original eating and sleeping IF routines showing how they reduce by 5.1:

15080 IFBB=1THENCLS:LOCATE0,11:PRINT"VOUS BUVEZ":SB=SB-5.1:IFDR=1THENDR=0:BB=0:GOTO30000 ELSE GOTO30000

15150 IFVI>0THENCLS:LOCATE0,11:PRINT"VOUS MANGEZ":SN=SN-5.1:VI=VI-1:DR=1:IFVI<>0THENGOTO30000

The lack of warning, the downward spiraling interaction between drinking, eating and sleeping, the lack of the effectiveness of sleeping, and the excessive punishment for over sleeping made the game seem exceedingly brutal and unfair.  In fact, I think the fact that SS (sleep) would not get reset to zero would mean that for every turn thereafter EX would continue to be subtracted, making hunting impossible from then on. This would explain the "death spiral."

So I made a judgement call that this is one of those instances from back in the day (when very little software was available) of making games brutally hard just to allow players to get "maximum play value" from a game (i.e. days and days of frustration chasing the exact random conditions that would allow a win after a brutal education in the finicky expectations of a program). So I trebled the effect of sleeping (to -6 or -9), and took out the *8 EX punishment for oversleeping, which brings it into line with the other two factors. And I changed the decimal reduction (-5.1) for eating and drinking to just -5, so that warnings will always be able to be given about your needs. And I added an additional warning for both at the second to last turn before death. When you kill a bison, you get +2 EX, but killing a bird only earned you +.1. This seemed an excessive contrast so I set the value of killing a bird at +.5.

After those changes I found the game more playable and was able to concentrate on trying to win. I wont give away how to get fire back to your village, except to note that there are multiple pathways, and that I clarified a graphics hint, which can only be seen during daylight. Once you get fire you need to get back to your village, so mapping is probably a requirement. Here is a partial (and possibly somewhat inaccurate) map from my own rough notes:

The game creatively uses combinations of terrain graphic elements to make a diverse array of location types. The variety is more than the code might otherwise appear to be capable of, given that it is under 16K in size. It is really a clever little resource management, simulation, with text adventure and CRPG elements.

It has some charming images given the limitations of the graphics screen. I tweaked a few of them to provide greater contrast of some objects such as the bird and the tree trunk. I also had to shift a few of the coordinates of the PAINT commands, or add a pixel so that some areas would get filled, such as the leaves of the tree on the plain (top left below). It took quite a while for me to figure out the bird. I finally realized (gestalt shift) that it was a bird diving to the left rather than a large beaked toucan-like bird flying upward. Close examination of the operation of the PAINT command, which seems to work slightly differently on the Sanyo, revealed hidden elements when fills worked correctly, such as one of the arms of the tyrannosaur. One of the legs of the cave man didn't fill either. I also added colour to his spear hand and right foot to match his body.

Similarly with the different types of the terrains, I had to tweak the PAINT commands to get certain features to fill in, such as the red hill on the hill terrain, or the yellow horizon of the forest terrain. The images of the top row of the following set are how the terrains looked untweaked. The bottom two rows represent the tweaked day and night variations. The night variation of the forest is quite different from the original PHC-25 game.  That version filled almost the entire screen with blue, except for the very bottoms of the trunks below the horizon level. I opted instead for a moody green background color and simply filling the leaf canopy dark blue. I also adjusted the waves/ripples on the river terrain to make them look more wavy.  On the mountain terrain, there was a little sliver on the bottom right which didn't get turned red as in the original, but stayed the color of the day or night sky. I made sure it got filled in.

I hope my edits haven't maimed the game (made it too easy), but simply more playable and fair (given the patience levels of modern audiences). But if you want the raw original, you can always try it in French using a PHC-emulator, which I believe can also be found on the phc25.com site link above. Thanks to David Kilpatrick, Nicolas of phc25.com, and to Dave Bernazzani for spotting a spelling variance between the LOOK description and GET routine (AX versus AXE) in my translation.

FIREWAR.C10 for the Tandy MC-10 with MCX-BASIC can be downloaded here:

https://archive.org/details/FIREWAR

FIREWAR.BAS for the Tandy Color Computer can be downloaded or played online here:

https://archive.org/details/firewar_202508

The conversion to Coco Basic from MCX Basic required putting spaces into the code after certain uses of variables. And you can't use a simple color number after LINE commands, but must change the foreground color using the COLOR command first. Then you must use PSET or PRESET for the color attribute of the LINE command. Also, I had to change to different POKES and PEEKS for the DATA statement pointers.

The source code for both version can be found here: https://github.com/jggames/trs80mc10/tree/master/quicktype/MCX/FireWar

** SPOILER ALERT **

If you are really curious, here is a video of me winning the game, to show that it can be done:

And here is a screenshot of me winning on the Coco version:

"TPUG Sample Adventure" by Steven C. Darnold (1985)

This is a text adventure modified to work on the TRS-80 Micro Color Computer ("MC-10") using Micro Color BASIC from the author's published source code in TPUG Magazine June/July 1985 pp. 8-12. The game is a sample adventure described in an article "Do-It-Yourself Adventure", which provides the basic building blocks for creating your own text adventures in BASIC. TPUG Magazine was the newsletter of the Toronto Pet Users Group, one of the largest Commodore computer clubs in North America in the 1980s.

Here is a walkthrough:

N,GET CANDLE,EXAMINE PEWS,GET KEY,S,W,EXAMINE DESK,LOOK,GET MATCHES,W

LIGHT CANDLE,LOOK,READ SIGN,GET SHOVEL,E,E,DIG,DROP SHOVEL,GET GOLD,W,W

DROP GOLD,SCORE,E,E,E,OPEN SAFE,DROP KEY,S,GET COINS,N,W,W,W,DROP COINS

SCORE

TPUGADVR.C10 for TRS-80 MC-10 can be downloaded or played online at the Internet Archive: https://archive.org/details/TPUGADVR

The source code can be found on GitHub: https://github.com/jggames/trs80mc10/tree/master/quicktype/Text%20Adventures/TPUGAdvr

"Survival" by Stewart F. Rush (1981)

I've created a new MC-10 version of "Survival" aka "Moon Survival Adventure" from David Ahl's 1984 book "Big BASIC Games". I only made minimal changes to get the source code to work properly. Renga in Blue (Jason Dyer) did a blog post about the game which made me aware that a version I had created a while ago (from source found online) was actually a modified version with the authorship attribution changed (as was common back in the day). My new version is a faithful rendition of the source code found in Ahl's book. In fact you should be able to simply type in the following changes recommended by Rush in the description of the game to make it easier:

350 T2=275

360 P1=320

370 P2=75

730 IF T1>485 THEN 2960

740 IF T1>380 THEN 3840

The following line is the specific one that sets the item max to 3 items:

2270 IF C>2 THEN 2390

I wouldn't bother using that one. As Jason makes clear, the game difficulty is set too hard for enjoyable adventuring set at the original numbers. Typing in the first five lines above (i.e. without 2270) should make for a more enjoyable experience.

I made a few other changes. The carried item count is not decremented when you get the fuel and then use it to refuel your rocket. This shrinks your carry limit to 3. I fixed it. Also, the following line was missing from the code listing in the book:

3750 O(6)=14

This "exposes" the location of the de-activator, which is absolutely required to complete the game. Now it will show up at the appropriate time. Jason suggests in his blog post that this is because you have seen the clue in the space station indicating the location of the item, but it is actually just timed to occur at 200 minutes into the adventure. In other words, it appears after you have likely been exploring long enough to have got into the station and back out on to the surface.

In the following screen you will see that I have added some comments at the bottom of the listing that allow for a simple way to modify the game to be played at a more reasonable level:

Just type 9070 and hit enter before typing RUN.  However, this only modifies the oxygen level, line 350 in the list above.  It leaves in place other timed events like the coming of the meteor, that crushes the station at line 730, if you take too long:

I have played the game through using the walkthrough by Garry Francis over on the CASA Solution archive.  Here is the screen just before I blast off to game completion.

If you are looking for an authentic experience of the original 1981 version of the game published in Ahl's 1984 book, it can be played on the Internet Archive: https://archive.org/details/survival_202504

"Drakulas Diamanten" by C. Seibt (1983)

Full Walkthrough

"Dracula's Diamonds" was originally published in German as a type-in for ZX-81 in the October 1983 issue of Homecomputer magazine, pp.30-35. I found out about it from Strident over on the CASA Adventure forum. He suggested it as a possibility for conversion and translation. Thanks Strident! He mentioned a VZ version and provided some useful info for tracking the game down. I was able to find it on one of the VZ repos under the collection of German Laser 200 programs. Using Google Translate I was able to translate the German messages and items into English.

Apparently, there are also Spectrum and C64 versions. The titles vary ranging from Dracula to Draculas Diamanten and also the more Germanic Drakulas. The main differences seem to be in tweaks to the graphics. I used techniques I've developed to translate the graphic characters from Laser/VZ-200 BASIC to something that works on the MC-10. Unfortunately, they all come over as red semi-graphic block characters. Then I have to "re-colourize" them.

A modern coder Frank Gerbig liked the game so much that he translated it into a modern Interactive Fiction (IF) creation engine (Inform), which can be played online (in German).  Like him I couldn't resist reimagining the game. First I tweaked the graphics using my MC-10 screen editor software. It was very awkward back in the day to draw text graphics using only the keyboard to input characters. But today I can just transfer an entire screen to my special BASIC editor program. Then I can print out the screen and re-line number it and add PRINT statements and reinsert it back into the code using a modern text editor. So I was able to fix some clunky aspects of the line drawings, and fiddle with colours and change shapes to make the images look a little more coherent and the items a little more identifiable. For example, I tweaked the "fan" in the bathroom to look more like a fan (I initially thought it was some weird decoration).

Original Painting and Cabinet

I also fixed the operation of the fan switch so that when it is turned on, it prints a message about the "stench" disappearing. The walkthrough for the ZX-81 or Commodore version on CASA mentions such a message, but it didn't appear in the VZ version.

I fixed the two-word parser to accept more synonyms. Now you can TAKE or GET, PUT or PLACE.  Nouns too. GET NOTE or GET PAPER. OPEN CABINET or OPEN CUPBOARD.  PULL or MOVE. FRIDGE or REFRIGERATOR, etc.

I changed many of the "hints" and added a few more. Some of the original hints seemed to imply that Count D. is aware that you are there. The first one was weird. It said "YOU WILL NEVER FIND THE STONES."  I didn't like this notion of D. being aware of the presence of the investigator., although this particular hint could have also been meant to give a hint about the puzzle in the Tower Room that involves a "stone" (seems a stretch). Another one was an outright instruction: "SOMETIMES PAINTINGS HIDE VALUABLES." I changed the notes to avoid threats, indications of awareness of your presence and outright instructions. I also altered the location of a few of them to make them slightly harder to find and more understandable as to why they might be there. In most cases I made them into notes of D. to himself, like the new one on the table in the first room: "REMEMBER: BUY MORE CANDLES." This seems more reasonable-- just a shopping list-- and that table is right below a chandelier with what might be recognized as having candles in it.  Or I made them jokes or cases of possible doodling.

I added to the graphic images that appear when you take actions in rooms that show the results of your actions. I fixed the door of the fridge to make it look more like an opened door, for example. I also added a board to the bathroom when you figure out where to place the last piece of the puzzle. I made some significant changes to the way young Count D. looks (i.e. Count Dracula-- As if it is really a mystery). I changed the code number to the actual birthdate of the actual historical Count.

Finally, I added "C. Seibt" back to the title screen. Wolfgang Wesemann, seems to have felt his alterations to the code warranted the dropping of the original author (not an uncommon practice back in the day). I would agree that it must have been a lot of effort to get the game working on a Laser/VZ-200 so I kept Wesemann on the title page, but I thought it best in the Internet Age to add back a reference to the original author.

If you want to compare the changes I have made to something closer to the original Laser/VZ-200 version, watch my walkthrough at the top and the other Youtube video, then these snippets of the rooms as they now appear. In the snippets I show all the possible actions available in each room.

New BOARD animation and game completion.  Ladder down added to hatch.

New Fridge door, New kitchen door to the east. Pipe added to cabinet.

New Count (scarier I hope). Now the blood can be opened anywhere.

Basement shows hatch above. Tweaked BLOOD RESERVES and CHISEL

New initial NOTE clue. Improved CABINET and PAINTING

New Bathroom clues re: BUTTON, toilet ROLL, BOWL.

New FRIDGE and STICKER clue. New Tower Room with WALL/STONES clue.

The game can be played on the Internet Archive:

https://archive.org/details/DRAKULAS

ADDENDUM:

Added color to the window in the first room and changed an aspect of the game that prevented the curtain from being opened until you read the note on the table. Seemed somewhat confusing and arbitrary that players couldn't draw a curtain simply because they hadn't read a note.

Cyan Window

I also added the ability to open the stove.  Seemed arbitrary that you could open the fridge and not the stove.  I also added the ability to COOK the LAMB LEG you find in the fridge.  This eliminates a needed item, and represents another possible obstacle to completion.

"Bally's Alley" by John Collins (1980)

Jason Dyer made a post about an interesting little text adventure for the Bally Astrocade system. He was able to get a version of the game running from source code typed-in by Paul Thacker in November 2022 from a printed listing and handwritten notes of the original author, which were preserved by Bally Astrocade hobbyists. This game fits in 4K of memory, which is quite a feat of programming by the author. Jason wasn't able to complete the game because he ran into some apparent bugs. My MC-10 version contains bug fixes to ensure that it can be played to completion. 

The following is a map by Jason of how far he got (pink box) from the start (green):

The problems were probably a result of a few slightly misinterpreted numbers by Thacker from the handwritten notes.

I have two proposed fixes to the hand recorded list of variables:

• @(17) change from 370 to 3170. This allows the player to move on to room #19 of the Color Maze, which I don't think Jason would have been able to do. This was my best guess of where a typo would most likely have occurred to prevent a move to room #19 (and the whole subsequent section), as the method of room number parsing only allows jumps from 1 to 2 (plus or negative) from the current room number. So the problem had to be either #17 or #18 that was preventing movement onwards in the Color Maze. The handwritten note for room # 17 looked like it had a possibly partial "1"that needed to be added to its 3 digits (370)-- just the hint of a "1" in front of the "7." When I tried it, it worked. 
• @(14) change from 1603 to 10603 (this one is optional). Thacker's version just lets you go N from the WELL directly into the COLOR MAZE, which I think undermines a puzzle Collins wanted/was working on. I suspect he had some problems with his room number parser, possibly due to rounding errors, which was a problem for my MC-10 version. I fixed these problems by converting the room numbers to text, and then chopping them up as needed using the MID$ function instead of division by 10s 100s and 1000s and INT and subtracting INTed and non-INTed versions from each other.  Collin's handwritten notes have numerous scribbled-out numbers and replacements for the room data. (This data had to be entered directly by the user, to help conserve memory), which suggests that he might have been experiencing frustrations with rounding errors too.

I think the problems with transcription and the possible one with rounding were what was preventing Jason from being able to initiate interaction with the WELL and also the similar PURPLE room puzzle. Both these rooms need to have 5 digit numbers to initiate a COMMAND prompt after typing a DOWN direction. But only the PURPLE room (room #20 on my map) had 5 digits. It is possible that Collins had switched to 1603 for the WELL room (#14) just as a kluge to temporarily deal with these problems.

# of Room Jumps------>
Rooms	Get a Command?	+2	+1	-1	-2
17			3	7	0
New 17		3	1	7	0
20	1	0	6	0	8
14		1	6	0	3
New 14	1	0	6	0	3

The trick with the WELL is to be carrying the KEYS, have just tried to move DOWN, and then issue the command UNLOCK when prompted. This should take you to the COLOR MAZE room with the LAMP (I'm sensing that Collins was inspired by Crowther's original, Adventure and its formula of "get lamp").

Similarly, in the problematic PURPLE room (it's red in my MC-10 version), the player must have just tried to move in the DOWN direction, and then must issue the command "F."  I'm not sure what "F" stands for, but perhaps "Find" or "Fire," because the player must also be carrying the OIL (but the LAMP doesn't seem to be required in the original). I changed it so that if the player types "F" or "L" (Look) or "S" (Search), a descent to a new section which I call the "Echoing Cave" is initiated (room 30 "No Way Up" in my map below). It also might simply be for "Fall" (If so, wouldn't "J" for jump be better?)  However, since the COMMAND parser only looks at one or two characters (G for Get, DR for drop, L in unLock), it doesn't much matter. Apparently Collins mentioned that people could play the game "for weeks." I can understand why.

The descent takes the player to an area, where the rooms don't have descriptions. Instead, I'm pretty sure each room makes a different noise. I don't have Jason's patience to get an Astrocade emulator running, so I'm guessing based on a rough knowledge of Astrocade BASIC (original and extended versions). Maybe there are some screen effects too. I'm not super familiar with the system but I was able to build some knowledge converting Clyde Perkin's classic "O-Jello"4K "Othello" game, which has a wicked AI opponent for a 4K game. Each room has a slightly different tone/pitch to its sound. This is an absolutely intriguing game dynamic. I don't think I've ever seen a text adventure from this era that uses sound as a critical part of the navigation/description system. It could be a first.

My new MC-10 version fits into 4K like the original (I am in total awe of Collins) and has a few other "fixes" (possible improvements). I added an "L" Look command that can be used in any room to redisplay the description as well as other function ("S" for search will have a similar effect, and both will also accomplish the "F" Find/Fall action). I also added save/load to the main menu and an extra hint to help with the purple room puzzle. I made it so that the player must have both the LAMP and the OIL to descend into the Echoing Cave, based on the assumption that the player needs these items to navigate "the darkness." BALLYSAL.C10 for MC-10 emulators can be found here, but people should be aware that my colors for the Color Maze will be different from those of the Bally Astrocade original:

The MC-10 version can be played online at the Internet Archive.

BALLYSAL.C10 can also be found and played online at the Color Computer Archive (Thanks Guillaume!)

The source code is on the Internet Archive (highest numbered is latest).

I have managed to play it to completion. I'm not sure if 956 is a good score, but your score is decreased by how many moves you take. Since I was using maps and cheats (most importantly reading the source to know what to do), I suspect it's a pretty high score compared to what a real player, working from scratch, would be able to get:

Unlike Jason, I used maps and a temporary modification to the room display routine to print the room numbers (and to allow me to jump to rooms). This helped keep me well-oriented for my own map making. The following are two maps that I created, the first one based on those he posted:

Adjustments to Jason's Map for my new MC-10 version:

My additions to Jason's Map (for the MC-10 version):

Thanks to Jason for the inspiration for such an interesting "Reading Week" coding project, and for his map making and game history and links, which are so helpful when it comes to bug chasing. I'm curious if any of the Astrocaders will figure out other more accurate fixes to Thacker's groundbreaking work. I never know when I bug fix whether I am helping to restore/complete a programmers original vision, or mangling a classic piece of software. I hope it is the former. This one certainly deserves it.

"Computer Dominoes" by David Smith (1982)

I've typed in another game with an AI opponent and modified it to work on the TRS-80 Micro Color Computer ("MC-10") using Micro Color BASIC.  It's from source code in Your Computer Magazine, February 1982, and originally was for the Commodore PET.  The game plays a variation of the "All Fives" game of Dominoes.  But instead of just multiples of 5, scores are also awarded for end totals that can make multiples of 3.  A single point is awarded for each possible multiple of the two types. The computer and human player start with 9 dominoes. When a player uses up their dominoes or neither player can place a domino, then a new hand of 9 is dealt. The goal is to be the first to earn a total of exactly 72.  If points are earned over this amount, they are ignored until the exact amount is achieved.

As usual, I had to chop out the Petsci text-graphic part of the program (involving lots of POKEs), and replace it with an MC-10  semi-graphic-4 character printing routine (using lots of PRINT@s).  I created a routine to lay down a string of dominoes that snakes around the screen so that all 18 possible dominoes can fit. The routine had to print horizontal and vertical dominoes, depending on their location in the string.  It also is used to list the human player's dominoes at the bottom of the screen.  The very low res. nature of the Semigraphics-4 (64X16) mode called for some compromises. The 6 dot domino looks like two solid bars instead of 3 discreate dotes for each bar and in order to differentiate between individual touching tiles, I alternate the colors of the tiles between white and yellow.  It is based on my recollections of  "mixed" sets of dominoes from my youth, which had pure white tiles and more yellowish "ivory" tiles.

Also as usual, I found what I think are some bugs in the original code, which would have affected play on the original PET version too.  One involved the zeroing of the array holding the tile info for the player's hand.  This array is a 0-6 by 0-6 grid.  But the routine meant to put the hand back to an empty state didn't start from zero for the "J" dimension:

1540 FORI=0TO6

1550 FORJ=1TO6:D(I,J)=0:NEXTJ

1560 NEXT

The result was that sometimes, after the first hand, some un-discarded low numbered tiles could be left in the array. Then, when the array was searched for tiles belonging to the player, more than 9 could be found. This error might not have caused a crash in the original program, but in mine it caused the program to try to print a domino to an undefined 10th screen location.  Since those locations were stored in an array (which only went up to 9 locations), an out of array bounds error was triggered.  So I just changed line 1550 above to:

1550 FORJ=0TO6:D(I,J)=0:NEXTJ

This ensures that when the array is repopulated with 9 tiles for a new hand, there is no possibility for old data to be left behind in the first J column.

The other error involved sensing when the computer had played out its final domino. The routine to select the piece would, if possible, select the last tile and designate it as played (=3), and then increment the number of pieces played variable (CD) for the computer. Then it would immediately check if that was the last tile or not (CD<>0).  If it was zero it would proceed to a message that it was "out of dominoes" and then go to the deal a new hand routine.  But this meant the routine would never get to the routine to print the tile on screen and would also miss the end of game/win checks, which follow line 3950.

3950 D(X,Y)=3:D(Y,X)=3:CD=CD-1

3960 IFCD<>0THEN3990

3970 M1$="OUT OF":M2$="DOMINOES"

I noticed that when the computer ran out of tiles it would always flash the "last domino" message and then go directly to a re-deal. Did it win?  Was it a good play?  Did it earn points? The lack of any domino played animation was weird.  So I switched the CD=0 check to the end of the display routine instead.

4140 IFCS<>72THEN4190

4150 M1$="COMPUTER WINS!":M2$="":M$=""

4160 IFPS<66THENM2$="MORE PRACTICE!"

4170 IFPS>65THENM2$="GOOD GAME!"

4180 GOTO2340

4190 D(X,Y)=3:D(Y,X)=3

4191 IFCD=0THEN3970

4195 GOTO1670

Now it displays the domino played (line 3990 - 4130) and then does the win check.  If the computer doesn't win it goes to 4190 and then checks if no tiles are left.  If there are none, it jumps to the no more dominoes message and does a re-deal.  Otherwise, it heads back to the input routine for the next player's move (1670).

I find that it plays a pretty tough game.  But then again, I'm no Dominoes player (no game player of any sort actually), but I forced myself to test it to the point of a "human win."  It was actually kind of fun.

Human for the win!

The game source can be found on my Github:

https://github.com/jggames/trs80mc10/tree/master/quicktype/Artificial%20Intelligence/Domino

It can be played online at the Internet Archive:

https://archive.org/details/domino_20250125

Another Human for the win!