Since I mention a minor (apparent) bug that I think I found in my last post, I should also mention another minor bug that I think I found in another classic BASIC program. I recently did a port of "Football Manager" to the TRS-80 MC-10. I added some nifty little text graphics to the Dragon 32 version, which I am quite proud of. They can be seen in the video:
The rendition of games/matches no longer simply display a changing list of scores of the two teams until the final whistle. Every new score update is attended by a ball being kicked into an ASCII net past a befuddled ASCII keeper. I'm also pretty happy about my modifications to the screen display of stats and numbers and prompts. The original was a little chaotic, especially in the way it used reverse character messages. I tried to bring some consistency to formatting the screen displays in my final version (completed after the video above).
But on to the bug. It seems to me that in the Dragon version the variable for storing the amount of your interest repayment was not one of the variables stored when you save the game state while playing. This means that after you reload the game you are free from interest payments on your loan. This is a boon and a curse. It means your loan is not being repaid. It just remains static. That is unless you get a new loan, at which point a new value is calculated for your entire amount of debt, so you're back to normal. So, I imagine that real players are typically getting loans on a regular basis, so perhaps they never noticed this bug.
The problem variable is RE and I just added it to the array that I use to store and then save all the game info to tape. Here's the line in my code:
53 D(0,0)=RE
I hadn't used D(0,0) yet so I just stuck it there. In any case, if there are any Dragon folks out there who read this, I think there might be a bug to fix the version of the game on the Dragon Archive.
And as I'm writing about national sports, I recently created a new Semigraphics-4 version of the American Flag and a little bit of the American anthem. I'm thinking of using it in some type-in BASIC version of baseball for early 8-bit computers (I've got some code for a small game for the Adam Computer). But in the meantime here it is:
This is a conversion to Micro Color BASIC of a game by Clyde Perkins for the Bally Arcade/Astrocade game console and early 8-bit home computer. The first "Bally BASIC" version appeared in the Arcadian 2, no. 5, March 24, 1980. The "AstroBASIC" version was released on the "Best of Arcadian, 1980" tape. I took the source for my port from Arcadian Vol 5 No2, Dec 1982. Perkin's game is an early version of Othello or the game of Reversi with an AI opponent created in BASIC. It also allows for a game between two human players, and it does this on an MC-10 computer with only 4K of memory! Amazing!
Thanks to the Bally Alley folks for their helpful playthrough:
There's nothing much to report about this port regarding differences in BASIC. The only real bump regards the diabolically hard translation of AstroBASIC graphics, which are laid out as a grid with the 0/0 coordinates located at the centre of the screen. The graphics are 160 by 88 pixels:
44
|
-80 --- 0,0 --- 80
|
-44
I had to do some fancy math to translate everything to a more common graphic grid starting in the upper left corner and then scale it for the MC-10 low res 64 X 32 Semigraphics-4 screen. Otherwise, BallyBASIC is pretty straightforward. Quite nice in a lot of ways, although very memory restricted. That's okay though, because it means we now have another board game to add to the BASIC Checkers sold by Tandy for the 4K MC-10. Source code can be found here:
I'll post an addendum here when I have a chance to think about the project a little more.
Addendum.
I think I found a bug in the original program.
This is the board position weighting used by the AI:
5 3 99 2 2 99 3 5
15 8 2 -15 -15 2 8 15
0 1 15 0 0 15 1 0
9 5 8 1 1 8 5 9
9 5 8 1 1 8 5 9
0 3 5 0 0 15 1 0
15 8 2 -15 -15 2 8 15
0 0 99 2 2 99 3 5
^ why this anomaly in the pattern? The pattern should be like this (shouldn't it?):
5 3 99 2 2 99 3 5
15 8 2 -15 -15 2 8 15
0 1 15 0 0 15 1 0
9 5 8 1 1 8 5 9
9 5 8 1 1 8 5 9
0 1 15 0 0 15 1 0
15 8 2 -15 -15 2 8 15
5 3 99 2 2 99 3 5
^ Fixed?
I'm not 100% sure if there is something I did in my port, or something different about the BASICs, which can account for this apparently missing info in the matrix. Or perhaps there is something needed strategically in the AI that benefits from not going for one of the corners? Apparently Perkins worked from an article in Byte magazine, which I'll have to go look up. But in the meantime I just added the two missing numbers into the matrix in my version (see line 58 in my test routine that produce the two matrices below).
I thought I had added that fix when I played the following game, but it turned out that I hadn't re-loaded the new code into the emulator. So two values were actually put into incorrect locations (my preliminary attempt at guessing the location that needed modifying) in the matrix. But maybe that actually helped, because the AI beat me! But at least you can see some changes I made to the flashing cursor that appears during the search routine that makes this version a little more like the original than the first video I released (above):
Me being beaten!
In any case, the following is me playing the properly modified code to a fairly tight victory (I only pull it out of the bag near the end):
On to victory!
O-Jello can be played online using Mike Tinnes' Javascript emulator hosted on my games site on GameJolt:
Just select "Play" from my game page, then select my "8-Bit BASIC A.I. Programs" collection and then select "OJELLO" from the Cassette menu and type RUN and hit Enter in the main emulator screen. Feel free to list the program (it's really tiny) to see it for yourself in all of its under 4K glory.
The game "Lines of Action" was invented by Canadian born Claude Soucie. He moved to the United States during the Depression as a young child, and learned to amuse himself, and eventually others, by inventing games, Sol Guber created a two player version of the game in BASIC for the 8-Bit Atari Computers. It was published in ROM Magazine Dec/Jan 1985, which was a short lived Canadian Atari publication. This version is a port to Micro Color BASIC on the TRS-80 MC-10.
I had to rip out all the complex Atari graphics commands for drawing the board and the round playing pieces. I created a simple Semigraphics-4 grid in white, and some chunky blue and red pieces to replace the original white and black ones.
I had to fix the subroutine for checking if you were trying to jump on one of your own men. The original program checked for if you clicked on your own selected piece earlier than checking for whether you were trying to actually jump on one of your own. By clicking on your own selected piece the program would abort that move, and allow you to select another piece. But this prevented the program ever getting to the routine to check if you were trying to jump on one of your own players because it just checked for whether you were clicking on one of your own pieces (any piece). The message about not jumping on your own pieces would never print and the turn would simply end inelegantly without removing the old active piece marker, etc. So I changed the check to specifically look for whether you were landing back on your starting piece. Then the program could also get to the later check for trying to jump on one of your own men. I also made the routine print a message that your move in progress was cancelled. Also, the routine for ending the turn seemed overly complicated and created issues with screen cleanup, so I simplified it and standardized the screen cleanup done for all the error messages.
There were lots of poor scan issues and just plain old typos in the original listing from the article.
For example
225 T1PT=TPT: U1=T=UPT: IF UPT>TPT THEN U1PT=TPT+Cl: TAPT=UPT-CA
Should have read
225 T1PT=TPT: U1PT=UPT: IF UPT>TPT THEN U1PT=TPT+Cl: TAPT=UPT-CA
I couldn't get the original win routine to work. It was an interesting attempt to create what was in a essence simply a case of the "flood fill" algorithm. Basically you find the first piece for a player. Then flood fill from it. If after it finishes going through and changing any interconnected piece location connected to that original location, if the final total of pieces is the same as the total pieces the player has, then the game knows you have interconnected all your pieces and are a winner. I think Guber was trying to create a clever way of doing this but it only worked sometimes, on simple shapes like
OO
OO
But failed on complex chains like:
O
OO
O O
Not sure, but he might have just given up or have not tested enough. I just replaced it with a simpler more standard flood-fill routine that seems to work fine and is a little quicker. One problem with his routine was that it sought to search on the 8 locations around a piece 0-7 and then store where it left off in a string (which holds the whole grid of locations) as an ASCII value of where you are in the search around aa piece added to the value of the player piece code (5=blue 10=red). But he didn't calculate the values correctly. The 0 value would leave the stored player piece value unchanged (5 or 10) since the first search value for the array storing the 8 directions is 0 (as in 0-7 for the array storing those direction offsets). I created a test bed routine and as far as I can discern his method would never really be able to work on complex chains since its doesn't store unvisited locations on stack, and can "get lost" following down side tracks.
It would be nice if someone could figure out a simple AI routine to add to the program, which is for two human players. I'll have to see if my son Charlie is game for a programming challenge the next time he's home for an extended visit, such as at Christmas.
LINESOFA can be player at my GameJolt site under the "More 8-bit BASIC game ports" menu item.
Just select Play Game, "More 8-bit BASIC game ports", and then select LINESOFA from the Cassette Menu, and type RUN and hit Enter in the Main emulator screen.
I've been working on a port of Lance Micklus' Star Trek III game to Micro Color BASIC from TRS-80 Model I/III BASIC, which I did some time back. I had been unsatisfied from the start with the flat somewhat weird appearance of the graphic that Micklus devised to represent the starship Enterprise. I was also underwhelmed by the chunky, somewhat oversized appearance, of the Klingon ship. So I finally resolved to try to tweak them a little. Here's how the ships used to look in my original port:
The Klingon looks more like a Romulan Bird of Prey. I toyed with the idea of flipping it upside down and giving it protruding neck, more like the Klingon battle cruisers I was familiar with, but it just looked odd. And I didn't want to stray too far from the original game's look. I just thought it would be better to downsize and tweak the images to take account of the bigger semi-graphic 4 pixels of the MC-10. There was something about the original Enterprise design that just didn't indicate well, to me at least, which direction the ship was pointing. So I added a bridge, after spotting a small Enterprise icon somewhere on the Net that showed what that might look like.
The exercise of opening up the source code also tempted me into squeezing in some code optimizations to speed up menu display a little. And also decided to add some more colour. The game now displays the Status screen with the background color of the current operational condition: Green, Yellow or Red. The flashing "Space Storm" message now has a purple background, and when you collide with something, an orange screen is displayed with that message. I also centred the Status display screen. The old uncentred screen is more obvious on the MC-10 with its contrasting black border to the green text screen background. I also tweaked the combat routines, which use a flashing alternate text color set effect, and tweaked the SOUND commands.
Finally, I added references to all the main bridge characters and other Paramount Star Trek (C) references. I hadn't noticed it before, but the early version of the code (1978/1979?) that I used for my port was obviously done at a time when Micklus was fearful of a possible copyright infringement hit. For example, the Klingons are simply called "Warships", the Enterprise is a "Starship" and the Phasers are a "Beam Weapon." So based on some videos I watched of latter versions of the game (mine is probably TrekIII.3 or before), such as TrekIII.5, I added Sulu on helm, Checkov on weapons, Uhura reporting damages, Spock making science reports and Captain Kirk and the Enterprise on the main menu. So now players can have a full copyright infringing experience like any kid back in the 80s could have if they even knew the scantiest about hacking BASIC program code.
It's a very tough version of the classic Star Trek text game genera. Here are three videos in sequence of me trying to complete the game.
Playthrough 1
Playthrough 2
Playthrough 3
TREKIII game can be played from my GameJolt page by selecting "Play Game" and then selecting the Star Tek Games Collection of from the menu of my different games collections. Here is the link to my page:
Click on the above, choose "Play Game" then "Star Trek Games" then select "TREKIII" from the Cassette menu and type RUN in the main (green) emulator screen.
P.S. If my son Charlie is reading this. There is an easter egg in the code.
This game is a conversion of a BASIC program made by "Free Game Blot" for the Matra Alice to its cousin system, the TRS-80 MC-10. The game is called "World War 3" in its docs, but "Third World War" on the game title screen. The original program used high resolution graphic images to represent tanks and artillery units, although the artillery symbols really look more like infantry rifles, which leads me to think that the documentation and programming teams were quite separate entities at Free Game Blot. I have replaced the high res symbols in my version with low res graphic characters. I used an L-shaped block character for tanks, and diagonal line block character for artillery units.The flag graphics from the intro screen have also been re-rendered using low res semigraphic-4 character graphics.
Fancy hires unit display of Alice version
The game is a kind of combination of Risk and Battleship. Like Risk, you must maneuver military units on a map, combine and split units, and engage in combat with enemy units to conquer spaces on the map. Like Battleship, the map takes the form of a grid and you cannot see the enemy units. Instead you must rely on the limited reports of scouts and captured soldiers, who can tell you about specific spaces. Also unique to the game, units can have different levels of morale, which influences their effectiveness
In addition to the graphics, the computer uses musical refrains to indicate which of the sides is victorious. Since the Alice shares with the MC-10 only the simple Microsoft BASIC SOUND command it was not very difficult to translate those refrains. However, the Alice uses a much more feature-rich but complex Thomson graphics chip that also allows 40X24 and 80X24 text screens. Many machine language subroutines had to be used to allow these graphics to be displayed on the Alice. After much trial and error I was able to strip out these routines and replace them with a simpler set of PRINT@ commands using low res block graphics of the MC-10's 32X16 text screen (and the Alice, when it is in 32X16 "MC-10 mode").
To figure out the conversion process I had to translate (with the help of Google) the instruction sheet from French (The Alice was an early French 8-bit home computer developed from the Tandy MC-10). Here are those instructions (with some added notes by me in red):
WORLD WAR THREE
By Free Gameblot
Au debut de chaque bataile, vouse et votre ennemi (l'ordinateur) disposez de 18 unités chacun. Vospositions, artillerie et chars sont dessinees sure un échiquier de 45 cases reérees verticament de A a E et horizontalment de 1 a 9. Seuls vost poistions sont visible a l'ecran, celles de l'ennemi demeurent invibles. Le but de jeu consiste a aneantir toutes less armées adveses en ayant le minimum de perts possible.
1) Description des unités: 1. l'artilerie, reprsentée par les fusils; 2. les blindés, par chars. Moral des troupes: a chaque unité est associé un niveau de moral: N: moral normal; F: moral fort. Le moral des troupes est déterminant dans un combat. Par example, deux artilleries avec un moral fort ont beaucoup de chance de remporter un compat face à une unité de blindés au moral normal. Le moral de vos unités est variable en fonction des combats livrés. Si une troup au moral normal remporte une bataille, son moral devient automatiquement fort. Inversement, si une troupe au moral fort perd une bataile, son moral devient normal.
Les combats se font avec les déplacements de vos unités. Il n'est donc possible de déplacer au maximum que le nombre d'unités inqiqué sur une position de l'échiquier.
2) Déplacement des troupes.
Les positions sont repérpées horizontaiement et verticalement. Il est donc possible de déplacer ses unités latéeralement, verticaiment ou en diagonale, mais toujours à partir d'une case contigue.
Pour déplacer les unités, indiquez d'abord la position d'origine (lettre puis chiffre), puis la position finale (lettre puis chiffre).
Enfin, indiquez par un chiffre 1 de à 4 le nombre d'unités à déplacer.
Ce nombre doit être inférieur ou égal au nombre d'unités indiqué sur la position concernée.
Il est possible de regrouper vos unités sur une même position, mais à condition de ne jamais dépasser 4 unités par case.
Les regroupements de troupes ne peuvent se faire qu'avec des troupes de même arme, c'est-à-dire artillerie avec artillerie ou blindés.
Les regroupements avec des unités au moral différent (F et N) entrainent automatiquement des unités au moral normal (N).
3) Les Eclaireurs.
Avant chaque déplacement, vous devez envoyer un éclaireur sur l'échiquier pur essay de repérer les positions ennemies. Il est prudent d'envoyer l'éclaireur à proximté de vos positions pur déjourer toute tentative ennemie. Ses indications sont précieuses:
- Nothing to report: Rien à signaier, pas d'unité ennemie sur la case désignée.
- Champs de mine: tout déplacement sur cette case entrainera une destruction de votre unité déplacée.
- Une position ennemie, l'enemi a des troupes sure cette case, l'éclaireur vous indque alors le nombre d'unités, le type de l'armée (artillerie ou blindés), et le moral des troupes.
- Un prisonnier a parlé: vous avez capturé un prisonnier qui vous révele less positions de l'ennemi, mais sans doner de quantité.
4) Les coups de main et les accrochages.
Les coups de mainadverses peuvent survenir à tout moment et se soldent par des gains si des perts d'unités pour vous et votre adversaire.
Si vous restez maitre du terrain, vous conservez la position acquise. Si l'ennemi gagne cette bataille, vos troupes disparaissent de la case et celles de l'ennemi prenent leur place sur l'échiquier.
Si vos unités remportent une bataille, leur moral se renforce. Dans le case contraire, il devient (ou il resté) normal.
5) Fin du Jeu.
La guerre se poursuit jusqu'à la destruction totale de vos unités ou de celles de votre ennemi.
A vous de déplacer judicieusment vos troupes au bon moment pour détruire le maximum d'unités ennemies. Mais attention aux contre-attaques de votre adversaire... Bon Courage!
ENGLISH INSTRUCTIONS
At the start of each game, you and your enemy (the computer) have 18 units each. Your positions, artillery and tanks are drawn on a board of 45 squares labelled vertically from A to E and horizontally from 1 to 9. Only your positions are visible on the screen, those of the enemy remain invisible. The goal of the game is to annihilate all the opposing armies with the minimum possible losses.
1) Description of units:
1. artillery, represented by an upper angled graphic piece;
2. armored vehicles, represented by lower angled (L-shaped) graphic piece.
Troop morale: each unit is associated with a morale level: N: normal morale; S: strong morale. The morale of the troops is decisive in a fight. For example, two artillery units with strong morale have a good chance of winning a match against an armor unit with normal morale. The morale of your units varies depending on the battles fought. If a troop with normal morale wins a battle, its morale automatically becomes strong. Conversely, if a troop with strong morale loses a battle, its morale becomes normal. (Note: This instruction is confusing as all battles are resolved with one side or the other being annihilated in the particular square of the grid. In other words, there is no possibility for units to "become normal" again after "losing.")
Combat takes place with the movements of your units. It is therefore only possible to move a maximum of the number of units indicated on a position on the board.
2) Troop movement.
The positions are marked horizontally and vertically. It is therefore possible to move your units laterally, vertically or diagonally, but always from a contiguous square.
To move the units, first indicate the original position (letter then number), then the final position (letter then number).
Finally, indicate with a number from 1 to 4 the number of units to move.
This number must be less than or equal to the number of units indicated on the position concerned.
It is possible to group your units in the same position, but on condition that you never exceed 4 units per square (Note:My son and I noticed in examining the code and playing the game that this limit doesn't appear to apply to the computer. We both have seen groupings of 5 artillery-- a case of do as I say, not as I do? Perhaps it is a accommodation to help compensate for the computer's weak AI?)
Troop groupings can only be done with troops of the same weapon, that is to say artillery with artillery or armored vehicles with armored vehicles.
Groupings with units with different morale (S and N) automatically result in units with normal morale (N). (Note: I have found that the game allows strong morale units to join with normal morale units with the high morale preserved, but if normal morale units join with strong morale units, the morale returns to normal-- I am not sure if this is a bug or a feature)
3) The Scouts.
Before each move, you must send a scout onto the board to try to locate enemy positions. It is prudent to send the scout near your positions to thwart any enemy attempts. His indications are vital:
- Nothing to report: Nothing to report, no enemy unit on the designated square.
- Mine fields: any movement on this square will result in the destruction of your moved unit.
- An enemy position, the enemy has troops on this square, the scout then tells you the number of units, the type of army (artillery or armored vehicles), and the morale of the troops.
- A prisoner has spoken: you have captured a prisoner who reveals the enemy's positions to you, but without giving any quantity.
4) Hard strikes and skirmishes.
Main attacks can occur at any time and result in unit gains or unit losses for you and your opponent.
If you remain in control of the terrain, you retain the position acquired. If the enemy wins this battle, your troops disappear from the square and those of the enemy take their place on the board.
If your units win a battle, their morale increases. Otherwise, it becomes (or remains) normal.
5) End of the Game.
The war continues until the total destruction of your units or those of your enemy.
It's up to you to carefully move your troops at the right time to destroy as many enemy units as possible. But watch out for your opponent's counterattacks...
Courage!
ADDENDUM:
I think I found a bug in the code. A couple actually, although the first isn't really a bug as such, but perhaps more a calibration and game testing issue. I found the game impossibly/unfairly hard to win on levels 2 and 3. I thought this was just me being a crappy player, but having played quite a bit now and figured out some simple strategies (basically seeking local preponderance of force wherever and whenever possible, otherwise avoid combat), I realized the AI was just unfairly advantaged at level 2 and 3. The raw level numbers were used to weight the formula for determining the outcomes of battles and also in a latter check about who won (there's some "compounding weighting," as my son Charlie put it, going on). But on level 2 and 3 the scale is tipped way too far in favour of the computer AI. I found that 1, 1.3 and 1.6 worked better as a scale factor. On level 1 it can be won by novices, 2 is a tough slog, and I haven't won 3 yet, although I think I came close once. Charlie recommended getting rid of the double weighting, but I felt my re-scaling changed the game the least from the original, which is more in keeping with my preservationist goals, so I'm sticking with it (for the time being). Here's the edit:
350 A$="CHOOSE LEVEL (1,2 OR 3)?":JJ=7:II=4:FA=0:NM=128:GOSUB30000:A(0,0)=3:GOSUB9500
355 IFN<1ORN>3THEN360
356 NV=1:IFN=2THENNV=1.3
357 IFN=3THENNV=1.6
358 GOTO420
We also noticed that there is a compounding element to the combat formula involving a turn counter that slowly makes it more difficult to defeat the computer as the game goes on. This seems to be a way of encouraging making bold strikes at the beginning of the game, and discouraging simply meticulously avoiding combat until you can build a local preponderance of force.
The real bug in the code resulted in enemy units disappearing from the board. Random numbers for possible next move coordinates were generated, but the routine used a division by 2 operation that would sometimes result in .5 on some coordinate numbers. These would just get INTed out when used in checking the board array. However, in some checks done to throw out coordinates, such as the one comparing the current coordinates with the newly generated ones to make sure they were not simply the same, they would sometimes not be discerned as being the same because some new coordinates would have a decimal number in them. This would allow a move to the very same location and then erase the old location (which was that same location) essentially wiping the units from the board. So I simply added INTs to the new random coordinate generator lines of the subroutine. Here is the new code:
REM RANDOMLY MOVE ENEMIES
2100 S1=INT(S+(RND(8)-3)/2)
2110 IFS1<1ORS1>5THEN2100
2120 T1=INT(T+(RND(8)-3)/2)
2130 IFT1<1ORT1>9THEN2120
2140 IFS=S1ANDT=T1THEN1072
2150 IFTD(S1,T1)<>TD(S,T)ANDTD(S1,T1)<>0THEN1072
2160 D(S1,T1)=D(S1,T1)+D(S,T)
2170 TD(S1,T1)=TD(S,T):D(S,T)=0
2180 TD(S,T)=0:XD(S,T)=0:GOTO1072
I also fixed an improperly exited set of FOR/NEXT loops, as this always worries me as possibly causing problems. And an unRETURNed GOSUB after you win. The game would restart by jumping to the start of the main part of the program. I made it reRUN that line number instead so all variables and unreturned GOSUBs would be reinitialized. Otherwise, if you played enough you might blow the lid off the RETURN stack.
I'll keep testing a little more to ensure that my fixes have worked and there aren't other bugs. On the whole, I'm a little underwhelmed with Game Blot's quality control and game testing performance. It seems this game had most of its effort poured into its fancy graphic interface, rather than the game itself. Which is sad, because it's a simple but fun little text game when it works, even if its AI is, as Charlie puts it, a wee bit "stochastic parrot," whatever that means.
I came across a very interesting article in "Input Magazine" with a simple AI BASIC program. "Input" was an early 1980s computer publication by Marshall Cavendish. It was dedicated to teaching the basics of computer programming. Every issue included both BASIC and machine language programs with detailed explanations of the listings. The magazine also included very engaging artwork in the form of playful cartoon characters and scenes illustrating aspects of the programs.
In order to illustrate simple AI techniques like the Alpha-Beta algorithm the authors of the magazine chose a simple board game to automate (rather than a complex game like chess) called "Fox and Geese." In his comment on my Youtube video about the game @me_fault provided a nice little synopsis of the game:
Only the green squares are used. The four Geese on the green squares at one edge; the fox on a green on the opposite edge. The objective of the Fox is to cross from one side of the board to the other; the Geese's objective is to prevent it from doing so. The fox is trapped when it can no longer move to a vacant square.
The Geese move diagonally forward one square (only one goose per turn); the fox diagonally forward or backward any number of greens. There is no jumping, occupying the same green, taxes or removal of animals.
Here is a graphic of the game to illustrate the elements of @me_fault's description:
The geese are the yellow objects at the bottom, the fox is the red object in the top half of the board.
As was normal for "Input" magazine, listings were provided for Commodore 64, Sinclair Spectrum, Coco/Dragon 32 and Acorn Electron. The Coco version illustrated the game board (standard 8X8 chess board) using hires graphics. The scan of the magazine was very good, so the text capture required (relatively speaking) much less editing to get it into an operating condition. The latest version of the VCC Coco emulator includes a feature to paste text directly into the emulator and BASIC. Unfortunately, it randomly drops lines during the pasting process, so I had to go back to my utilities that transfer Windows .txt files to virtual disks to get a clean transfer. Once that initial task was done, I could use the paste function to input lines fixed in the Windows file into the emulator.
I had a hard time getting the program running because there were some errors in the magazine listing. The most vexing was a missing minus sign in the following line:
2026 BX=B(31)*2-B(24):E=1E30:H=1E30
Which should have read
2026 BX=B(31)*2-B(24):E=1E30:H=-1E30
I only spotted this one because I gave up on getting the program running and had started working on the Commodore 64 source code to try to convert it to an MC-10 version using lowres graphics. Since I had combed through the Coco code so many times looking for transcription errors, when I saw the minus sign on the H variable I remembered that the Coco code lacked that. I think I noticed this because it seemed odd to assign two variables (probably constants) with the exact same value. So when I saw the C64 code with two values that were different, it triggered a recognition. When I fixed this, the Coco version finally worked.
Another problem I ran across involved some DEFN mathematical functions (there are a bunch). The program kept throwing errors when two of these functions were called. It turned out that this was because there were some extra brackets in one of the formulas and a misplaced asterisk in another:
2140 DEFFNX(B)=(B=G(1) OR (B=G(2)OR (B=G(3) OR B=G(4))
It's difficult to understand how these errors could have crept into the listing. They are quite catastrophic. I fixed the DEFfunction errors first, because they could be spotted just in terms of bad BASIC syntax. After I had fixed those the program would run, as long as the player only chose level 0 for the computer opponent for the geese or fox. So the best I can imagine is that the Coco conversion was based on one of the other versions and that perhaps the programmer only tested human player versus human player function. Or perhaps the Dragon is somehow more tolerant of bracketing in its implementation of Color BASIC.
Another problem I ran into was that there are places where Color BASIC (on the Coco, not the MC-10) absolutely needs spaces in front of certain commands for the parser to recognize those commands, which is a problem if they are preceded by an purely alpha variable name. Otherwise, the parser can't spot the command (i.e. differentiate it from the alpha variable). This is the case for
AND
OR
THEN
TO (in an FOR/NEXT loop construct)
For example the following packed lines will not work
IFA=BTHEN
FORA=BTOC
IFA=BANDC=DTHEN
These need to be re-written as:
IFA=B THEN
FORA=B TOC
IFA=B ANDC=D THEN
Since the magazine used proportional spacing, some spaces were not always evident (to either a reader or the OCR software). So all such instances had to have spaces added. At the same time I was able to eliminate unneeded spaces, which should help speed up program execution.
Another problem that I ran into was that the emulator kept running out of memory (OM ERROR). I've run into this before, most commonly because a program assumes a tape based system. When a Coco disk cartridge is added some memory is reserved for disk activities. So programs made for a purely tape-based systems have slightly more space to work with. This seemed to be the case here. I was able to try to condense the program in various ways such as shortening messages and removing redundant code, such as consolidating multiple identical win messages into a single subroutine.
Finally, a graphic message is flashed when a player makes wrong moves or provides improper input. In the original program this involved flashing a simple red box with a buzzer sound. The box was unclear (to me at least) in terms of the message it was meant to convey. I chose to replace it with a simple flashing X with buzzer, which seemed clearer to me as an indicator of illegal input. So I replaced:
The directory is in my MC-10 repository because, as I mentioned, I was going to try to make an MC-10 lowres conversion. I might still try that. But in the meantime the Coco version of the game can be played here:
According to the Giant Bomb game website "Space Mouse" was created in 1984 as a "type-in" program in the Japanese computer magazine I/O. The following blurb from Giant Bomb regards a modern 2016 re-make of the game in celebration of its 25 Anniversary:
Space Mouse: 35th Anniversary Edition is a deliberately-retro vertical-scrolling sci-fi maze game developed and published digitally by Mindware for the PC on November 8, 2016.
The sixth game in the studio's "Video Game Classics" series, Space Mouse is a remake of the NEC PC-8001 game of the same name, which was originally created by Takanari Suzuki as a "type-in game" for the September 1981 (Vol. 6, No. 9) issue of the Japanese microcomputer magazine I/O.
In the game, players must guide Alice up each floor of a tall building to its roof while avoiding being caught by space vermin. She is under a time limit (with a limited air supply), but can make use of power-ups to smash through walls and ceilings.
This version features numerous enhancements from the original, including smoother gameplay, additional levels, a key/door system, chiptune audio, and redrawn 8-bit pixel art. Additionally, players can play a port of the original PC-8001 version and an alternate arrangement (based on the Sharp MZ-700 series of computers).
If I recall correctly, I made my variation of the game in BASIC back in 2016 too, inspired by some online images I had seen of a version for the NEC PC6001. I somehow (perhaps asking my son to translate some Japanese description) came to the conclusion that the game was by a fellow named "Seiji" from 1983. Perhaps this was simply a NEC PC6001 remake of this "classic" of the Japanese home computing era. But it is hard to confirm the facts of the original game, including the author's name. The site strategy wiki mentions that the author also went by the name "Geimu Kyoujin." But I can't locate the source in the magazine proposed by Giant Bomb to confirm whether it was a BASIC program or some kind of machine language listing.
The date provided in the quote doesn't seem to point to a scan of I/O with an obvious listing of Space Mouse. I even asked my son Charlie, who knows the Japanese alphabet systems, and can use Google translate to do searches, to look for it. Here's the link for where I think the volume can be found on the Internet Archive:
It states in the top corner of the front page that it is Vol. 6, No. 9. for 1981. But I can't find any article in it that would seem to be for Space Mouse. And my son did a search for the Japanese for "space" and "mouse" and only came up for the word "space" in a few adds for space-themed games.
The Youtuber Highretrogamelord provides a playthrough of a NEC PC-88 version of the game:
Space Mouse is a vertical-scrolling maze game. The player controls a cat who is travelling up through an infinite maze. The player gains points as they travel, and the goal is to travel as far as possible. Space mice travel down throughout the level, blocking the player's progress; the player must dodge the mice, and loses a life if they come in contact [with] them. The mice have simple movement patterns but move quickly, and there are often several on-screen at a time.
Space Mouse was released as a type-in BASIC game in a 1981 magazine, and was later included in other type-in software books. A port was bundled with a number of enhanced remakes as a part of Space Mouse 35th Anniversary Edition for Windows in 2016.
He suggests that the original game was in BASIC, but as I said, I have not been able to confirm that. I think his reference to PC-8000 is probably for the original PC-8001 mentioned in the Giant Bomb quote. There seem to be a lot of versions of the game out there, including one for the FM-7 home computer. On the P6ers web site (retro users of the NEC PC6001) there are multiple entries. It suggests that the program has been made available by the author. I think this refers to the PC-6001 version that might have been the inspiration for the version I made back in 2016, but I can't seem to find any video playthroughs for the PC6001 version now.
This site mentions that the game was very popular:
This is a link to a 40th anniversary celebration conference for the PC-8001. In addition to mentioning that Space Mouse was one of the systems most popular games it also mentions Heiankyo Alien. Both are included built for a modern mini-emulator version of the PC8001. Although the game was popular, today this popularity mostly extends to later variations of the game. Once again, we might have an example of a "classic" game that had its beginnings as a humble type-in, maybe even a BASIC type-in, but for which the majority of the historical recollection focusses on the professionally published commercial versions and not the type-in that inspired the entire family of games.
My Recent Update of the Game
I have been editing my version to improve it. I have added key sensing using the PEEKS provided to me by Greg Dionne. They give better response, don't get "stuck" and allow multiple key presses to register, so you can use diagonal directions. I have also added the feature of Power Boosts that move you upwards at a fast rate, including smashing through floors. However, I have made some changes to the backstory. The Japanese call the game "Space Mouse" but it should probably be "Space Mice" because in the original the antagonists are mice moving downward as you try to move upward. You are supposed to be a cat climbing a tower/"building." When you reach the top, you enter a rocket ship and blast off becoming the first cat in space. I suppose the fast moving downward objects are kind of like scurrying mice, but in my version I chose to change the premise. This is mostly because I am using orange blocks for the energy objects that you need to collect as you climb. For technical reasons I want to use orange blocks (they're at the end of the ASCII character list of the MC-10). Orange reminds me of cheese, so I think of the player as a mouse scurrying to the top of the tower chasing a trail of cheese left by workers. Meanwhile, Taby cats living in the tower are trying to thwart your assent. The small orange pieces renew your energy and allow you to continue to ascend. When you have a run-in with a cat, you lose energy. You need one energy unit for each new stage, so don't let if fall too low. If you collect the large orange block, you will shoot to the top of the stage, so don't select it if it makes more sense to simply eat more ordinary cheese blocks on that level.
