Monday, 21 May 2018

"Kinder Morgan" 8-Bit Text Adventure

I decided to enter the AdventureJam 2018 contest. The challenge was to create an interactive fiction game in just two weeks. Just? I didn't think it would be a problem to come up with an original  two-word parser game in that time.
And I was right. It took me less than a few evenings and a weekend. The toughest part was coming up with a story. I have been very disturbed by the development of pipelines from the Tar Sands to transport bitumen to world markets. For example, I recently wrote a letter to Minster of Finance Bill Morneau against pipeline development.  I'd also read about anti-pipeline protesters who sabotaged pumping stations. These protesters had claimed they had carefully researched how to shut down the pipelines that they tampered with. This struck me as an interesting premise.  How could they be sure that they knew what they were doing?  They would have to have obtained documents to explain how to operate the equipment.  I thought that could serve as a central premise to some adventure.
I was also thinking it would be neat to incorporate an element of decision by the player to contribute to the protests or remain a bystander, since this was what I was doing by simply sitting at home writing letters to government ministers. A response acknowledging receipt of my letter from Minster Morneau arrived on the same day that he went on TV to announce that the Federal government was going to indemnify Kinder Morgan while the challenges to its pipeline were ongoing. It was like he was flipping me the finger personally.

So I created a little fantasy called Kinder Morgan to try to highlight the importance of the issue and the critical moment in history we are living through.  My son Charlie had helped me write and mail the letter to minister Morneau while he was home on Spring Break, so I suppose I was also thinking of the game as kind of a teaching moment for him. I hope he will join the political struggle for the future and move beyond mere clicktivism.  It was truly a child's morning when I walked to the mailbox with him after our protracted political discussion and writing session.

He graciously agreed to to play test the game.  He discovered a bug/quirk. He realized that he could easily use the game save feature to simply restart and try different responses to the final puzzle, until he got the right answer.  So I made the program notice whether you had made multiple failed attempts, or had actually figured out the clues to allow you to choose right on the last puzzle.  It only gives a fully positive win message and musical fanfare if you solve the puzzle on the first try.  My wife also noticed a spelling error on the win screen when reading my sons's text with the image attached showing he'd solved the game.  Thanks to both of them for their contributions.

Sunday, 20 May 2018

Uchuu Yusousen Nostromo

A few years back I stumbled across some screenshots of a game for the NEC PC6001 called Nostromo. Since the name of the spaceship from the movie Alien was "Nostromo" it seemed likely it was based roughly on that movie franchise. The goal of the game is to foray into a series of hallways and raid 8 lockers/rooms to retrieve various items while the alien hunts you down. I didn't have a fully operating emulator for the PC6001 back then so pretty much all I had to go by was an animated gift:
Based on that gif I came up with the following rendition of the game. I found the 8 box layout a little boring, so I added a little variety. So I alternated a second style of map. Since I didn't have a clue about the scoring or what the second number meant of the two number at the top left of the screen, I just had the player hit a key when she returned to base in the red area to signal that she was finished collecting.
Fast forward to today and Robert Allen Murphey on the Coco Facebook group mentioned that he was going to take a stab at playing my port. But he used a Japanese title for the game "Uchuu Yusousen Nostromo," which means, I think, "Space Freighter Nostromo." These additional words gave me some additional terms to search for to find out more about the game. I also had been able to get a working PC6001 emulator in the meantime, so I was able to download the game rom image load it up and extract the Basic source code. Although the game is credited to Akira Takiguchi and Masakuni Mitsuhashi on many sites, I noticed that the Basic source code had a set of remarks at the top indicating it was copyrighted by Hiromi Ohba. Here's the link to the original website I found that gave me access to the source code:
Although I was able to load the game into an emulator by James "the Animal" Tamer called "VTrek" (for virtual NEC Trek--the name of the version of the computer unsuccessfully distributed by NEC in North America) either bugs in the emulator or differences between the NEC Trek and the PC6001 wouldn't allow me to run the game. So I had to rely on a video in which a Russian vlogger, Panteryasha, does a walkthrough/review of the game:

Later my son Charlie used some of his computer voodoo skills to download the subtitles of the video and translate them into English, which was really helpful. For one thing, Paneryasha noticed a bug that occurs in higher levels where you are required to collect 7 of each item, but the algorithm that randomly creates the layout of the items in the rooms/boxes (versus blank spaces and purple barriers) can only guarantee a maximum of 6 items for each item type. So you could end up with a screen that it was impossible to clear. However, unlike Panteryasha, I was able to see in the code that there was a possible out. You could let yourself be killed and then hit the "h" key and the screen would be re-drawn with new resources and a time penalty. I changed the 'h' key to "H" and instead of a time penalty I made it so that you lost any points you had accumulated on that screen.

This feature is not just useful for higher levels. Even on lower levels, if you are killed while carrying a load of items, you must then go back out and get at least enough new items for one of the item categories to push your number over the number required for that screen (the second number at the top left). Unless you reach that number the computer will not register that you have collected any items or give you a score for them when you return to the red home base.  However, if you have collected all the items on the screen before returning to your base and are killed, then you will not be able to have those items scored so you can complete the screen. I suspect the programmer added the "H/Help" restart feature to allow you to sacrifice a life in order to continue. The moral of the story is that you must get back to the red base area with at least one category of items at the target number if collected items are to be registered for scoring purposes.

I also replaced with pure Basic all the machine language calls and code in the original that handled player and monster movement. The NEC PC6001's Basic was a little slow, so I suspect that the programmers had to use machine code routines to get speed for the player and monster movement. Luckily the programmer used Basic for all the scoring and screen transitions. I did use a M/L Timer USR function provided by Darren/Mechacoco to handle the countdown timer part of the game, so it should portray accurate seconds. Thanks Darren! And thanks Charlie for translating the comments of the Russian reviewer for me.  Here's what I came up with:
The sound routines were still petty rough.  It took me a while to figure out some of the quirks of how the NEC's SOUND and PLAY commands work. Turns out some of the SOUND commands are just meant to reset the sound chip in various ways and not actually produces noises, so some of the sounds I thought were in the program were not really supposed to be there. I thought I had got a pretty good bug-free version when I noticed a really bad bug. I had never tried shooting at the outside white wall when I was play testing because I knew shooting was for the rooms in the interior, so I didn't notice that you could shoot the exterior wall and escape the screen and have your character POKE into memory areas where you shouldn't be allowed to go. I also added a saved high score feature. This necessitated re-working the main loop a little. Because the original program would simply re-RUN the whole program every time you lost, the programmer didn't care about properly RETURNing from the various main subroutines or resetting variables to zeros, etc. But since I wanted to save the high score from game to game I had to fix these problems. I also noticed that the nearest item type was worth more points (25) than the farthest (10), which seemed odd.  I reversed this order so that risking a longer journey to the left of the screen would be rewarded with higher points. I also changed the original T key layout to be further right on the keyboard, which was more comfortable. And I reduced the time allotted for each screen, as the original amounts seemed excessive:
It has been a long journey getting to a working rendition of this apparently classic Japanese early 8-bit game. It's even, if  Panteryasha is correct, considered one of the first examples of a horror game. This is apparently a result of the cut scenes with the monster and the higher levels when the monster flicks in and out of view, which is kind of creepy and a bit suspenseful. Still, I wonder whether it is true that is the first horror game. I'm aware of at least one game "Alien" for the ZX81 that has similar features, also based on the Alien movie, which might possibly be as early:
Both programs are dated to 1982 by various sources on the Net. I'll let retro-gaming archaeologists figure this out.  In the meantime, I hope some folks might  have some fun playing the MC-10 versions of these classic games.  If you are interested you can now download all my games and the VMC10 emulator by James "the Animal" Tamer from my GameJolt site: There are some instructions there that will help you get whatever program you are interested in running.  Here's a link to a full list of my games: My most recent version of Nostromo is called "NOSTRO.C10".  The older version is called "NOSTROMO.C10".  I have left it there for historical purposes, but I really recommend playing the newer version.

Sunday, 29 April 2018

RetroChallenge 2018/04: The Golden Sphinx

The Matra-Hachette Alice was a home computer sold in France starting in 1983. It was a clone of the TRS-80 MC-10 produced through a collaboration between Matra and Tandy. The Alice was distinguished from the MC-10 by its red case.

Unlike the MC-10, the Alice became a fairly popular computer and Matra later released two successor models with much improved graphics and a built-in assembler. The Alice 32, released in 1984, shared the case of the original, but was a different computer inside with the EF9345 video chip in place of the MC-10's Motorola MC6847. It had 16K memory as standard. The Alice 90, released in 1985, featured 32K and a full-size keyboard.

Because of the introduction of the EF9345 not much of the Basic software for the Alice will work with the MC-10. The EF9345 is capable of 40 and 80 column text and most of the software you can find on the Net uses one of these modes. However, a few programs still use the 32 character mode. In order to maintain some backwards compatibility, Matra made a special screen using the 40 X 24 screen with a 32 X 16 window positioned in the middle and a black border around it consisting of the unused rows and columns. This means that you can still gain access to the columns and rows around the 32 X 16 screen through the use of PEEKS and POKES. I found a Basic game for the Alice that uses this 32 X 16 mode (mostly) with only a few hires embellishments and a few screens that use 80 column mode directly: The Sphinx d'Or.

As you can see from its intro screen (with the pyramid--not the Sphinx), there is a colourful banner around the standard semigraphics screen. There are also some hires embellishments to the standard semigraphics block graphics of the MC6487. The sides of the pyramid have been smoothed, and in the second picture there are some rays that have been added to the sun.

But besides little details like these, it is essentially a Basic graphic text adventure that uses mostly standard SET/RESET block graphics. Of course, it is in French, but with the help of my son Charlie, who was home from Dalhousie University and a graduate of late French immersion for grades 6-9 here in Sydney, and Google translate, it wasn't long before we had English versions of all the text messages. Thanks Charlie (there's an Easter egg in the code in honour of you)!

Then I just had to convert a few of the screens that used the 80 column mode. Also, the original program from the Alice was split in two parts and had a multiple- loading process for different parts of the story. I think this was because the Alice 32 only has 16K RAM (and a 16K ROM--hence the name Alice 32). But I was able to combine both programs into one that fits entirely in a 20K MC-10 (4K + 16K RAM pack) by using the RENUM command that comes with MCX Basic. The first part of the program had the starting screens and also the final game completion puzzles and win routine. A value was POKED into memory that was preserved between loadings that re-directed program execution to the intro or completion routines depending. So you had to load the game, then load the second part, and then re-load the first part to complete the game. There is a version of the Master Mind game in the completion routine that used the 80 column screen and graphics. I was able to create new semi-graphic images for this and all the other aspects that used hires. The only hires thing I couldn't recreate was that fancy permanent woven banner around the screen. But you can't have everything. But, banner aside, we now at least have a new piece of software for the MC-10 compliments of the French. Merci beaucoup citoyens du france et Monsieur Schwartz!

I still have to solve all the riddles of the adventure, but I have tested most of the individual parts of the game. When I'm confident that it is bug free I'll post about in the Interactive Fiction Database, etc. and see if I can find some volunteers willing to try to solve the game and test it more fully.
Original tape cassette box art
I also have completed some minor projects such as adding James Diffendaffer's speed-up POKE to a bunch of my existing arcade games and Darren's Atkinson's (Mechacoco's) keypoll routine that allows multiple keys being pressed at the same time on the keyboard to be registered at the same time. This allowed me to create a version of Tandy's two player Pong game that does't allow the other player to block your key input by holding down his keys. This represents true two-player arcade action coming to the MC-10 for the first time.

Here is a partial list of my activities over the last several months that I have been wanting to blog about:

STORM an original game using Semigraphics 6 mode.
ALATTACK is original game for the 10 Liner Basic Contest. Roughly based on game "Alien Attack" by Scott McCann and Peter Lear.
RACEDRIV is a port of some obscure code from a Dragon 32 Magazine I found on the net.  Taken from a page scan.
ALERT10 is an original game that tries to recreate a Defender style game in 10 Lines of Basic code.  Little slow in starting up, as it has to build the scrolling map, but interesting once it gets going.
MAZERACE was also for the 10 Liner contest.  Mechcoco moded it with some machine code to draw the maze in a blink of an eye! Not a legitimate entry for the contest but still amazing; literally! Thanks Darren!
TEMPEST is a port of a Coco game created by Carangil for the 10-Liner contest. It requires the hires commands of the MCX pack.
C-TREK is a port from a Coco Version of the Classic Star trek game.  I have about a half a dozen different variations of this type of game now for the MC-10. I added a little text graphic of the "Enterprise" to the title screen.
VAMPIRE is a text adventure from Australia, originally for the TRS-80 or possibly one of the other TRS-80-like clones. I took my source from the Commodore 64 version though (if I recall correctly).
Robert Moore posted on the Coco Facebook page asking whether there were any other "Stellar Empires" addicts out there. This prompted me to look this game up. STELLEMP is a port from the Coco variation, although I started using TRS-80 Model 1 source code that lacked an AI computer player. It's another variation on the space-trading-empire-building genre. This one has lots of combat and up to 4 can play. I have converted a number of similar games to MC-10, including what is likely the original of the genre, "Star Traders" by Dave Kaufman, and "Andromeda Conquest" by Avalon Hill.
Star Traders
Andromeda Conquest

Stellar Empires
I think this is likely my last post for the RetroChallenge month. To sum up: I was able to finish working on my MC-Chase game for the MC-10 and then convert it to Coco Basic in time for Coco Fest. And I did the same for Dig Dug. I also accomplished some bug testing of my port of Bruce Moore's "Forest of Doom" Coco hit. I'm pretty confident that version is bug free too. And I have a working version of the Golden Sphinx ported from the Matra Alice.

I send thanks to all the other RetroChallengers. I've been a very busy at work this month so I have had little time for looking at everyone else's projects, but I look forward to browsing them over the coming months.  And thanks to John Lineville for running the contest.

Friday, 20 April 2018

RetroChallenge 2018/04: CocoFest Version of MC-Chase and Contest

In honour of CocoFest. MC-Chase! And a contest. Get your name on the splash screen by deciphering the secret mystery message!


I got a coco version working just in time for the Friday night start of CocoFest. In the course of completing it I was able to sniff out a few bugs in the later two maps. Hopefully got them all, but I'll have to wait till I have some more free time next week to do some through play testing. In my haste, to post the Coco version, I let a bug slip past. It involved the routine for managing the coloured sections of the walls. You can see in this video, when I move towards the end of the long side wall.  The end section remain the same color as I move towards it:

I also had a spelling mistake in the REM instructions for the contest. See if you can spot it (watch both videos)!  3DMCHASE.BAS can be found on JGGAMES12.DSK in my zip distro of my Coco BAsic games:

or from my Google drive file space:

Not sure if anyone will even take notice of my challenge at Cocofest. It's difficult trying to participate from a distance.  And I don't have the promotional flair of Bruce Moore. But I hope someone might eventually take up my challenge. The trick is to get to the third map and then examine the maze structure for a secret mystery message. Tell me what the message says and show a picture or video of the screen, and send an e-mail to and you will get you name on the splash screen in the official version of the game, eventually to be uploaded to the Coco Archive.  The winner will be the person with the earliest e-mail time stamp.

Also made a coco version of DigDug and included on JGGAMES12.DSK. The semi-graphic design was by Carlos Comcho, and he also contributed the intro theme song based on the original game.  My son Charlie (just home from Dalhousie University), contributed the fanfare when you complete screens.  A real cooperative effort. Thanks fellas.

And greetings to all the Cocoers at CocoFest 2018!  Have a great time. Wish I was there!

P.S. My son Charlie came home from University and helped me with testing both games.  More certain now that the MC-10 versions are clear of bugs.  Thanks Charlie. However, when we looked at my sister's old Coco2 (which lives in his bedroom), it turns out it had been left on for who knows how long, and I think  some of its ICS got cooked, so no way to test the games on a real Coco2.  Will have to swap out the Coco 2 for a Coco 3 and see if I can get the games running on it. Will let you know.

Tuesday, 17 April 2018

RetroChallenge 2018/04: 3DMCHASE--Faster Yet!

I've been working on speeding up the wall rendering part of the program and a few other speedups.  Renumbered the code at one line increments, because that can also help a little with speed, as the main routines are at the top of the program and switch them from 3 digit line numbers to 2 means one less digit to interpret for GOTO and GOSUBs. You be the judge if you can discern any speed increase from prior versions (maybe turn the music off, as my choices might influence your perceptions:). Here's the latest:

And the prior version (demonstrating the multiple screens):

Also been testing the 3 new screens I added.  I have yet to play three three whole maps to get to the next map. Will have to do a full playthrough without tricks to make absolutely sure everything works. Right now you get a new map after completing the prior map 3 times. The third map/maze has a secret message, which you will be able to see if you get to it, or if you can read the code very carefully. But I think it will be hard to discern using the code reading method. Maybe this will entice someone to try to get to the third screen (i.e. nine successful clearings of the mazes). I won't, however, be offering an MC-10 mug for the first person who does and deciphers the message. But maybe someone out there who might be willing to put up a piece of MC-10 swag to encourage some friendly competition. Who knows...

My plan is still to port the code to Coco. Hopefully with the speedup poke it will be even faster. I'll wait until I've got all the bugs out of the MC-10 version before doing the conversion, as its annoying to then discover bugs and fixes and have to work on both versions simultaneously. I might also try to convert my DigDug program too, if I can find the time. I've been very busy with marking, as it is end of term at the University and I did an overload course. Still, Basic coding is a nice way to wind down after a day of marking exams and papers. Ah the joys of pure logic!

Saturday, 7 April 2018

RetroChallenge 2018/04: MC-Chase the Continuing Evolution

I've added two maps to the game. You get a new map every 3 completions of a map. The third map contains a "secret message." The maps are saved as DATA statement lines. Since the speedup routine by James Diffendaffer also uses DATA statements, I had to create a routine to restart at the first map DATA statement after you lose your last man. Pippa's POKE/PEEK routine for doing a RESTORE to a specific POINT in the DATA statements was helpful in accomplishing this:


Her routine effectively provides the same ability that other Basics have of including a specific line number with the RESTORE command to have data reading begin at that line. In fact, it is even more flexible because it allows you to choose which specific data item to restore READing to once you repoke the saved value (in the example above OD is used to restore the memory address located by the PEEKs done at line 8).

My plan is to convert the game to Coco after I've got all the bugs out. I'll then release both versions during Cocofest. I won't need Pippa's routine for the Coco version because I won't be using Diffendaffer's speedup M/L routine. Instead, I'll include a routine giving the option to use the standard Coco 2 or 3 (or Dragon) high speed POKES.

Sunday, 1 April 2018

RetroChallange 2018/04: The 'B'

I have been working on my new game for Cocofest. I am calling "MC-Chase."  I have got the wall rendering  of the 3D maze about as fast as I will be able to get it. I have the giant "B" that eats you if you're not fast enough. I have an AI for the 'B' based roughly on the same routine I worked out for DigDig. I have the routines for displaying and converting Cocos to MC-10s and keeping track of the score and high scores. Not much more to do. I think I'll just take the rest of April to search out those minor speed-ups to the code that always seem to be possible.

Next post: Some more info on my 10-Liner games for the 10-Liner Basic programming contest. I think I will also try to make a version of Frogger in 10 lines based on a graphic by Carlos Camacho:

No automatic alt text available.

Thanks Carlos!

Monday, 26 March 2018

RetroChallenge 2018/04: New Game for Cocofest

Working on an idea for a new game for Cocofest.  Here's a screenshot:
The premise I'm working on is the following:
The game is based roughly on the idea of 3D Monster maze. I will release it at Cocofest. Got lots of work to do to get it to a playable state (if that's even possible). Will keep you posted.

Saturday, 24 March 2018

RetroChallenge 2018/04: Dig Dug and FOD Updates

I have been fiddling away on both Dig Dug and Forest of Doom. On FOD I have been able to make some real improvements to the sound routines around combat and random messages. To make room for these new routines I have been combing the code for more memory savings. I found that I could really pare down the input routines. While doing so, I was also able to add a T structure for directional key input. Now TGFH can also be used in addition to the cardinal directions NSEW. I also found some redundant code that seemed to have been related to the Break key. And I improved on screen formatting. Since I have been playing the game quite a bit, I found a few places where I needed to add clearing the screen from the current cursor position calls. I sped up the sound and slightly fixed the music for Inns and also added back a few routines I had left out for space saving. I think I have sounds now for all the routines in the original program.  And I have more space left (300 bytes) than I had a week or so ago (250 bytes).  Here's a vid:
I have also been combing through DigDug. Found some more speed ups there too. It's quite fast now. In playing it, I felt I should re-adjust the scoring a little. I made rock dropping worth 80 if you kill the monster and inflating them worth 20. The disparity struck me as a little bit too extreme (90 versus 10).  Also adjusted the fire breathing and laser blast a little so they appear a little more clearly on the screen before being erased.
Played Dig Dug to the point that I confirmed that you earned a life recharge at 500 and 1000. Should also work for 1500 and so on. I still haven't played FOD to a win. Whenever I get to level 6 I run into something like a Dragon that just does me in.  At that level, especially after you get the scepter, the monsters just come thick and fast, almost every time you move a space. I haven't had much luck with getting the mirror or magic book from the innkeepers, nor much success with digging up X's. I play at level 2 so I can find the Xs but I just don't find them that often and they're usually a trap.  I think you must have to win the sword and find the mirror and book to have a chance to make it out alive.  I have tested these routines by way of  breaking and using GOTOs to get to them, as you can see demonstrated in the video. I have even won this way. So I know these routines work. But I wonder if there is some bug in my port that somehow makes it impossible to win. It would be nice if some of the pros out there could play the MC-10 version to see if it is operating comparably to the Coco version.  Maybe some folks at Cocofest?!

Anyway, I'll have to send the latest version on to Bruce.

Next postings I'll talk about my recent 10-Liner submissions to the 10-Liner Basic game contest.

Thursday, 22 March 2018

RetroChallenge 2018/04: Dig Dug Final Installment?

I thought I had finished Dig Dug but Carlos Camacho, the graphics design artist on the project, posted in the MC-10 Facebook the notes for the background/intro music of the original game. He thought that when Allen Huffman gets his sound-through-the-serial port device working it could be added to play in the background in some future rendition of the program. I'll certainly do that. In the meantime I had been feeling the existing game start routine that flashes our names could use a little music. It only had a silent pause between my name and Carlos' name. So I used my sound routine developed for FOD to play the refrain while our names are being displayed when the program is first run.

Here is what he posted:
10 PLAY "T8;O1;F#;G;G;G;G;G;G;G;G;G;G;G;G;G;E;D;E;D;E;D;E;D;D#;E;E;E;E;E;E;E;E;E;E;E;E;E;E;D;E;D;E;D;G;F#;G;G;G;G;G;G;G;G;G;G;G;G;G;E;D;E;D;E;D;E;D;D#;E;E;E;E;E;E;E;E;E;E;E;E;E;E;D;E;D;E;D;G"
20 PLAY "T8;O2;F#;G;G;G;G;G;G;G;G;G;G;G;G;G;E;D;E;D;E;D;E;D;D#;E;E;E;E;E;E;E;E;E;E;E;E;E;E;D;E;D;E;D;G;F#;G;G;G;G;G;G;G;G;G;G;G;G;G;E;D;E;D;E;D;E;D;D#;E;E;E;E;E;E;E;E;E;E;E;E;E;E;D;E;D;E;D;G"
100 GOTO 10

I'm posting it here in case anyone else might find it useful and because its a convenient place to go back and get it from when I need to use with Allen's device.

I also (of course) found a few more tweaks to the code to make the main loop just a little bit faster (I think). I should also mention that I built in James Diffendaffer's M/L speed-up routine. It's one little tweak to Microsoft Basic (something about using the 0 page), that he estimates speeds up execution by 1-2%. Only a little bit, but every little bit helps!

0 REM01234567890123456789012345678901234567890123456

1 CLS:GOSUB3000:GOSUB10000:GOTO100:REM program start line number

9998 DATA60,54,55,150,246,129,126,38,25,220,247,195,1,5,131,1,1,221,252,206,67,113,236,1
9999 DATA221,246,236,3,221,248,236,5,221,250,51,50,56,57,240,129,58,37,1,57,126


I've added it to many other programs in my arcade collection as well:
Here is a link to that collection:

Tuesday, 20 March 2018

RetroChallenge 2018/04: Finishing up Dig Dug

After getting the basic AI working for the monsters I started implementing some features from the original game. In the original, after you kill all the monsters but one, the last one will make a break from the surface and high tail it to the left of the screen. In my version I made so that if any monster gets to the blue at the top of the screen it heads west at high speed.
I also added the inflate attack of the character. It was too difficult to implement a multiple inflate process until the monster pops--that would involve too much processing and overhead. But now you can shoot a hose at the monsters who then inflate to fill their block, before "popping" for 10 points. The hose is short enough that you have to let them get uncomfortably close to launch such attacks.  Also, you have to be pointing in the desired direction. The pipe sections get left in place, which saves processing and keeps the game flowing and has the added benefit of allowing the player to create temporary barriers to slow enemies--All characters have to take an extra turn to clear pipe before they can proceed through that space.  This at least partially covers the role of inflating in the original, which can serve to temporarily stall monsters.

I messaged with my son Charlie over the weekend and he agreed to work up a little fanfare based on one from the original game to play at the end of clearing the screen of monsters. Thanks Charlie!

I also combed through the code and as usual found many ways to speed it up. One neat trick I came across recently was using a FOR/NEXT loop with a STEP 0 for the main loop. This allows an indeterminate loop which you can trigger an exit from by setting the variable.

10 FOR A=0 TO 1 STEP 0
50 END

I haven't checked it but I suspect that using a NEXT statement without a variable is a probably a faster way to loop than using IF statements and a GOTO with a LINE NUMBER.  A little less processing involved. Maybe I'll try these benchmarking programs and see what I get:

10 FOR A=0 TO 1 STEP 0
20 B=B+1:IFB=10000THENA=1
50 END

10 B=B+1:IFB=10000THENA=1
30 IFA=0THEN10
50 END

Yep.  The FOR/NEXT finished many seconds before the IF/GOTO routine.

I added "flowers" to the top left because when you kill a monster I simply blank its strings and set its coordinates to the upper left. So I needed some characters around the hidden character, which it can't move through. Since I added the ability of the monsters to move into the blue, I had to allow the characters to enter blue spaces, so I put the flowers in to "trap" the hidden dead monsters.

I made it so that when you drop a rock on a monster you get ninety points. This gives the player an incentive to work at trying to trick monsters to go under rocks. As further incentive you get a recharge of your lives every 500 points. Since shooting the monsters at short range can give them opportunities for them to get up close and shave off lives from your initial 10. You need to work at balancing the risks of shooting and crushing to make it to the next 500 points to get a recharge. I also made the seeking AI routine get more acute at tracking you as you clear more screens.

Finally,  I added a random fire breathing/laser shooting routine to the monsters, which is further incentive to crush them at a distance rather than just get up close and fire away and risk getting fried. I reused the same subroutine as the player's pipe shooting routine, except using alternate graphics (yellow lines versus the "pipe" pieces) that disappear immediately as they fly away from the monster (very fast like a flame or laser). The frying gets more frequent as you clear more screens.
It's a very tough game, maybe too tough now that I have sped it up further. Hard to tell. The problem is I don't like playing games--just making them. So I don't do as much play testing as I probably should. Which means I can't really be sure if the game is complete crap, so any feedback would be highly welcome!

Sunday, 18 March 2018

RetroChallenge 2018/04: Forest of Doom Port--Beware the Shadows!

Bruce Moore's "Forest of Doom" has been a bit of a sensation in the Coco community. I thought it would be nice to try to convert it to MC-10 so I sent away for Bruce's book and the code to download the game. When the book arrived I fired up Vcc and loaded up the program and LLISTED it to a text file and started pouring through the code. It is a complex game and it took a lot of play testing and watching Stevie Strow and Crew playing it to figure it out. There was a mysterious machine language routine embedded at the heart of the basic program that seemed to do a lot of different things. I'm still not sure if I have figured out everything that it does, but based on watching game play and playing it myself I have uncovered at least the following basic functions:
·         clearing to bottom of screen from current cursor position
·         screen bounds checking for cursor movement on map screen
·         time keeping and sound for countdown till next hit
·         time keeping for checks for wandering monsters
·         “Inn now” secret key press (still don't know how many it will allow)
There may be more mojo hidden in there, but I'm not sure. Bruce has told me he'll try to dig up the source and send it to me, by the time of Cocofest.  He's busy with another project to follow up on FOD.

The big challenge in converting the program was coming up with a memory efficient way to try to recreate all the nice music and sound in it. It is impossible to recreate everything using just sound commands, but I tried to come as close as possible without the help of my son Charlie, who is away at university. I came up with a simple routine for encoding a string of note letters and a number (for length) which could be sent to a subroutine.  I came up with this:

0 DIMN(21)
1 CC=1:FORC1=1TO63STEP3:N(CC)=VAL(MID$("073093102119134141154166176180189196200206212217219221227229232",C1,3)):CC=CC+1
10 M$="G4G4G4A4B4B4":GOSUB4

Line 1 is the initialization of the routine with the note info. You create a string M$ and GOSUB4 to call the routine. Line 10 demonstrates such a string and call. The routine uses ABCEDFG and then HIJKLMN and OPQRSTUV for the next two octaves up. I actually used the O-V range to encode some flats needed for FOD, so that version is slightly different from the generic one above.

Like my port of Caves of the Unwashed Heathen I also had convert the graphics into simple strings of semi-graphics characters. Vcc allowed me with the help of a little basic subroutine, to print these out to the printer port (i.e. text file on my PC). Then I could edit them into text strings condensed as much as possible to save memory space. I also had to figure out ways to use some of the graphics for multiple purposes, such as the iconic red tree, which is used for the title screen and final death screen. On the Coco version there is no need to use such memory saving techniques.

I worked out rough equivalents for many of the sound routines from the original, at least to the best of my limited musical abilities  Here’s a vid of an Alpha version:
I have left it to Bruce to decide if he would like to pursue sharing my version with the wider MC-10 retro community.  I think he's waiting till Cocofest where he might be able to have some of his game testers take my version a spin to see if it really works. I’m sure MC-10ers would be very pleased to participate in the excitement he created in the Coco fold.  In the meantime I am continuing to play and bug test. Here is a vid of the latest version with the most recent music and sounds:

Had to do a lot of condensing to make space for some new sound routines related to the combat subroutine. When I was doing this I came across some REMed lines, that I think were an attempt to implement some special behavior of the Shadows on the first level. One of the clues given by Innkeepers is that "A shadow is not always what it first appears."  However, I had never found anything obvious in the code in terms of printed messages that would indicate anything special about shadows. But I did notice two REMed lines referring to monster #5. A quick look indicated that this was the number for shadows. It looked like what the lines were supposed to do was present a message when you were attacked by a single shadow (which can only happen on level 1) that you were being attacked by a Shadow and then swap the monster number for a random monster (1-10). Not sure why it might have been taken out but it might have been because of complexities with the monster names which are processed to deal with plurals or single monsters and then saved in three strings for different purposes.  Or maybe the shadow routine got put in the mysterious machine language helper program somehow.  In any case, I re-implemented the REMed lines and made them report an attack from a shadow and then choose and list a random monster in the upper area of the screen. So if you don't check to confirm what is attacking  you, it could be something you don't expect!  Beware the shadows, they may not be what they first appear!

RetroChallenge 2018/04: Dig Dug's Artificial Intelligence

The next major task at hand was to give the monsters intelligence.  I did this with a sequence of ON/GOSUB checks.  Here's the main LOOP

20 K=K(PEEK(2)ANDPEEK(17023)):C=1:ONKGOSUB2,4,6,8,50:FORC=1TO3:ONK(PEEK(R(C)+M+32))GOTO21,21,11,21,10

In line twenty there are two ON/GOSUB statements. The first is for the player's movement. It jumps to line 2, 4, 6, or 8, which process legal moves and then place the character. The next FOR/NEXT loop for three iterations checks the rocks and then drops them if they only have black space under them.

Line 21 and 22 are where the enemies move. They use the same character arrays as the player character to store their positions and strings (looking left, looking right) and so they can use the same 2,4,6,8 move check subroutines as the player character.

The first IF checks if a random number is higher than a level variable G. If so, then Xs and Ys coordinates for the character and the monster are compared to allow the monster to home in on the character's position. A direction for X is chosen first and checked with a GOSUB to 2 or 4 (horizontal directions) and the same happens for 6 or 8 (vertical directions). Then there is a jump to the beginning of the main loop.

Line 22 is done only if the IF level G variable check failed in line 21. It just tries to move the enemy in the last direction chosen in line 21. It also tries to move the character in a random direction.  It then checks if the character has been killed yet and jumps to the top of the main loop.

This is the basics of AI of the enemies. Next post I'll discuss some cleaning up and improvements to the main loop and the behavoir of the monsters.

Friday, 16 March 2018

RetroChallenge 2018/04: Dig Dug in BASIC

Welcome to my first post for RetroChallenge 2018/04Carlos Camacho posted in the Coco Facebook group some semi-graphics 3 mock-ups:
They were meant to be inspirations for games using that mode.  He used the drawing tool that Davie Mitchell came up with for the Dragon. His mock-ups included Mario Brothers and Joust. Thought I would try to bring one to life. I chose his Dig Dig graphic to start with (see upper left corner above). Converted his idea to semi-graphics block characters for the MC-10 using my SKETCH program.  Then I just printed the screen to text output and used wordpad to edit that output into 16, 32 character lone screen lines with PRINT statements added. Also drew some simple characters. The astronaut character is cyan and there are also green dragons and a nondescript purple crawler of some sort.  This video shows the simple random motion I started with:
Next step will be to add some intelligence to the monsters and decide how much of the game dynamics can be implemented in a tight main BASIC loop that still allows for a challenging game.  Here's a video of the original arcade version:
Carlos also sent me a helpful link to the basics of the history of Dig Dug.

Tuesday, 9 January 2018

Underground Adventure (Duckworth)

Nearer Turn Bear
| | |
100ft Drop Bricked Around Gate Mix Large
| | | | | |
Vast Chasm Heart Deep Wall Entrance E/W Tree Twisty Old
| | | (Rope)
Rock Jumble Chasm Rock Cave Chasm
Sharp Twist Main
| |
West Mine Offshoot Choice Long Drop Twist E/W Dead End
| (Axe) \ | (Parchment) (Dynamite)
Panther Bottom Twisty

I have ported the text adventure "Underground Adventure" by Peter Gerrard found in the book series "Exploring Adventures" by Duckworth publishing house. I worked from a Dragon 32 version. The game is evocative of Colossal Cave Adventure (the original text adventure), in that it involves a descent into an apparently ordinary cave, which quickly turns from a mundane to a magical realm. There is a magical bridge in both and mysterious mists and twisty passages. And a sinister "living gargoyle" (instead of a dwarf) occasionally shows up to throw knives at you.

There are two other Exploring Adventures games. The main purpose of all three programs was to illustrate how to program your own adventure games in BASIC on a variety of 8-bit home computers systems (C64, Atari, Spectrum).

The map above is incomplete. It only illustrates the preliminary rooms. The adventure is quite extensive and took quite a bit of squeezing to get it to fit into the 20K of the MC-10. Most of the classic 8-bit systems had a least 32K to work with. Using my standard techniques described elsewhere in my blog posts, I got it below 20K. I condensed and simplified descriptions and you have to load the direction data from a separate file to avoid reading them into an array variable from DATA statements which then are redundantly left in memory.

In the course of doing the port I changed what I felt were some unclear or inconsistent descriptions and items. The most significant "alteration" was the use of the terms "track" and "cave." For example, there is an instance in which a track must be "oiled" so that it can "slide away" to reveal a blocked entrance. The use of these terms seemed to indicate to me that the "caves" were actually an old abandoned mine and the obstruction was actually an old mining cart, so I "fixed" the use of these terms in various descriptions to fit that theme better.

There were also several errors in the code I got from the Dragon. The axe could be thrown even if it had been dropped somewhere else.  It then would appear in the room you threw it in and could be picked up.  Also there was a place where you could go east but not back west for no apparent reason.

I maintained a save-game feature, but it involves saving and loading two separate array variables. The first file is called "UNDRGAME" the second "UNDROBJS." Couldn't unify them into one array as I have done for other games. Just not enough memory. Little clunky, but workable.

Here's a vid: