"Euchre for Two" by Victor J. Raybaud

I have converted the program "Euchre for Two" Victor J. Raybaud to TRS-80 MC-10. It's from a listing in The Best of Creative Computing (Vol. 3, 1980). Originally for the Univac 1106, I had to debug it for Micro Color Basic operation. For example, it contains many uncompleted FOR/NEXT loops, which needed to be dealt with. Also, there was a recursive use of GOSUB. I suspect that the Univac could easily handle these techniques without problem, but they were causing hiccups for 8-bit Microsoft Basic. I also found some formatting bugs for the main card layout screen, which I also fixed. Or at least they seem like bugs, but perhaps there is some strange nuance to Univac Basic string formatting that somehow eluded me.

It was somewhat puzzling why I couldn't find  working version of this program that you can run in any of the regular online software repositories that I keep track of. I think that it is possible that the quirks of Univac Basic that I had to find work-arounds for might have frustrated enough people back in the day, that the program was unable to make the leap from the Univac to the 8-bit personal computer world. Lack of 8-bit distribution could easily prevent copies from surviving to the current day. It's a big complex program, that would be very intimidating to type in. The line numbers skip by 100s and have leading zeros, which adds to the intimidation factor. Coupled with the quirks, which would have been very frustrating to hunt down in the old line editor environment of the home machines of the day, and you have a perfect recipe for a "missing program."

It's sad that the game seems to have been lost, because it is a wonderful piece of early artificial intelligence programming.  It plays what appears to me to be a reasonable version of a complex card game.  There's bidding that requires predication. Some of your cards are hidden and some are displayed, which demands strategy to manage well. Like many of the programs of the Creative Computing crowd, it has an elegant simplicity to its user interface.  I typed it in with the idea of converting it to a new small graphic "card set" that I had developed recently:

But in the end I didn't want to mess with the elegance of the original.  So perhaps on some other future card game project I'll find an opportunity to use the new graphic card set.

I've also been fiddling with another David Ahl/Creative Computing conversion. I did "Hockey" this week.  It's a simulation from David Ahl's 1978 collection. There were a number of typos, such as wrong line numbers and garbled variable names, in the TRS-80 source code that I worked from, which I corrected. There was also an error in the original source.  In the routine  that allows you to take a shot from the Red Line (i.e. no passing selected), the option 2 subroutine just bleeds into the option 3 routine, so that you would get both result messages.  Since most people would only select option 1 (slap shot), I suspect the original programmer didn't notice the problem in his debugging.

I had to use my word wrap routine for the messages, since the MC-10's screen is so confining, but I think it looks pretty good.  It plays like the transcript of an old fashioned radio broadcast commentary.

I am currently working on the Ahl card game "War." It's a very simple game, so there is not a lot of incentive to complete the project, but I'll get to it eventually.

I've also done a number of conversions from Australian Coco magazine, including "AUSMAP" which I blogged about last week.  But I also did a game called "Space Bar Bandit," which is a simple slot machine simulation:

I also spent a little time working on some variations of the classic 10PRINT program. I was inspired by Robin of 8-bit Show and Tell, who looked at a neat new "orthogonal" variation of the program created for the Commodore 64.  That version was supposed to fit in just 32 bytes and was written for a programming contest.  Inspired by his vid, I created a new shorter version of my own "orthogonal" version of the 10PRINT program.  As typed in, it should be less than 32 bytes. In the video jump to the 50 second point to avoid my excruciating typo at the beginning:

All this prompted Emerson Costa to a do a little refining of his own for the Brazilian MCE-1000 8-bit computer:

https://www.facebook.com/groups/mc1000/posts/2573299429388227/

https://www.facebook.com/groups/mc1000/posts/4456715507713267/

I also created a version of the program using the SG6 screen mode.  This one creates a maze that should be functionally equivalent to the one created by Commodore version:

Finally, I don't think I have blogged about a simple game I converted from the Sinclair ZX81 last week. It's called "Space Taxi" which many folks pointed out was the name of a famous Commodore 64 action game. Robin from 8-Bit Show And Tell mentioned:

"this is both 1) a super-early example of an "infinite runner" game and 2) has the same name as a legendary Commodore 64 game, but was made 2 years earlier! Neat game, too bad it's so unfair at the beginning of each screen with random spawn positions."

So the game is not a rip-off but a trailblazer for a neat game title!

Some Australian Coco Magazine Stuff

5 REM*****************

6 REM*  AUSTRALIA    *

7 REM*BY ALAN BRIDGES*

8 REM* SEPTEMBER 1984*

9 REM*****************

Published in Australian Coco Feb 1985.

This is a screenshot of the original map:

The following is a recommended change by Mike Garcia who I'm assuming is a dinkum (us Nova Scotians would say "right good") Australian:

I've moved the 3 and the 2 up one space and to the right one space each. That's my best guess from looking at a map. What do you think looks more accurate?

Addendum:

Darren Ottery, who  I know for sure is a dinkum Australian, confirms that the second version is "as close as it can be on a 32x16 grid."  So I have uploaded that version to my repository sites.

Elon Musk's Early Type-in Game "Blastar"

I have ported the Basic game "Blastar" to the TRS-80 MC-10. This game was made by Elon Musk at the age of 12 for the Spectravideo 328, a relatively rare 8-bit computer of the time. More info can be found in an article from the Verge e-zine and in this thread from a Commodore forum: https://www.lemon64.com/forum/viewtopic.php?t=71960&sid=0f7d81624f50e2fd49b87e30b92dba9c

There is a modern web port, which allows you to play the game online. It can be found here: https://blastar-1984.appspot.com/

I hope my version might provide an experience a little more like the original program, since it is still in Basic and running on a 8-bit system architecture, rather than being a port to a modern web language/environment. The web update strikes me as something of an amalgam of sped-up features and artificially slowed down features. I'm not sure if the author is using some kind of emulator for the Spectravideo 328 or has translated the features of the program to a modern web language environment. The following shows an update of my first version of the program (as seen in the video above):

In most of the blurbs discussing the program on the Net, there are two statements made that I think might be errors. It is often mentioned that the program was made for the Commodore VIC-20. This is not the case, unless there are different versions out there about which I am unaware. The Spectravideo 328, an early MCX-like 8-bit computer, seems to be the system used by Musk. Also, it is often stated that Musk was paid $500 dollars for this program. This seems too high compared to my sense of what people typically were paid for programs by magazines at the time. I wonder whether Musk was paid something worth approximately 500 Rand, and simply failed to properly translate that amount into "American dollars" in his discussion of his first program. My sense would be something like US$50 - $150 would be more normal, but I could be wrong about this estimate.  However, Simon Goodwin's article "Writing for the early UK Home Computing mags" suggests that something between £5 to £90 (exchange rate was about 2.3 at that time) was closer to the norm for what he earned early in his career.

The magazine in question is "PC and Office Technology" from December 1984:

The game code for my port can be found here:
https://github.com/jggames/trs80mc10/tree/master/quicktype/Arcade/Blastar

Walter Bright's "Empire" in Basic: Updates

Once again I'm indebted to my son Charlie for making invaluable suggestions for the improvement of the game.  The main one is that he pointed out some inconsistencies in the movement of units.  I hadn't made it so that an attack on a unit was counted as a "move."  Nor had I made it so that an attacking piece, if possible was to occupy the space of the defeated unit.  In our first attempt at a real game together, Charlie pointed out that this would allow a unit to launch an attack, and then effectively outrun any attempt at pursuit by nearby enemy units.  So I made some major revisions that now mean when an attack is launched, the winning piece will, if possible,  occupy the space of the unit being attacked.  Also, for units with higher than 1 Str, attacks will continue until a resolution of combat has been determined.

Of course this also pointed towards other issues.  If an attack was launched by an Army unit from the shore on a sea unit, what happens?  The rule document I was working from noted this possibility.  It explicitly states that even if an army unit is victorious over a naval unit, it is "drown."  So I added that feature too.  The naval unit, of course, in reverse, can't occupy an army's space, but a move is at least registered for it.

A similar problem of movement was also noted by Charlie.  I hadn't registered it as a move when an army was disembarked from a Transport onto the shore.  Each army started with a fresh move count.  But as he pointed out to me, this could mean that an army could be disembarked to reveal areas of coastline, then reembarked, the Transport moved down the coast, and repeat.  It's little things like these that I often overlook, but Charlie, with his mathematical mind,  notices right away.

Charlie also requested and contributed some aesthetic changes.  Not having been raised on the MC6807 screen, he didn't like the fact that the normal uppercase characters of the first player blended into the green colour of the ground.  He felt this was like ships "carrying around" pieces of ground with them. It also made it hard to distinguish where channels were.  So I changed to the alternate text colour set.  This way the units of both players are separate from the green land colour, and the message bar at the bottom of the screen is also distinguished from the land.  Of course, because of quirks of the MC-10, this makes playing sounds problematic, because their use automatically switches the VDG back to the regular text mode.  So I changed the beep I had been using to provide feedback for key presses. This beep was necessary because sometimes minor delays could make it seem like a key press hadn't registered.  So I used POKE commands for a key click that doesn't switch the VDG back to regular text mode.  Charlie also provided some musical refrains for victories and defeats.  So the screen flashes back to regular mode briefly for these.

Finally, Charlie pointed out that if two players were physically present with each other during play, they would be able to glimpse the screen of the opposing player between turns, after a player had hit Y to the "End Turn" prompt.  So now, there is an intermediate pause screen, which also prompts the user with the possibility of quitting and saving the game.  This addition was good, because previously I had not given any notification of the game save feature.

I was able to have memory space for all these changes because I had noticed that I had assigned the main string array elements directly using their numbered variable elements, like this:

M$(30,2)="......

Instead, I switched to DATA statements, which I just READ at the beginning using a simple FOR/NEXT loop:

DATA"....

I had forgotten that Microsoft Color Basic is smart enough to assign strings initialized in this way, simply by pointing to the original READ location of the string, rather than using string space.  Then, when I POKE these strings with new information, the string in the DATA statement in the source code is modified in memory.  This change gave me an extra 500 bytes or so, which allowed for more elaborate messaging, and the updates described above.

All these updates can be viewed on my Github:

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

Thanks to Charlie, who is off to Halifax to look for work and begin his life away from home. I'll miss his invaluable contributions to my programming efforts, but he's off to pursue programming efforts of his own.  God speed my boy!

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