"Stellar Odyssey" by Nick Marentes (1982)-- A Conversion Odyssey

I was watching The Coco Nation live stream stream show the other day, when somehow the conversation got on to Nick Marentes' first game "Stellar Odyssey" I was intrigued to hear that the game was mostly BASIC. I think Nick mentioned that it was a hard game to get running on emulators because it was designed in the form of three tape files. The first was a loader program that poked M/L language routines into memory. The the main program was then loaded and run.  Finally a save game file was loaded to get you off and running, either from the initial starting point, or some other point that had been saved while playing. This system was used to save memory on the limited 16K of space of the early TRS-80 model 1 computer. Nick noted that it was unlikely people would bother to give the game a spin these days because of these complexities.  I think Curtis suggested that it might be nice if someone could convert it to Coco.

I immediately typed into the chat to volunteer, since this is precisely the kind of program I love to convert. The program sounded intriguing. From the description Nick provided and subsequent investigation, I learned that the game uniquely combines elements of the text adventure genre, the RPG genre, rogue-likes, graphic adventures, and arcade animation. I searched online to see if I could find a copy on one of the TRS-80 sites I know, but I realized it wasn't listed in any of the usual places. So I asked in the chat if Nick would share his source code.  He generously agreed, so I sent him and email and he responded with the three files.

My first challenge was to try and load the files into my Model 1 emulator. For some reason this would not work. In the course of trying to figure out why, two things happened.  I somehow ruined my Model 1 ROM that I was using with the emulator, so that it stopped working. The second thing was I re-discovered forgotten knowledge I had once had about the different speeds that cassette files could be saved and loaded with on the TRS-80.  I think Nick's files were probably saved using the low speed setting and that I needed to type "L" at the Cass? prompt that TRS-80 Model 1s with Extended BASIC start up with.  But by this point, this knowledge didn't matter because my emulator was fried, and I had to go looking for either a new ROM or a new emulator. 

I came across an interesting online TRS-80 emulator that had some nice file handling utilities built in.  Using it I was at least able to view the files and extract the ASCII text of the main BASIC program file. Once I had that working I could begin examining the code. I couldn't run the whole program though because the emulator would only allow one file at a time to be drag and dropped on it. So I couldn't load Nick's loader program, and then have it load the main program, and then the game file to start the game. But not being able to run the program was not my chief worry. By just examining the code of the main program I was starting to suspect that the loader program might not just contain M/L routines to handle sound generation (as I had hoped), but that might also handle drawing the walls of the maze-like ship that you explore. I could tell that the USR calls spread throughout the main program were mostly of a type USR(0) to USR(255), which appeared from the BASIC routines to be doing something roughly equivalent to SOUND command-like stuff. Swapping the USRs for many such instances created the typical kinds of effects I also use in games using SOUND, so part of the mystery of the M/L USR calls was solved.

But there were some calls with values other than 0-255 (they appeared to be memory addresses). These were usually preceded by or connected with POKE commands to specific areas of memory. Some of the USR (0-255) type calls also had POKEs connected with them, but I guessed that these were simply fiddling with the pitch or length of the sounds being produced for certain sound effects.  But the ones relating to memory addresses were, I guessed, communicating info about rooms, so that a specific one could be rendered. There were a lot of rooms (86), and I began to despair that I would be able to port the game.

Then Canadian Thanksgiving happend and my software engineer son Charlie came home from Halifax.  With his help I was able to view the bits of integer DATA from the loader program. I was able to guess by the length of that data that each room was composed by 5 single bytes, with the bits of each byte being used to render the 7 horizontal spaces of the 5 rows of each room. Then my son was able to craft an elegant algorithm in BASIC (with his old man's help with the archaic language) that would render the byte numbers into a stream of zeros and ones to print 3X2 blue blocks or black semi-graphic spaces to create the rooms on screen. Then we just had to extract the data from the loader program and put it into my slowly evolving Micro Color BASIC version of Nick's main program.

At this point we descended into Unicode Hell. I asked Charlie to create a Javascript routine to take the bytes from the loader program turn them into characters and break them into the 5 character strings for each room. First, the Javascript compiler wouldn't recognize some of the bytes generated from the code as ASCII because it insisted on translating some (sometimes all) of them from UTF-8 to two byte UTF-16 codes.  It was a monumental struggle informing ourselves and navigating these processes that occur behind the scenes in the Windows environment. So many landmines tripped over. Just switching between Notepad (Charlie's preferred editor) and Wordpad (mine), caused what felt like endless confusion. There was much hair pulling and debate about what was going on, but we finally figured it out and got what appeared to be a clean stream of 5 byte strings to render each of the 86 rooms. I say "appeared" because we seemed to have a few extra bytes. Two to be exact.

Then we descended into Micro Color BASIC text handling Hell. The BASIC Interpreter in the MC-10 and the Coco doesn't like dealing with characters below 32. And even some characters above that range have problems.  ASCII 32, for example, is always being hot swapped for a light green character 96 in the printable character set.  Others can't be typed in from the keyboard and are annihilated by the interpreter when they are "quick-typed" in.  Some of the graphic characters above 128, cannot be displayed in Windows editors and "disappear" when working with them. This meant we couldn't just easily create plain text strings to economically store the room DATA. But by translating that DATA into raw list of integers, and then rendering those as rooms, we at least were able to create a utility (ROOMS) to examine the maze. Most rooms looked okay, especially early in the list. But some of the later rooms looked messed up and didn't link up with other rooms properly. Those "two extra bytes" were clearly affecting things at certain points. But the real problem was that using raw numbers in DATA statements would require too much memory to work with Nick's main program. It was fine for a utility to just examine the map, but not for the game. We had to translate the data into CHR$ commands for some of the problematic bytes concatenated with strings of regular characters. Once again my son's Javascript (with another slight foray in Unicode Hell) was able to automate the process.

Then my son went home, and left me to figure out the extra two byte problem. This simply required using the evolving ROOM utility to explore the map and make guesses where the list of bytes had become misaligned by the rogue bytes. In the end there were not just two extra bytes, but also a few incorrect bytes.  As I said, the space character does not play nicely in the way the Color BASIC Interpreter handles it. So there were two rooms that I had to find close binary approximations to ASCII code 32. I think room 48 was one of these.  In the end I was able to get all the rooms of the maze to properly connect up as I believe they did in Nick's original.

In the course of working on the rooms, and in examining and working on the main game code, I was able to begin to create a solution map of the evolving MC-10 version of the game.  I slowly was figuring out the puzzles and the clues (variables used in the save data were a great help here). I was creating lower res Colour equivalents (64X32) for Nick's higher res (128X48) semi-graphic characters and animations. I like to think that in making conversions from TRS-80 to MC-10 there is an acceptable trade off between added colour versus lost resolution. But I don't know if Nick would agree.  But I think I've done the best that I can in rendering the game elements in a MC6847 environment. But I wish some folks would take the game for a spin, and offer constructive criticism to help improve it if necessary.

The process of translating the screen took more trial and error than I normally have to do for TRS-80 to MC-10 conversions, because the lower resolution of the MC-10 (32 versus 48 in the vertical) forced the title block at the top to have to be 3 lines, instead of two, to properly render readable letters of the game title. This meant everything on screen was pushed down by 1 row.  So instead of just taking all PRINT@s and dividing them by 2, I actually had to calculate the location of each PRINT@ and screen POKE and PEEK command. This would have been necessary eventually anyway, because I soon realized the game would just barely fit into the 20K of memory of an expanded MC-10. In other words, no simply using a divide by 2 kludge. Of course, in the emulator I could just turn on extra memory until I could get the program properly "slimmed down."

As I played the game I began to suspect that Nick's expectation of player expertise and persistence may have been set just a bit too high. As a programmer, I have sometimes come to have overly high expectation of players. You live with a program so intimately as a coder that you know all its nuances and secrets. This can incline you to make a game more and more challenging so that it can maintain a challenge for you.  As I played the game it appeared to me that the aliens, who begin to attack you above room 14 (there are two other main levels/areas of the map-- see above), come so often and with such intensity that I couldn't actually get through the map to the end without saving the game at the end of every screen to preserve my health and life. I had to resort to programmer tricks so I could test features, such as breaking out of the game, modifying the room number variable, entering "CONT" and zapping myself immediately somewhere I wanted to go.

So, I added difficulty level selection at the start of the game and nerfed the RNDs used for combat elements of the game. I have now played though on level 1, but if you choose level 3, you will be playing on an unadulterated Marentes level of play. The final win screen now also reports which level you are playing at. I also added to the clue provided by Nick (he has at least one clue for every puzzle) for solving the final puzzle. It makes it a little more apparent what you must do.  Otherwise you will likely have to die several times and restore from a saved game before you can figure out the final puzzle. Finding that clue is pretty tough and it will still require some careful interpretation. I also added a clue to another puzzle, to help you find a needed object a little more easily. I really would like some folks to try playing the game on the tougher levels (and without my map above) and to hear some feedback about whether I have nerfed the game too much.

The old clue.

I also changed the game save and load features. The original requires you to load a game at the start of each launch of the program. The standard "gamefile" just stores the ordinary starting details. Then you could just save new files, to start at different points in your progression through the game and load those instead. I chose to hard code the starting details and begin the game with those every time.  Then, if you want to save or load you simply choose "Q" to go to a file menu for these actions.  You can also restart the game from that menu, hence the "Q" for "quit" key choice.  You have to hold the Q down slightly to launch this menu, as it uses a different method (PEEKing the keyboard roll-over table)  rather than INKEY$ used for commands entry. This is a good thing, because it helps prevents triggering of the menu if you just brush the key. I also changed a few other keys. I switched the "V" key command (Verbs) to what I feel is a more standard "H" for help screen command. Since the normal MC-10 right arrow "S" key is used for the "Sprint" command, I used the < > keys (i.e. the comma and period) for TURN LEFT and TURN right commands. The other commands should be the same as the original and are listed by the "H" command. I should note that on Nick's web page it mentions one of the commands being "Attack" conceivably using the "A" key, but the command I found in his sources code was "F" for Fire.

I hope that I can take this completed program and convert it to Coco BASIC, but realistically, I don't think this will happen until Christmas. Once again, I had Charlie try to create a Javascript program to consistently convert all the raw semigraphic-4 characters embedded in strings into CHR$ and STRING$ commands as appropriate. But once again we descended into Unicode Hell, with some characters just not being sensed or sensed correctly. It is simply too daunting a task to think of doing this manually. But once we figure the graphic character conversion issue out, then I can simply manually translate the lines which the Color computer requires spaces to be inserted before command keywords, that the MC-10 interpreter doesn't have trouble with:

FORA=B_TOC_STEP

IFA_ORB_THEN

IFA_ANDB_THEN

I will also have to switch the CLOAD*array commands and CSAVE*array commands to Coco equivalent disk load and save routines. I had to convert Nick's routine, which saves 16 numeric items, and then a single string containing hashed information about items carried and/or the rooms in which they are currently located.  I convert that string into a bunch of integers, which I simply add to the numeric array values that I load and save using the special CLOAD* and CSAVE* command of the MC-10 (it's really convenient). I must say, the hashing routines created by Nick are amazing examples of memory saving technique, especially when one considers he was only in high school at the time. The whole program, in fact is a master class of memory parsimonious BASIC programming. And it's still elegant and readable to boot. My hat goes off to Nick. He's a national treasure of the Coco nation.

I think Nick might have had some M/L special effects as part of the final Win Game scene, which I have converted to flashing the screen to the alternate yellow/red character screen colours of the MC6847. But having never got the original game running, the special effects in the game are just my best guesses.

The Internet Archive is currently down from a cyber attack, but when it is back up and running, Maybe I'll put the Coco version of the game up there, unless Nick wants to pull the distribution in-house. But in the mean time, for testing purposes, the MC-10 version can be played for the next little while at my Gamejolt page:

https://gamejolt.com/games/jgmc-10games/339292

Just hit the big green "Play" button then select the "Text Adventures Requiring Save/Load" menu option.  Use the "Cassette" menu of the online emulator to select STLODSSY and type RUN and hit Enter in the main emulator screen. You should also be able to save and load the GAMEFILE, using the the buttons under the main screen.  Comments welcome.

ADDENDUM:

Nick contacted me, and helped me figure out the nuances of Discord so that we could have a chat about his game. He had some suggestions for how to make the screen more aesthetically pleasing and clearer. I've started to implement his suggestions, which really streamline things nicely. Nick thought the big title could go and be replaced by a simpler text title, but I'm kind of attached to his swoopy graphic title.  But I did centre it a bit better.

I've made some headway on the Coco conversion too! Should be out in the next couple of weeks.

Coco version finally completed! Here is the game playing on VCC

Edits up (Nov 8, 2024). Tweaked room descriptions. Added "You are" back to the beginning of the descriptions. And altered the hint I embedded in one of the room descriptions to help in locating a needed item.

"Des cavernes dans le poquette" by Charles Feydy (1982) Update

"Some caverns in the pocket" is how I would translate the title of the game and article by Charles Feydy published in 1982. A while back I made and English translation from French and port of this little game from TRACE magazine Issue 2, 2nd quarter 1982, p. 62. This post is an supplement to the one I originally made on the project (https://jimgerrie.blogspot.com/2021/09/retrochallenge-2021-les-cavernes-by.html). It was prompted by a post by Jason Dyer on his "All Text Adventures" blog, who helpfully took the game for a spin.  He confirmed my vague sense at the time that the game was not functioning properly before I lost interest. I went back to look at some suspicions I had that differences in precision between Micro Color BASIC and the TRS-80 Pocket Computer 1, which was the original target machine, were not fully dealt with. In particular the exponent function's decimal precision has some wonkiness (try printing 10^7).

There is a bug/accuracy limitation in some early 80s Microsoft BASIC's exponent functions which produces erroneous decimals results rather than a whole number. For example, 10^7 on the MC-10 produces 9999999.99 instead of 10000000. Simply adding .5 and adding an INT (integer) function to any exponent function call can often clean up these possibilities. It seemed to clean up some of the weird room descriptions, but not all, and there seemed to be an inordinate number of dead ends still happening. It also improved the combat results, because the exponent function was also used in that subroutine.

I also altered some of the translation choices I made based on the comments from readers of Jason's blog. One about "trappe" being “hatch” versus an actual “trap,” as I had naively assumed, was especially helpful in clarifying an oddity I had noticed that "traps" didn't seem dangerous.

I now think the port might be functioning more-or-less correctly, and that any remaining difficulties might be inherent. The game represents an exercise in producing a simple “procedurally generated” dungeon based on the initial number you enter and the oscillating and pseudo random decimal numbers produced by the SIN function. Those numbers result in calculations that will recreate the same “dungeon” (arrangement of nodes, monsters, rings). What results is a mathematically generated series of unique interconnections that when combined with descriptive words creates a simple unique “maze".  However, this maze is not actually fully interconnected as you cannot actually reverse paths to go back the exact way you came.

Sometimes these interconnections end in dead ends–- either because you can’t pass a monster given the "rings" you have found– or because the node is simply empty (no ways out). Overall, I think this is essentially a mathematical challenge (not surprising for pocket computer owning crowd) of finding the right starting Dungeon Number and combat Level Number combo that actually has a possible solution.  Such a solution will involve being able to find a path that includes the right arrangement of rings and interconnected nodes to get all 10 of those rings, while also defeating all the monsters encountered along the way. The number of monsters defeated is counted as one's score.  So I think the ultimate goal of the game is to find the Dungeon number and path that will allow one to collect all 10 rings, with the intermediate goal being simply to get the highest monster kill rate.

I have to do some more testing, but that is the win hypothesis I am currently working on. I might be able to set my software engineer (and Math major) son onto the problem to see if gaining all 10 rings is mathematically possible. Maybe he could use a proper language and some AI techniques to find if there actually is “a solution” if my hypothesis is correct.  It is an interesting game-theory question if anyone is looking for a grad thesis.

I decided to create a completely alternate exponent subroutine to do my testing and allow me to fiddle with alternate ways of implementing the exponent function. As I noted, simply INTing the result was not enough to fully correct all the apparent errors in maze generation. In revisiting the source code and original listing I think might have also found a few bracketing errors, but not sure if they were the causes of any of the troubles I was having.

In the end I realized the problem was also a result of a slightly lower level of mathematical accuracy between the MC-10 and Pocket PC. The game relies heavily on the mathematical accuracy of the Pocket PC and its BASIC. Simply put, it needs 10 decimal digits to come out of SIN, whereas the MC-10 could only give 9. That is because the decimal is multiplied by 100 to give two hole number digits, which are used for combat calculations, plus 8 decimal numbers, which are used to store maze node information for 4 directions of moves. The Pocket PC apparently could give you a number like

90.12345678

Whereas the MC-10 can only give you

90.1234567

The 8 decimal number give 4 groups of 2 numbers which store the node information for the four directions of movement. If the first digit is 4 - 9 then you can go in that direction. If the second digit is odd and there is a monster present, then you will be blocked. If you defeat the monster then you will be allowed to move to a new room by adding one to that digit to make it an even number and then a new SIN number will be generated based on the current number. Since I was missing an 8th decimal digit I made it so that it is simply replaced by a zero.  So there will likely be differences in the maps of the original machine and the MC-10, but I don’t think it should matter that much. It is really a math nerd’s game, allowing the player to explore the interactions of a complex set of calculations “Fibonacci-style” as a dungeon maze.

Here is a vid of some early testing: https://youtu.be/N4bUl5sQNtA?si=k0mLNOnd-EH-Nu0j

Here’s a vid of a long play of the final iteration (I hope): https://youtu.be/M8UySLhMr80

The game can be played online here: https://archive.org/details/CAVERNES

As part of the testing I also did a MS Quick Basic conversion, which can be seen here:

The source for that version can be found on Github here:

https://github.com/jggames/QuickBASIC/tree/main/Cavernes

The source for the MC-10 version can be found here:

https://github.com/jggames/trs80mc10/tree/master/quicktype/Text%20Adventures/Cavernes

The last point I would like to make is about what genre this game fits into. It straddles the line between CRPG and text adventure. Since there is combat and "items" that can improve one's performance it seems like its a CRPG.  But there is no ability to define one's character or change it in any way beyond collecting the single type of item, which makes it an extremely limited form of CRPG.  But it also has all the tropes of a text adventure in terms of vocabulary: N S E W directional movement, Inventory, Look, and Get. The room descriptions are sparse but it is not really randomized in terms of the maze, as they are in many CRPGs.  There is a narrative "Get the 10 Rings" which will play out in the same environment every time, as in a text adventure.  And as in a text adventure there is a puzzle to solve-- Can the path to the 10 rings be found?  In the end I would describe this as a simple mathematical text adventure with CRPG elements.  Credit must be granted to the Feydy for being able to fit this into a machine with extremely limited memory.  He used a bunch of tricky techniques, including having the user key in all the description data by hand before every session, instead of using costly DATA statements redundantly reading their contents into separate array variables. Amazing! It is a tribute to the persistence of early computing pioneers on these extremely limited machines.

P.S.  Turned out there maybe were some precision errors in the mathematical routine to "snip out" the individual decimals in the node variable. When I printed its results they were offset at the third digit for some reason (more rounding errors?). That routine made two calls to the exponent function to do its calculations to derive a single digit from a designated location in the string of decimals. In the end I realized I could simply convert the decimal to a string and then use the MID$ function to snip the desired digit from the desired location. Then I could just use VAL to make that character back into a number. I had the luxury of memory to do this, although I think the routine was actually shorter, but it uses string handling, so I can't say for sure if it is actually more memory parsimonious.  Oh well, now the routine seems to work reliably.

"Softball" for BASIC 10-Liner Programming Competition (2025)

I decided to try to make another 10-Liner BASIC game for the next BASIC 10Liner Games Contest on Homputerium. It is loosely based on many computer simulation baseball games I've seen over the years, but more specifically, a game video I saw recently for the old 8-bit Japanese home computer the Sharp MZ-700:

I've been thinking for some time that it would be simple to animate a pitcher batter interaction and the plotting of the movement of runners around the 4 bases of a diamond.  I wasn't so sure whether it could all happen on the same screen though, until I saw the MZ game.  That old 8-bit machine isn't all that more functional than an MC-10 in its screen resolution. I also really liked the simple dynamic of different zones in the outfield representing different possibilities for number of bases. The original had 1 to 4 base possibilities and two "out" zones mapped along the back fence. I thought I could save some space by using the pixels of the semigraphics-4 mode of the MC-10, which gives me 1-64 units horizontally.  This is a lot better than the 1-40 units of the text "graphics" being used on the MZ game, and more than twice what I would have if I used the 1-32 horizontal text spaces of the regular MC-10 text screen. I just requires using solid colours instead of numbers.

In the end fitting in a diamond and a side bar for the pitcher and batter interaction on the right meant I could only fit in 1,2 and 4 base zones and two zones for outs. The MZ game also had four positions in the inner outfield for outs. I used Red for the zones causing an out, and then the colors corresponding to the semi-graphic 4 values 1,2,4 (offset slightly) to save my program doing some conversion between sensing the color the ball is travelling through and the number of bases achieved.

The MZ game doesn't actually recreate a baseball/softball game. There is something else going on about points for hits.  I can't really tell.  My son knows Japanese so maybe I'll try to locate the article for the type-in magazines with the game and see what he can make of it.  But I thought I could recreate the rules of a simple softball match, which I remember from school, including grad school recreational teams I played on. The balls just track within the diamond.  There are no out of bounds.  This would be too complex for a 10-Liner.

The game basically is a reaction game where you try to time your key press to activate the bat at the same time that the ball is crossing directly to the right of the player.  If you make a hit, a random trajectory from a slightly random starting point at the bottom apex of the diamond heads up screen. If the pixel track hits anything besides green, a number of bases are won, or the ball is out if it hits red.  Once I had the graphics for diamond and pitcher and batter printed, and the animation for the pitch and the swing done, then there is just some simple calculations of runs and misses until 3 outs has happened. Then a shift is made to the other team and it is all done again. Repeat until 9 innings are completed, then END with a report of the two scores.

To achieve this in 10 lines requires all the techniques I've developed over the years.  The most important are using "ON -(logical test) GOTO line num,num..." as a kind of 8-bit BASIC replacement CASE SELECT IF/ELSE commands.  The other "biggy" is using Boolean logical operators directly in calculations to help omit using IF/THEN statements for conditional calculations. Then it's just the simple techniques-- single letter variables, reusing variables/scratch variables, removing spaces, etc.

The code can be found on my Github here:

https://github.com/jggames/trs80mc10/tree/master/quicktype/Strategy%20%26%20Simulation/Softball

But I'll include the current version here:

0 J=3.5:K=1:B$="*":C$=" ":C=40+RND(10):?"ßßßßßß¿¿¿ÏÏÏ¿¿¿ßßßßßß","ßß߯¯¯¿¿¿ÏÏÏ¿¿¿¯¯¯ßßß","ŸŸŸ¯¯¯¯¯¯ŸŸŸ",

1 ?"ŸŸŸŒŸŸŸ","†Žƒ‰","߆¿¿Ž‡‹¿¿‰ß","ß߆Ž‡‹‰ßß","ßß߆Ž‡‹‰ßßß"

2 ?"ßßß߆Œ‡‹Œ‰ßßßß","ßßßßß‚ßßßßß","ßßßßß߆‰ßßßßßß",:A$(5)="ÿ":A$(6)="€ƒƒ‡":A$(7)="Ž‚":A$(8)="‹‹

3 ?"ßßßßßß߆‰ßßßßßßß ‹ÿ","ßßßßßßß߆‰ßßßßßßßß ‹€","ßßßßßßßß߆‰ßßßßßßßßß ","ßßßßßßßßß߀ßßßßßßßßßß ‡‹"

4 ?@58,"X":FORB=90TO470STEP32:?@B,B$;:FORZ=1TOC:NEXT:?@B,C$;:IFINKEY$<>""THENFORT=5TO8:?@214+T*32,A$(T)" ";:NEXT:IFB=378THEN7

5 NEXT:IFB=474THENS=S+1:SOUND1,2:IFS=3THENS=0:?@277,O+1"OUT":N=N+1:S=0:O=O+1:IFO=3THENO=0:R(W)=R(W)+R:R=0:W=-(W=0):N=0:K=0

6 FORZ=1TO2500:NEXT:N=N*-(N<10):?@480,"R"R"O"O"P"N+1"T"W+1"SC"R(W);:?@0,;:ONKGOTO0:FORT=0TO9:P(T)=0:NEXT:I=I+1:INPUTE:CLS:GOTO0

7 B=500:X=19+RND(3):H=RND(0)*SGN(RND(0)-.5):FORY=25TO0STEP-1:X=X+H:P=POINT(X,Y):RESET(X,Y):IFP=4THENB=442:Y=0:S=2:GOTO9

8 IFP>1ANDP<6THENQ=P-1:?@277,Q"BASES":Y=0:P(N)=.5:FORT=0TO9:P(T)=P(T)+Q*-(P(T)>0):R=R-(P(T)>J):P(T)=P(T)*-(P(T)<=J):NEXT:N=N+1

9 NEXT:?@480,"R"R"O"O"P"N+1"T"W+1"SC"R(W)"I"INT(I/2)+1;:FORZ=1TO2500:NEXT:ON-(E=0)GOTO5:PRINT@0,"T1:"R(0)"T2:"R(1):INPUTE:GOTO5

10 REM                                                                                             1         1         1         1

11 REM   1         2         3         4         5         6         7         8         9         0         1         2         3

12 REM78901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234

Doesn't seem like much, but it plays a whole game of softball. If your reactions are good then you will get more hits and more chances for various runs. If you miss a lot, then you'll get fewer runs.

It is working but I know as Christmas approaches and I have some more time for programming that I will want to refine it. There are possible bells and whistles I can add to make it a little more fulsome a game, possibly out of bounds hits, and maybe even adjusting the zones to include 3 base runs. I originally had the game limited to 127 characters, which is the max line length of the MC-10, but the contest only has a categories for 80, 120 and 256 line lengths. So I am definitely stuck with the 256 category.  Since there are some ways to trick the MC-10 to accept 256 character lines, I started adding features. But there is still room left.

I'll post addendums here as I go.  If you are interested, you can try playing the current version online at the Internet Archive.  Here is the link:

https://archive.org/details/softball_202407

The Six Lilies/Le Jeu de Six Lys by Infogrames (1984)

I have made another conversion of a game for the Matra Alice to the TRS-80 MC-10. This game is a computer role-playing game (CRPG). It uses some nice graphics that are made possible by the upgraded graphics chip for the later models of the Alice, which had the same chip as the Thompson 8-bit computers.

Dead-end

There were some pretty creative images, generated using line-drawing techniques developed by the Infogrames programmers.

4-Way Intersection

These graphics are drawn using machine code routines that are loaded along with the BASIC program.  The BASIC program, however, covers combat and other main functions of the game like random item distribution and input, so all I had to do was recreate new room, character and item drawing routines in BASIC. Despite the creativity and variety of the hires images, they all boil down to 3 basic forms: Passages (no distinction between east-west, and north south), 4-way intersections and dead ends. I was able to create a simple room rendering engine using the chunky lowres Semigraphics-4 graphics of the standard MC-10/4K Alice. This engine indicates which directions there are exits (north, south, east or west) in the orientation North-back, West-left, East-right, South-foreground. It didn't require too much memory and was as speedy as the machine language line-drawn artworks of the original. Simple, but they do the trick:

North and South exits ("Guard" spelling now fixed)

4-Way intersection with East and West Exits

In my system, dead-end rooms are just rooms with one exit, but unlike the original, they clearly indicate in which direction the exit is located.  I was able to have enough room for just two extra special rooms. One was the "Web Room" where there always seems to be a spider (a very powerful creature) which must be defeated before approaching the dragon.

I've refined this room graphic a little since taking this screen shot by adding a web string in the upper left corner. I also changed the name of the creature from "Migilus" to "Spider".  I generally moved towards trying to use clearer English equivalent names for monsters when they were apparent.  For example, "Nain" which is French for "gnome," was renamed and given a little red "hat" to evoke the garden gnome cliché, just for fun.  I went through two renderings of the Dragon big baddie, which is double width to all the other creatures.

Chunky original dragon idea

A more stylized dragon glyph

I went with the less chunky dragon, but please let me know if you feel I went the wrong way. I had to work the semigraphics-4 hard to get an interesting variety of monsters to cover the 40 used in the game. Each is meant to evoke the size, ferocity and type of creature from the original artwork, but I did take some liberties. These are the glyphs I came up:

Monsters 1-16

Each monster was limited to a 4 by 4 grid of pixels, which due to color clash, must largely be limited to a single color.

Monsters 17-32

Colors can be used to evoke certain kinds of monsters. For example, white is a good colour for undead types. You can see in the above how I was able to sneak in the red cap of the gnome by carefully avoiding color clash between individual 2X2 pixel character blocks.  When the names, which I think were probably loosely based on Latin terms rather than French, were not hard to pronounce and were evocative of something, I left them untranslated. Otherwise, I opted for straightforward English terms for the various types. Their size relative to the player will hopefully indicate that these creatures are of extremely large size and aggressiveness for their species. But not all of them attack when you enter a room. Some are simply cannon fodder, that you must combat to build up your strength and constitution in preparation for fighting the Dragon.  You must figure out which are the most and least dangerous, and start small and work your way up. Otherwise, you are doomed. The food and other items in the dungeon can help you replenish constitution and can raise and lower your intelligence, which also helps with your combat.

Monsters 33-40

If you manage to survive and build your stats to an appropriate level, you can face the dragon (seen above in "split" form).  If you can defeat the dragon, you can make it to the room with the Lily, which you can then take to an appropriate room (which you must find) to win the game.

BUGS

As with many of my conversions, including my last one (WW3) from the Alice, I found some bugs. At least one was potentially game busting depending on your patience. I found that if you picked up and then dropped the sword, you would be granted a larger amount of Constitution points than would be taken away. So if you simply stayed in a room picking up and dropping a sword you could conceivably raise your constitution to whatever level you needed to defeat everything in your path.  It might take some time, but players back in the day would have ruthlessly seized on such bugs to achieve victory, no matter how underhanded such a victory would be. Here is the kind of progression in Constitution you would see from a series of pickups and drops:

234, 244, 239, 249, 242, 252, 247, 257, 266...

It struck me as an inadvertent asymmetry in the GET and DROP routines. Possibly there was some concern that since any action, including dropping an item, also uses a small fraction of Constitution (which is like your "energy level") some restitution was due. But the decimal math was not right for simply offsetting that specific fractional amount. It just seemed to be a mistake. It only effects the sword, since that is the only item that grants an increase in Constitution when you GET and carry it. I fixed it so that the benefits of STR and CON are given and taken to the same level for GETs and DROPs.

A less game-breaking bug is one that affects the reading of scrolls.  It is clearly the case that like most of the items some scrolls are positive and some negative. For example, some vials are poison and some are magically helpful for (STR, INT, or CON).  But the routine to register either positive or negative effects jumped to a line number just after the IF check for deciding whether an item was of the positive or negative type. So all scrolls would simply default to being positive in effect. But given the information messages that are provided when you use the "IN" (Intelligence/Inquiry) command, some of the scrolls are clearly meant to be negative. In general, scrolls and vials that are good provide more benefit compared to the bad effects of negative counterparts, so there is an incentive to be cautiously bold.

In relation to the IN command, it takes a number of intelligence points to use that command, which is obviously meant to be a disincentive from using it too much. But I read in the instructions that this command was only available to those of requisite "high intelligence. " But the game would let you use the IN command without limit and subtract points even into the negative range, which seemed strange. So I added a feature to only allow use of the command if you had Intelligence points above at least zero. Otherwise the message "nothing" is printed.  A player must be careful about using the IN command and should not ignore INT when choosing character stats at the beginning and try to keep them up during the game.

 

Finally, there was a minor quirk in the way the game seeds the random number generator, which resulted in the first game always being the same dungeon arrangement from a cold computer start and game load. This is because the random item/monster distribution routine is called before the "random seed" routine is called in the form of an RND embedded in a "press a key" loop. So I changed this so that you always get a completely unique game for any startup. The program also NEWs itself if you lose, forcing the player to reload-- Part of the incentive to play well, I suppose. I took that feature out, and added a simple re-start prompt at the end. I also added a brief version of the game backstory as part of the intro screens, and a list of the commands. That way, anyone playing the game online can simply figure out what is going on after typing RUN.

If someone from the Alice world would like to fix the bugs that I think found in the original version, I have added REM statements regarding the three main ones discussed above. The source code (highest number is latest version) can be found here: 

https://github.com/jggames/trs80mc10/tree/master/quicktype/Dungeon/6Lilies

My version of the game can be played online at the Internet Archive:

https://archive.org/details/6-lilies

P.S. Thanks to whoever created the walkthrough map that I found online.  It was really helpful.  And to Le Fétiche for his long-play video of the original game:

SPOILER ALERT

The following is a video of the dragon being defeated. It shows where you must go after defeating the dragon to win the game, and the brief animation that occurs with your final victory.  For those who don't wish to spoil the game, I recommend not viewing the video and playing the game yourself!

Video of a win!

"Castle Adventure" by Dave Trapasso (1981)

This is a type-in text adventure from Computronics magazine, April 1982, which I don't think exists as a playable game anywhere on the Net. It was originally for the TRS-80 Model 1/3, but my version is for the TRS-80 Micro Color Computer:

Here is a walkthrough map:

The magazine scan was very clear. I mostly only had to add carriage returns and fix a few lowercase L's in place of 1s. Otherwise it was just a standard exercise in using my word-wrap routine and reconfiguring (cutting by half) the PRINT@ commands from the Model1/3 screen, which is 63X16 to scale the messages to the MC-10's 32X16 screen. The program has a somewhat unique screen layout with room descriptions and items being printed at the top, response messages in the middle, and commands entered in the bottom two lines. I had to make new clearing routines for these different zones and I bumped the response message area up a line to just below the demarcation line (now a sequence of SG4 characters representing a castle "parapet") between the top description zone and the message zone. This is because some of the messages obviously take multiple lines on the MC-10 and the bottom of the main message area is used for temporary messages like INVentory lists and random messages, such as when the damsel yells for help.

Finally, I added a pixel art title screen to replace the simple REMarks with the authors name and date info. I didn't include the old address info.

The game "CASTLE" can be played at my GameJolt page under the "Text Adventures" menu item. Just select PLAY GAME, then the "Text Adventures" item, then CASTLE from the Cassette menu and type RUN and hit Enter in the main (green) menu screen.

https://gamejolt.com/games/jgmc-10games/339292

"Adventure" by Let's Compute Magazine (March 1991)

I've typed-in a demo text adventure from a UK computer magazine called "Let's Compute." The CPC computer wiki describes the history of this publication as follows:

Let's Compute! was a monthly British magazine that catered for the Electron, BBC Micro, Commodore, Atari ST, Spectrum, Archimedes and Amstrad CPC. The magazine was 99 pence and only lasted 12 issues (August 1990 to July 1991).

It was produced by Database Publications-- with the managing editor being Derek Meakin (from Computing with the Amstrad).The last two issues were published by Europress Publications.

The magazine covered as much as possible in its 48 pages - game reviews, news, cartoons/jokes, reader questions and type-ins. Sometimes the type-ins would specific only to certain platforms, other times they would provide you with the lines to change in order to make it work for your platform.

The text adventure engine/demo program was covered in the magazine's last 5 issues (March-July) 1991. The game as published functions but it's puzzles/storyline were not completed. There was going to be a least one other installment of the series covered but the magazine was cancelled after issue 12.

This loose end struck me as particularly sad because when I typed in the program I discovered quite a nicely programed and flexible text adventure system programmed in BASIC.  It uses DATA statements with a clever system for sensing additions and calculating the number of items and actions being added, and adjusting itself accordingly.  It also uses a complex system of hashing/encoding what happens with new vocabulary, items and actions that is both flexible and efficient.  The result is that the parser is both quick and able to sense unique vocabulary terms, either verbs or nouns, that can trigger appropriate responses even if the user types complex phrases or even sentences.

It seemed a waste that this program should not be preserved for posterity.  I suspect that I wasn't able to find any evidence that it had been preserved as a running program anywhere on the Net because 1991 was a bit late for type-in games and the timeframe of the computer systems the magazine was directed at were already well into the period of the dominance of commercially produced software. I suspect very few people using them would have wanted to type in and preserve type-in games, especially ones that were never fully completed.

So  I have completed the story as best I could from the clues and the layout of the items provided in the source code and also from the discussion in the accompanying articles. I feel pretty confident that I have recreated the demo adventure storyline that the author or authors were aiming at and likely to have produced in the final article. And just for my own fun in TRS-80 MC-10 programming I added a fancy title page using semi-graphics-4 characters.

The magazine article begins "We're off on the road to Adventure."  It's a simple space adventure somewhat akin Lance Micklus' 1979 Dog Star Adventure.  There are a few tricky puzzles and only a few possibilities for insta-death. No specific author is identified in the articles from what I have read (perhaps they are mentioned elsewhere in the magazine). The version I made is for Micro Color BASIC on the TRS-80 MC-10 but the article claims the program should work with only a few minor changes on the BBC, Archimedes, Amiga and PC (GW-Basic), but that it will not work on the C64/128 or Spectrum.  However, I can see no reason why it shouldn't work on the C64/128. I suspect the intensive use of string handling and string handling commands (MID$, LEFT$, RIGHT$) used in the program might be difficult to translate to Spectrum BASIC, which treats strings as string arrays instead of using string functions to manipulate them. The C64 omision might simply have been due to its shorter line length (80 characters), which might have required some extensive editing of long lines to reconfigure for the C64.

The game can be be played by selecting "Play" on my GameJolt page, then "8-Bit BASIC Text Adventures" and then choosing LCADVENT from the Cassette menu.  Finally, type RUN and hit ENTER in the emulator's main green screen:

https://gamejolt.com/games/jgmc-10games/339292

"Minidam" by Christian Garaud (1985)

This program is a "solitaire" logic puzzle game. The goal is to transpose the red pegs and blue to finish with the red pegs on the right and the blue pegs on the left. A peg can only move diagonally in the direction it is meant to travel, towards an empty space or jump over a peg to reach a space that is empty. You can start with any colour that you want. To move a peg, just type box number in which it is located. If you are stuck, type 99 to restart.

Published in the French language magazine Micro 7, April 1985.  I translated the French prompts and ported to the code to Micro Colour BASIC.  The game was originally for the ZX Spectrum 8-bit computer.

Not sure if this puzzle even works.  But it struck me as an interesting piece of code to get working, from a old computer magazine that I had never heard of before.

I also typed in another program called "Testamour" (TSTAMOUR). It is credited to the editorial team of Micro 7.  It's meant to test the reader's knowledge of BASIC. If they could figure out what was going on, then they would be able to respond in a way that they would get rewarded with an image being printed on the screen. Perhaps the answer of what the program did would have been revealed in the following month's edition of the magazine for those who didn't understand BASIC well enough to figure out the trick for getting the image to display.

I know Steve Bjork had mixed feelings about the MC-10, but as an MC-10er I have nothing but the deepest respect for him. His programming skills were an inspiration to me as young programmer. Allen Huffman recently sent me some old BASIC code of Steve's. I have ported his perpetual calendar source. Now he is a contributor to the MC-10 program library. Thanks so much Steve!

Finally, here is a slight update to an old program from way back that I typed-in called XMAS.  It is from the Coco.  But the program only used to blink red lights by using RESET. But now I have it cycle through multiple colours.

Update:

Christian left a message on Facebook and says the puzzle is solvable:

https://www.facebook.com/groups/731424100317748/posts/7194936100633150/?comment_id=7195188603941233&reply_comment_id=8618010184992394

"Haunted House" by Tandy (1979): A Narrative Update

This is a classic text adventure first sold for the TRS-80 Model 1 in 1979 by Tandy. It is a little unclear who the actual author was, but the game was originally a machine language game in two parts, which was able to be played on an original 4K TRS-80. More info on the game can be found on numerous sites, such as the following very helpful homage site:

https://www.figmentfly.com/hauntedhouse/hauntedhouse.html

Now it is available for the TRS-80 MC-10 because Donald Foster ported the game to QB64 BASIC and posted his source online. I just had to add line numbers (instead of subroutine titles). I can't recall now or locate where I first spotted his source, but it was attached to a post in one of the innumerable retrocomputing forums that I visit.  He has my thanks. If I recall correctly, his post asked folks to try out his port and report any bugs. I think I might have overcome some minor ones and some limitations in game logic in a few places, which I can't recall now. But there was one major bug I do recall. The 4th "chief" ghost was supposed to be "immune" to the attacks of the sword, but I think instead there was the same message printed about "killing" the ghost.  But the ghost would still be there regardless of the message. I noticed this because published walkthroughs of the game kept mentioning how the main ghost was "immune" to your attacks.

This got me going on a kick to make some more changes to the game. I added an intro screen in semigraphics-4 mode of a creepy old house. I also made some corrections to the intro text that Foster had added (from the manual I presume). Thanks to some folks who posted some comments on my first video about the game I was able to correct some spelling mistakes and typos. 

I've now made some substantial additions and a few subtle changes to the messages and the outcomes to try to create what I feel is a more coherent narrative for this classic. Even in the original game it was apparent that there were two warring metaphysical factions at work in the house. I have worked to clarify and highlight this tension. Each faction is contending with the other as a result of a terrible wrong that has trapped both in a seemingly interminable struggle. 

-- Can you figure out which is on the side of right?  Can you help right a historic wrong and bring resolution to a lost soul?  It all depends on you!

I have added many messages that hint at this refined narrative to allow the player a richer more standard text adventure experience than the original spare 4K version could provide. For example, Jason Dyer of the Renga in Blue text adventure blog series expressed frustration with the lack of interactivity with the BUCKET object regarding the flames in the first floor master bedroom:

https://bluerenga.blog/2016/09/21/haunted-house-finished/

The bucket it turns out is a complete red herring because the fire is an illusion. But now with my changes you can at least try to use it and get some response instead of the original game's standard "I don't understand."

The player can now "examine" things and get some narrative hints at what might have occurred in the house to create the metaphysical deadlock. As noted above, the original narrative hints at some struggle between spirits-- malevolent versus benign. The knife doesn't want you to read the scroll for example. But the scroll points to a possibility of escape. The fire seems aimed at preventing you from getting to the room with the hole that will take you to the second floor, but if you get there the rope uncoils and allows you to go up. The three upstairs ghosts in the main rooms block your way, but a magic sword is left that allows you to vanquish them. Behind one of those ghosts is another who, if you get to him only lets you pass to the final room if you relinquish the weapon. I added the necessity of also "killing" (i.e. dispatching to hell) all 3 of the obstructing ghosts.

I made this addition because otherwise there appears to be no function for killing the other two ghosts, since they don't obstruct you from getting to the 4th ghost. And I take it as given that these are the three malevolent spirits of the house and that the 4th is benevolent (i.e. fundamentally non-violent) and that there is an issue of justice at stake. The intro mentions "a visitor." My take on the story is that the visitor was an innocent victim of the three sinister and grasping McDaniels who had made vast profits off of illegal hooch manufacture during prohibition. I've added clues that hint at this narrative that you can find by using the added "examine" command. For example, one clue you don't see in my walkthrough video above is that if you EXAMINE COINS you will see they are minted in 1932, which was a year before the end of prohibition. 

I also changed the "suit of armour," which prevents you from getting to the key in the servant quarters, to a "spectral hound". The suit of armour seems out of keeping with the North American setting I am assuming for the house. If one assumes the knife is in the command of the evil McDaniel spirits, then the possession of the crumpled paper talisman with "Plugh" on it, is imbued with the power of the good spirt. Even in the original game you must be carrying that paper to be able to get hold of the floating knife. If you don't have the paper, you can't get the knife.  But if you do get the knife then you can also scare the spectral hound/suit of armour. My take on this is that the knife of the McDaniels was often used to harm their old guard dog. So the control of that knife can actually be used to subvert their manipulation of the spectral dog to protect the servant quarters. If you get past the dog you can now also find bottles hinting at the source of the McDaniel's ill-gotten wealth.

So I am of the mind that somehow in around 1932 a federal agent by the name of Plugh was investigating "hooch magnet" McDaniel when somehow he ran afoul of him and his murderous clan. They killed Plugh, but somehow he was able to strike back, either metaphysically after his death, or before his death in some way that brought about their end as well, and perhaps inadvertently the end of their poor maltreated dog too. I'm thinking a gas leak or a series of fomented mishaps. Their house was obviously booby trapped to the hilt to prevent theft of their vast wealth, which can now be seen in the final room. Perhaps even Plugh was tempted by that wealth and the possibility of making off with it, which helped bring about his end. This might explain the somewhat cryptic/ambivalent/poetic clue scratched on the sign in the final room. I have added the treasure at the end to allow for this reimagined scenario. Can you maintain your honour and escape like Plugh perhaps did not?  Can his failure to rise to the challenge of this temptation explain why he was consigned to his spectral existence-- to atone? Can you rise to the challenge?  The introduction hints at what you must do.

Enjoy.

Jim Gerrie, (c) 2024.

"HAUNTTRS" can be played online here (at least for a short while): https://archive.org/details/@james_gerrie

ADDENDUM

I've made a few more changes and additions in keeping with my new narrative.  I changed the paper at the beginning to an FBI badge with "Plugh" on the back of it, and hidden it under the front mat. I've also added a reaction of the benign ghost if you drop the badge in front of it.  To allow for this, I've added the ability to "wear badge", which will allow the badge to be carried with you up the rope. I might as well go whole hog on altering the game since there's no point in just recreating the original.  There are many ways for folks to play the pristine original if they really want to. Here's a video with the main changes demonstrated-- and a "speed playthrough" to a win-- SPOILER ALERT!

ADDENDUM TO ADDENDUM

I made some more changes. I added some randomness to the location of the rope. I added much more descriptive content to be EXAMINEd. I added the ability to move objects around and drop them in other places and then pick them up again.  I added another puzzle regarding the badge. Now you must have it for the sword to appear. There is not much more that can be added.  Sadly I'm getting close to the max 20K now.  So hopefully, this will be my last addendum.  The game should now at least be equivalent in game play to your average 16K 8-bit BASIC text adventure.  Abysmal, but better than a two meagre 4K games. My task is complete.  I feel I have taken a classic game that was an introduction to many, but sadly somewhat wanting because of the strictures of the classic trinity 8-bit computer it was designed for, and rounded out its very suggestive but minimalist storyline.

"Dungeon" by Brian Sawyer (1979)

This is a port of the classic PET "Rogue-like" game (before Rogue) "Dungeon" to the TRS-80 MC-10. I found an unfinished part in it that would have allowed the player to have a double distance "fog of war" view instead of the single space view immediately around the player's position. The "S" key was assigned to the function and it would have cost -2 HP. In fact, I think the -2 part of the function works when you hit S, but the full expanded view routine doesn't seem to have been implemented. See lines 610 and 1310 in the source that I worked from:

600 K=-40:J=3:M=40:R=3:GN=0

610 IFSM=1THENK=-80:J=5:M=80:R=4:SM=0

620 O=L-32767-R

630 IFO+32811>33768THENM=0

This is the beginning of the "fog of war" reveal routine. The SM variable is a switch that if activated in the key input routine causes an alteration of variables to create different offsets for the reveal box around the player. But not all these variables are actually used in the subsequent nested FOR/NEXTs used to display the spaces around the character.  I think Sawyer realized that an odd number would be needed for the routine to actually be centered on the character, which would require a 5 X 5 character space box around the player character instead of an originally planned 4.  Also, this would require some error checking as the routine moved past the edge of the screen in the bottom right and top left.  A vestige of that can be seen in line 630 where a check is made to see whether the offset takes the view outside of screen memory at the bottom right.  

Here is the code that was meant to switch the mode on:

1310 IFL$="S"THENSM=1:HP=HP-2

My guess is that Sawyer realized what a daunting task getting the routine working would be (a bounds check also for the top left, for example) and that the game was playing just fine without it. So he just left it half implemented and carried on. It is not uncommon to find such unfinished bits and pieces in old BASIC games. I think there were other unused variables that I removed from this game and untold others in other games. They are the vestiges of the unwieldy editors that one had to use back in the day.  It was impossible to simply view the code as a whole and to be able to do quick global searches and replaces. LISTing and then pausing the display as the lines sped past meant that many false starts would simply be left in place if they didn't impede program execution. Today I like to clean these things up, as they can help smooth out and speed up game play.  I recognize that there is a loss of fidelity with the original, which is why I try to document such modifications. But my love of these programs means I like to see them run as best they can.

To that end I also added a feature to continue with another dungeon if you get all the gold on a screen.  The game as it was would simply end in the same way as when you die. It would reveal the map and prompt for a replay. It didn't display a win message.  However, it seemed simple to preserve the player's basic stats of Hit Points, Experience and Gold Pieces and then generate a new map for the player to continue their quest. This will be extremely difficult as the monsters ramp up according to your own HP modified by their own intrinsic level of ferocity.  In fact, it might be a good strategy to simply bleed off HP down to a level that is easier to manage.

I also added a "bloodstain" which shows where you were killed on the map. It's just a red block, but it helps differentiate an end from death versus completing a level. I also added messages "You have found all the gold" and an alternate prompt "Continue to next level?" if you complete the map. Here's a video of a test of an early version of this feature:

I also added some sounds, such as when you find gold or are killed, since the MC-10 is a slightly more advanced machine than the soundless classic "trinity."  And I added some instructions to the title screen about the keys used in the game.

Hit Points Oddity Fixed?

There's an oddity about one of the keys. There seems to be no limit to the player's ability to press R (the 5 key in the original game) to "rest" and gain Hit Points. The only disincentive seems to be the time taken waiting for the screen update.

1290 IFA=ASC("5")THENHP=HP+1+SQR(EX/HP)

The use of the SQR function and a division of Experience by Hit Points scales the function down (I think) as you increase the number of HP, so the speed of increase will decrease as you add HP.  This means you will have to waste more time pressing the R key.  And you also will simply have to fight tougher monsters as you add HP as HP is one of the factors determining the stats of the monster you face.  So there is some mathematical alchemy of hitting the right spot of building strength in relation to experience that might be useful for game play. I will have to examine the code more closely and discuss this issue with my mathematically adept son next time he comes home. If he has any insights, I'll add them here.

But as I tested the game I realized that using the Rest function in combination with the "walk-through-walls" spell gave a pretty ironclad way to defeat the game. You just have to run away from monsters after you get the report of their HP and then build HP using the Rest function until you are equal or better than them. Then I realized I could even do this from the safety of being inside the walls!  So, as soon as I spotted a monster, I would just fade into the nearest wall and start hitting R. Then I would reemerge and kick the monster's butt. This seemed unfair and kind of dull once I'd figured it out.  So I just modified my version to prevent Resting while inside walls. And as further incentive, if you try to do this, you lose the standard amount of HP used for regular movement. I thought this made sense.  After all, you are casting and maintaining a powerful spell while travelling inside walls.  Now, at least you must use HP to travel and then risk emerging into areas to rest that may be inhabited by other denizens of the dungeon. A little more resource management and path planning skills will be needed.

Finally, I had to take all the fancy string declaration used in the original PET version to clear a space in high memory where the dungeon can be safely POKEd before being revealed to the screen by the Fog of War function.  Robin from 8-bit Show and Tell has a nice video documenting a bug that affects this function between early and later versions of PET BASIC.  This video is what made me aware of this classic game, and his information about the game and links to other sources was very helpful.  But I didn't have to replicate this method.  I could just use the CLEAR command to define the end of memory that BASIC is allowed to use.

CLEAR500,26384

Then I just poked the dungeon into the space above 26384. This second argument of CLEAR is usually for defining an area to POKE any machine language subroutines that your BASIC program might call using the USR or EXEC functions.  But its also handy for simply protecting an area for poking data into.  I guess the PET doesn't have this function or the programmer simply used a different method.  I've certainly used blank strings, usually in the form of array strings, to define areas to POKE info into.  It's a very memory efficient method as long as the strings are not altered so they are switched around in string space.  I usually use the VARPTR function to find the beginning of the various indexed array strings, and then POKE using the address returned.  But I didn't use that method here as the program itself uses a method of a single continuous space in memory like the screen memory somehow defined by the string declaration of the early version of PET BASIC, but not in the second version.  Robin was able to patch this code so it worked on the more common updated version of BASIC.

Since the MC-10 screen is smaller than the PET's I also made the dungeon generating routine use all the space in the box defined by the impermeable outside wall around the dungeon. The rooms therefore can butt right up against the outer walls. I also decreased the max room size from 9 to 7.  Hopefully these changes maximize the space for the dungeon.  My efforts at such re-scaling were helped by the fact that the program uses variables to define the horizontal and vertical screen size of the dungeon/screen area.  It makes me wonder whether the dungeon engine had been designed for some generic BASIC system and then utilized by Sawyer.  Either that or he possibly planned to create versions of the program for other systems.

One final oddity. The following code from the monster movement routine has a number 31 in it:

910 IFA=41THENA=39

920 IFA=-39THENA=-41

930 GOTO960

940 IFA=31THENA=41

950 IFA=-41THENA=-39

When moving up or down in a 40 column screen numbers like 40,-40,39-39, 41 and -41 make sense. They allow movement in the up, down and horizontal directions. But 31 doesn't make sense except for a 32 column screen like the MC-10 has. For that kind of screen you want values like 32,-32,31,-31,33 and -33.  It might just be that someone inadvertently modified the original PET source, but it seems strange. I got my source from PYDungeon on Github, who has made a port of the game to the modern language Python. But it might be another indication that the game was originally designed for a different system from the PET with a different screen resolution. Perhaps the KIM?  Who knows.

 

My source can be found here:

https://github.com/jggames/trs80mc10/tree/master/quicktype/Dungeon/PETDung

How to play

PETDUNG can be played at my GameJolt site under the "More 8-bit BASIC game ports" menu item.

https://gamejolt.com/games/jgmc-10games/339292

Just select Play Game, "More 8-bit BASIC game ports", and then select PETDUNG from the Cassette Menu, and type RUN and hit Enter in the Main emulator screen.