RetroChallenge 2017/10: Fly Wheel

When I have an idea for game, there can sometimes be a number of false starts before I get something that works. This is the case for my game Fly Wheel. Originally I thought I might be able to recreate the shifting 3 dimensional highway affect of Pole Position type games using a complex algorithm to adjust the road to represent straightaways and curves and sections of strings for moving the horizon with shifting mountains and clouds. My first attempt was rather crude.  It kind of worked, but it was obviously going to be far too slow once I added all the code needed for a full game, such as being able to move the car, collision detection, scoring etc.  Here's what my first attempt looked like:

Pretty funky that snaky road! The car looks a little weird too. What I needed was something much simpler for the road graphics. Nothing sprung to mind, and so I let the project languish. Then I paid a visit to a site for ZX81 programming that I have been visiting on and off for some time maintained by Steven Reid.  He, like me, is an old 1980s BASIC programming hack who really enjoyed (enjoys) cooking up programs for his beloved Sinclair machine. I've created programs based on some of his ideas, such as Tower Dodge and Joust. This time I spotted his game "Fly Wheel."  What it showed me is that creating the illusion of moving road curves could be as simple as slanting two perspective lines creating the road from joining at the centre of the horizon to joining a little to the left or right. Like this:

He also provided inspiration for the other elements for a game of this type such as how to depict the horizon (a simple unmoving city skyline) as well as some other nice graphic touches, such as the starting line and explosion when you die:

It's obvious that Steven got a real kick out of coming up with compelling visuals for games on his limited little machine (only 4 chips!). I can't imagine all the hellishly complex keystrokes he must have had to execute on the ZX81's infamous membrane keyboard to get the graphics characters input into strings on a real machine. Nor the horrors of the ZX's infamous ROM pack wobble possibly obliterating all his work before it could be saved to tape. It's nice to program these days in a Windows editor and then "quicktype" it into the VMC10 emulator.

The ZX81 has lowres graphics in the resolution 64X48, which is just like the resolution of the MC-10 when you put it in Semigraphic 6 mode (POKE 49151,28 or POKE 49151,68). The only difference is that the MC-10 doesn't allow mixing of text with graphic when in that mode. But that's okay. It just means using cut scenes to display messages, such as the score. The advantage of the MC-10 is that its Basic runs must faster than the ZX81's, especially if you use as few variables as possible, and other speed up techniques that I have built up over the years. So unlike Steven's game, mine is actually a little more than somewhat challenging.  As Steven is obviously aware (just read his many blog postings) it was very easy for ZX user's dreams for their Basic game programs to far exceed their grasp, but that was okay back then, when half the fun was simply getting something to work. It's still fun now.

The higher speed allowed me to add a feature I wanted in the game from the beginning. I wanted the car to drift to the outside of a curve as you took the corners.  In my program there are actually two degrees of road curve and the sharper the curve the more the drift. You therefore must continuously counteract the drift when cornering and be sensitive to the different degrees of curve that you are currently on. Straightaways don't have drift, but they do have a little bit of randomness. Your car will occasionally bump right or left, so you also have to be a little careful on the straight sections.

Steven's program was based roughly on Atari's Night Driver game, so the other cars appear only as oncoming tail lights. I borrowed his model of how to show the progression of those lights in size and spacing, and then, thanks to the two colours available in SG6, made them red. They come down the road in a line starting at a random location at the top, so they are either some degree left, central, or to the right side of the road. Where they appear gives you some warning of the path they will take. If needed, you can drive a little over the edge of the road, but you lose points every time you do and if you go too far over the edge your tires go and your car blows up. So the trick for getting high score is trying to limit the number of times you overshoot the edge as much as possible. A little sound attends any move over the edge. Thanks to Robert Sieg for providing me with a POKE routine that allows this sound to be generated while in SG6 mode (Q=PEEK(9)AND128:POKE49151,4+Q:POKE49151,128-Q+4). This routine works for the POKE 49151,28 colour set. Using the normal SOUND command automatically takes you out of SG6 and bumps you back into normal text mode.

Generating the sequence of the curves was something I simply encoded into DATA statements. Each cycle through the main loop a road variable is read indicating straight, or one of two degrees of left or right curve. Then I just coded the sequences of numbers for a simple oval, a slightly more complex liver shaped track, and a multiple tight-hairpin-curve track. The score you achieve is a sum of how far you go through these variables, minus any times you have gone over the edges and multiplied by the degree of difficulty of track (1-3). I have found it easiest to keep to the inside of curves as you try to counteract drift, so it's a good idea to study the maps and make preemptive moves on straightaways to get positioned for the upcoming curves. Thanks to Pippa from over on the CASA Adventure database forum for showing me the PEEKs and POKEs to reset the pointer for the READ statement. This allows me not to have to re-read all the prior DATA again for the other tracks each time you restart, which really helps speed things up.

Find position of next date item to be READ and store it in variable E:
E=PEEK(173)+256*PEEK(174)

Restore next READ to the E position:
POKE174,INT(E/256):POKE173,E-256*PEEK(174)

I'm under no illusions that this game is a rival to a real Pole Position or night driver game. Like Steven, I'm just in it for the challenge of seeing whether a certain vision for a game can be carried out given the limits of the machine and the limits of Basic as a programming language. I think the game I have come up with is a nice extension of Steven's concept. In particular I'm really pleased about how I was able to make use of the only two other useful characters (dark green and light green blocks) that are available in SG6. Because of the way the MC-10 was wired by Tandy, the lower 128 characters are not really rendered properly and simply show up as varying (ugly) sequences of green and dark lines. But the two useful ones (solid dark and solid green) provide some contrast to the red and blue graphics characters. I like the "brooding" green night skyline and the dark green tires actually alternate with one's with an outer light line to add some effect of tire movement. In Steven's program for ZX the skyline is rendered by the light grey stippled block character, as are the tires, with an alternating stipple to give the tires the illusion of motion. It was a neat challenge to figure out how to achieve similar effects using the MC-10's quirky semi-graphics. I have also figured out a way to render chunky alphabetic characters using only the graphics blocks, which I used on the start/finish sign.

The start sign with graphic text

Cars collide

First level of left turn (car coming!)

3 Tracks with starting direction indicated

Here's a video of the game running.  I have chosen Track 3 (I think):

Thanks to Steven Reid for the inspiration and to John Linville for running another RetroChallenge. Please feel free to comment.

RetroChallenge 2017/10: Pyramid Solitaire

I saw my wife playing Pyramid Solitaire on the MS solitaire games collection for Windows 10. I immediately thought, hey you don't need a Windows 10 class computer to play a simple game like that!  I could program that on an MC-10!  I dug out a game I had converted recently from Coco Basic. Solo Poker by James Garon.  I had seen the original in a video by the HighRetrogamingLord:

I had simply converted it from using the hires graphics screen to using lowres Semigraphics 4 representations of the playing cards.

I had created this card set for several prior card games like Crazy 8s. Since Garon had worked out a nice little routine for "shuffling" the deck and I had already worked out routines for displaying the cards, all I had to do was figure out the rules to Pyramid Solitaire and put those routines to use. I ran the MS Card games pack and called up the help screen for Pyramid Solitaire.  A little research on Wikipedia helped clarify some issues.

First I made a routine to lay out the first 28 cards out from the randomized deck in a pyramid, starting with the top card.  Then I created a simple cursor routine to jump between the cards in a diamond direction pattern using the ASZX keys.  It just checks that it doesn't jump off into the cyan border area around the cards.  As part of that routine I took note of the card value of the current card highlighted by the cursor.  Hitting (Enter) would select and reverse video that value and then allow you to move again to select another card, or simply choose from the deck (D) or from the wast pile (W).  Pressing (C) would cycle the cards from the deck to the waste pile for a max of three cycles.

The biggest challenge was creating a refresh routine for the pyramid that would recreate the proper illusion of the cards lying on top of each other with some being only partially revealed as they alternate from top to bottom.  In the end it was simplest just to blank the removed cards and then refresh the pyramid from top to bottom and the top of the piles, but leaving out removed cards.

The whole process took surprisingly little time. I am getting proficient creating simple card games. Don't know what to try next, but if anyone out there has any ideas of card games they would like brought to the MC-10, or Coco, just let know.  Here's what the final product looked like:

And this is what happens when you win:

After playing the game for a while I got much better at it.  At one point I had a real run of victories.  5 to be exact, with no losses.  A total fluke I think.

Wizard's Castle

David Ahl was one of the giants of the earliest era of  personal computers in the late 1970s and 80s. He edited Creative Computing magazine and published several major type-in program books such as Basic Computer Games, which sold millions of copies.

I thought he was the author behind a game I had in my collection (VENTURE.C10) for the MC-10 called "Castle Adventure." The title screen mentions his name:

The instructions mention a "Wizard Bergal" and a "Orb of Zot."  I don't know where I got this piece of code. Its been in my collection for quite some time, and might have been one of the programs I had from tapes for my original MC-10 from the 1980s. Recently I came across some discussion on the Net for a "classic" Basic game called "The Wizard's Castle" by Joseph Power. The discussion mentioned the "orb of Zot," which triggered my memory of Venture. However, as I explored people's discussion of Power's game and its influence I began to realize that it was a very different program from the one I had. For example, in Power's game there are flares that can be used to shine light into all the cells immediately surrounding the one you are in. Also, you can buy a lamp, but it never runs out of oil. You can also choose other equipment (and can find better equipment in the dungeon). People commented about the simple but interesting D&D like character creation (Hobbits, Elves, Human, etc.) and equipping choices in Wizard's Castle. Such features, along with others that occur while you are exploring, were completely absent from Venture:

Clearly the program in my collection was not the classic program by Power. I had to lay my hands on the source code of the original and take a look. I went to my standby go to source for source, software repositories for the original TRS-80. I easily found references to Power's Wizard's Castle. Once I had the source roughly converted (including removing a modification that simply revealed all the locations) it was obvious that its 8X8X8 multi-dimensional array blew the lid off the memory requirements of a standard MC-10 with just the 16K RAM pack expansion. I would have to do some cutting or figure out a way to organize the info into a less memory demanding form than 5 byte floating point numbers for each array element. I began to suspect that the "Venture" program I had was a significantly simplified version of the game that made space for the massive numeric array by removing many of the minor, more quixotic features, of the original. Sadly, these features were what gave the program much of its charm. If I was going to preserve these features, I'd have to be creative.

I realized that each location in the array only needed to store an ASCII character representing the different items in each room, "B" for books, "C" for chests, etc. All I needed was to create a string space so each item could be stored as a single byte character poked into that space. As I read more about Power's efforts to create the program for the 16K Exidy Sourcerer computer he developed the game on, he'd had to do a similar thing. In fact, he used a memory space used for storing user definable characters. When someone had ported the program to TRS-80 they had simply removed this stuff and substituted simpler integer numeric array references. But the subroutines for doing all the fancy "poking" were all still there for me to re-engineer back into place a routine for poking the memory into a string space using VARPTR command (to find the appropriate locations in that space).

Eventually I got the program pared down (removing spaces, creating long multi-command lines, etc) to work in a standard 20K of the MC-10 with RAM pack. I even had enough space left over to create a simple "castle" graphic to wrap around the presentation of the grid map. The parring down also helped with the speed of set-up for the map layout, which was quite long.  Here are videos of the first version and the final product. Notice the difference in the length of time for setup:

Galaxy Trek Adventure #1 and #2

Galaxy Adventure #1

I have already ported Howard Batie's second Star Trek themed text adventures for the Coco to the MC-10. The Coco program for his first adventure, which can be found in Hot Coco Magazine August 1983, was based on an original game for the TRS-80 16K by Randy Hawkins in 80 Micro (August 1982, pp. 174-184). In fact, the version I ported might be more akin to Mr. Hawkins' original, as I based it on some source code that I found for the TRS-80 Model 100, which might have come from the Model I version rather than the Coco version.  However, the fact that Batie's name is on it leads me to believe that it must be based on the Coco version. I have source for the Hot Coco magazine version, but it's from OCR text of a scan of the article, and it was getting very tedious trying to get it into running form, so I switched to the source for the TRS-80 Model 100. I might still plunk away at the original magazine source, because Mr. Batie suggests in the article that there are some differences between his version and the TRS-80 Model I version, which might be nice to uncover. Also, the magazine version uses the technique of encoding all of the messages, so you can't cheat by looking at the source code.

There were a number of errors in the Model 100 source. Some of these problems are outlined in a Gaming After 40 blog post. I found others and corrected them. There was a big problem with how the game handled the button pushing for the impulse engines, which essentially allowed you to correct the orbit without having to solve the puzzle. GamingAfter40 suggests that the way to get rid of the Klingon guarding the Tribble on level 2 is to get the phaser, but really it was because he pushed the button for the engines on level 1 and triggered the bug (which moves the guards to the planet). The real way to get rid of the guards is to shoot all of them with the phaser. The phaser only self-destructs on the planet after you've done all the necessary shooting on the ship. There were also problems with beaming routines, that allowed you to beam down without Spock being present, but which indicate that he is present by the messages displayed. There were also some problems with how the score was accumulated.

I have bug tested the program pretty extensively and played it to completion a number of times. Here's a play-through for those who may have been frustrated by the game in their youth.

** SPOILER ALERT **

G A L A X Y

A D V E N T U R E    # 1

COPYRIGHT 1982 HOWARD BATIE

HERNDON, VA 22070

NORTH,WEST,NORTH,DOWN,SOUTH,EAST,EAST,GET NEEDLE,WEST,WEST,NORTH,DOWN,SOUTH,WEST,NORTH,WEST,GET PHASER, GET COMMUNICATOR,EAST,SOUTH,EAST,EAST,FIRE PHASER,EAST,INJECT SPOCK,WEST,WEST,NORTH,UP,UP,SOUTH,WEST,FIRE PHASER,WEST,GET TRIBBLE,DROP NEEDLE,EAST,EAST,NORTH,DOWN,DOWN,DOWN,SOUTH,EAST (IGNORE SPOCK'S REMARK), EAST,THROW TRIBBLE,GET TRIBBLE,EAST,HELP,SAY TRISAETI,HELP,WEST,WEST,WEST,NORTH,UP,UP,SOUTH,EAST,NORTH,FIRE PHASER,EAST,GET MANUAL,WEST,SOUTH,WEST,NORTH,DOWN,DOWN,SOUTH,EAST,EAST,EAST,READ MANUAL,WEST,WEST,WEST,NORTH,UP,SOUTH,WEST,NORTH,WEST,GET SHUNT,EAST,SOUTH,EAST,NORTH,DOWN,SOUTH,EAST,EAST,EAST,INSTALL SHUNT (A GREEN PANEL LIGHT GLOWS...),WEST,SOUTH,READ MANUAL (NOTE: INSTALL CRYSTALS),NORTH,WEST,WEST,NORTH,UP,UP,UP,SOUTH,EAST,EAST,SAY ENERGIZE,FIRE PHASER,GET CRYSTALS,DROP PHASER,DROP TRIBBLE,DROP MANUAL,SAY ENERGIZE,WEST,WEST,WEST,WEST,GET TRIBBLE,EAST,EAST,NORTH,DOWN,DOWN,DOWN,SOUTH,EAST,EAST,SOUTH,INSTALL CRYSTAL (STARTS A COUNTDOWN),NORTH,WEST,WEST,NORTH,UP,UP,UP,UP,EAST,EAST,PRESS BUTTON (STABLE ORBIT ACHIEVED),WEST,WEST,DOWN,SOUTH,EAST,EAST,SAY ENERGIZE,GET PHASER,DROP COMMUNICATOR,EAST,NORTH,FIRE PHASER (PHASER VAPORIZED),NORTH,THROW TRIBBLE,EAST,WEST,SOUTH,SOUTH,WEST,GET COMMUNICATOR,SAY ENERGIZE

I also completed the clean up of two simple programs taken from OCR text of scans from Color Computer Magazine and Hot Coco Magazine. The first is a simple game called SPRINKS the second is a Mother's Day graphic and simple music demo called MOTHER:

Galaxy Trek Adventure Addendum August 2022

I worked on condensing the code of Galaxy Trek Adventure #2 by Howard Batie. Now both programs fit into memory as a single program without any requirement to load an additional data file. I also did some renaming of the files:

Galaxy Trek #1 is called GALTREK

Galaxy Trek #2 is called GALADV2  but you can also load and run a file GALADV, which will print some background story for the adventure and then prompt you to load and run GALADV2.

Here's a complete walkthrough of the condensed version of Galaxy Trek #2:

More info about these adventures can be found here:

http://solutionarchive.com/game/id%2C5142/Galaxy+Trek+Adventure.html

and here:

http://solutionarchive.com/game/id%2C7188/Galaxy+Trek+Adventure+2.html

4 Mile Island Adventure: Update

4 Mile Island Adventure, not to be confused by another Basic adventure for a recent programming contest (in the 2000s) of the same name, was a text adventure made by Owls Nest Software for TRS-80 Color Computer and MC-10 in 1983. Ported the Coco version to MC-10. Made some changes in the save game routine. In addition to the object list of locations, it now also saves the following variables:
F,G,CF,TB,GB,CA (# of objects being carried), RT (reactor temperature), YO (present location), DO,NOT,DR,M
This means that you don't start fresh every time you save and re-load a game, which makes the game more challenging (as there is a countdown to meltdown).

Brief Outline:
The 'impossible' has happened! This area was devastated by a severe earthquake. The reactor has been severely damaged. The plant has been deserted. Only you can save the area from a major disaster! Your goal is to achieve a cold shutdown of the reactor at Four Mile Island. Alternative? Death!

Walkthrough:
S, E, E, S, S, LOOK DESK, UNLOCK DRAWER, OPEN DRAWER, LOOK, GET BADGE, DROP KEY, N, N, N, N, LOOK WALL, INSERT BADGE, LOOK, D, W, GET CROWBAR, GET WRENCH, E, U, S, E, LOOK FLOOR, MOVE TILE, LOOK, DROP CROWBAR, GET ID, W, N, N, N, D, GET SPANNER, U, S, S, E, N, PUSH BREAKER, N, PUSH BREAKER, S, S, W, S, E, DROP WRENCH, GET CROWBAR, W, N, E, OPEN VALVE, W, PUSH SWITCH, PUSH LEVER

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

RetoChallange 2017: Graf Spee

Came across a neat game for the Sinclair ZX81. It's a World War II naval simulation. You play the role of the captain of the German battle cruiser the Admiral Graf Spee. You must destroy shipping and avoid being captured or destroyed. I have't got it working quite yet, but I have made substantial progress.  Here are some screens showing a little of what the game will look like.

 I still have to finish converting all the lowres graphics for all the ship types.

This is likely my last posting for RetroChallenge 2017. Thanks to John for organizing another competition for this year. Thanks to all the other posters. I'm still working through browsing all the projects. They are wonderful inspiration for further efforts in my own retrocomputing hobby activities. Good luck to everyone and I hope to see you all again next year!

P.S.

Here's a video of the completed game:

RetroChallenge 2017: 4 Mile Island Adventure

Found another obscure adventure in the TRS-80 Color Computer Archive. This one's called 4 Mile Island Adventure. It's loosely based on the 3-Mile Island nuclear disaster. Everyone has fled and it's up to you to cold-shutdown the reactor.

Couple of weird things about the adventure. First the save routine seems to just save the objects array. It doesn't appear to store anything else, such as your location, the reactor temp, radiation level or how many items you're carrying (although this may be generated when you take an inventory).  So when you restore, you seem to start off at the beginning location, but you have any items you found previously.  Since you are racing against the reactor temperature going up, it seems like you can reset the clock by saving.  Don't know if this is important or unimportant, but I might change it.

There is a link in the archive to the manual by Owls Nest software. I can't find a link to the game in the CASA: Solution Archive, although there is a listing for a program of the same name written for a recent text adventure contest.

Since there's no listing, I'm working on solving it.