According to the Giant Bomb game website "Space Mouse" was created in 1984 as a "type-in" program in the Japanese computer magazine I/O. The following blurb from Giant Bomb regards a modern 2016 re-make of the game in celebration of its 25 Anniversary:
Space Mouse: 35th Anniversary Edition is a deliberately-retro vertical-scrolling sci-fi maze game developed and published digitally by Mindware for the PC on November 8, 2016.
The sixth game in the studio's "Video Game Classics" series, Space Mouse is a remake of the NEC PC-8001 game of the same name, which was originally created by Takanari Suzuki as a "type-in game" for the September 1981 (Vol. 6, No. 9) issue of the Japanese microcomputer magazine I/O.
In the game, players must guide Alice up each floor of a tall building to its roof while avoiding being caught by space vermin. She is under a time limit (with a limited air supply), but can make use of power-ups to smash through walls and ceilings.
This version features numerous enhancements from the original, including smoother gameplay, additional levels, a key/door system, chiptune audio, and redrawn 8-bit pixel art. Additionally, players can play a port of the original PC-8001 version and an alternate arrangement (based on the Sharp MZ-700 series of computers).
If I recall correctly, I made my variation of the game in BASIC back in 2016 too, inspired by some online images I had seen of a version for the NEC PC6001. I somehow (perhaps asking my son to translate some Japanese description) came to the conclusion that the game was by a fellow named "Seiji" from 1983. Perhaps this was simply a NEC PC6001 remake of this "classic" of the Japanese home computing era. But it is hard to confirm the facts of the original game, including the author's name. The site strategy wiki mentions that the author also went by the name "Geimu Kyoujin." But I can't locate the source in the magazine proposed by Giant Bomb to confirm whether it was a BASIC program or some kind of machine language listing.
The date provided in the quote doesn't seem to point to a scan of I/O with an obvious listing of Space Mouse. I even asked my son Charlie, who knows the Japanese alphabet systems, and can use Google translate to do searches, to look for it. Here's the link for where I think the volume can be found on the Internet Archive:
It states in the top corner of the front page that it is Vol. 6, No. 9. for 1981. But I can't find any article in it that would seem to be for Space Mouse. And my son did a search for the Japanese for "space" and "mouse" and only came up for the word "space" in a few adds for space-themed games.
The Youtuber Highretrogamelord provides a playthrough of a NEC PC-88 version of the game:
Space Mouse is a vertical-scrolling maze game. The player controls a cat who is travelling up through an infinite maze. The player gains points as they travel, and the goal is to travel as far as possible. Space mice travel down throughout the level, blocking the player's progress; the player must dodge the mice, and loses a life if they come in contact [with] them. The mice have simple movement patterns but move quickly, and there are often several on-screen at a time.
Space Mouse was released as a type-in BASIC game in a 1981 magazine, and was later included in other type-in software books. A port was bundled with a number of enhanced remakes as a part of Space Mouse 35th Anniversary Edition for Windows in 2016.
He suggests that the original game was in BASIC, but as I said, I have not been able to confirm that. I think his reference to PC-8000 is probably for the original PC-8001 mentioned in the Giant Bomb quote. There seem to be a lot of versions of the game out there, including one for the FM-7 home computer. On the P6ers web site (retro users of the NEC PC6001) there are multiple entries. It suggests that the program has been made available by the author. I think this refers to the PC-6001 version that might have been the inspiration for the version I made back in 2016, but I can't seem to find any video playthroughs for the PC6001 version now.
This site mentions that the game was very popular:
This is a link to a 40th anniversary celebration conference for the PC-8001. In addition to mentioning that Space Mouse was one of the systems most popular games it also mentions Heiankyo Alien. Both are included built for a modern mini-emulator version of the PC8001. Although the game was popular, today this popularity mostly extends to later variations of the game. Once again, we might have an example of a "classic" game that had its beginnings as a humble type-in, maybe even a BASIC type-in, but for which the majority of the historical recollection focusses on the professionally published commercial versions and not the type-in that inspired the entire family of games.
My Recent Update of the Game
I have been editing my version to improve it. I have added key sensing using the PEEKS provided to me by Greg Dionne. They give better response, don't get "stuck" and allow multiple key presses to register, so you can use diagonal directions. I have also added the feature of Power Boosts that move you upwards at a fast rate, including smashing through floors. However, I have made some changes to the backstory. The Japanese call the game "Space Mouse" but it should probably be "Space Mice" because in the original the antagonists are mice moving downward as you try to move upward. You are supposed to be a cat climbing a tower/"building." When you reach the top, you enter a rocket ship and blast off becoming the first cat in space. I suppose the fast moving downward objects are kind of like scurrying mice, but in my version I chose to change the premise. This is mostly because I am using orange blocks for the energy objects that you need to collect as you climb. For technical reasons I want to use orange blocks (they're at the end of the ASCII character list of the MC-10). Orange reminds me of cheese, so I think of the player as a mouse scurrying to the top of the tower chasing a trail of cheese left by workers. Meanwhile, Taby cats living in the tower are trying to thwart your assent. The small orange pieces renew your energy and allow you to continue to ascend. When you have a run-in with a cat, you lose energy. You need one energy unit for each new stage, so don't let if fall too low. If you collect the large orange block, you will shoot to the top of the stage, so don't select it if it makes more sense to simply eat more ordinary cheese blocks on that level.
I was working on trying to port to Micro Color BASIC "Cribbage" in Microsoft BASIC. The program was ported to MS BASIC by Steven Williams from Sheppard Yarrow's original source from Creative Computing (May 1979) and then published in David Ahl' Big Computer Games book (1984). I can't play Cribbage, but my volunteer tester, George Phillips from over on the MC-10 Facebook group, told me it couldn't score runs properly. So I combed the code for typos, compared the original Creative Computing listing and the MS version. The only major typo I could find was in line 560 which read:
It should have read:
The first 2 cards are the computer's discards being assigned to C() from M() done at lines 540 and 550 and the second 2 discards from you are done at line 560 and 570. These make up the "crib" and George reported that the crib was messed up. So, I looked and noticed the asymmetric distribution between the M()s and Y()s being assigned to C().
But besides that typo and a multitude of improperly closed FOR/NEXT loops (which I fixed) I couldn't seem to get the runs search subroutines to work.
So I began digging deep into these subroutines by creating a test-bed routine for just the 3 run subroutine and discovered it was definitely not working. The program has to figure out complex runs like 4,3,2,2,2, which give you 3 separate 3 runs, and the like. Yarrow obviously felt he had an algorithm that worked, but I couldn't get the 3 run subroutine to recognize even a simple run fed to it directly in my test-bed. How could a game published in Creative Computing, and then David Ahl's Big Computer Games in BASIC (conceivably another million seller) be so broken? How could all 3 subroutines break at once?
Well I think I finally cracked it. The sorting before doing the run check subroutines (5,4 or 3), says in the REM comments that it orders in ascending sequence, but it actually does descending. When I turn my test sequences around, the subroutine worked!!!!!!!
George was also doing some looking at the code. As he commented,
Yeah, you'd think that if it had a flaw it would be a subtle one. I took a look at the original code. It looks like it is kinda doing the right thing. Sorting the cards and then looking for a sequence of increasing values. That should find simple runs though it is far from obvious that it handles double runs and the like.
I'd come to the same generals sense of the subroutines. But when I looked at the sorting routine I began to wonder if it really was ordering the list of cards (by values 13-1) in an ascending way. From test input, and the output of the test-bed it looked like the cards were actually going into the subroutine in a descending sequence. You can try it out yourself.
Here's my test-bed routine for the 3 run search subroutine:
10 CLS:S(1)=1:S(2)=2:S(3)=3:S(4)=3:REM** THESE ARE READ FROM DATA IN THE ORIGINAL ONLY ONCE
But if I reversed the sorting (at least by my updated test-bed routine above) it worked!
5280 REM** SORT HAND INTO ASCENDING
5290 REM SEQUENCE
Try an card order like 2,2,3,4,12 or 2,10,11,12,12
I'll let you folks know with an addendum here whether the reversal fixes all of the search routines and whether it is actually able to find double runs and the like.
If folks want to help, the current "fixed" version can be tried here using the online MC-10 Emulator by Mike Tinnes. Select CRIBBAGE from the Cassette menu and then type RUN and hit Enter in the main (green) emulator screen:
I also, on the recommendation of George, added in some "Press ENTER to continue" prompts and the ability to type "Y" at most prompts to have your cards re-displayed. And I altered most PRINT statements to use my 32 character screen width word wrap routine.
George told me that it seems to recognize runs now. Including double runs. Here's one hand he said it scored correctly:
Hopefully, we've got all the major bugs out now....
Nope, Spoke too soon. Looked through subsequent issues of Creative Computing and found a correction by Yarrow in Aug 1979 issue:
I implemented it for the Microsoft version as follows:
2705 IFM5<>1THEN2840:REM CORRECTION CC AUG 1979
I also found this discussion in the Oct 1979 volume:
Several readers have contacted me concerning my
CRIBBAGE program (May 1979) and brought to light three
problems. The first is a real bug: the computer will on occa¬
sion after a “GO” situation, replay a card it has already
played. The correction involves the addition of a line of code
2605 IF M5 <>1 THEN 2730
The second problem is an irrelevant bug in that line 2710
should be 19=VC(B9,1). The lijie as currently written causes
no problem, and may be entirely eliminated. This section of
code is only used when the computer’s hand consists of four
5’s. The correction will cause the computer to play the first 5
in its hand; leaving the line as is or removing it causes the
computer to play the fourth 5 in its hand.
The third problem turns out to be a bug which will appear
or not appear depending on how a particular BASIC language
processes FOR/NEXT loops. Consider the following
3220 FOR L=K+1 TO I
IBM BASIC evaluates the limit of the FOR/NEXT loop
before processing the loop; therefore, when K reaches the
value of I the FOR/NEXT loop on L will not be executed
because I + 1 is greater than I to start. On the TRS-80
however, BASIC evaluates the limit of the FOR/NEXT loop
at the end of the loop and therefore will execute the loop with
L equal to 1+1 which causes all sorts of problems during the
play of the hand. To eliminate this "bug" (?) change line 3220
to read FOR L=K TO I.
No one has rated the game on that site, which makes me wonder whether its "brokenness" meant that people were excited by the game, but ultimately disappointed by its performance and few ever really played it. However, that speculation is frustrated somewhat by another reference I found in Czech computer magazine from back in the day:
A little Google translate done on the article reveals that the bulk of it is simply explaining the rules of the Cribbage to a non-English speaking audience who are unfamiliar with the game. However, there is a small discussion at the end of the Microsoft version:
At the "Remove" prompt, enter a number between 1 and 52 in this space
will remove the package for the cards. The cards in your hand are in the game
numbered 1 - 6, for inputs use the numbers, not in card values. If you are forced to say "GO" write "go" or "GO" instead of numbers and cards.
The computer shuffles and deals the cards, generates a reversed card,
keep track of the score and correctness of the points obtained during the game. He won't let
you go past 31, but he does not check if you have a card that
you could play If you miscalculate the value in your hand or
in the game, you don't have to doubt that the computer calls out mercilessly
The program uses a relatively simple strategy consisting of
the cards whose point total has the highest value are also held.
There are many more sophisticated strategies that you can play with
introduced in a book about card games. Here, however, there is too much
it didn't work out.
Kralupy nad Vltava
Mr. Vltava says "Nice Game" at the end of his review. So obviously there must have been a working version out there that didn't suffer from the catastrophic error of the reversed sorting routine. But I can't find mention of a correction of this anywhere. But I can't see how the source as printed could do anything except reverse the order. It's not a typo by me. Here's the original article.
It kind of make question reality. Maybe my MC-10 and its Micro Color BASIC are part of some parallel universe, in which sort routines work backwards?! If anyone could shed light on this matter, I would really appreciate it if they could leave a comment and put my mind at ease.
The author of the Retroprogammez blog made a nice post about this game. It is an example program from a fairly regular contributor to the French computer magazine Jeux & Stratégie. Garry over on the CASA Adventure forums noted that in terms of items in the CASA database:
The only games I'm aware of from Jeux & Stratégie are 'Nordal le Magicien' and 'La Route de Samarcande'. Both are role-playing games for the Amstrad CPC written by Michel Brassinne.
Garry wasn't sure whether Mission Adventure would be worth translating to English (it might be an RPG given its pedigree). He also pointed out that the source I was working with from Retrprogrammez had been modified by a number of individuals.
1 REM ====MISSION AVENTURE====
2 REM Auteur : MICHEL BRASSINNE
3 REM Jeux & Strategie numero 29 - pages 44-48
4 REM Reprise : DOMINIQUE RIOUAL
5 REM Version : 1.0 du 17/12/2017
6 REM 1.1 : 16/09/2022 - Corrections avec VSC
I can confirm that it is definitely a text adventure, but it is not going to be a historically pristine representation of the original listing. It's unclear what if any "corrections" were made by Rioual or drawn from the follow-up article in VSC (See below). Taking a look at the scan of the original code I couldn't notice anything obvious. But I found that the code still seems to have some bugs, or oddities that perhaps I simply couldn't figure out correctly. There are some uncompleted or redundant (non-operative) lines and a number of other issues.
There is a "candle" listed among the items/objects in the program, but I couldn't find any aspect of the code that would seem to allow a player to find that item. That being said, I did find a reference to an unmentioned single word command. If you typed "LUX" at the "Action" prompt the variable for turning on light in the cave areas would be switched on and the French equivalent (at least according to Google) for "cheater" would be printed. This seemed to be a kluge, perhaps used by Brassine during the debugging process, and maybe he mentions it in the original article. I changed it to a formal "QUIT" command instead.
There is a routine for uncovering a hatch in room 5 of the cave. You "move" the green foam, and then the hatch appears. Then you can open the hatch and see a lead box, which you can also open. Inside is a key. But there isn't any apparent function for the key. The box, however, will turn out to have a use.
The main source of light is to "search" the "uniform" of the skeleton in room 3. You must issue the right command of "look skeleton" to find that he is wearing a uniform. "Search" and "examine" also produce various messages throughout the game, but for the most part the heavy lifting is done by using "look" in combination with an object. That being said, "search" is needed for finding the matches in the pocket of the uniform and "examine" to find a paper in a book-- so standard "guess the verb stuff." Also using "open" or "move" with many objects will produce interesting results.
"Look" normally must be used with any object, but I added the function of a single word version of it redisplaying the current room description and object list, which seemed absent. Otherwise, you might find that you had to leave and re-enter a room to observe it. Normally for most rooms, you need to periodically "light match," to get room descriptions displayed instead of the message "It's pitch black" because most of the adventure takes place deep in a cave complex (only the first few rooms do not require matches).
The main objective is to find the "portrait" in room 15, "move" it to reveal a hidden safe, and then use the hint written on a note found in room 8. The note is inside a book in a cupboard in that room. If you "examine" that book a "paper" falls out, with the cryptic message "U40.W25.U12" on it. I took the "U"s and "W"s to be references to the directions for a combination lock, with German annotations. Google translate produces "Uhrzeigersinn" for clockwise, but "counter clockwise" doesn't" produce an obvious "W" word. But I went with that interpretation in trying to make the combo dial routine work for the safe in room 15. A walkthrough in the next issue of the magazine mentions that the letters should actually be "L" and "R" as "in German (rechts and links)" (the words for "right" and "left"). But the original source definitely looks like "U" and "W". Weird. I left the message as at is. I changed the routine that runs when you "read book" to make the output look more like actual text rather than simply a scoll of random characters. I also added descriptions to make the messages clear that the book is a manual about special "hydraulic safe" installation.
For some reason the safe routine expects that you will reach a final total of 37. But +40-25+12 only totals to 27. I'm not sure if this was a typo or not. Or whether I was missing something obvious. But in the end I changed the number to reach after 3 turns to be 27 not 37. As long as you get the dial to 0, which prompts a restart to your number of turns, then you can get the safe open by ending on 27 after three turns. Inside are a bunch of "Bars" or "Ingots" depending on how Google feels like translating at any particular moment. I standardized on "Bars" and added a few elements to the descriptions to clarify that these are solid gold bars.
Another aspect to the game is that you must carefully choose the number of bars you will try to get out of the cave. If you select more than 3, then a gate will fall at the entrance. If you try to "open" that gate you will be dropped down by a trapdoor to your doom. You can increase the number of bars you can escape with up to 10 if you get the lead box and drop it in the safe. If you do that the hydaulic mechanism will lift the gate. There was no accurate way to report the number of bars. The variable that keeps track of the "weight" you are carrying seems to count other things as well. So I added a dedicated bar count variable.
Another change I made was a better check for whether items are in a room when you try to interact with them. No check was made for whether an item is actually in the room, or your inventory. The only check was that you typed the item name correctly, and that it was one of the items recognized in the game (I changed this check to look only at the first 5 characters-- this allows you to type "light match" instead of "light matches" while still allowing "matches" to be the default item name). The lack of full checking meant that you could issue commands regarding items from anywhere in the dungeon and actions could work. Now you must either be in the room with the item, or have it in your inventory.
I also fixed up the "dropping" and "taking" items routines so that items consistently get dropped in the room you are in, instead of some original room in which you might have found the object containing that item. For example, you could get the skeleton's uniform, take it to another room, search it and then the matches would appear back in the skeleton room. Similarly, if you took the book and examined it in another room, the paper would fall out back in the room where you originally found the book.
Finally, nothing would happen when you got back outside with your loot. I made the game print a message with the number bars you manage to "liberate" from the NAZIs. Also, just for giggles, I added a graphic for the "portrait." It's an ASCII image of der Führer and is displayed when you "look" at the portrait.
Here is my attempt at a walkthrough map:
“Mission Adventure” by Michel
12 Narrow Corridor
13 Narrow Corridor
14 Narrow Corridor
10 Narrow Corridor
11Room (NESW Exits)
15 Room (NW Exits)
9 Narrow Corridor
8 Nearly Empty Room
6 Passage (N.E.S)
7 Slippery (E-W) Corridor
east until Dead End is reached, then W
5 Damp N-S Corridor
4 Dusty Room
(Don’t try leave with more than 3 bars)
3 Dark Room
Map: Jim Gerrie (2023)
Here are some of the details from the follow-up article that was published in the next issue of Jeux & Stratégie translated into English (curtesy of Google Translate):
Solution... of the Mission Adventure game
You had to discover that the cave was occupied by a German soldier (green uniform), who died on July 25, 1944, as the ephemeris indicates, that is to say during the Liberation. The exploration of the central corridor to the north is only possible with a means of lighting. This one is discovered by searching the uniform: a box of matches is there. Each match has a lifetime corresponding to three actions or moves. Then you had to strike a new match to see clearly. In one of the rooms, a portrait is visible. As is often the case in reality, there is a safe behind it. The order to move the painting makes the safe appear. However, you still have to open it.
Looking at the safe, you could see that it has a dial. The combination of the safe was written on a sheet of paper, slipped into the book placed in the cupboard (when leafing through the book, the paper falls out). The letters accompanying the numbers were the initials of the words "right" and "left"... in German (rechts and links). You could therefore turn the button of the safe to the right, to the left then to the right again, the number of notches indicated on the sheet providing the combination. And this, after having reset it. As the title of the book found in the cupboard suggested, it was a safe with hydraulic protection. Indeed, the bottom of the safe is like the plate of a scale, capable of knowing at any time what weight it supports. As soon as it detects a difference in weight compared to that initially indicated, it triggers the fall of a gate which condemns forever the intersection near the entrance. Grid which, in turn, triggers the opening of a hatch as soon as one tries to force it.
Cutting the Lines Several readers have rightly pointed out to us — after having tried in vain to type in the listings for the adventure game and checkers (J & S micro of n°29) — that their machine did not accept 255 characters at the sequence of a single instruction number. It is therefore necessary to cut the lines and to include each of the sections under a different line number. Two cases can arise: simple instructions and tests. Simple instructions can be split into as many lines as there are instructions separated by “:”. For example: 345 A = 2: Z 3: PRINT "ACTION —" T can become 345 A = 2. 346 Z = 3. 347 PRINT "ACTION -" T. Care must be taken when it comes to testing , i.e. lines of instructions where there is an IF THEN, because if what follows the IF is verified, then everything after the THEN will be carried out. If the condition following the IF does not hold, then nothing following the THEN will be read, and the program's read pointer will jump directly to the next line. You must therefore split the test in two, or even divide it into as many successive tests as necessary so as not to exceed your capacity of signs per line. Let's take the following example: IF A = 2 THEN B = 3 : C = 4 : D = 5 :.../... Z = 27. This test modifying the value of all the variables from B to Z will be much too long for one line of instructions. So you can do:
340 IF A = 2 THEN B = 3 : C = 4 : GOTO 350
345 GOTO 1000 (case where A is different from 2)
350 IF A = 2 THEN D = 8
5: E = 6: GOTO 360 355 GOTO 1000 Another way to proceed, this one faster, by reversing the test:
350 IF A < > 2 THEN 1000
360 B = 3: C = 4: D = 5: F=6
370 G=7: H=8: I=9: J=10 etc.
If A = 2, the pointer does not jump to 1000 and reads all lines that follow the test. Reversing the test is often the most practical procedure. NOTICE NOTICE NOTICE Adventure game on Commodore Philippe Peltier, from Juan-Les-Pins, tells us that owners of Commodore (Pet, Vie. 64) must very slightly modify the program proposed in J & S n°29, page 44 to respect the syntax of the Commodore, otherwise it is guaranteed to crash. It is particularly necessary on this machine to concatenate (paste!) a space at the end of the string A$, otherwise MID$ (A$, I, 1) will cause a “BAD SUSCRIPT ERROR” when it reaches its maximum value. On the other hand, there is memory loss of the loop pointer because of the ON T GOTO in line 1 100. Here is the remedy proposed by Philippe Peltier:
Another fix I made was to the parser. The French language parser was actually a neat variation of the standard English 2-word parser. Because of the standard use of definite articles with all nouns in French, it was actually a 3-word parser. "POUSER L'ARMOIRE" for example, would be the standard command structure, with the directive verb form followed by the definite article and then the noun. This meant that the parser had to search not only for spaces between words, but also the apostrophe, for contractions between article and noun, as in this example. Took me a bit to twig to that before I realized I had to modify it to the English 2-word format. It is interesting in the original article to read Brassine's comments on the origins of the "text adventure" game form. He attributes it to American college students and mentions Colossal Cave "Adventure" as a founding program of the genre. It obviously took until 1984 for this type of game to start to become more common in France and Brassine felt he was helping to introduce it (and modify it as necessary) to a French audience. Another example of this is the need to include gendered indefinite articles for the objects (UN, UNE, DES). It provided an interesting case study for seeing how one culture appropriates the technological practices of another. And a fun little adventure to boot once I got it working.
In a 2000 post, Jeremy Raynor claimed that this is the first ever Doctor Who computer game. It took the form of a 3 page of listing in the March 1983 edition of the British magazine Computer and Video Games. Like Jeremy I typed it in. However, as I did so I converted the code to Micro Color BASIC from the original Atari 8-bit BASIC code. The original version seems to have had a creeping memory fault, which eventually corrupts the redefined character set, used in the game for all the onscreen graphic objects. Jeremey asked if anyone out on the Net, who was good at debugging BASIC, could figure out the problem. I think I have.
There were lots of un-RETURNed GOSUBs. A central room movement handler routine called by the main loop would GOSUB to the various different room description and character movement subroutines. But then sometimes Guggenhiem would use a GOTO to return back to the main loop, other times the room handler would be called *again* by room character movement routines when the player left those rooms. This would leave GOSUBs uncompleted or add further GOSUBs (recursively using the room handler jumping routine again). The stored memory addresses for each RETURN would pile up in stack memory somewhere. Eventually that stack would accumulate enough unhandled addresses that it would begin to cannibalize the area of memory used for the redefined characters. Guggenhiem himself was aware of the problem and in the original article said it could occur after "15-50 games," but he couldn't figure out what caused it.
It is strange that it would occur across multiple games because Guggenhiem uses RUN to restart the program at the end of each game. However, he also redefines some variables at the end before issuing the RUN command so I suspect that Atari BASIC doesn't necessarily clear all memory and variables back to null when a RUN is issued. Perhaps some special clearing command needs to be issued to get a true cold start. This is different from Microsoft BASIC where RUN reinitializes pretty much everything (string spaces, numeric variables, FOR loops and their return address, GOSUB calls and their addresses, etc.)
I basically had to resolve this problem by getting rid of the use of GOTOs to jump back to the main game loop. Instead, what I did was create a kind of pseudo "recursion" feature in the main program loop which calls the room handler (itself a subroutine). When the room handler routine GOSUBs to a different room routine it increments a counter. Then instead of jumping directly back to main loop, if that subroutine calls the room handler routine again to go to another room, the counter gets incremented. An IF statement checks after each call to the room handler routine. If the counter is not zero a RETURN is issued. This will return the program to the room handler routine. That routine then decrements the counter and issue a RETURN (which takes it back to the room handler again) until the counter is zero. At that point a final RETURN is issued returning control the main loop, which had made the initial call to the room handler. At that point all the RETURNs have been cleared, and a fresh call is then made to the room handler routine to put the player into the correct new room. New calls might be made from that routine (an attempt at recursion) but each time a return is issued a cascade is triggered eventually returning control to the main loop, allowing for a fresh call to the room handler and the next desired room. All this had to be done to eliminate the use of GOTOs and prevent any buildup of unresolved recursive calls to the room handler subroutine.
I made a few changes to the game to make it more in keeping with my understanding of the character of the Doctor. The original game called for the use of a ray gun to kill the Master. My understanding of the Doctor is that he never uses violence (God love him). So I changed it so that the ray gun is "broken." The player must figure out what to do with it so that the Master will end up trying to use it against the Doctor, resulting in its malfunction, which will kill the Master by his own hand. Similarly, the player must avoid the deadly snake rather than kill it and find a way to ward off the deadly Sphinx rather than kill it. I've added one red herring item to slightly increase the complexity of the puzzle. Mishandling that object adds to the dangers that the Doctor' must face in the already dangerous maze/pyramid he is exploring. I also added a rogue/lost Dalek to the monsters that must be faced.
Of course, instead of character graphics as in the original, I had to create new semigraphic images using semigraphic 4 characters. These take the form of 2X2 character blocks (4X4 semi-graphic pixels), which makes for a 16X8 map screen. I think the Atari game used some kind of double-width character mode, because it seems to run on a 19X21 grid, so the difference between the two screens is not too great. The countdown clock is just a decimal variable decrementing counter used by all routines. I had to shorten some of the messages because of the smaller screen of the MC-10. Messages are printed in the "wall" spaces, since there are no spare lines at the bottom of the screen as in the Atari version. I used Greg Dionne's key PEEKs to get 8-way movement from the AWSZ keys used singly or in various combinations with each other.
Contrary to what Rayner suggests, this is not the first Doctor Who game. I have converted a text adventure by James Smith from 1982:
But it is perhaps among the earliest. It's a fun little graphic puzzle game with some minor arcade elements. Actually, I find it hard to characterize its genre exactly. I wonder whether it is an early example of a hybrid genre of graphic-puzzle-adventure games. There is definitely a story, including a detailed backstory from the original article, but also the story unfolds in the game itself as the puzzles are solved and the graphical "dungeon" (pyramid) is explored. So I didn't know whether to put it in my "Arcade", "Text Adventures" or "Puzzles" subdirectory. But I eventually decided all the movement and visuals, and need for some quick reactions make it more of an arcade-style game. Certainly the use of the joystick in the original speaks in favour of this conclusion. In any case, here is the directory where the source can be found:
This one is a bit of a mystery. I went looking for some early source of a Gin Rummy game. I wanted to add this popular card game to my list of early attempts at BASIC AI opponent programming. I first stumbled across a reference to a game for the Atari called Gin Rummy 3.0. by Manhattan Software. Some sites, such as the Giant List of Classic Game Programmers, designated the programmer as S. Silverman.
I have found converting programs from Atari BASIC difficult in the past. The emulators are complex and the BASIC is somewhat different from Microsoft versions of BASIC. So I went looking for something by Silverman or Manhattan Software for the TRS-80. This lead me to some BASIC source for Gin Rummy 2.0, which I was able to convert fairly easily to TRS-80 Micro Color BASIC. The TRS-80 Model I/III has a 64X16 character screen so conversion mainly involves taking PRINT@ screen location values and dividing them by 2. That gives you the rough equivalent for the PRINT@ value for the MC-10's 32X16 screen. Then all you have to do is condense the length of messages by about a half to get everything to fit on a MC-10 screen.
Here is the TRS-80 Model I/III main screen:
Here is the TRS-80 MC-10 main screen:
You can see how the prompts have been shrunk. Also, the representation of the cards was switched from full text descriptions to two characters. The face cards become letters, as does the ten and Ace, which become "T" and "A" respectively. Otherwise the values are simply a number. The suits also just become single characters. I separate the two with the standard suit colour of red or black character to help identify the suit and to separate the card value from the suit more clearly. This is a much shorter way to identify the cards, which really helped with the confined screen space of the MC-10.
The real problem came with the program itself. The program contains a large number of unclosed FOR/NEXT loops. Silverman uses multiple such loops to do searches of the hands, and then simply jumps out of them when some sought after value is found. The program then just continues execution by GOTOing to some location after the FOR/NEXT routine. However, in one place (600-740) the author actual goes from in the midst of two nested FOR loops, to a subroutine and then GOTOs back to the NEXT of the calling loop. It does this in two different FOR/NEXT routines. To continue those routines it uses an IF to GOTO back to the NEXTS of the different calling routines. Or if a search item is found it simply continues with execution after those routines and the subroutine. All these crisscrossing FOR/NEXTs get the Micro Color BASIC interpreter confused. Especially if it comes across a NEXT that doesn't have a specific variable attached to it. So occasionally I would get a NEXT without FOR error, which indicated that the interpreter was putting the program back into the midst of the inner loop of the nested FOR/NEXTs, but without initializing the outer FOR, perhaps because that loop and its variable had been reinitialized elsewhere in the code's meanderings. It was a real mess.
So I tried to add proper exits to some FOR/NEXTs in a few places where I though this would help. I also entered in a few dummy loops at the start of the offending section of code. This is a way to ensure that all the FOR/NEXTs get reset before they are utilized again. Finally I put the appropriate variable on every NEXT command in the program, so there is no possibility for a NEXT to trigger a return to an unclosed loop. By doing all this I was able to eliminate the error and I was able to remove an ON/ERROR kluge command that Silverman had obviously used to recover from the error.
590 ON ERROR GOTO 600
600 RESUME 610
There was also a simple typo in a FOR/NEXT loop:
I changed this to 3360 FORX=(C+1)TO11, as 11 was common search value. O111 would just be interpreted as an undeclared variable and simply return a zero. So the loop would only be run once.
It was Greg Dionne who let me know about this bug, after I asked folks on the Facebook group for the MC-10 to have a look at the program. He used his BASIC compiler to check for undeclared variables. I had noticed before he made his bug report that sometimes the program would miscount the melds in my hand. Occasionally, a meld of 4 items like JH,JD,JS,JC would only count three of the items (It might also have done this on a 3 item meld but I can't precisely recall if this was something I spotted early in my testing or not). I had hoped that Greg's fix would be the fix to this problem, but after much play testing it occurred again on a 4 item meld of Jacks. It only happens very occasionally. I've checked the code for typos I might have entered, and don't think it is a result of any change I made. I think it might be related to the special search (See the REM about "hidden meld") for whether a card is playing a role in a meld or a run. That is to say, the program has to distinguish between if you are using a card, say one of the jack's above, as part of a run, rather than as an item in 4 meld. It certainly can count 4 item melds, but I need to generate multiple game conditions where I can test this hypothesis, which takes a long time. And the code is so spaghetti that it is really difficult to get a sense of what is going on. It's also possible that a rule I'm simply unaware is what is causing the problem, or some nuance in the code conversion that I have overlooked. I'll have to play the original TRS-80 on an emulator to see if the error occurs there too.
In any case, I've created a kluge work-around. If on the SCORE SHEET screen you type 'C' at the "Another Hand" prompt you are given a chance to type in new values for the final scores for the player and the computer that are listed. That way, if you notice the error, you will at least have an opportunity to make a manual readjustment to the scoring tally and keep playing. I think Silverman might have been aware of these errors and worked to fix them. You can see the program being modified to work on different computer systems, but also increasing in version number. The TRS-80 version is labeled 2.0." The Atari version is labeled "3.0." And there appears to be a PC version labeled "4.0."
TRS-80 Version Ad
Atari Version Ad
I hope that I might be able to figure out some day how to get my hands on the Atari source code for 3.0. Then I could look through some of the search routines for analyzing the hands for changes to the code. I have searched but can't find any copy of the PC version. I might also continue to search for the bug myself. But in the mean time, I would still agree with the rhetoric of the ads that Silverman's code does play "a strong game," and thus represents an interesting part of early BASIC AI opponent programming. Of course that is an assessment of someone who'd never played Gin Rummy before this porting exercise. So I only have Gin Rummy 2.0 as teacher (and some reading on Wikipedia) upon which to base my assessment.
I went back and added a few more dummy FOR/NEXT loops just before the hand checking routine. I'm not sure if this might have fixed the problem with rare miscounting melds, but I haven't seen any for some time. I also added colourful graphic cards that somewhat emulate the cards which can be seen on the Atari version. I have changed the version number to 2.5 to reflect this slight updating. I also fixed up the Score Sheet screen to format the numbers properly via right justification. The original used the PRINT USING command, which I had to emulate by the use of STR$(num var) and RIGHT$ commands to get things properly lined up. Here's a vid of the new look:
I also think I might have stumbled on a possible explanation of the miscounting of melds. The computer seems to prioritize RUNs over melds in its analysis of hands, such as can be seen in my hand in the following pic of the computer achieving Gin! I might not have recognized this in my early play testing as I was still learning the game.
And I think I found some other bugs in the program. The routine that prevents you from discarding the upcard you picked up before knocking, didn't do the same variable resets before returning you to line 80 as other checks did (e.gs. knocking with more than 10, lying about your knock points). This seemed to cause some catastrophic weirdness. So I changed it to mimic the resets of the other check routines. Also, you can now type -1 at the discard prompt after knocking, to back out of that routine. I found that I could knock right at the start of the game and it would allow me to discard any card and input any knock count under 10, and then reward me with 25 points, even though it reported that my unmatched cards and the computer's were both zero. So I made a distinct check for this condition, and then display the warning that you have knocked with more than 10 knock points. It then does the resets and returns you to your hand.
Computer Got Gin!
Me Got Gin!
P.P.S. I did catch the game miscounting melds again. I had 3 aces, which the computer simply ignored in its count. My new hypothesis is that the error may have something to do with the discarding of the 11th card. In this case I might have had 4 aces, and been forced to discard 1. Then something in the counting of this 4-meld and then the checking for the possible use of 1 of the cards in the meld being used instead in a run goes wrong. Somehow the re-check for the 3-meld does not get done correctly. I think what happens normally is that melds are found first, then runs, but if knock counts are different, then 4-melds are blanked, and then checks for runs are done again. Then the meld checks are done again. Or something like this. But something is screwing up in very rare circumstances, and I think what makes them rare has to do with the 11th card (the one the player is forced to discard when they knock). Which raises another issue, I'm unsure how 11-card Gin is handled for the player. There is a message and a flag variable for the computer getting such, and some code to display the 11th card, but there doesn't seem to be anything like this for the player. Sadly, I think I will have to leave this one with some extant errors. I've created a special version GINRUM25_15.TXT that prints an error message and returns you to your hand if your knock count doesn't match with the computer's check of your count. This will give me some ability to re-try after moving cards around. But I don't think this will help much as the checking routines probably check the cards in their original slate orders of value and suit (by way of pointers) rather than the actual cards of the player's hand.
I have created three programs for the BASIC 10-Liner contest using Micro Color BASIC for the TRS-80 Micro Color Computer aka the MC-10.
SMASHUP (for PUR-120)
This program is a simple simulation of a smashup derby. You are the green car. The aim of the game is to hit the other cars. Unless you are willing to risk driving head-on in the hope that your move/turn is timed as the last before the two colour blocks connect, the best strategy is to try to hit the other colours from the side as they pass in front of you. this takes good timing. If your timing is off and you drive in front of the oncoming colour block, then it hits you and you lose a life. 3 hits and you're out. But if you hit the other car you get a point. There is a time limit. Your score is the number of hits achieved within the time limit. A high score is displayed and you can then choose to play again.
Movement Keys: AWSD
VOLCANO (for Extreme-256)
This program involves flying your helicopter over a erupting volcano to retrieve a trapped person "Y" on the other side of the volcano. Avoid the rocks flying out of the volcano. You can only take 3 hits, then you are dead. Land on top of the victim to collect them. When you do so, another person will appear on the other side of the island. You must fly back and retrieve them. Continue to collect as many people as you can. You must be careful when landing. The ground will not stop your descent. You must land gently and not simply hit the ground relying it to stop your descent. How many people can you save before your craft reaches its limit? Lives are printed in the bottom right. Your score will be printed next to your helicopter after your last hit.
Use the Cassette menu to select SMASHUP or VOLCANO and then type RUN and hit Enter in the main (green) screen. Or you can type LIST to see program. However, here are the program listings:
0 DIMT,L(8),D(8),V(8),C(8),R,I,J,K(255),H,Q,V,M:V(1)=-1:V(2)=-33:V(3)=-32:V(4)=-31:V(5)=1:V(6)=33:V(7)=32:V(8)=31:GOTO7 1 SOUND100,1:S=S+1:PRINT@480,"SC"S"HI"HI;:ON-(S<HI)GOTO5:HI=S:PRINT@480,"SC"S"HI"HI;:GOTO5 2 POKE49151,64:POKEL(T),134:L=L-1:PRINT@496,"LIVES"L;:POKEL(T),137:SOUND1,1:ON-(L>.)GOTO5:GOTO6 3 Q=2:FORV=1TO350:FORT=.TO7:IFPEEK(L(T)+V(D(T)))=.THEND(T)=RND(8):GOTO5 4 POKEL(T),H:L(T)=L(T)+V(D(T)):I=PEEK(L(T)):IFI>HTHENIFT=.ORI=RTHENON-(T=.)GOTO1:GOTO2 5 POKEL(T),C(T):NEXT:D(.)=K(PEEK(Q)ANDPEEK(J)):NEXT 6 FORT=1TO10:SOUND99,1:NEXT:PRINT@496,"TRY AGAIN?";:FORI=0TO1STEP0:Q=ASC(INKEY$+CHR$(0)):I=-(Q=89ORQ=78):NEXT 7 CLS:PRINT@452,"smash up! BY JIM GERRIE":V=32:H=128:I=16:J=17023:R=143:K(65)=1:K(68)=5:K(87)=3:K(83)=7:S=0:POKE16925,0 8 POKE16926,1:M=16384:FORT=MTOM+479:POKET,.:NEXT:FORT=1TO13:?@V*T+1,"€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€";:NEXT 9 FORT=0TO7:D(T)=RND(8):C(T)=R+T*I:NEXT:FORT=0TO7:L(T)=M+261+3*T:POKEL(T),C(T):NEXT:L=4:ON-(Q<>78)GOTO3:END 10 REM 1 1 1 11 REM 1 2 3 4 5 6 7 8 9 0 1 2 12 REM789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 13 REM smash up! JIM GERRIE 14 REM 2023 10-LINER CONTEST 15 REM USE: W 16 REM A S D 17 REM YOU ARE THE GREEN CAR. 18 REM SMASH INTO THE OTHER 19 REM CARS, BUT DON'T LET 20 REM THEM SMASH INTO YOU. 21 REM THERE IS A TIME LIMIT.
Both programs use PEEK and POKES to place the player objects on the screen and to check for collisions between objects. Key sensing is also achieved using PEEKs for speed and for continuous input sensing rather than the single key press sensing of INKEY$.
Volcano uses a large number of PRINT statements with the graphic of the volcano to refresh the screen. It also uses the RESET command (line 7) of Micro Color BASIC to plot the exploding debris from the volcano. The POINT command is used to determine if a RESET space is clear.
In both programs ON-(A=B)GOTO2 constructs are used instead of IFA=BTHEN2 to allow for multiple branches to be packed onto a single line. For example see the end of line 9 in Smashup.
ERII (for SHAU category)
This program simply presents a memorial image of her Majesty Queen Elizbeth the Second. It uses a special screen mode of the MC-10 to get 9 colours rather than the regular 8. One of those colours works better as a skin tone. This program is for the SHAU category.