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!
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.
I have finished porting two Greg Hassett adventures. "Atlantis" was ported from a Coco version. It was very buggy and the screen formatting was very weird. It also lacked save and restore routines. So I had to go back to the TRS-80 16K version and put them back in based on what I found in that source code. I have played it through using a walkthrough, so I hope it is pretty much bug free now.
I also ported "Enchanted Island." I used source from TRS-80 16K source. Working on Atlantis had prepared me well for Hassett's programming style, so this conversion went very fast.
After completing these two adventures, I realized from internal advertising that Hassett displays in them that he had set of adventures.
59000 R1$="TRY SOME OTHER GREG HASSETT ADVENTURES: JOURNEY TO THE CENTER OF THE EARTH, THE HOUSE OF SEVEN GABLES"
59005 R2$="KING TUT'S TOMB, SORCERER'S CASTLE, VOYAGE TO ATLANTIS"
These messages get displayed at various occasions, such as when your character reads a newspaper, or at the end of the game. I realized that I had previously ported the others. So I went back and fixed them up to use a common visual aesthetic (eg. solid line demarcating main messages from input prompt). Now I have a set of six Hassett adventures:
I noticed a BASIC adventure "Dr. Livingston: The Search For" listed on Curtis Boyle's site. I have searched through many Coco archives, but I couldn't recall every seeing a copy of this game. I also found a listing for it under Gaming after 40 blog. It sounded like an interesting game, that was having a little fun with the famous story of the search for Dr. Livingston, who disappeared into the heart of Africa in the early period of European contact with that continent.
I also found a listing for it under the Interactive Fiction Database. The reviews were't very good, but I think this was because most people had played an unofficial version of it for the Commodore 64 that was a little buggy. Here's what I said for a review I wrote for the the database:
I have read the other reviews and can't but wonder whether some of the frustrations result from the versions they are playing. The parser is not so problematic in the TRS-80 versions of the program. These machines often ran in all caps mode (the original TRS-80 didn't have uppercase characters and the TRS-80 MC-10 never had them). Apparently there were also changes made to the puzzles in many of the unofficial versions. The TRS-80 version I ported remains entirely true to the original TRS-80 16K version.
There are some intentional inconsistencies to the movement in the game. I didn't find them all that bad (especially compared to some other games from the era). For the most part I think they were carefully chosen and meant to enhance the effect of being "lost in the jungles and savannas" of central Africa. To a large extent, I think this technique works successfully in this adventure, where the setting makes it appropriate to use. Once I had some mapping in place, it wasn't all that problematic and there is a kind of logic to the backs-and-forths.
There are some really charming aspects to the game. The quicksand graphic is a wonderful piece of TRS-80 chunky pixel 8-bit animation. If you die the program simulates a return to the basic command prompt, before surprising you with a resurrection to a restore point part way into the game (preventing a need for a complete restart).
The game is challenging and doesn't have any of the totally arbitrary deaths that are so common in games from this genera. I found the plot to be a nice balance between slightly humorous almost fantastical whimsy and an attempt to remain true to the Victorian mythology of the original quest for Dr. Livingston.
For fans of 8-bit Basic adventuring I would highly recommend this game. But for less hardy souls, it might be better to stay away from venturing into the dark heart of the Victorian imaginary.
I had asked if Curtis could put his hand on his copy, but it sounds like he's buried under a pile of original disks. He said he'd keep his eyes peeled. In the meantime, I put my hands on the original TRS-80 version of the source code and over Good Friday and this Easter Weekend I plunked away at converting it to Micro Color Basic. I don't think I have ever come across so many convoluted long IF-ELSEIF lines before. Some took a number of different stabs at it before I got them right. The really fun part was re-creating the graphic for the jumping character animation.
I ran into some snags at the end in the form of some strange behaviour with FOR/NEXT loops. I think this might have been a result of the fact that like a lot of early programmers the author of this game use a lot of FOR/NEXT loops for searches which they exit ungracefully from the middle of using a GOTO statement when they find what they're looking for. I always try to properly finish a FOR/NEXT. Anyway, I fixed a few of these and started using my own variable for my additions to the program to avoid conflicts with the FOR/NEXT variables used in the original. Another, difficulty with porting was the use in the original TRS-80 16K version of IF structures like this:
IF A<B GOTO 10
or
IF A>B LET A=0
It's possible in original TRS-80 Basic to dispense with the THEN command. In Micro Color BASIC this can only be done using the GOTO command. Others, like LET don't work. Had to weed all these out. Also the programmers had used DEFSTR to define a bunch of character string variables without dollar signs, another feature missing from Micro Color Basic. I think it is fully debugged now. I have played it through to its end a number of times and in a number of ways. Here's a vid of LIVNGSTN.C10. At the end of it you can see the effect of the fake "exit to Basic prompt" before it revives you to a restore point. Very clever little effect that demonstrates the care lavished on the game by its original programmers, Carl Russell, Karen Russell, Ralph Fullerton, Becky Fullerton. (published in Softside, Vol. 2. no 12):
Someone besides myself finds it interesting to browse through old Japanese Basic computer magazines looking for code to convert to an 8-bit computer with a Motorola MC6847.
A video of mine describing my odyssey in converting a type-in BASIC program found in an old Japanese magazine (1988), originally for Fujitsu FM-7/77, to my Brazilian CCE MC1000, based on CPU Z80 & VDG MC6847 & PSG AY-3-8910.
It's in Portuguese, but here is an abstract:
I describe the game mechanics and rant about some of the FM-7/77 BASIC instructions that write text and stamp images on the graphic screen.
I talk about how game logic is mixed with interface logic, and give an example of how I separated those things in my conversion (reading keys from the keyboard vs getting commands from the player).
I show a first version in text mode, and then go on to make it graphic (using MC6847's Resolution Graphics 6, which is set by MC1000's HGR instruction). Machine language comes into stage with routines to draw 8x8 characters/sprites on graphic mode, and remove keyboard beeping. A final section of the BASIC program is added to POKE the corresponding bytes into memory.
Sound is still lacking. The original program uses the PLAY instruction, MC1000 has TEMPO & SOUND instead. I studied them all instructions and came up with an HTML page with JavaScript code that translated PLAY strings into a series of SOUND commands.
Then the conversion is complete. Oof! 😅It should be easy to adapt the program to MC-10?
Emerson was very generous to provide some further conversion advice:
Some machine-specific info: CALL 49158 -- Waits for a key to be pressed and released. POKE 910,0 -- Avoids an annoying behavior of PRINT, just ignore it. PEEK(483) -- ASCII code of last key pressed. PEEK(485) -- 255 if a key is pressed; 0 if none. POKEs after HOME -- Makes cursor invisible. Ignore. POKEs at the end of program -- Machine code routine related to keyboard reading. Ignore.
The CCE MC-1000 is an interesting machine. It's got the screen of a Coco, the keyboard of an MC-10, and the Basic of an Apple II. It's a totally unique hybrid. The Brazilian government really fostered some interesting creativity in 8-bit computers with its protectionist policies. Anyway, with Ensjo's help I was able to get a version working for the MC-10.
Your penguin is an A
It's able to jump in the following ways:
A to here
■
It can jump from here A up through the block (using the W key jumps straight up).
It can jump up and left or right using the Q and E keys.
A to here using the E key A to here using the Q key
from here A ■ or ■ A from here
You can also push blocks left and right if there is only one and there is open space for it to move into. Blocks don't fall if you push them off other blocks. But you will fall if you jump off a block. Some weird physics, but it makes for a neat puzzle. I still haven't solved puzzle 1 yet, so the game has yet to be fully bug checked. If there are any puzzle fanatics out there who solve it, let me know. You can play the game online here: https://archive.org/details/@james_gerrie
The following is an update of my original attempt, with improved handling of the move sound and music interludes (I hope):
And here are some further updates to messaging and a demonstration of the Win music routine:
I have done some more tinkering to speed up the Basic part of the program (e.g. renumbering lines). The big change is now smoke only lingers for a few moves and then dissipates, which is more like the original. I think I am coming close to the definitive edition...
As well, I'm still finding the occasional bug regarding the walls, which I fix by changing the numbers in an numeric array representing the map. It uses the basic 4 number code for walls (and zero for open space): 1 v 3 > ■ < 4 ^ 2 So if you hit a wall marked as 3 you will turn left and so on. It took a bit of trial and error to work out the proper system for such deflection. Hopefully I've sniffed out the last of idiosyncratic places that would let the enemy car "pass through walls." But if there's anyone out there who notices any.... https://www.facebook.com/jimgerrie/posts/1261129703922549
Thanks to Darren Atkinson and Robert Sieg for volunteering to do some M/L coding to help me speed up Cross Rally. In this video you can see the latest version in which I have implemented Darren's USR routine. Its speed boost allowed me to add a permanent update of the mini-map with the enemy car's position relative to yours. Also, the game will get slightly faster each round.
There is only about 400 bytes left, so I can't put in any REM statements with thanks to Robert and Darren, but I will thank them here. You can play the game online at: https://archive.org/details/@james_gerrie
This is a video of the demo that Robert worked up for displaying the Map info:
Well I have added the final bells and whistles. The intro screen explains the basic keys of the game. Hopefully the rules are not too opaque. In brief, you must collect the 10 regular Checkpoint flags and then make your way to the Level Checkpoint flag. The regular flags appear on the mini-map on the bottom right of the screen, but the Level Checkpoint flag does not, so you must keep your eyes peeled for it while you rove. You can run over it, but it will not take you to the next level until you have collected the 10 regular flags. Completing the level faster adds a bonus to your score when you level up. There is also a special Bonus flag, which will give you an extra car. Be carefully when collecting these, as you can only have a max of 5 cars and if you run over the bonus with a full car complement, it will be wasted. You can also create a smoke screen (oil slick?) by hitting space. You only can do this 6 times per car. The dark green bar labeled "F:" tells you if you have any left. You can run over these smoke puffs without any problem. Avoid the rocks. They're as deadly as the enemy car. Pressing the "C" key or the "B" key will flash the current location of the you and the enemy car. It would be nice to have this continuously updated, but it would slow down the game too much. You have to make some sacrifices when you make a game in Basic. When you exit the game it will report the last score and the highest score.
Here's a video of the original for comparison purposes.
This project is for Retrochallenge 2017. For more info about retro-programming projects see: http://www.retrochallenge.org/
Well, it's a game now. Just have to fix up a few more fiddly bits and maybe add smoke and some point bonuses. Might be a possibility someone will take my offer on the Yahoo group to program a slightly speedier screen rendering routine for refreshing the map on screen. Right now I use a bunch of MID$ print commands. If that were possible, it could possibly be even speedier. I guess we'll see. I suspect this will be my major effort for RetroChallenge 2017. Hope I can get it finished.
Found a really neat site listing Basic programs for the NEC PC-6001. One of the games called "Car Rally," written by Maiden Artist, looked liker a good prospect for porting or re-programming for the MC-10. Apparently he had ported it from a Pocket Computer version of a classic arcade game Rally X rally. It used semi-graphics 6 mode.
You must collect flags.
While avoiding an enemy car.
And watching the map on the right side of the screen that indicates where the flags are.
You can release smoke to block the enemy.
GAME OVER
The game is over when the remaining fuel runs out. If you collect all the flags you can go to the next stage, but the number of enemy vehicles will increase.
I have been working on a version that uses strings for the map and the MID$ function to display the section you are. Its pretty speedy so far but I have yet to add the enemy care and its search algorithm. Hopefully I can keep the code tight enough to keep the speed up with the tracking added. I'm going to use the VARPTR function to poke the obstacles directly into the map strings, and maybe even the moving enemy car too. Here was the test of concept:
Here is an update with the routines added to prevent hitting walls.
Next, enemy car tracking and collision detection. The routines to randomly place flags in the maze and plot their locations on the little map.
