"Cribbage" in Microsoft BASIC by Sheppard Yarrow (1979)

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:

540 C(1,J)=M(I1,J)

550 C(2,J)=M(I2,J)

560 C(3,J)=M(I3,J)

570 C(4,J)=Y(I4,J)

It should have read:

540 C(1,J)=M(I1,J)

550 C(2,J)=M(I2,J)

560 C(3,J)=Y(I3,J)

570 C(4,J)=Y(I4,J)

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

20 REM** INPUT CARDS

5375 FORC1=1TO5:PRINT"CARD"C1;:INPUTM$:W(C1,4)=VAL(M$):NEXT

5380 FORC1=1TO5:PRINTW(C1,4);:NEXT:PRINT:PRINT:REM** PRINT CARD SEQUENCE

5400 GOSUB5700

5410 PRINT"END":END

5700 REM** CHECK FOR A 3 CARD RUN

5710 FORL=1TO3

5720 D=W(L,4)-S(1)

5730 FORI=1TO3

5740 S(I)=S(I)+D

5750 NEXTI

5760 FORI=1TO3

5770 PRINTW(L+I-1,4),S(I):IFW(L+I-1,4)<>S(I)THEN5820

5780 NEXTI

5790 REM** A 3 CARD RUN

5800 P=P+S(4):REM** INCREMENT SCORE

5810 PRINT"RUN FOUND":RETURN

5820 NEXTL

5830 PRINT"NO RUN FOUND":RETURN

Here's the original sorting routine:

5280 REM** SORT HAND INTO ASCENDING

5290 REM  SEQUENCE

5300 FORI=1TO5

5310 FORJ=1TO5

5320 IFW(I,4)<=W(J,4)THEN5360

5330 K=W(I,4)

5340 W(I,4)=W(J,4)

5350 W(J,4)=K

5360 NEXTJ

5370 NEXTI

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

5300 FORI=1TO5

5310 FORJ=1TO5

5320 IFW(I,4)>=W(J,4)THEN5360

5330 K=W(I,4)

5340 W(I,4)=W(J,4)

5350 W(J,4)=K

5360 NEXTJ

5370 NEXTI

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 an online MC-10 Emulator:

https://archive.org/details/@james_gerrie

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.

ADDENDUM

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:

2710 IFC<>1THEN2840

2705 IFM5<>1THEN2840:REM CORRECTION CC AUG 1979

2720 FORJ9=1TO4

I also found this discussion in the Oct 1979 volume:

CRIBBAGE Debugged 

Dear Editor: 

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

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

3210 FORK=lTOI 
3220 FOR L=K+1 TO I 
...
3270 NEXTL 
3280 NEXTK 

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. 

I couldn't find any mention of the correction of the problem with the sort routine I discuss above.  Which is weird.  But I did notice a reference to the game on a database of video games site: https://videogamegeek.com/videogame/247086/cribbage-1979

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:

http://zxm.cz/zxm/1991-3.pdf

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:

-------------------------------------------------- -------

*** PC version specifics ***

-------------------------------------------------- --------

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

"MUGGINS".

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.

Nice game

TOPSOFT

Kralupy nad Vltava

1987

==============================

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 makes me 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.

"Mission Adventure" by Michel Brassinne (1984)

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 of 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 Brassinne (1984)

12 Narrow Corridor	13 Narrow Corridor	14 Narrow Corridor
10 Narrow Corridor	11Room (NESW Exits)	15 Room (NW Exits) -          Portrait -          Safe -          Dial (R40,L25,R12) -          Bars
9 Narrow Corridor	8 Nearly Empty Room -          Wardrobe -          Book -          Paper -          (Code: R40,L25,R12)
	6 Passage (N.E.S)	7 Slippery (E-W) Corridor -          Move east until Dead End is reached, then W
	5 Damp N-S Corridor -          Foam -          Hatch -          Box -          Key
4 Dusty Room -          Calendar	2 Crossroads -          Gate (Don’t try leave with more than 3 bars)	3 Dark Room -          Skeleton -          Uniform -          Matches
	1 Start -          Entry -          Exit (to win)

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:

1000 IFX=OTHEN370

1010 00SuB1230 1020 IFY.OTHEN370

1030 011SUB1300 1>340 GOT0370

1050 REM========

1060 IFRIOHT$KR$,U="3"THENF=1

1077 1071 RṢ. -R$+" 1020 

1090 IFEe=CHR$(32)ORE$=CHR4(39)THENT=T+1 ri0T01130

1100 ONTOOT01130,1120 

1110 Ve-VS+1 ; e:GOT01130

1120 Ne-,N.e+B $ 1130 I=I+1

http://fr.1001mags.com/parution/jeux-strategie/numero-30-dec-84-jan-1985/page-112-113-texte-integral

My version of the game can be played online at the following: https://archive.org/details/@james_gerrie

Addendum

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.

"Doctor Who Adventure" Jeremy Guggenhiem (1983)

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:

https://github.com/jggames/trs80mc10/tree/master/quicktype/Arcade/DocWho

The game be can played online using a TRS-80 MC-10 emulator here: https://archive.org/details/@james_gerrie