I think I have found another bug in a commercial BASIC game distributed for a computer equipped with the Motorola MC6847 Video Display Generator. I recently ported the code for "Super Mind" for the Sanyo PHC-25 to the TRS-80 MC-10. Like my last project from that machine, "Fire War," there was a bug in the code that I think would have prevented the game from functioning as the designers intended. In Supermind the problem would only have occurred on the last of your 10 guesses. For that guess there was no need for the computer to print a report about how many of your guesses were right colors and rightly placed, since it was your last turn, so the programmer had created a special routine for your last guess. But I think that guess would never be able to be judged correct.
The following routine calls the input your guess routine (3000). Then if the number of the guess you are on is 10 it will jump to the last move routine (5000). Otherwise, it goes to the check the guess against the hidden code (4000), which counts up the absolutely right guesses (O) or right color wrong places. If the number of absolutely correct guesses is 4 (O=4), then it jumps to the end of game routine (6000) to print the appropriate congratulatory message. Otherwise, it keeps getting guesses (2510).
The following analysis applies to the code block listed here, which is the routine jumped to for your final guess (5000).
5000 REM Reponse dernier coup
5010 IF Z=1 THEN 5050
5020 FOR I=1 TO 4:LOCATE2*I+2,1:PRINT" ";CHR$(C(X(I)+1));" ":NEXTI:GOTO5090
5050 LOCATE4,1:PRINT " "
5060 FOR I=1 TO 4:LINE(42+(I-1)*16,18)-(45+(I-1)*16,23),X(I)+1,BF:NEXTI:GOTO5090
5090 IF O=5 THEN 5100 ELSE 5110
5100 LOCATE0,13:PRINT "Í° Gagne en 10 coups De justesse !!! ":GOTO5120
5110 LOCATE0,13:PRINT " Vous avez perdu... "
The problem is that the check routine (4000) is not run anywhere in this last guess routine. Line 2510 of the calling input routine either runs that check routine or jumps to this final guess routine. The final guess routine simply prints the last guess input (5000-5020) and then prints the hidden code (5050-5060). Then a check is made whether the number of exact correct answers (O=5) equals five (5090). If it does, then it prints a game won message, otherwise it prints a game lost message. This is very strange, since the guess check routine (4000) which determines how many absolutely correct selections (O) have been made has not been run. It is unclear why O would contain any number other than what it contained from the 9th turn guess. And it is unclear why O equaling 5 would be an indication of a correct guess of a 4 digit code. It might have made sense to do a simpler kind of check, perhaps to compare whether the guess perfectly matched the hidden code, but that does not appear to be done anywhere in the above.
Now it is somehow possible I have misinterpreted some aspect of the program or some nuance of the type of BASIC used on the PHC-25, but I really don't think so. The BASICs are very similar and conversion is not particularly difficult. There are no obvious nuances that I think could overcome this problem. The code certainly had the effect of always saying you lose in the MC-10 version I made. I had added a simple cheat for testing, which printed the hidden code at the start of the game. So I could see the right answer. But no matter what I input on the last try, correct or not, I would always be told that I had lost.
I can make a few guesses about why the code might have ended up like it did. The programmers might not have applied my cheating technique to do bug testing. It was an easy thing for me to add when I work with a modern text editor and can easily create subroutines and add and subtract lines in a temporary fashion. But when you were coding with the clunky line editing back in the day, these things were tougher. Also, it is possible that the authors intended to add a routine or line that did the simple test I mentioned, which would return a 5 if the two codes matched perfectly, but then forgot to add it.
I made some changes to fix the lack of a comparison check of the guess and the hidden code to fix the problem. My experience with the software made for the PHC-25 has left me very unimpressed. Another game I converted Labyrinth also had an error in it.
I was able to bug fix that error:
But along with the problems in Fire War, it's a pretty poor record of software reliability. This perhaps help explain why the PHC-25 computer was a market failure. If you are interested in trying the game as it (perhaps) should have run, it can be played here:
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:
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-10s 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:
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:
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.
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.
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
"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.
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.
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:
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.
