Converting Programs from MC-10 to Coco

Converting MC-10 Basic source code to Coco Basic requires paying attention to the following special instances where Coco Basic requires spaces after variable names and the following commands (the version of MS Basic for the MC-10 seems to have eliminated these possible confusions and thus allows complete packing of all lines):

ONT_GOSUB
FORT=D_TO
IFA>B_THEN
A_AND_B
A_OR_B
FORA=1TOB_STEP

All screen pokes have to be changed to reflect the change of the start value for the MC-10 screen (16384) and the Coco screen (1024).  The MC-10 does not have an ELSE command, so all cases of the use of this must be modified.  If the last command of an IF preceding an ELSE  statement is a GOTO, than all one must do is move the subsequent commands to the next line.  If not, then a GOTO will have to be added to jump over this new line. 

I add a routine (10000-10004) to handle the high speed poke of the Coco.  The MC-10 runs its basic programs about 10% faster than a Coco in regular speed, so some of the basic programs I have written really require the use of high speed.  But in other instances, high speed makes them a little too fast.  For the latter instances, I make using high speed optional so that people can use the lower speed as a difficulty level option, or learning mode. Otherwise, the routine (which someone on the Dragon Archive forums kindly gave me--Zephyr?) automatically pokes high speed for the Coco 3, but always prompts for Coco1 and 2s (and Dragons) just in case one's Coco 1 or 2 can't handle high speed. 

Any orange text screen use must be switched from the MC-10's POKE49151,64 to the Coco's SCREEN 0,1. Also, all the peeks to sense the keyboard rollover tables must be changed, because these are handled very differently between the two machines.  Here's the difference between how I continuously sense for key input on the MC-10

20 ONK(PEEK(17023)ANDPEEK(2))GOSUB1,2,3,4,5

These two peeks will return the value of whatever key is currently being pressed on an MC-10 keyboard and then consult array K to branch to the appropriate subroutine for that key.  K is a 255 unit numeric array in which the elements represent the ASCII values and what is stored in those values represent which subroutine to jump to.  Typically the arrow keys get assigned 1,2,3,4 and the space bar gets 5.  On the coco you must consult a sequence of peek locations to check if keys are being pressed and then consult a peek location for the ASCII value of the key being pressed.  For example the following will accomplish the same as the MC-10 code above:

19 ONK(PEEK(135)) GOSUB8,9,10,11,12:RETURN
20 ON1-((PEEK(345)ANDPEEK(344)ANDPEEK(343)ANDPEEK(342)ANDPEEK(341))=255) GOSUB19

In most of my programs the main loop (along with input like that above) is usually located in the 20-25 line range.  So I just have to go and change the MC-10 code for the above.  This is not usually a problem as the Coco allows 256 long character lines (versus the MC-10s 128 character limit) and with the speedup poke's slightly higher speed, no appreciable loss of speed occurs.  I have discovered that Coco 2s with Extended Basic versions  1.2 and above need to have the peek addresses (345-341) in the rollover table poked with 255 before consulting them, as they are not reset when the key stops being pressed.  Even with this large number of pokes, the speed typically only drops back to the level of the MC-10, which was as I said, about 10% faster than an un-double-speed-poked Coco.  I learned about this problem from Zephyr on the Dragon forums and from Arthur Flexser.  Zephyr noted:

The truth is that Tandy modified the keyboard routine slightly for v1.2, and added the following extra code at the start. This was done in an attempt to speed-up BASIC when no keyboard input was required. They quickly realised that this caused problems for existing BASIC software that read the keyboard by peeking the rollover table. The extra code was then removed for the CoCo 3.

Other than such changes, the machines are pretty much the same if one is not using high res graphics or any other Extended Basic commands not available in the MC-10 such as PRINT USING, ATAN, STRING, etc.  But most of these functions can be recreated in Basic.  The old Coco manual "Getting Started With Color Basic" provides some useful subroutines, such as one for ATAN, which I needed when I ported the classic  8-bit astronomy program SKYSCAPE:

Available at:
https://github.com/jggames

The Doctor's Adventure on Scaro: Intro and Program Notes

Doctor

INTRO TO THE DOCTOR'S ADVENTURE ON SCARO

You’re an inveterate tinkerer.  Because you have a Ph.D. in Physics, and also because this is a fact you never hesitate to remind people about, your friends call you "the Doctor."  Because of your advanced knowledge of physics you have managed to invent a time machine.  Using your time machine you have begun to travel through space and time.  Unfortunately, during your travels you uncover a plot by the evil species, known as the Darlecs, to gain control of the entire universe.  They have managed to capture the "Infinity Device" which will allow them to destroy a whole star system, if they should so desire.  They plan to use the threat of this device to extort untold wealth from the other civilizations of the universe.

INSTRUCTIONS

You were in the midst of attempting to recover the device when you were captured, but now you have managed to escape and continue your mission.  You must collect the Infinity device parts (Purple) while avoiding the Dalecs (Red).  Your advantage is speed.  Dalecs are a somewhat sluggish robotic race.  When not actively following orders they tend to shut down into an energy saving mode from which it takes a moment for them to recover.  You can use this to your advantage when exploring their lair.

To move use:
  W                                                    Y
A   S                     OR                 G   H   J
  Z

Pressing space will cast an "energy net" (orange) in whatever direction you were last moving.  When Dalecs run over this net they will be destroyed.  Beware, you cannot cast a net directly onto a Dalec.  You are able to pick nets up by running over them.  You have managed to collect 3 by the time the game begins.  Another 4 can be found at random locations throughout the base.

There are also nuclear reactor energy stations (yellow) spread throughout the complex.  These can be modified to explode spreading a deadly pulse of energy, which will destroy all the Dalecs in a particular area of the complex.  However, they can be tricky to adjust, so you might have to work a little while at getting them to go critical (by running into them).  When they do go critical, a countdown from five will begin.  You have that much time to get to the next area of the complex to escape the energy pulse.

Collect the yellow keys to open the locked doors of the complex.  There are enough keys for all the doors, but sometimes they will be protected by Dalecs. Pressing the 'K' key will display the number of keys you currently have.

After having collected all the Infinity Device parts (12) a message will flash indicating it is time to go to the time machine.  When you get to the time machine you will be presented with your score, which reflects the number of Dalecs killed and other aspects of your skill at getting through the maze.  You will not be able to get into the time machine until you have collected all the parts.  Pressing the 'P' key will display the number of parts you currently have collected.

If you run into a Dalec you die.  If the Dalecs touch you, they will shock you with their electrical prods. You can receive 3 such hits before you die.  Use the Dalecs literal machine responses against them by luring them into different areas of the complex in order to get around them or destroy them more easily.

Don't assume anything about the maze of the Dalecs. Some mysteries and anomalies exist in how it is structured, that you might be able to use to your advantage.

To download the MC-10 version of the game go to:
http://rsp.retrocomputacion.com/games-the-doctors-adventure-on-scaro/
or to the following link for the latest Coco version:
http://rsp.retrocomputacion.com/games-a-romp-in-the-garden-ported-to-cocodragon/


Jim Gerrie, Cape Breton Island, Nova Scotia, Canada             17 October 2012


P.S.
I would like to thank my son Charlie for his contribution of the 8-bit music intro to the game and his work as beta tester and the rest of my family for their patience with my programing hobby activities.


VERSION HISTORY

DOCTOR1.TXT
Preliminary coding

DOCTOR2.TXT
End Game routines

DOCTOR3.TXT
Tweaks to the Maze and bug fixing. Added the ability to call up # of keys and parts.

DOCTOR4.TXT
Fixed rare but major bug in maze read routine involving confusion of variable 'O' and digit '0' in FOR/NEXT loop of that routine. Tightened code of main loops.  Added alternate G,Y,H,J key input.

DOCTOR5.TXT
Fixed a rare problem with key pickup routine, when key is on the edge of the screen between two areas.

Here is a screen shot from the Coco version of my latest programming production--"PipeFrenzy."  I'm hoping that this is the definitive version.  I have switched the key input to using the INKEY function to make the game a little more challenging.  I have also changed the way the starting and ending positions  are chosen and have added the placement of some random "blocks" in the centre of the screen grid.  I should mention that one change I also made at some point over the last few weeks, is to randomize the direction that water flows when it hits a "T" junction of pipe.  This can be used to a player's advantage.  If you're in a circumstance where the type of corner pipe isn't coming up, you can opt to throw the dice on a "T" junction, which might do the trick instead.

I have found that level 1 is good for getting the feel of the game.   Level 2 is the level I use for regular play, but I'm starting to feel an urge to try to move up to level 3.  Levels above that are probably beyond the ability of anyone to play, but I have left them in with the vain hope that someone out there might find the game interesting enough and challenging enough to work at mastering them.  Pipe Frenzy can be found on my website in the "JGGAMES5.DSK" zip file, which can be found by clicking here:
https://github.com/jggames

Pipe Frenzy Update

Well here's an image of my new game Pipe Frenzy being run on an Un-extended Basic 16K Coco 1.  It seems to run fine except I had to remove the X=RND(-TIMER) command at the beginning of line 2500.  I guess the TIMER function is part of the extended Basic command set.  Other than that it seems to run OK, although I'll have to find a different way to seed the random number generator.  I noticed, however, that the key sense routine that I use, which uses the keyboard rollover table, doesn't seem to work quite right on my Coco 2.  The peek locations don't seem to reset to 255 as soon as you're not holding them down anymore, as seems to happen on a Coco1 or Coco 3.  It's very strange.  It also runs fine on Vcc emulator.  I'm thinking of switching the key sense routine to using INKEY, since the game seems a little too easy using the rollover table routine.  You can just hold the space bar down (slowing the game immensely) and cycle the shapes until you get the one you like.  The result is that there is much less need to strategically move in order to best deploy the shapes that you can see.  I also don't like the way the start and end points are chosen and have noticed that in the on-line Java version, which I've been using as a model, the start and end are simply always placed on the opposite rows of the screen (spaced one row in towards the middle).  I think I'll switch to this method to ensure a more challenging distance between start and end points, and also add the occasional solid block piece at random in the middle to increase the challenge further.  Look for an updated version to be distributed soon...

One Way the MC-10 is Tops

Stumbled upon a neat article on the site "Hard Core Gaming" discussing the game "Catrap", for the Game Boy, which the author of the article insisted was based on one of the "great basic games" of the early 1980s.

I think I had actually searched on "great basic games", which is probably why I found it.  One of the "goals" of my hobby is to try to bring to the MC-10 as many of the great/most classic basic games of the 8-bit era as I can.  So I was interested to see that the game didn't look overly complex in its screen graphics:

Original Version

MC-10 Version

In fact that "neon" green screen on the right hand side looked faintly VDGish.  It looked like a good prospect for a port.  Of course, it was not going to be quite that simple. Originally created in 1985 on a MZ-700 home computer by Yutaka Isokawa. The BASIC listing was published in the August 1985 issue of the magazine "Oh!MZ Publications," which hard core gamer had luckily been able to secure a scan of.  However, it was not a very good scan and the original language was quite an esoteric version of Basic, which didn't use data statements, but instead read data from a special file. Things didn't look good, but I decided to do a little further searching, and eventually I was able to uncover a French version of the same game (thank goodness again for my old highschool French), in a different version of Basic that did use DATA statements to store the 50 levels.

The original game was called "Pitman" and it is essentially a puzzle solving adventure game similar in style to Sokoban (which I have created a version for the MC-10 using the screens transferred from an OS9 text version made for the Coco that I got from the old RTSI OS9 software archive):

Pitman was very nicely programmed by Isokawa and only used the 40*24 text graphic characters of the MZ700. The original graphics were based on the use of 3X3 characters.  By reducing these to 2X2 character VDG graphic equivalents, I was able to adjust the game to the much smaller MC-10 32*16 screen.  Then it was just a matter of making sure all "scaling" factors used in the program were adjusted to the new regime.  The game also included level editor and save/load functions, which I have now fully implemented for use on both an MC-10 cassette system and Coco disk system.

Obviously the MC-10 graphics are a little more chunky than the original, but as a dedicated MC-10er, I have come to revel in the glorious chunky graphics of my favourite 8-bit machine.  After all, the visible squarish pixel is the very symbol and essence of "8-bit."  And in that regard, the MC-10 is king!

I have added the latest version of Coco Pitman to my JGGAMES5.DSK, which is available from my GitHub site: https://github.com/jggames

I've updated the title page to look more like the original and added disk directory and save features to the screen editing section of program.

Romp Rules and Version Notes

Noticed a couple of videos of the game "Garden" on YouTube by a Bulgarian programmer (hence the colors chosen for the title screen). See:

The concept was simple enough that it seemed possible to convert to MC-10 basic.  The basic idea seemed to be that the player's character is some yob romping around someones garden, crushing the grass and picking the flowers.  In the original, it is the garden's owner who is chasing the player, which is conceivably why the owner avoids stomping on the grass, but only follows along the pathways created by the player.  Due to the limitations of the MC-10 character set I decided to make the enemy a snapping dog figure using the <=> characters.  Conceivably, in my version, the dogs have been trained somehow not to stomp the grass, hence their tendency to only follow the player's path.

Versions 1-8
Took a while to create an algorithm for the dogs' movement that was similar in effect to the original and also challenging.

Basically the algorithm checks each time the dog reaches an intersection with at least 3 passages leading off it.  Then it changes direction from the current one, to one that tracks your character.  If it reaches any impasses it chooses a new random direction and heads off.  There is a random selection every 30 or so moves to simply change direction randomly or choose a new direction based on tracking (either horizontal or vertical).

Version 9
Added the "bone" feature, which allows the player to create passages that can be used to lure the dog into finding the bone "/".  When it does, the player scores 250 points and that dog stops for good at the bone.  When that happens, a new dog is released from the top left.  The player should avoid the stationary dog, as touching it is deadly. Perhaps the player is Homer Simpson (hee hee hee), and the owner of the garden as Mr. Burns (RELEASE THE HOUNDS!)

Version 10
Fixed the capture routine so that the dog gets to chew on you a bit before the game ends (it deserves that much, after so much hard work).  Changed the grammar of the end prompt from "Take another romp?" to "Go for another romp". I was thinking of "take another walk", but I realized that in English the normal phrase would be to say "go for a romp."  Added a randomize peek at the beginning of the program, so that it doesn't start the same way when the program is run from a cold start.  Fixed the screen creation routine so that a bone will appear for every new screen.

Jim Gerrie
Cape Breton Island--"Ciad Mile Failte!"
Nova Scotia, Canada
Program developed in the month of November 2012

The MC-10's Cousins

An interesting thing I have discovered about the MC-10 as I have explored the Net looking for software to port, is the other computers that share some hardware affinity with it (besides the Tandy Coco).  The most obvious hardware affinity has to do with the distinctive graphics chip used by the Coco and the MC-10: the Motorola MC6847 Video Display Generator (VDG). I had always felt a little ashamed about this aspect of the MC-10 and Coco when compared with other 8-bits. The VDG was not the most powerful graphics chip by any means, certainly not by 1983.  However, it was one of the very first colour graphics chips for use with a TV and powerful indeed when it was first developed in the late 1970s. When I realized that the Coco and MC-10 were not the only machines that had used this chip, I embarked on a quest to find their distant cousins, because I thought, if I could find programs developed in Basic for these other machines and their shared distinctive grotesque, unusual, but eerily familiar nuclear neon green 32*16 text screen (and 64X32 basic graphics set) these would certainly be more easily converted than the programs of other 8-bit machines with their much more typical 40X24 screens.

In the process of my search I came across a host of such machines (many with groups like that for the MC-10 on Yahoo). For example, there was the very early home computer/game system called the APF Imagination Machine. Then there was the Dragon 32/64 Computer made in Wales and there was the Dick Smith VZ-200/300.

Dick Smith was an electronics retailer in Australia who licensed  the design for the Video Tech Laser 210 / Laser 310 - Texet TX 8000 - Salora Fellow computers, which were sold all over the world, but especially in central and Northern Europe. The VZ 200/300 had developed a fierce following in Australia where the Dick Smith electronics company was seen as a real "Aussie Battler" taking on the likes of giants like Radio Shack. In learning about these other systems I learned about the powerful affection other people had for their childhood introductory computers and about the diverse history of home computing (a truly global phenomenon) in the early 80s. I also found ideas and code to bring to the MC-10.

From the VZ200 for instance I ported, or took inspiration from, Dracula's Castle, which has many interesting semigraphic images of strange monsters, which I won't show here (except for the Zombie below) so as not to spoil the fun you might have in discovering them for yourself, and Gammon, which provides a nicely laid out version of backgammon. I had ported a version of backgammon from a TRS-80 model 1 program, but in the midst of converting it I wasn't able to get the screen to display as nicely as this version. I'm not sure which one plays a better game of backgammon. I took the Model 1 backgammon from code provided by Jeff Vavasour on his really neat site http://www.vavasour.ca/jeff/level1/simulator.html. I think Dracula's Castle is originally from the Sinclair ZX81 and was completely in black and white.

It was called "Tomb of Dracula."  It's images match those of Dracula's Castle for the VZ:

My port of the game "GhostBlasters" by G. Rowe from the VZ was not as direct a port as these others because it had been originally designed mostly for the lowres graphics screen, except for its nifty title screen, as can be seen above, and a bonus round screen in which the stay-puff-marshmallow man makes an appearance. The original main action graphics looked like this:

The premise seemed interesting enough to try to make a port for the MC-10.  However, I didn't have the ability to program the game using the hires graphics of the MC-10, which can only be got at through machine language programming. So I decided to simply try to re-program the main action screen myself in lowres graphics (see the black screen above), while using the title and bonus screen lowres basic code from the original. The result is a hybrid re-program/port I re-christened "GhostBusters." It can be a bit tricky, but with some persistence, players will discover that there are certain places on the screen where you can safely position your central ghost buster, so that he will never cross the stream of the other two ghost busters, for example, you can move him completely to the left or right to stand right next to one of the other ghost busters.  From such a position you can then make brief forays out into the more dangerous middle (where you can cross streams) when absolutely necessary. Give it a try in both its VZ original form using one of the nice VZ-emulators for that machine, or the versions I have made for the Coco and MC-10 which can be found here: https://github.com/jggames

The following is a table for converting the graphic character of a VZ program listing containing embedded lowres graphic characters to their Coco/MC-10 CHR$ equivalents.  It was created simply by writing a program for the VZ emulator that outputs to a virtual printer (i.e. text file) all the ASCII characters above 128.  Utilities like these are essential for doing program conversions. Once you have details like this, simply use search and replace in your text editor to adjust the file listing of the program to be converted.
CHR$(128)= €€€€€€
CHR$(129)= €€€¸¸¸
CHR$(130)= ¸¸¸€€€
CHR$(131)= ¸¸¸¸¸¸
CHR$(132)= €€€‡‡‡
CHR$(133)= €€€¿¿¿
CHR$(134)= ¸¸¸‡‡‡
CHR$(135)= ¸¸¸¿¿¿
CHR$(136)= ‡‡‡€€€
CHR$(137)= ‡‡‡¸¸¸
CHR$(138)= ¿¿¿€€€
CHR$(139)= ¿¿¿¸¸¸
CHR$(140)= ‡‡‡‡‡‡
CHR$(141)= ‡‡‡¿¿¿
CHR$(142)= ¿¿¿‡‡‡
CHR$(143)= ¿¿¿¿¿¿
CHR$(144)= €€€€€€
CHR$(145)= €€€¸¸¸
CHR$(146)= ¸¸¸€€€
CHR$(147)= ¸¸¸¸¸¸
CHR$(148)= €€€‡‡‡
CHR$(149)= €€€¿¿¿
CHR$(150)= ¸¸¸‡‡‡
CHR$(151)= ¸¸¸¿¿¿
CHR$(152)= ‡‡‡€€€
CHR$(153)= ‡‡‡¸¸¸
CHR$(154)= ¿¿¿€€€
CHR$(155)= ¿¿¿¸¸¸
CHR$(156)= ‡‡‡‡‡‡
CHR$(157)= ‡‡‡¿¿¿
CHR$(158)= ¿¿¿‡‡‡
CHR$(159)= ¿¿¿¿¿¿
CHR$(160)= €€€€€€
CHR$(161)= €€€¸¸¸
CHR$(162)= ¸¸¸€€€
CHR$(163)= ¸¸¸¸¸¸
CHR$(164)= €€€‡‡‡
CHR$(165)= €€€¿¿¿
CHR$(166)= ¸¸¸‡‡‡
CHR$(167)= ¸¸¸¿¿¿
CHR$(168)= ‡‡‡€€€
CHR$(169)= ‡‡‡¸¸¸
CHR$(170)= ¿¿¿€€€
CHR$(171)= ¿¿¿¸¸¸
CHR$(172)= ‡‡‡‡‡‡
CHR$(173)= ‡‡‡¿¿¿
CHR$(174)= ¿¿¿‡‡‡
CHR$(175)= ¿¿¿¿¿¿
CHR$(176)= €€€€€€
CHR$(177)= €€€¸¸¸
CHR$(178)= ¸¸¸€€€
CHR$(179)= ¸¸¸¸¸¸
CHR$(180)= €€€‡‡‡
CHR$(181)= €€€¿¿¿
CHR$(182)= ¸¸¸‡‡‡
CHR$(183)= ¸¸¸¿¿¿
CHR$(184)= ‡‡‡€€€
CHR$(185)= ‡‡‡¸¸¸
CHR$(186)= ¿¿¿€€€
CHR$(187)= ¿¿¿¸¸¸
CHR$(188)= ‡‡‡‡‡‡
CHR$(189)= ‡‡‡¿¿¿
CHR$(190)= ¿¿¿‡‡‡
CHR$(191)= ¿¿¿¿¿¿
CHR$(192)= ÿÁ¾¢®±ÿ
CHR$(193)= ÿƒíîíƒÿ
CHR$(194)= ÿ€¶¶¶Áÿ
CHR$(195)= ÿÁ¾¾¾Ýÿ
CHR$(196)= ÿ€¾¾¾Áÿ
CHR$(197)= ÿ€¶¶¶¾ÿ
CHR$(198)= ÿ€öööþÿ
CHR$(199)= ÿÁ¾¾®Œÿ
CHR$(200)= ÿ€÷÷÷€ÿ
CHR$(201)= ÿÿ¾€¾ÿÿ
CHR$(202)= ÿß¿¿Àþÿ
CHR$(203)= ÿ€÷ëݾÿ
CHR$(204)= ÿ€¿¿¿¿ÿ
CHR$(205)= ÿ€ýóý€ÿ
CHR$(206)= ÿ€ýû÷€ÿ
CHR$(207)= ÿÁ¾¾¾Áÿ
CHR$(208)= ÿ€öööùÿ
CHR$(209)= ÿÁ¾®Þ¡ÿ
CHR$(210)= ÿ€öæÖ¹ÿ
CHR$(211)= ÿÙ¶¶¶Íÿ
CHR$(212)= ÿþþ€þþÿ
CHR$(213)= ÿÀ¿¿¿Àÿ
CHR$(214)= ÿøçŸçøÿ
CHR$(215)= ÿ€ßç߀ÿ
CHR$(216)= ÿœí÷ëœÿ
CHR$(217)= ÿüû‡ûüÿ
CHR$(218)= ÿž®¶º¼ÿ
CHR$(219)= ÿÿ€¾¾ÿÿ
CHR$(220)= ÿýû÷ïßÿ
CHR$(221)= ÿÿ¾¾€ÿÿ
CHR$(222)= ÿûý€ýûÿ
CHR$(223)= ÿ÷ãÖ÷÷ÿ
CHR$(224)= ÿÿÿÿÿÿÿ
CHR$(225)= ÿÿÿ ÿÿÿ
CHR$(226)= ÿÿøÿøÿÿ
CHR$(227)= ÿë€ë€íÿ
CHR$(228)= ÿÛÖ€Öíÿ
CHR$(229)= ÿÙé÷ËÍÿ
CHR$(230)= ÿÉ֩߯ÿ
CHR$(231)= ÿ÷øüÿÿÿ
CHR$(232)= ÿÿãݾÿÿ
CHR$(233)= ÿÿ¾Ýãÿÿ
CHR$(234)= ÿÖã€ãÕÿ
CHR$(235)= ÿ÷÷Á÷÷ÿ
CHR$(236)= ÿßÇ÷ÿÿÿ
CHR$(237)= ÿ÷÷÷÷÷ÿ
CHR$(238)= ÿÿŸŸÿÿÿ
CHR$(239)= ÿßï÷ûýÿ
CHR$(240)= ÿÁ®¶ºÁÿ
CHR$(241)= ÿÿ½€¿ÿÿ
CHR$(242)= ÿ®¶º½ÿ
CHR$(243)= ÿÝ»»»Éÿ
CHR$(244)= ÿçëí€ïÿ
CHR$(245)= ÿغÚÚÆÿ
CHR$(246)= ÿÁ¶¶¶Ïÿ
CHR$(247)= ÿüþ†úüÿ
CHR$(248)= ÿɶ¶¶Éÿ
CHR$(249)= ÿù¶¶¶Áÿ
CHR$(250)= ÿÿÉÉÿÿÿ
CHR$(251)= ÿ¿Ääÿÿÿ
CHR$(252)= ÿ÷ëÝÞÞÿ
CHR$(253)= ÿëëëëëÿ
CHR$(254)= ÿÞÞÝë÷ÿ
CHR$(255)= ÿýþ¦úýÿ

International Draughts: A Language Translation Game Port

One of the most interesting quirks about the sad history of the TRS-80 MC-10 was although it ceased production only a year after it was released in North America, and so was banished to the category of failed "never-ran" 8-bit computers forever overshadowed by the Ataris, Commodores and better known Tandy products (or so I thought), the full story of the orphan MC-10 turned out in reality to be more positive.  Somewhat akin to the case of the actor Jerry Lewis, the design for the MC-10 (although I didn't learn this until recently) was passed to a French computer company called Matra-Hachette and in a much more sexy red plastic case went on to become one of the great intro 8-bit systems of that country, something like the ZX81 in Britain.  It was called the "Alice" and it makes the beige North American MC-10 look positively dowdy:

I didn't know anything about this until I stumbled upon it while researching my programming projects for the MC-10.  It was kind of like discovering that your dotty old grandfather was actually a 1960 rock-and-roll heart throb, or that your wife has a twin who is an international spy, whod'a thunk it!

What this meant in practical terms was that there was potentially more software out there for the MC-10.  All I had to do was dust off my old highschool Canadian French and go find it.  Well it turned out that the French hadn't stayed long with the garden variety MC-10, but had quickly updated the internal hardware specs, and soon after exterior casing, creating much more powerful machines with powerful graphics capabilities.  So most of the software preserved on the Net was machine language games for these higher level machines.  That being said, a certain amount of Basic language software was created for the MC-10 level Alice, and some of it seemed worth translating to the MC-10.  Two of these programs I have translated are International Draughts (pronounced Drafts), which is simply the version of checkers (Jeu de Dammes) played in France.

INTERNATIONAL DRAUGHTS INSTRUCTIONS

When entering moves type the row letter first followed by the column number.  After entering the starting space and all the landing spaces, press ENTER to make your move. International Draughts is played by two players (or you and the computer), on opposite sides of a playing board, alternating moves.  One player has light blue pieces, and the other has orange pieces. It is against the rules for one player to move the other player's pieces.  The player with the light blue pieces makes the first move unless stated otherwise. A move consists of a player moving their piece diagonally to an adjacent unoccupied square.  If the square is occupied by an opponents' piece, it may be captured (and removed from the game) by jumping over it to the unoccupied square one square beyond the opponent's piece. The playable surface consists of using only the dark squares of a board with alternating light and dark squares. A piece may move only diagonally into an unoccupied square. Capturing is mandatory.  The player who has no pieces remaining or cannot move owing to being blocked loses the game.  Uncrowned pieces move one step diagonally,  and may capture opponents' pieces by moving two consecutive steps in the same direction, jumping over the opponent's piece on the first step.  Multiple opposing pieces may be captured in a single turn provided this is done by successive jumps made by a single piece; these jumps do not need to be in the same direction but may zigzag changing diagonal direction.  In international draughts pieces may also capture (diagonally) backwards. When a piece reaches the kings row, the farthest row forward), it becomes a king, and is marked by becoming blue for the light blue pieces or red for the orange pieces and acquires additional powers including the ability to move backwards.  As with non-king men, a king may make successive jumps in a single turn provided that each jump captures an opponent man or king.  In international draughts the flying kings rule allows kings to move as far as they want along unblocked diagonals. This move can (but need not) end by a capture in the usual way, jumping over an opposing piece to an adjacent unoccupied square. Since captured pieces remain on the board until the turn is complete, with flying kings it is possible for a king to reach a position where he is blocked from moving further by a piece he has just captured.  Don't forget, that in cases of flying kings, landing spaces need not be immediately next to a jumped piece.

Another couple of games are Strategie and Isola.  Strategie is a colourful variation of the classic 8-bit game MAXIT programmed first for the Pet, which I have also ported:

Isola

Strategie

Maxit

Battle Bots Rules and Version Notes

INTRO

Based loosely on the game "RobotWar" created by Silas Warner in the 1970s. The main activity of RobotWar was to write a program that would operate a simulated robot. No physical dexterity was required or even relevant in RobotWar because there was no way for the player to actually take part in the battles.  I'd been reading about this classic computer game for many years and wanted to create a Basic version for my favourite 8-bit computer, the Tandy TRS-80 MC-10 (Coco and Dragon versions followed shortly after).

RULES

You play 10 rounds.  At the end, you are presented with a scoreboard, which lists your round total and number of victories.  The total score represents the sum of all the scores for each round you won times the number of victories.  Round scores are calculated based on the speed of the victory.  Each round takes about 2 minutes (max).  If no bot has won by that time, then no score is awarded for that round.  It is possible for both players to destroy each other (crisscrossing shots, each step on a mine at same time, etc).  In that case, no score is awarded for that round.

PROGRAMMING

Your bot is controlled by writing little 10 command programs.  These programs consist of 10 different types of instruction.  Each bot runs its 10 line program and then repeats it until one of the bots is destroyed, or the time limit runs out for the round.  Command number 9 "SENSE" is slightly different from the rest.  It has two "switches," which you will be prompted for if you include this command anywhere in your program.  The first
prompt (Switch 1) is:
    SENSE? 1. WALL  2. BLUE MINE  3. RED MINE  4. BLUE BOT  5. RED BOT
The sense command examines the space immediately in front of the bot for the type of obstacle selected from the list above.  The second prompt (Switch 2) is:
    AND THEN DO? (1-8)
and refers to the standard list of commands (See below).  Select which one to perform when the type of obstacle selected is sensed.  You may include as many sense commands as you wish in your program but they will all perform the same kind of operation as determined by the switches.

0. DEFLECT (If against a wall, turns your bot in the direction of a deflection)
1. RIGHT 45' (Turns your bot right 45 degrees)
2. LEFT 45' (Turns your bot left 45 degrees)
3. RIGHT 90' (Turns your bot right 90 degrees)
4. LEFT 90' (Turns your bot left 90 degrees)
5. RANDOM DIR (Turns your bot in a random direction)
6. DROP A MINE (Lays a mine at your current position)
7. MOVE FORWARD (Moves forward one space in the direction bot is currently facing)
8. SHOOT (Shoots in the direction bot is currently facing)
9. SENSE (But when used as a switch 9=turn 180 degrees. See above)

The last switch (Switch 3) is to pick a starting direction:

5 6 7
4 * 0
3 2 1

BATLBOTS1-3

My initial version had only a two player option and no intro screen.  Playing against my son Charlie, we figured out some useful "programs."  Charlie didn't think it was fair for the first player (blue) to always have to program his bot first, so I made it random who gets chosen to program first.  After a while, we just started asking each other to look away while we created our "masterpieces."

Here are some of my son's (interestingly named) favorite creations:

• "Turret"                       8181818181 --0
• "Snail"                        5967681828 330
• "Search and Destroy" 7389898389 130
• "S+D Ball"                 7838383839 130
• "Gunman"                   5867586788 --0
• "Wall Crawler"            7776777968 140
• "Seek & Destroy"       6728181829 130

And some of my creations:

• "Q"              6767476789 330
• "Careful"      9898598985 670
• "Cowboy"    8448397181 190 (The killer app?)
• "Strafer"       0778697786 297
• "Slink"          8187287587 --1
• "Redoubt"    9789789786 561
•  "Killer"        8184898184 677

The first 10 digits are the program, the next three are the "switches" (See PROGRAMMING above).

BATLBOTS4

Created a single player version with a simple AI.  The AI starts with a few of the basic programs worked out by Charlie and me.  Then in a simple form of machine learning it "cribs" any winning programs (either from itself or the human player) and adds that program to its repertoire.  If it takes its own programs or versions of winning programs made by the human player, this simply means those program will figure more prominently in the random selection from its repertoire of programs--in other words a very simple learning algorithm.  Up to 50 programs can be stored in this process.

BATLBOTS5

Added a high score name entry feature. And the ability to sense for a blank space and a switch to turn 180 degrees for use in the Sense command.  Changed the intro and end screen colours to the alt colour set.

BATLBOTS5

Modified programming screen to allow re-input if an error is made.  Changed the prompt between rounds to allow abort of game (just hit "n" at the (C)CONTINUE? prompt).  Tightened code to speed up the firing routine and main loop.  Added some programs to the AI initial repertoire.

BATLBOTS6

Added a new function "deflect" which allows a bot to bounce off walls like a ball.

BATLBOTS7

Added a function that allows a user to choose a startup direction.  Now when prompted to "(C)ONTINUE?" at the end of each round, you can hit "c" or "y" to continue to the next round, which allows you to just hit "y" again to reuse your last program and proceed to the next round.

BATLBOTS8-10

Tried various additions to the Sense command to replace the useless self reference to one's own bot (4 or 5) in the switch list.  Finally settled on a feature I called "SCAN" which, starting at direction 0 (see above) scans for a selected object type in the spaces immediately surrounding your bot. When that type is found (the same types as for the regular sense command objects 1-6), the scan will turn your bot to face in that direction.  I don't know how useful this function will be but I wanted to add as many options as possible, so I could increase programming variability as much as possible, but not in any way that would be too powerful, so as to make the other functions redundant.  The options I tried either did this, or were redundant (recreated functions already creatable through existing commands).  Also, now the wall colours change randomly between games from either cyan, purple, or orange options.  Changed the way scoring was done so that points are awarded for both speed of victories per round and the number of victories achieved.

OUTSTANDING ISSUES

Charlie and I are divided on whether there should be any limits on the number of shots and/or mines. He thinks there should.  I am worried that if the number was too low for either, both bots might run out and be left with nothing to do.

We also were unsure how collisions of the bots should be handled.  Currently they just treat each other as walls (obstacle that cannot be moved through, i.e. simply aborts any 7. MOVE command).  We talked about making "deflection" or "reverse" one of the defaults.  I'm unsure.  I could make all of these "options" at startup, but for the time being I thought I would keep things simple, so that comparisons between high scores and success of programs could be more easily made.

If you're just interested in running programs against each other for comparison purposes, you can type the following after loading BATLBOTS:
    160 GOTO 140 <Enter>
    24 <Enter>
Then select 2 player and type in your two programs.  They will run automatically for the 10 rounds, and then you will get a report on their success against each other.

Any comments on these issues would be much appreciated.  We are also, of course, looking for that "killer app" version of a 10 line program, that is significantly better than all the rest.  If you think you found one, feel free to send it or post it on the Retrospectiva site.  Thanks.

HOW TO PLAY

Batlbots can be played at the following link (just search on "BATLBOTS"): https://archive.org/details/@james_gerrie

Jim Gerrie,
Cape Breton Island--"Ciad Míle Fáilte!"
Nova Scotia, Canada
Program developed later November early December 2012 ("Feliz Navidad!")

Grail of the Gods Port

Typical of the results of my web crawling for code for conversion to the MC-10 is the example of my game port of "Grail of the Gods."  Using my methods of searching on the keywords GOTO and GOSUB and another theme keyword (probably "DUNGEON" in this case) I stumbled on the following site dedicated to the high-level compiled basic language (focused on modern game creation) called "DarkBasic": http://forum.thegamecreators.com/?m=forum_view&t=169862&b=11

On this site a fellow with the username "ibol" describes his new game, designed in the spirit and style of old text-based 8-bit games and modelled specifically after the classic game "Rogue."  He had made what he called a "rogue-like" game in only 20 lines of Dark Basic code.  Here's an example of his first few lines of code:

DIFF=0 : set display mode 1024,768,32 : set text font "copperplate gothic bold" : set text size 32 : hide mouse : sync on : sync rate 0 : sync : dim L(10,4) : restore : for t=1 to 10 : for u=1 to 4 : read a : L(t,u)=a : next u : next t : dim m$(14,2) : for t=1 to 14 : read a$,b$ : m$(t,1)=a$ : m$(t,2)=b$ : next t : DIM w$(20) : for t=1 to 20
read a$ : w$(t)=a$ : next t : depth=0 : rank=1 : XP=0 : Gold=0 : Wep=10 : Arm=10 : HP=40 : Kills=0 : center text 512,240,"GRAIL OF THE GODS" : center text 512,600,"press any key to begin!" : sync : wait key : cls : for t=1 to 10 : ink rgb(L(t,2),L(t,3),L(t,4)),0 : read a$ : text 100,t*50,chr$(l(t,1))+" - "+a$ : next t : text 100,600,"use arrow keys to move" : sync : wait key
come_here: : inc depth : fail=0 : dim m(22,22) : dim n(22,22) : for x=1 to 20 : for y=1 to 20 : n(x,y)=0 : if x=1 or x=20 or y=1 or y=20 : m(x,y)=1 : else : m(x,y)=0 : endif : next y : next x : repeat : repeat : inc fail : x=rnd(19)+2 : y=rnd(19)+2 : p=0 : q=0 : for t=x-1 to x+1 : for u=y-1 to y+1
if m(t,u)=1 : inc q,(2^p) : endif : inc p : next u : next t : if q=2 or q=3 or q=6 or q=7 or q=8 or q=9 or q=32 or q=36 or q=72 or q=73 or q=128 or q=192 or q=288 or q=292 or q=384 or q=448 : m(x,y)=1 : fail=0 : EXIT : endif : until fail>500 : until fail>500

Since I'm always on the lookout for ways to expand the limited software library of the MC-10, I thought it would be nice to add a "rogue-like" game to its stable of programs.  Since it was only 20 lines of Basic, I though it shouldn't be too difficult to convert.  The picture of the game also boded well, as it only used text symbols and was not that wide.

The dungeon itself was only 20 characters wide, leaving 12 characters on an MC-10 screen for the text on the left hand side.  The first thing I had to do was take the code and convert it to all uppercase (using MSWord's change case menu function), provide line numbers and limit each line of code to the 128 max line length of the MC-10's version of Basic (the Coco has 255 characters to play with).  Second I had to convert the more advanced control structures like WHILE/WEND and IF/THEN/ELSE/ENDIF to their interpreted basic equivalents.  Third, ibol made extensive use of the MOD/% command function (Modulus=only the decimal remainder of a the division of two numbers), which the MC-10 lacks, so I had to search out what this function was and how to recreate in Microcolor Basic.  Finally, I had to weed out all the special commands dark basic has, which make it a special game development language, such as commands that update the screen in a single action after a sequence of commands that manipulate the screen have been executed.  I also had to, in the end, fiddle with the size of the dungeon a little in the vertical axis, as it is 20X20 in the original, which obviously would not fit the MC-10's 32X16 screen size.

At the core of the game was a neat little algorithm for generating the random mazes, with a pattern that allows access from the centre of the maze to all outside edges of the maze.  This is a difficult kind of maze to generate, and ibol had figured out a neat way for doing this quickly.  However, it was not so speedy an algorithm that an original 8-bit machine could calculate a new maze in a reasonable amount of time.  No matter how much I used my techniques (described in prior posts) to wring speed from interpreted basic (no ifs, just on/goto/gosub statements, etc.)  I couldn't get the time below 5 minutes at regular speed.  This was not so much of a problem in the development stage because I generally use Emucompboy's excellent MC-10 emulator, which allows me to massively bump up the speed of my virtual MC-10.  This is normally a great benefit because it allows me to make changes to the basic source code I work from in MS Wordpad, then use the "quick-type" function to read that text files quickly and directly into the emulator, type run and see the results of my changes without any of the normal delays as would happen on an original 8-bit machine (from declaring and loading variables, screen prep, etc).  This makes developing programs for the MC-10 just like using the MS QuickBasic or Borland's Turbo Basic, which I have used quite extensively over the years.  So, in order to make a game that was actually usable on the MC-10 I had to run the algorithm multiple times and generate a dozen maze maps as DATA statements, which then simply get randomly populated with stuff (monsters, treasure), rather than having fresh mazes made for each level.  This was acceptable to me, as it is simply a part of the process of creating or adapting software to a beloved old 8-bit machine to have to accept certain  limitations and quirks.  The end result was a variation of ìbol's "Grail of the Gods" game that looks like this:

When it came time to develop my game DUNGEON CRAWL I was able to draw on some of the elements of this game, such as the way weapons get "used up" over time, the impact of armour on attacks, and its multiple levels.  In the end, I found ibol's settings in regard to the impact of weapons and armour and the achievement of rank to be a little too generous, so I adjusted these to make the game a little less forgiving.  Since doing that, I haven't won the game (I like my games to be challenging), but then again I haven't played it much since making these final changes.  I would certainly appreciate any feedback on whether the game has been made too challenging.  It can be found in Coco form in the file JGGAMES5.DSK or for the MC-10 at: https://drive.google.com/open?id=1SFPbVqgzO4GzT7Tnjc2gI3W91fwIcPdo

There's also a thread on Atariage forums of someone who did a TI99 version of the program, who took inspiration from my port.  Cool...
http://atariage.com/forums/topic/271679-grail-of-the-gods-a-rogue-like-game-in-compiled-xb/

Pipe Frenzy Update

This is just  brief update on my new game based on the 8-bit classic game "Pipe Frenzy."  I have most of the game completed.  It is very challenging even on level 1.  I suspect that any level above 3 will be impossible, but then again, I am more of a game programmer than a game player, so I don't know if people will be able to master it up to level 3.  Basically the object of the game is the same as the original.  In this specific version you have to build a pipe trail from the blue reservoir with the white pipe to the red reservoir with the green pipe before your pipe fills with water.  There is background music too!

I'll be releasing it shortly.  So stay tuned...

Dungeon Crawl

I began making Dungeon Crawl just before Christmas 2012. I had always wanted to have a 3D first person dungeon game for my MC-10. I essentially had Dungeons of Daggorath envy. However,  the best I could do as a kid was to type in the CAVE HUNT from Rainbow magazine.  It was a very simple text dungeon crawler. When I re-started my MC-10 hobby, I tried to improve on the simple text descriptions with some simple VDG wall graphics and characters based on "pixel art" examples I found on Google images.

Cave Bear

This is a "cave bear!"  So I had a 3D dungeon crawler, but the game player was very simple.  I wanted something more like the original DND I had played as a kid.  I had already tried to make such a game in my DUNGEON game.  In fact, that game very closely applies the rules of the original Basic D&D, including the creation of a multiplayer party with a variety of races and spells, etc.  However, all those complex rules ate up memory and only left space for a simple overhead view of the dungeon.

In the picture above "P" is your party and "D" is a door.  The orange and red blocks are walls.  I liked this game for its fidelity to D&D's rich rule set, but not its graphics.  I had really wanted to try to create something closer to the Daggorath experience.  Finally, after some reflection I realized I could probably create a simple but doable 3D perspective in the 20k of an MC-10 by limiting myself only to two blocks of distance from the character, instead of the complex long distance perspectives, such as are rendered (thanks to the nice machine language line-draw routine provided by Greg Dionne) in my port of the Rainbow mag CoCo game RATMAZE to the MC-10s 64X48 graphic mode:

The result was an cross between all three of the above, which I call DUNGEON CRAWL.  It has the characters of CAVE, some of the complex combat and magic of DUNGEON and a 3D perspective closer to that of RATMAZE:

You can find the instructions and version history listed below.  Crawl can be downloaded here:
http://rsp.retrocomputacion.com/games-dungeon-crawl-by-jim-gerrie/

INSTRUCTIONS

The dungeon is dim and your torch only casts a little light.  It can be hard to distinguish things in the dungeon.  Objects only appear as light blue blobs.  Monsters can easily be mistaken.  In the flickering light you only catch glimpses of colour and the dim outlines of what appear to be faces.  Shadows easily create the illusion of threatening human forms, even when the reality is much different.  So beware, your eyes can deceive you.  You will find in the dungeon more than a dozen monsters.  Their "colours" range from green to blue to red to cyan to purple to to white to orange.  Some are (essentially) harmless like the deer that have wandered into the dungeon and become trapped, others are less so.  Deer (orange) can be eaten for health, but don't try to eat any of the other creatures!  In fact they will be trying to eat you!  So you must learn to recognize their distinctive colours and powers and avoid combat whenever necessary.  That being said, monsters (but not all) often carry useful items, which they will drop when defeated, so combat can sometimes be useful.

In order to defeat the pit fiend you must build up your cash of powerful weapons.  You must also keep your health up, although 100 is the maximum.  In the dungeon you will find magic items that will allow you to cast powerful spells to harm attacking creatures.  Like your health, your maximum when it comes to magical power is 100.  When you use magic against a monster you can cause up to 25 points of damage, but you will lose whatever amount of damage you cause from your magical power.

Magic can be used like any weapon.  It can be cast at figures in the distance, just like you would shoot an arrow (which you must also collect).  However, be warned, once shot at, monsters will immediately attack, and you only have a 50/50 chance of hitting them.  If you do, you will do up to 6 damage for an arrow or 25 for magic.  Once a monster is in your square, regular combat will ensue.  You always get to strike first (after all you're a professional warrior and mage!)  However, if you wish to flee a combat you must turn from your enemy as many times that are necessary to make your escape.  Each turn spent moving is a turn you are open to attack by your enemy. So be careful when attacking creatures down blank hallways. You can push past creatures in one move, but you might find yourself trapped!  There is also a chance that the creature will follow.  It depends on their speed and inclinations.  Each creature is different in terms of speed and inclination to pursue.

Different weapons have different powers, but all weapons can break in combat.  So collect up to three of the most powerful weapons you can.  Shields come in different strengths, but since they can never be broken, you will automatically keep the most powerful that you find.

You have one special form of magic.  If you are facing an interior wall and have more than 25 of magical power, you can choose the magic option, and you will be given the chance to blast the wall in front of you to smithereens.  This can be useful to gain access to parts of the dungeon that might be cut off from the
main areas of the dungeon.  You should, however, never be cut off from ladders going between levels or the pit fiend himself, who resides somewhere on the bottom level.  Find him and defeat him!

To save a game use the "P" key.  When your tape is ready press "S" to begin the save process.  In the emulator, you will be prompted to save the file to your hard disk.  The program uses a single standard file name, but if using the emulator, feel free to change the default file name to anything you wish.  After saving is completed you will have to re-run the program and answer "Y" to the "LOAD PREVIOUS" prompt to re-load your saved game.  Then press play on your tape player, or select the file name you saved a game under from the "play cassette" option of the File menu.


VERSION NOTES

Versions 1-4
Created the characters, the 3-D engine and the mini-map.

Versions 5-9
Created the combat routines.

Versions 10-11
Buffed up the user interface and got the mini-map reveal running.

Versions 12-16
Added the game save routine and intro screen.  Spent a lot of time condensing the code as I was down to a few hundred bytes, which sometimes led to OM errors.  Think I have condensed the program enough, so these shouldn't occur but please contact me if they do! Please contact me also about your thoughts on the  balance of powers versus those of the monsters.  This may still need fine-tuning.

Version 17
Fixed a spelling error in the intro screen and tightened up the code a little bit more to ensure there is adequate spare memory so as to ensure no OM (Out of Memory) error will occur.  Fixed the end routine so that whatever creature is killed last will be erased from the screen (in symbolic recognition of your victory).  It's the best I code do in the limited memory...

Version 18
Fixed a bug where your weapon could break even if you were attacking with magic.