Monday, 20 June 2016

Just Call me a Type-in Fanatic


I have been very active lately porting programs from various sources. Mostly I have been using the large number of PDFs available from various archives of classic 8-bit computer magazines you can find on the net. Often I simply stumble across someone's post in some forum about a classic Basic game they remember playing. They might mention a magazine and sometimes even an issue and other details that allow me to track down a version of it.

This is how I stumbled across the source code for my very latest porting project. I think I probably did a search on Google like "GOTO GOSUB robot." Maybe I also added the term like "Atari" and tweaked Google to show only sites added in the last year, to see if anything fresh had shown up (i.e. I know I've already searched on "GOTO GOSUB robot" before). Somehow I ended up running across Computer Science by Rafal Bujakowski in which he talks about his programming exploits porting an old Basic type-in game to the Commodore Amiga dialect of the language. It was called "Robot R-29" from a Polish computer magazine from his youth called "Moje Atari" or "Your Atari." Maybe what drew me to his site was a graphic image. I often switch Google to display images rather than sites and then quickly browse for obvious 8-bit computer "screen shots" (i.e. employing simple text graphics).

After finding his site and reading about his interest in the game and where he found it (he had included the graphic image of the actual page you see above) I was able to find the entire magazine on the net. Then I could get a proper printout of the page and begin the process of typing in the program and converting it to MC-10 Basic. Luckily, I didn't have to type in all the maze info because Rafal had helpfully supplied the source code of his update of the program to Commodore Amiga Basic.  His listing included DATA statements with strings containing the 5 maps of the original program. It was a very elegantly written program and the elements unique to Atari Basic were not too difficult to figure out.

Still, I also found it helpful to download the Altirra Atari 8-bit computer emulator and search for an program rom/cassette file for the game. It was a bit of learning curve getting the emulator up-and-running, loading the image figuring out how to connect a joystick to my PC and to get the emulator to use it (the game only used joystick for input). But once I got it working I was able to see how the game played, which was helpful in figuring out the program logic of the original listing. I have emulators now for all the major 8-bit machines that used the Motorola MC6847 video chip that the MC-10 used (Coco, Dragon, NEC PC6001, Dick Smith VZ-200, etc) and also for Atari, Commodore and TI. This really helps with my porting activities and is a fun way to learn about other machines and their quirks. For instance, I learned (after a little frustration) that Atari Basic doesn't like "LIST 100-200" to list a range of program lines, but rather requires "LIST 100,200." So "un-microsoft!"

After overcoming all these little hurtles I was able to get a neat little puzzle game going for the MC-10, which should also be easily portable to Coco and Dragon with a few edits.  Here's a vid:


I have also done a lot of other porting exercises since my last post, each with its own quirky adventures of hunting down the code, figuring out the quirks and differences between types of Basic and tweaking the code to Micro Color Basic. Here's a brief rundown:

WILLBURG

A classic text adventure found on some virtual Coco disk and transferred to PC using the utility decb.exe. Here's the command I use: decb copy -a blank.dsk,WILLBURG.BAS WILLBURG.TXT Of course I have already saved WILLBURG.BAS onto the blank.dsk using the VCC Coco emulator. I can be saved as an text file using the standard disk Basic command SAVE "WILLBURG",A
The comma followed by A means the program is saved as ASCII text.

KORPS

A text based tank simulator. I think from a DEC system archive, or a computer like the DEC.

CAVMARS * (for Homeputerium 10Liner Contest)

Original 10-liner program. You must descend a cavern on mars and land at the bottom. Based on the Atari game "Caverns of Mars."

KLONPUZZ

Back from the Klondike is an original program that implements one of Sam Loyd's most famous puzzles, first printed in the New York Journal and Advertiser in 1898.

SEABATL

Sea Battle, is, I think, a classic Basic game from one of David Ahl's collections. You command a sub which must maneuver around a grid map destroying enemies and sea monsters while avoiding being hit or eaten.

QUATRAIN

Quatrainment from Compute! magazine.  Logic puzzle game.

ATLBALN

Atlantic Balloon crossing simulator. Ported from TRS-80 Model 1/3. Inspired by a talk on TRS-80 games presented at the Games Developers Conference (GDC) by Jim McGinley.  Thanks for the inspiration Jim!

TBIRD

Breakout game with a twist, from Coco magazine.

DTRAP (By Dave Maunder)
HUNTER

Two games from VZ-200.  Thanks Dave!

GALTREK

Galaxy Trek.  Star Trek themed text adventure.  I have restored all the character's original names.

BDOWNS

"Bringmee Downs" horse race simulation from coco magazine. Cleaned up the display and added a horse race animation.

MARSLAND

10-Liner Mars lander game.  Maybe for next year's 10-Liner Basic contest, if there is one.

SKETCH

Update to the drawing program I use to create images for use in games.  Now with large text entry and circle draw routine added. Also took out some bugs. You can print the screen to text file in the emulator and then edit the result in Notepad for easy inclusion in programs.

SPCTRK1

Another Star Trek text adventure with the original cast member names restored (which had been altered to protect the guilty in the past when copyright still applied).

ORANGE 

Weird puzzle game from a Coco magazine.

STOCKSIM

Stock Market simulator.  All text.

MOUSE

Space Mouse an original program created from an idea found on YouTube of a game for the NEC PC-6001. Here's the video:


HLANDER 

Hyperspace Lander. A variation on the Luner Lander theme, with some neat quirks. From one of the more obscure Color Computer publications.

CAPTCHEM

Captain Chemistry.  Quiz program for chemical elements. ported from Coco. Son tried it. Got perfect (or almost perfect), but he was studying for his Grade 12 IB Chem exams at the time. Way to go Charlie!

DRAGON

Simple Dungeon crawl, with a Dragon that must be defeated to win it.

AMAZIN

Simple navigation of a moving pixel through a maze game. From Compute! magazine when they were still covering the Coco. Compute's coverage of the Coco didn't last long but it provides a rich ground for finding programs to convert to the MC-10. Compute typically made programs that had versions for many 8-bit platforms, so concepts had to be simple and usually stick to simple screen graphics.

WARBIRDS

Original game program with a panning star field as you move in any of 8 directions and two Romulan Warbirds who dart forwards and backwards towards you. You must try to move your ship using the 8 direction keys:
 T Y U
G        J
 V B N
until a warbird is in the centre and then zap it using SPACE. You must be quick or they will get too close and zap you!  Five different sized images simulate the warbird's distance from you. You only have 3 lives.

JACK

Jack'o lantern graphic from Coco Magazine

ZODIAC 

Low res graphic images of constellations of the Zodiac and some other info.

SABOT

Sabotage. An original program based on idea from Sinclair ZX-81:


REBOUND

Bounce a ball around a screen using only symbols  \ and / entered to deflect the ball in a direction. Must try to hit unfolding sequence of numbers.

64MAZE

Program ported from Commodore 64 three dimensional maze program. Here's the link to the blog posting about how it came about: http://codegolf.stackexchange.com/questions/15932/dungeon-construction-set
I hope I might be able to use it for some future dungeon crawl game.

UMANSION

Unexplored Mansion reviewed by Gaming After 40 guy. Originally a Coco game. Thanks for the inspiration!

SUCCESS

Success Mansion. A text adventure for the Coco from Rainbow's Book of Adventures.  Original version supported Speech Synthesizer Cart.  had to remove all that stuff and perform my regular pare-down techniques to fit it into 20K. Load in two parts. First part is the program. Second part is the DATA for the main array of locations. This saves having to have DATA statements and memory for the array. By loading array directly from tape you, only need the memory for the array. I don't think I have ever seen a walk-through published so here's a map:
Instructions:
You start on the porch. MOVE or PUSH the MAT to GET KEY1. Don’t GO SOUTH or you will be forced to exit the game. Basically GET every object mentioned, MOVE every object, LOOK every object and OPEN if possible. Once you have the keys you can UNLOCK all the doors (--[]--). The PAPER and the CARD reveal codes to type into the PANELs. Type OPEN PANEL and then the prompt will switch to one to allow you to type the codes.  Once you have all 13 scrolls go to the exit. Use INVENTORY for list of items (No max, but will not list all if you have too many). You really only need to keep KEYS and SCROLLS.


SLIDER

Game ported from magazine found on-line, probably just while browsing through an archive. I believe it is from Your Computer magazine, which was a general home computer magazine in Britain in the 80s. Because it covered all 8-bit computers, it sometimes had games for the Dragon 32 (i.e. British Coco), especially in the 1982-1984 period. Just stumbled across "Time Slider" (the article title) which had a listing of "Time Switch" (the title used in the program itself). Called the version I created for the MC-10 "Slider" because I already had program called switch. Probably should have used the filename "TSWITCH" but I prefer complete names. It's a thinly veiled Dr. Who text adventure, which again tries to avoid copyright infringement. I added a little graphic of a blue box at the end to overcome any such confusion.


References:

Programming projects and experiments.
http://rafal-bujakowski.blogspot.ca/2014/11/amiga-amos-programming-robot-r-29.html

Wednesday, 13 April 2016

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.

Wednesday, 6 April 2016

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.

Sunday, 31 January 2016

January 2016 Retrochallenge 10: Definitive Dash? And New 10-Liner "MiniDung"


Robert has really been working hard on BDASH game. I really like the BDASH016 version that he has created. His animation of the little "miner" character is a really nice touch. And the sound and visual effects he has contributed (the explosive flash and stepping noise) have really punched it up. And he's wedged in some instructions too! I think we must be approaching a definitive version for the 10-liner contest, if not finally reached it. Thanks Robert!

I have also been working on a new program for the contest called MINIDUNG. It's a graphic 3D first-person dungeon crawler, and all in 10 lines. Because of the limits of 10 lines the user interface has to be fairly primitive. You are basically limited to the INPUT command using numbers. So, for example, entering 1,2 in response to the MOVE,DIR prompt means "move 1 space in the 2 direction (i.e. West). Entering 0,2 means stand on the spot and simply turn West. Still it's not too bad. Here are some screen shots:




The blue blob with a red centre is supposed to be a Giant Spider. The purple dude is supposed to be a Demon. The red dude is supposed to be "the Evil Wizard." There are also other monsters. You must defeat the wizard to win the game. Here's what walls look like as you navigate the maze:


The 10X10 mini-map on the right slowly fills in as you explore. The little green blocks represent clear areas whereas the black blocks represent walls. Colours also will appear indicating the different monsters you run across as you explore. You can choose to fight them or run, but if you run there is still a reduced possibility of damage. There are 10 levels of play (more if you really want to try them). Here is the source: https://github.com/jggames/trs80mc10/tree/master/quicktype/Dungeon/MiniDung


Anyway, this is where you can download the VMC10.exe emulator, which has all my Basic programs in the JimG directory under the Cassette directory:
"Jim and Charlie's TRS-80 MC-10 Games"

This is also likely my last post for the 2016 January Retrochallenge.  Thanks to Mark Wickens and all the other participants for a month of fun and learning.

Friday, 22 January 2016

January 2016 Retrochallenge 9: 10-Liner Puzzle Game "Dash" (Update)

Je me baise bien!
My fellow MC-10er from the Yahoo group, Robert Sieg, showed me how to access 256 character long lines on the MC-10 instead of just being stuck with the standard 128. He used the MCX version of Basic (a modified version made by Darren Atkinson from the group), which adds all kinds of commands and improvements, including longer lines. The downside is, one cannot use any of the special added commands, since regular MC-10s wouldn't be able to run the program. The upside is that the regular MC-10s can load programs with longer than 128 char lines just fine! So edit in MCX, CSAVE and then load and run on a regular MC-10!

With all the extra space I have added a few functions to Dash. Now the program displays the "code" for whatever puzzle is currently on-screen. This is really just the four peek addresses of the random number generator seed, which is a 32 bit number stored in 4 bytes (thanks to Darren for informing me where they were located). So if one discovers a very interesting puzzle, the code can now be written down. Also, during any game hitting "P" will call a routine that allows you to enter the four numbers and poke them back in to memory and then display that specific puzzle (after you also enter the difficulty Level #, which also must be recorded).

I know its unlikely that legions of people will be clamouring for such a feature, but its nice to have. I've run across a few puzzles that were quite challenging and regretted not being able to retrieve them in some way. My son told me that some games like Civilization and Minecraft, actually have features to "set the seed" so that specific "randomly" generated worlds can be recreated by other people. In fact, he told that alpha codes can used and some have been discovered to strangely correspond to the worlds created, like the word "hell" ends up creating a largely lava world in Minecraft, or something like that...sounds a bit mythical, but...

So now there is something like that, in miniature, for the MC-10.

Robert also did a modification where he replaced many commonly used multiple digit numeric constants with single character variables, which could now be added to a longer line 0. I reordered his variable declaration just a little to put some of the more critical main loop and commonly used variables earlier in the list.  It's my understanding that earlier is better as the variables get stored in a lookup table and the earlier they are in the list the faster they can get used by the interpreter.  I therefore put variables only used during initialization later in the first line. Don't know if any of these ideas are true, but Robert's use of single variables certainly produced a quantum leap in speed.

Here's some of what he wrote:
Hi Jim,
First I carefully added variables that were not used before by the program using a text editor.
Then once I was happy with all the changes I saved the text file and loaded that into the MCX with quicktype because the MCX has a longer 256 limit per line. Then I saved that loaded text file with a CASVE. Now the good old MC-10 can load it and run it.
I was surprised that the speed increased so much.  The way I checked the speed was to clear the top and have the hero ----> X walk across the entire screen timed. In both versions I got 16.13 seconds for the original and 12.92 seconds for the optimized.
12.92 / 16.93 = .8009 ----> a %20 difference. kind of shocking I was thinking it would be maybe half that.
Sure we could do a dual authorship but the prize is offered at the expo right? Are you going?
By the way it could be tweaked just a bit more but it can be quite time consuming to do the conversion.
Warm regards,
Robert
Since Robert had been so helpful, I put his name on a new title screen I added to line 0.

Robert also made some suggestions about scoring.  It became clear that since he was playing the game by himself that he needed some way to see whether he was improving in his play.  I, on the other hand, was primarily playing the game against my son and therefore repeating maps with him trying and then me, and so on.

It became clear that there were possibilities for whole bunch of alternative "play modes."  If it weren't for the 10-liner restriction these could be easily handled in one program with some menus.

What I added to try to satisfy some of these different ways of playing was a timer function and report of the number of tries for each puzzle. These were in keeping with what my son and I had been doing. We would take turns trying to complete a map, and the person who got the highest score and lowest time and # of tries was "the dude" for that puzzle. I guess you could call this "two-person" or "competitive mode."

I think what Robert wanted was something that could be called "tournament mode." A person tries to get the best total score for a fixed number of maps and also gets rewarded from trying maps of higher difficulty level. So I also added an aggregate score for all maps completed that takes into account the time factor in the scoring for each map and the number of tries needed for the total number of maps completed, etc.

I was also able to combine some lines from the old program and use more IFs instead of an ON-GOTOs (256 chars to play with certainly is very liberating), which freed up a line for the puzzle # entry routine that allows the player to select specific puzzles.  Robert also pointed out a number of places where he though program logic could be rationalized, which was very helpful.

The biggest change that his feedback prompted was from a suggestion to add a "bomb" if there was a wall that totally blocked passage to the exit it could be removed. So I added a bomb (wait the NSC will flag this)-- I mean to say I added a routine to the game source code so the player can now blast virtual obstacles once per puzzle in our computer puzzle game;) Just hit the SPACE key and a series of reverse boulders will appear in the 4 cardinal directions around you. The player is able to move through these boulders. Blue wall units around the edge will not be destroyed, nor will regular boulders. However, the exit and diamonds can be destroyed so one must be careful.

I also added an auto level select feature where if the player just hits ENTER between maps the game uses the level selected for the last map.

I also streamlined the key entry routine quite a bit so the game no longer uses any Ctrl keys, just regular keys:

ASWZ to move
R to restart a map
N for a new map
P to enter a code for a specific map/puzzle (4 numbers separated by zeroes)
SPACE to blast around you.

I also changed the exit character to a reverse "E"

Now, I should start thinking about porting it to the Dragon and Coco.


Addendum:

After another set of helpful suggestions by Robert I made some more changes.
Now you can choose skill level at start-up. If you choose 1 then the program uses the standard boulder fall routine where only being in positions like this can kill you:
  @
X █
███
But if you choose 2 then any boulder falling next to you (or even just flying past) can potentially kill you such as:
X █
███
This makes skill level 2 much harder.  Score is also affected. Now the higher the difficulty level of the puzzle and the higher the skill level makes each diamond worth more.

Also different difficulty levels provide different numbers of bombs: 1-29=1 bomb, 30-59=2 bombs, 60-89=3 bombs.

Tuesday, 19 January 2016

January 2016 Retrochallenge 8: New 10-Liner Puzzle Game "Dash"

Puzzle-- Start Puzzle-- Finished
Dave Maunder (Bushy555), a member of the Yahoo MC-10 group and an avid user of the VZ200/300 posted that there is an up-coming 10-Liner Basic game programming contest being hosted by the Retrocomputing site Homputerium and posted on Vintage is the New Old. I decided to give it a try, so I dredged up an old project based on a video I saw on YouTube for a text based game written in C++ called "Dash." It is a version of the classic game "Boulder Dash." The use of text graphics inspired me to try to recreate the boulder rolling mechanics on the MC-10. Obviously, Basic is not as fast as C++, but with some tight coding and a limited number of boulders it might be doable. But could it be done in 10-Lines?

I think the answer is yes. The program I have created is 2 parts puzzle game, one part quick reflex arcade game. Well, one part might be pushing it. It's not super fast, but occasionally good timing will be critical to solving the randomly created puzzles, because the boulders do move and are erratic unless blocked in or wedged against each other.

The game mechanic is simple. Boulders fall when there is green space beneath them. They roll randomly from side to side if there is green space on either side of them. They won't crush you if they are next to you or right above you. The only way they can crush you is if they tip off something (have green on either side) and then roll into you. In other words if you are the X and boulders are @s then:

  @
X █

is a very dangerous position to be in. I think of it as the boulder rolling down off something and then on into you. Normally, as a confident miner, you can easily handle boulders, using bracing to keep them above you or temporarily wedging them in place when they are next to you, or blocking them if they are on level ground rolling toward you. But if they roll off something and then immediately head towards you, you're doomed.

Obviously, to solve the puzzle you must also not become blocked in by boulders, so you must be careful where you mine and be wary of how avalanches will occur so as not to hinder your movement to the exit (symbolized by a reverse "I"). It might also be necessary to create avalanches in specific ways to effectively clear the way. That being said, the puzzles are random so sometimes there will be no way to exit, or you might be trapped from the beginning. If that is the case just hold down Ctrl-J (Junk the maze/puzzle) to get a new puzzle.

Also, if you hold down Ctrl-D (Do-over) before exiting the maze, the maze will be redrawn in its initial starting layout, and you can try again. In fact, I found this feature useful when playing the game with my son. The first person tries the maze and gets to a point before exiting but having gathered as many of the treasures ("*" symbols) that are also scattered throughout the maze as possible, and then hits Ctrl-D. The score achieved to that point is reported and the maze is redrawn in its starting condition. Then the other player can try to get a better score. We found it interesting for the person waiting for their try to sit away from the screen so they couldn't see the mistakes being made by the other player, so each player gets a fair try at solving it on their own.  Then the scores can be compared and a new maze created.

The game starts with a level prompt. This simply determines how many immovable ("") wall blocks get scattered around. It also influences the scoring. You get a number of points equal to the level for every treasure ("*") that you collect. I found that 20 is a good starting number. Numbers below that might be useful for young kids, and much above, that starkly increase the number of unsolvable puzzles that are generated.

Here's a video demo:

The source code can be found here:
https://github.com/jggames/trs80mc10/tree/master/quicktype/Puzzle/Dash
It can be run by quicktyping the text file into the VMC-10 Emulator.

Addendum
One of the little annoyances I have with the current code is that it is too tightly packed to add a random number seed feature. If you load from a cold start the game will always proceed through a set sequence of pseudo random mazes. However, my son Charlie and I were able to overcome this by typing in a command like this:
PRINT RND(some number)
to reseed the pseudo random number to something less predictable than the last number called by the RND function. However, in Color Basic if you use a negative number in the RND function, the pseudo random number generator gets set to begin at that specific number, so that you can repeat specific desired sequences. So typing something like:
PRINT RND(-17026) 
will generate a specific puzzle (in this case one with a blocked exit). Try it! Using this method people could in principle "discover" and keep track of unique puzzles that they find particularly challenging. Also, of course, you will have to choose the same Level for the exact puzzle to be regenerated so for puzzle (-17026) use level 20 to see the blocked exit.

Sunday, 17 January 2016

January 2016 Retrochallenge 7: Ministry and Mini Pac-Man Revised

I ported the simple empire simulation game "Ministry" from C to Micro Color Basic back in mid November. Now I have made the few minor edits needed to make it work on Color Basic for the Colour Computer and Dragon.

The source code came via Rudi Horne's "Let's Compile" Youtube channel: https://youtu.be/Fw1H0wGP6fk.Thanks to Rudi and the original programmer, Wesley May, for the inspiration!  Here's were you can find the source:
https://github.com/jggames/trs80mc10/tree/master/quicktype/Simulations/Ministry

The original code wasn't very hard to translate to Basic. Not too much in the way of distinctive C programming techniques were present and only the simplest of commands were used. I wouldn't be surprised if the program was originally Basic and then translated to C. My other hypothesis is that it was some kind of educational assignment. In any case it is quite complex in its game play and options despite its relative simplicity as a program. It provides a simple example of a "God Game" for the MC-10 (and now the Coco and Dragon) in Basic. You don't play to "Win" because as far as I can tell, there are no "winning" conditions or a win routine. Instead, you play to achieve the highest amounts of wealth, land and scientific achievement for your society as possible.

Back when I was first playing such "type-in" style games I could imagine playing a game like this for a score to compare with a friend's achievement. However, I think the game could actually be easily modified to allow two players to play against each other or to add some kind of arbitrarily determined set of winning conditions. I would also like to add some kind of map function to visually represent the territorial expansion of your "empire." I take it that the title represents the player's ability to manipulate "with God like power" all the major "ministries" of government, which makes me suspect that Wesley may is a Brit, or from somewhere else that uses a Westminster system.  Here's a video to give you a sample of the game play:
If anyone plays the game please let me know if you run across any errors, bugs or suggestions. I try to play it enough to make sure there aren't any obvious programming errors, but you just never know.

For instances, I realized that there were several places where I added some INT functions to clean up the display of numbers in the MC-10 version right near the end of my editing back in November (last minute changes), which ended up making 2 lines (2040, 2301) too long for the 128 character limit of the MC-10. When you "quick type" the program into the Emulator, which just takes a text file and dumps it into the MC-10 as if you are typing it at the keyboard, these lines just get chopped. By revisiting the project to port the program to Coco and Dragon, I had one more opportunity to find such snags.

Since it didn't take too much effort to fix Ministry I turned my attention to the Mini Pac-Man program I discussed a few postings back. There were a few things niggling at me about the game. One was that it had an an extra Sound statement in the original source code, which really slowed the game down. It sounded for each move you made even when you were not eating dots. It was noisy and slow and I couldn't hear it in the video of the original Atari version, so I took it out. I also didn't like the reverse video greater-than symbol for Pac-Man. I thought some simple changes would allow me to use either a normal less or greater-than symbol combined with a "=" sign to simulate mouth movement. I also wanted to add variable scoring for the different levels (higher scoring for higher levels) and a visual image of whichever character (Pac-Man or the Ghost) that is left standing on the field at the end of the game. Finally I wanted to add the Quick Keys pokes for the Dragon version, which are really necessary to make the game playable on keyboard of that system. Anyway, here's a video of most of the changes:

Since the video I also added a slightly more satisfying sound and representation (via some additional Pokes) of the player or ghost eating the the other at the end. Here's the source code of the Dragon version with the Quick Keys pokes in line 0:

0 REM FOR DRAGON->IFPEEK(269)+PEEK(270)<>1THENPOKE65283,52:POKE256,116:POKE257,1:POKE258,81:POKE259,126:POKE260,PEEK(269):POKE261,PEEK(270):POKE269,1:POKE270,0:POKE65283,53
1 POKE65495,0:INPUT"LEVEL (1-9)";E:CLS0:M=1024:FORY=0TO9:FORX=0TO9:POKEM+X+Y*32,46:NEXT:NEXT:DIMF(255):F(0)=60:F(8)=62:F(94)=62:F(9)=60:F(10)=60:X=0:Y=0:A=9:B=9:W(0)=98:W$(1)="YOU WIN!!"
2 P=M+X+Y*32:G=M+A+B*32:C=PEEK(P):D=PEEK(G):POKEP,F(S):POKEG,98:S=0:IF(PEEK(344)ANDPEEK(343)ANDPEEK(342)ANDPEEK(341))<>255THENS=PEEK(135)
3 Q=(S=8ANDX>0):Q=Q-(S=9ANDX<9):R=(S=94ANDY>0):R=R-(S=10ANDY<9):X=X+Q:Y=Y+R:IFC=46THENPOKEP,61:SOUND99,1:C=32:T=T+E:PRINT@11,T;
4 P=M+X-Q+(Y-R)*32:G=M+A+B*32:POKEP,C:POKEG,D:IFRND(11)<=E THENA=A-(X>A)+(X<A):B=B-(B<Y)+(B>Y)
5 ON-((X=A)+(Y=B)<>-2)GOTO2:W(1)=F(S):C=-(T=(E*100)):P=M+X+Y*32:POKEP,61:SOUND99,1:POKEP,W(C):PRINT@353,"gAmE oVeR";:PRINT@385,W$(C);:PRINT@416,;:RUN1