Some Examples of Retro-programming Inspiration from Out of the Blue

Got a message one day from someone from Brazil. Érico had run across some of my videos and mentioned them to some of his mates on a forum for a modern variation of Basic known as GLBASIC. Here's what he said

On a different note, as curiosity, I currently do my games with a variation of basic called GLBasic.Back in our forum, we have a couple tandy color computer users and the subject comes up every now and then. Once we were talking about this mode and how I would like to do a game on this mode on modern computers and we then thought to try it out on a real coco. Matchy did a wonderful semigraphics paint tool in glbasic that would spit coco code and it would work fine on a PC, let me point you towards this:http://www.glbasic.com/forum/index.php?topic=9675.90 On page 8, you have Matchy´s code for that.I´m not sure you have to be logged to see code or images though. Cheers!  --
Érico

The graphics he had created were absolutely amazing.

 A closer look revealed, as he himself mentioned in subsequent e-mail, that the top picture was not really in keeping with the restrictions imposed by the nature of semi-graphics mode 3. There is no attribute clash, for instance, between the orange feet of the two top dudes and the underlying green of the ground. The middle picture is more in line with the quirks of the semi-graphic characters used on the MC-10. You will notice that the feet are surrounded by black pixels, which is the only alternate for any color in one of the 32X16 zones of the screen grid. So I was drawn most directly to that image.

I had been wanting to make a better boxing program than the one I had scrounged up a few years back from the VZ-200/300.  It had been a challenge to convert and I was hopeful that it would be fun to play, but I recall being somewhat disappointed once I had got it working. Here's what it looked like:

I can't recall exactly whether it was the game play or the graphics or both that I found somewhat lacking, but I do recall thinking that something better could be done.

One reason I wanted something better was because I had seen an interesting boxing game on another computer in the MC6847 video chip family, the APF Imagination Machine. Here's what it looked like:

APF Boxing

I remember when I saw these images and also some videos about the APF thinking "Hey I could probably do something like that in regular MC-10 Basic!"

But after seeing Érico's lovely mock-up image of the two karate fighters I realized that something even nicer could possibly be done.  I could make a game with slightly more realism than the clunky boxer figures above, and also supply the MC-10 with a BASIC rendition of the classic martial arts game motif as well.

Making the game was not hard.  First thing I did was fire up my trusty SKETCH program. It is a modified version of  William Barden's "Computer Sketch" program from his book TRS-80 Color Computer and MC-10 Programs. I had modified it to output the screen to printer, which in the Emulator takes the form of an ASCII text file. Then it's a simple task of cutting and pasting the bits needed from the resulting file into Wordpad.  You can use just pieces or even whole screens. You can usually recognize what is there and divide it up into strings as needed. Here's a sample of the kind of output you get from SKETCH:

¯° €€ÿ÷ýý÷ú€ÀÀÀ àç €€€€€€€€€€¯
¯    ðõûÿú€€ÎÍ  àçâ €€€€€€€€€€€¯
¯£££££÷££û££ÎÍ£££ÎÍ£££££££££ÎÍ£¯
¯  À           €€ €€€€€€€€€ ÎÍ€¯
¯ ÎÍ£££££££££££££££££££££££££££¯
¯€ÎÍ            €À          ÀÀ ¯
¯ ÎÍ        ÎÍÀ ÀÀ          ÀÀ ¯
¯£££££££££££ÎÍ££££££££££££££ÎÍ ¯
¯€À€À€€€€€€€€€À      ÀÀ    ÎÍ ¯
¯ ÎÍ££££££££££££££££££££££££ÎÍ£¯
¯ ÎÍ             À             ¯
¯€ÎÍÀ€€€€€€€€€€€ÀÎÍ€€€€€€€€€À€ ¯
¯££££££££££££££££ÎÍ£££££££££ÎÍ ¯
¯ ²                         ÎÍ ¯
¯·»ÐЀ€€€€€€€€€Ð€€€€€€€€€€ €ÎÍ€¯
¯¿¿££££££££££££££££££££££££££££¯

This is a printout of the screen designed for my KONG program mentioned in my last post.  Here's what the image looks like on the MC-10 screen:

After a while you get used to recognizing the symbols. For examples € is the standard black CHR$(128) character.  You can leave more space around things if you are just drawing single items, which makes cutting things up into strings a little easier.

In the course of using my version of Sketch, I ran across a bug, so I got a little sidetracked for a few days tracking it down and fixing it and also making some nifty changes and updates. I added circle drawing and large text entry. It's just an occupational hazard to get distracted. I have a whole directory on my github filled with unfinished ideas and projects:
https://github.com/jggames/trs80mc10/tree/master/quicktype/Current%20Projects
I got distracted cleaning up my repository too.

However, it didn't really take all that long to get a working game going. I had to sketch out some variations of the Érico's figures to provide animations for punching and kicking. I don't how well they turned out, but they'll do for now (unless Érico sends my some better variations). The tough part was refining the fighting routines.  It's a very simple game. If you step close enough to your opponent, your character strikes out with a random move and knocks the other character backwards out of the hit zone. That is to say, they get knocked back unless they are already too far back (i.e. with their back against the "wall").  It doesn't pay to push your opponent to the point that his back is against the wall because then both player's just end up equally exchanging blows until the attacker steps back. In other words, the game is about trying to dart quickly into the middle area of the screen, strike a blow, and then hop back before your opponent strikes a return blow. Since the AI of the computer player is randomized, with slight variation according to level of play, it gets more and more difficult to achieve safe blow and retreat in time. The algorithm of the AI is more predisposed to attacking than it is to standing still or retreating at all levels, so basically it becomes more aggressive as you go higher in level. It works pretty well I think.  The computer obviously can be very quick (since its continuously checking whether to attack, stand still or retreat), but you have the advantage of being able to think carefully about when to strike and how much to retreat (two or three paces is pretty much the most you can get). The best strategy is to always try to replay any blows and avoid pushing your opponent into a corner. Other than that its pure reflex speed and ability to button mash with gusto. Here's a vid:

I've slightly tweaked the AI since this video was made and fixed up some other things. For instance, I added multiple randomly occurring grunts from the the two players, instead of distinct one's for each. I watched some videos of real karate competitions, and I would have to say that many of them are darting duels of quick blows and retreats, interspersed with flying kicks.

I would like to thank Érico for sharing his ideas and his experiences as an Brazilian Color Computer clone user. It's nice to see a growing presence in the forums of people from this Brazilian aspect of the Color Computer family. The history of the 8-bit computing phenomenon there is fascinating and quite unique. I've really enjoyed learning about it over the years, including browsing some of the magazines such as the Brazilian version of Input magazine.

Érico also sent me an image of his recollection of a game he had made on his computer. He also described a little how it worked.  Based on his recollection, I came up with another game, which I was able to cram into 10 lines in the hope of entering into the NOMAM 2016 competition, but I was too late for this year.  Oh well, perhaps the "Monteiro Challenge" will make it into next year's comp:

Anyway, I don't know if any of these game are any good as games, but they're sure a lot of fun to program. So if there are any folks out there reading this blog (and I don't know if there actually are), and you have any ideas for games (or other types of programs), then please send them my way.

I was also contacted recently by Matt of of the MC-10 Facebook and invited to join. I unfortunately had to refuse, as I have tried to draw some lines in regard to the number of social media I will use (and types).  He mentioned that some of the folks there are trying to create a better joystick mod/add-on for the MC-10. I told him I would be happy to fix any games to work with it when it comes to fruition. I hope that it does (the Matra Alice had one). But I should have also told him to convey my willingness to respond to suggestions for games from anyone on that group. So if there are any such folks reading this, feel free to send me suggestions by way of this blog, or plain old e-mail and to tell others on Facebook that I am open to such suggestions.

And please, testing my games and sending bug reports or suggestions of any kind will be much appreciated. Although I like making games, I'm not much of a player, so beyond some basic testing, many of them have not been tested to their limits. I'll try to acknowledge any such inputs here. Recently, for example, someone commented on my port of the TRS-80 classic, Atlantic Balloon Crossing, that the way the display worked seemed a little confusing. Notice the list of items at the bottom of the main display. The first line displays the title and the line below it displays the value:

Such an arrangement works fine on 63 character wide screen of the TRS-80 Model 1/3, but is too cramped for the 32 character wide screen of the MC-10. I should have realized this, as I have had lots of experience converting TRS-80 games to the MC-10. Such experience has taught me that there is almost always some way of arranging information using shortened messages, acronyms or taking advantage of the reverse characters available on the MC-10, to convert a display from the 1024 character screen of the TRS-80 to the 512 character screen of the MC-10 without much loss of clarity. So with some prompting from teddybearharv I got off my duff, and cleaned up the display a little more. Very helpful. Thanks teddybear!  And thanks Érico and Matt!  And thanks to Jim McGinely for his video about the gaming on the TRS-80 which inspired my port of ATLBALN.

Here's the updated version of that program:

Next post, some of the tricks used to convert the MAP screen and other graphics from TRS-80 to MC-10.

The Joys of 10 Line BASIC Programming

A real MC-10 with the basic kit

It's been a while since I posted. I have been busy mostly with creating 10-liner games for the NOMAM competition. The competition results came in and I was able to crack the top 10 in a number of categories. I think this is something to be reasonably proud of since the MC-10 is such a modest 8-bit computer and the competition included MSX systems, the Commodore 64 and the latest of the Atari 8-bit line, along with all their bells and whistles, including updated versions of BASIC. That being said, I too used a few tricks involving an updated version of Basic for the MC-10 called MCX Basic. This extension to the language by Darren Atkinson adds all kinds of commands. However, it is not compatible with a regular MC-10 without using add-on hardware or lots of fancy loading of special software. I generally want to stick to writing programs for an ordinary MC-10 so I only used MCX (under the emulator) to allow me to create programs with lines longer than the normal 128 character limit. It's nice to have the space to cram just a few more things onto a single line if I need. Of course I can already do this (somewhat) by replacing PRINT commands with questions marks ("?"). When these get expanded to full PRINT commands the line can go over 128 characters. Using MCX I can get lines almost up to 255 characters long and regardless of how they are entered, programs with long lines load just fine in a regular MC-10.

The 10-line programs I ended up submitting to the competition were the following:

1. MINIPAC (version of Pacman arcade game)
2. AREA51 (text adventure)
3. CAVMARS (descent in a randomly generated cave, while collecting fuel from the sides)
4. KONG (version of Donkey Kong arcade game)
5. MINDUNG (3D first person dungeon crawl)
6. DASH (Puzzle game based loosely on the arcade game Boulder Dash)

There were difficult challenges to fit these programs into only 10 lines each. I had to really refine some techniques to reduce the number of lines used. These techniques included new ways to process key input that don't require use of multiple IF statements and techniques using ON-GOTO commands, arrays and pointer variables and variable assignments combined with logical tests to accomplish multiple tasks, so that multiple IF statements could be done away with.

In regard to key input, I generally used a technique I've discussed before of using variable assignment commands with logical operators embedded in them. So a command like this:

I$=INKEY$:X=X+(I$="A"):X=X-(I$="S"):Y=Y+(I$="W"):Y=Y-(I$="Z")

will allow X and Y to be modified continuously depending on which of the standard cursor keys are pressed on the MC-10. If you need boundary checking this can also be added:

X=X+(I$="A"ANDX>0)

will only change the value of X if it does not drop below 0. This method takes advantage of the fact that logical operations return either 0 if false, or -1 if true on the MC-10 (I think some non-Microsoft Basics used 1 for true). This is why I have to subtract from Y in the example using (I$="Z"). When Z is pressed we want to move forward/downward one space, so we must negate the -1 returned by the operation to get a positive value added to X. If you need to modify your input by values other than 0 (i.e. no modification) or + or -1 just times the result by some value. Sometimes, for example, it might be speedier to have a single POKE or PRINT@ location for a moving object, and then changes its motion to +-1 for horizontal motion, or +-32 for vertical motion. In such a case you can just use:

POS=POS-(I$="Z")*32

to get the right kinds of changes to your object's position. Remember, if it turns out to be false the 32 will be times by zero resulting in nothing being added to POS. If you need bigger jumps just use bigger numbers (i.e. *2 in the horizontal, or *64 in the vertical).

This kind of method can save a lot of use of IF statements for boundary checking and determining which keys have been pressed.

The other method of doing multiple IF/THENs on one line that may not even be related to a single function is to change variables to some desired value, do a check using an ON-GOTO function, and then change those values back to what they were before the test before proceeding onto other variable changes and checks in the line. So, for example, you can have a line like this:

9 TEMP=A:A=NEWA:ON-(B>10)GOTO1:A=TEMP:TEMP=C:C=NEWC:ON-(D=1)GOTO2:C=TEMP

In this example line 9 can assign a new value to A and then branch to line 1. It can also assign a new value to C and proceed to line 2. As long as you have a good awareness about when the conditions you are searching for are triggered, it will be possible for you to construct lines that do a multiplicity of checks, variable changes and branchings and even other possible actions (sound events for example), even if these have nothing to do with each other.  With the use of the MCX 255 character line technique, you can pack a lot of decision making activity into a single line.  I had to use this technique a lot in my 10 line adventure game AREA51. Text adventures need to engage in lots of decision making and event triggering.

By using lots of array variables, loaded with different stuff in their various numbered slots, you can mimic lots of event decision simply by changing certain pointer variables to those slots in the array variable. For example, you can change whether a win or lose message is printed at the end of a game by changing the variable WINSTATUS used in an array WINMSG. If WINMSG$(0)="YOU LOSE" and WINMSG$(1)="YOU WIN" all you need to do is PRINTWINMSG$(WINSTATUS) at the end and make sure that WINSTATUS is set appropriately somewhere in the program, such as in one of the densely packed decision lines.  In general, I had to use lots of arrays and lots o pointer variable in these programs, but hey the limit was just about the number of lines used, not the amount of memory wasted!  I was also able to use variation on the techniques above used for processing key input to change the pointers values to array locations.  So you could do something like this in regard to the WINMSG$ array. WINSTATUS=-(DEAD=1).  Such a construction allows for something to be checked and an event like printing the right message at the end of a program to be done without having to use a line wasting IF command.  The MC-10 doesn't have an ELSE command so any IF command will utilize one whole line just for itself.

By using the variable assignment structure of A=B with B replaced by a bracketed logical operations with the appropriate sign in front of it and multiplied by whatever values besides 1 that are required, along with arrays and point variables, you can fit a lot of actions into a single line. My sense is that these techniques really move Basic to being a lot like assembly language or higher level languages like C.  If that's so, I guess I should really get off my duff and learn some of these other languages, instead of just persisting in my use of Basic.  My fellow MC-10er Greg (phyber0pt1k) from the MC-10 group on Yahoo, for example, has generously created a whole set of machine language lessons (very professionally done I might add) to entice people like me into the joys of assembly language coding. It is a very generous contribution to the group on his part.  I certainly recommend it to anyone with an interest (they're in the "Greg Folder" in the files section of the group). For me though, programming is more like knitting.  Porting the existing Basic code from some other machine or writing my own small programs (the 10 line thing has been very nice) is something I can almost do without thinking while sitting with my wife in our den as she watches curling or the news in the evening.  I don't think this would be possible while learning assembly, so I unfortunately have to pass on Greg's generosity, at least for the time being.

I'd like to thank the organizers of the 10-liner competition and especially Gunnar, for all the work they put into running, judging, and publishing the results of the competition. They had over 80 entries, which must have been a lot of work to get running (on various emulators) and then to judge. The large turnout is an indication of the vibrancy of the retrocomputing hobby. Here are some links to videos of my entries which I haven't already discussed or shared somewhere else in this blog:

CavMars

Kong

Area51

In my next postings I'll discuss some of my most recent ports from other computers (i.e. code scavenged from the net) and some games inspired by the suggestions/visual mock-ups of a Brazilian Coco clone user from back in the day, Erico Monteiro.