"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

Walter Bright's "Empire" in Basic

I've made a version of Walter Bright's 4X Ur game "Empire" re-coded in Micro Color BASIC for the TRS-80 MC-10. It's for two players. The control is by arrow and Enter key and Yes or No prompts.  Running into enemy units initiates combat or other actions, such as repairs.  My re-code is based on a description of the game play and unit stats found  here: https://web.archive.org/web/20210418112142/http://www.catb.org/~esr/vms-empire/vms-empire.html

The most important information from that site was the details about the units and about how combat is carried on. The units are as follows:

Piece	You	Enemy	Moves	Hits	Str	Cost
Army	A	a	1	1	1	5(6)
Fighter	F	f	8	1	1	10(12)
Patrol Boat	P	p	4	1	1	15(18)
Destroyer	D	d	2	3	1	20(24)
Submarine	S	s	2	2	3	20(24)
Troop Transport	T	t	2	1	1	30(36)
Aircraft Carrier	C	c	2	8	1	30(36)
Battleship	B	b	2	10	2	40(48)
Satellite	Z	z	10	--	--	50(60)

I think I have all the basics of combat working.  In brief, you have a 50/50 chance of doing your strength ("Str")  worth of "Hits" damage to an opposing unit.

Saving and Loading Games

If you hit Enter when your cursor is on open land or sea, you will be prompted to end your turn.  Hit Y to let the other player have their turn, or N to continue with your turn.  If you hit Q you will be prompted to save the game.

The program creates two files when you select Q: The self-modified game program (EMPGAME) and a data file (EMPDATA) for the main array. By this method, games should be able to be played across the Net by sharing these two files between two people with VMC10. My son Charlie is moving to Halifax. I hope we can have a few long distance "mail-chess"-like games to keep in touch.  When you CLOAD and RUN the EMPGAME program file, just select N in response to the "New Game" prompt, and then hit Enter to load the EMPDATA file created along with that specific EMPGAME file.  Don't mix and match these files, or the game will be confused and not work.

The self-modification of the game source is to a 30 element string array with 64 character long strings.  There are three such array structures.  One for the base map.  The other two for storing the "fog of war" that each player sees.  There is also a 2 X 50 array for the Unit information for each player, with the base 0 element for storing basic info about what is under each unit being moved.  So each player can have a max of 50 units.  The original game had a 100 by 60 map, which apparently was the largest matrix that could be printed on a DEC printer of the time.  But compromises had to be made to fit the map into a 20K Tandy MC-10.  Still, I don't think it feels particularly cramped.

Movement

A feature that also might not have been in the original is map edge wrapping.  When your cursor or units move across the edges of the map (64X30) they wrap around to the other side.  As Charlie pointed out, this is hardly like a real globe represented in 2D, but again compromises had to be made.  In my version, the satellites take advantage of this feature to be able to engage in continuous diagonal movement to reveal portions of the map.  Also, in my version, you have to activate satellites each turn for them to make their 10 move sweeps.  This is perhaps something that should be done at the beginning of a turn.

There is also no dynamic updating of the fog of war (so a satellite might be especially handy). Your units only see what they last saw in the 8 units around them as they moved in your last turn.  In between your turn and your opponent's turn, this information might become "outdated," which can cause some ghosting of enemy units.  However, whenever you select one of your units, it will re-scan the immediate surroundings.  It's up to you to figure this all out, by careful use of units to get updated information.  The Fighter is particularly useful for getting up-to-date information, since it can move 8 spaces each turn.  But be careful it runs out of gas after 32 total moves.  So gas up regularly at cities or aircraft carriers.

The movement uses Greg Dionne's trick for key sensing, which makes it possible also hit two keys together (from the AWSZ keys) to get diagonal cursor movement.  However, you have to to be careful to hit both keys simultaneously.  Motion is reasonably fluid (given all the fog of war stuff) and the keys can be held down for continuous movement.

Unit Reports

Messaging and other flourishes have been kept to a minimum since so much memory is used for all the string and numeric array data.  There are no explosion sounds or verbose messages.  Destroyed units just disappear.  Old messages stay on the bottom of the screen until replaced by new ones.  The messages are terse.  When you select units you will usually see:

UNITNAME #

The # is the amount of hit points/strength the unit has left.  Many units simply have 1 unit of strength, and are one-hit-kills, so this info is only useful for units like Carriers and Battleships.

Loading and Unloading Transports

For units like the troop transport you first get a report of the number of armies contained and a prompt to unload if any are present.  The Fighter adds a prior # which represents the total range left before it must be refueled.  Armies can bump into your own Transports, at which point they will be loaded.  They can then be transported across water.  Just choose "Y" to the prompt to unload when you select transports to disembark armies on adjacent land.  You must do this for each army individual by reselecting the transport and hitting Y.  There must be available land in the surrounding 8 spaces.

Repairs and Refueling

Another compromise is that fighters can't be landed and moved around on carriers like armies can in transports.  Instead, fighters can accompany carriers and simply bump into them when they need to refuel. Similarly, when ships are damaged, they simply need to bump into a coastal city to get a repair point back.  They can only do this once per turn.

The two players are demarcated by different cursor colours. The first player is red, the second is cyan.  The first player has light green characters.  The second player has "reverse" characters (i.e. lowercase as in the table above).  You select units by moving the cursor over them and hitting Enter.  The cursor then disappears and you can just see the unit.  Move it using the arrow keys.  When you run out of moves, the cursor reappears.  You can end a turn early though by hitting Enter again.

City Menu

Selecting a city unit shows what is currently being produced by the city and the number of turns to go before it is ready.  If you hit a number from 1-9 you can see what else can be produced and how many turns they take (plus a additional amount for the first unit produced--see the last column in the table above).  You must hit Enter to make such a change in production.  Otherwise, hit 0 or any other key to abort the city function and return to cursor movement.

Winning

When one of the players destroys all the units of the opposing player, they are declared the winner.  To play again the program must be re-loaded because the array strings have been modified in the actual Basic source code.  To prevent possible confusion, a NEW command is issued at the end of the game to wipe the game from memory.

So, if you have a hankering for playing what Bright's attempt at originally coding the game in Basic might have been like before he abandoned it in order to code it in the "superior" language of Fortran, this is your game.  If you want to find out more about the history of the game, see Bright's page: http://www.classicempire.com/history.html

APF and Some Matra Alice Stuff

I've been taking some inspiration from the APF Imagination Machine for many of my recent BASIC 10-Liner programs.  However, what got me on to the kick was working a much more substantial programming project.  This was a complete re-code, based on videos and documentation, of the APF program Mission Improbable: Operation Alpha.  I wandered into some videos on Youtube of someone playing APF games. There were some nice playthroughs of some of the best machine language arcade games for the system.  But there were also videos showing humbler programs, including many that could easily be implemented in BASIC (although on the APF they were machine language). Mission Improbable was one these.

Getting APF cassette games running on the emulators for the APF takes some struggle.  I found converting the files to WAVs helpful.  However, I couldn't get this one to load properly or run. So I don't know if some or all of it was made in Basic.  However, I decided that I could probably just re-program the game.  I took a slow and careful approach (unlike when I'm programming 10Liners).  First I developed the menu systems and all the complex mission selection stuff.  Then I drew the main screen graphic.  Then I converted a variation of minesweeper to replace the alternate escape route option of the original.  Finally, I made the main game itself.  You can find a demo of the finished product here:

The toughest part was getting the flashlight beam effect of the roving guard. Besides that, the movement and other animations are pretty standard fare from other games I've made. Finally, my son Charlie used his finely tuned musical ear to recreate the win refrain-- The Stars and Stripes forever, although it first sounded like "Be kind to your web footed friends" to me.

Besides altering the escape route I also slightly altered the missions. Especially the Assassinate option.  The original had some complex activity of going into a dark room and listening to tones to zero in on the hiding Commandant. The APF has better sound generation than the MC-10, so perhaps such an activity would work, but the main game screen was already a little faster than the original game, so I opted for a moving Commandant that forces you to try to get close to him before he moves again.  He also is always flanked by two machine guns, which get left behind when he moves.  So the map screen gets progressively more difficult to navigate without getting shot.  I think it's an adequate replacement for the original mission activity.  

The final step was tuning the timer to make for challenge, but without making it mission impossible.  I've hopefully hit the right balance.  I had to play quite a few games to satisfy myself.  I still don't know if I've got it right, but considering that I will likely be the only person to play the game, besides my increasingly reluctant beta-tester son Charlie, I eventually had to just pull the plug.  Since I played so much, it's often hard to tell if levels are too easy, or whether they just seem so because I've got so good (and as the programmer have inside knowledge).

Another system that I have taken actual source code from is the Matra Alice.  I'd seen "Coloric" listed for many years on Alice software sites, but as it was a puzzle game (and not an "action") game I always put it on the back-burner for porting.  However, I decided to finally get around to it.  Robert Sieg has been discussion Alice graphics on the Facebook group, and his comments reminded me that the Alice, despite its powerful new graphic chip, maintained a certain basic level of compatibility with the old MC-10 semigraphic 4 screen.  In other conversions I've found that there are often simpler MC-10 graphics hiding under what is essentially a thin veneer of extra special effect based on the new graphic chip.

This turned out to be the case with Coloric.  Although it was placed on 40X24 character Alice screen, it still used standard SET/RESET for a lot of the basic work..  I just had to shift things into the smaller 32X16 space.  I found that every thing fit.  I just had to omit some of the embellishments and minor extra instructions present on the screen.

Now the MC-10 has an interesting puzzle game from a French 8-bit computer, translated to English.  I don't think I've played anything like it.  The French, like the Japanese, make some interesting puzzle games.  Here are my translations of the instructions:

Jumping Jack: Yet Another 10Liner and Some Updates

Oops I did it again.  It's a dull time of the year.  I sit waiting for emails to come back from students who need advising for the next academic year.  Otherwise, I'm reading or attending virtual meetings. But to break up the monotony, and sometimes just to escape the heat, its nice to head down into the basement and do some Basic coding.

I've got a third entry for the ASCII Basic 10Liner Jam on itch.io. It's based on a game for the Sinclair Spectrum that I stumbled across called Jumping Jack.  I had originally envisioned a game using Semi-graphics 6 mode.  I'd even worked up an elaborate set of characters.  But when the 10Liner contest came along I decided to try for something less complex. Obviously, I put the SG6 version on the shelf because getting the game logic running would require more of a time investment than I'm willing to give right now.  I needed a simpler set of projects. The 10 line limitation really provides that.  Perhaps some day I'll work up a more full version in SG6 using Greg Dionne's Basic compiler.

In the meantime here is what my first stab at making little ASCII Basic version of the game looked like:

I eventually cleaned it up a little in terms of animation of the main character and his final jump up off the screen, along with some other tweaks, including the ability to type in a difficulty level from 1 to 3 at the "new game" prompt.  Here's a vid of the latest rendition:

My version is a little more finicky than the Sinclair original. But that's what you get when you are limited to 10 Lines. No frills. JUMPJACK can be played online here using a JAVASCRIPT emulator.  Just select JUMPJACK from the cassette menu and type RUN in the main screen.

I also made some updates to my DFENDER entry (it can also be played at the link above).  I made the trail behind your cursor stay visible.  This makes more apparent where you have switched the background character to the ASCII values for the buff coloured semigraphic characters. This is all you have to do to explode the incoming missiles. When incoming missile characters are set into place, if they notice that the underlying character they are replaying is from the different colour set in the ASCII values above 128 (the 8 colors are represented in 8, 16 character sets) they explode and reset to the top of the screen.  So although you don't have to actually see the "trail" for this to work, people without knowledge of semigraphics might not be aware that, so I made the trail visible.  Now I'm thinking that it is like a trail of your anti-missile missile as it shoots through the sky.  I also added a little red explosion with the space saved in the code by removing the need to reset the pointer character, and some other reorganizing I did.

 Enjoy!