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 displays 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. Perkins' 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. When I printed the move-weighting table consulted by the AI via its lookup algorithm for reading the table data from a single index array this is what came out:
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
When my son Charlie came home for Christmas he looked at the routine that generates the table and also came up with this arrangement using a modern programming language. It seemed obvious to us that the corners were what should be prioritized with the 99 weights and that there were other weird asymmetries going on.
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 mixed up table. Apparently Perkins worked from an article in Byte magazine, but we couldn't find anything in the earliest article from 1977 (see refs at bottom) presenting a BASIC version of Othello. Eventually Charlie figured out that there was a problem with decimal points in the lookup algorithm in line 510 of our test routine below. This test program includes Perkins' routine (56-57) for generating and storing the 8X8 weighting table in a single index array variable A(2-66) and then uses the lookup algorithm from the program (510) to consult every space on the 8X8 board using the coordinate system for plotting pieces (500):
REM Perkins' original table generating routine for populating the array
0 DIMA(70):A(0)=-1:A(1)=-1:REM first two elements reserved for storing player scores
Here is how the table looks using the lookup algorithm with Charlie's -4 and -5 fudge factors, which he added to prevent decimal rounding errors in translating A and B coordinates into an index number for a single dimension array:
His version produces something we think makes more sense for weighting and when I implemented it into the game and played against it, it played like a boss. The following is me testing the new routine on high speed mode in the emulator:
Here is the result of another game with the new algorithm being played on Mike Tinnes online emulator:
Charlie's algorithm for the win!
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. Only about 1800 bytes long. I think he might have been working from one of these:
Duda, Richard O (October 1977). "Othello, a New Ancient Game". BYTE: 60–62.
Wright, Ed (November–December 1977). "Othello". Creative Computing: pp. 140–142.
Frey, Peter W (July 1980). "Simulating Human Decision-Making on a Personal Computer". BYTE: pp. 56.
Addendum to the Addendum
In checking out Duda's article I thought I would try typing it in as well, and seeing what kind of game it plays. Its algorithm is similar but simpler. It counts up pieces that will be captured, but it only adds extra weight to such possible moves if they are along the outside edge. There is no differential weighting of specific positions. Still, it plays a pretty decent game. Here's a squeaker, when I just manage to edge it out:
I should thank Peter McGavin from the facebook BASIC group, who noticed two typos/transcription/OCR errors in the source code when I posted it in the group.
These were in line 3210, which should have read 2310
And 1410, which should have read 1310.
Both of these errors were in the original source which I worked from. This source was from an article entitled "Analysis of the First Published Othello Game" by Timothy Swenson, which the author generously provided online. It saved me a lot of typing, but it had some typos so I also fixed some other errors than those found by Peter. But with his corrections hopefully now it's fully working so people can try it out.
How to play
OTHEBYTE can be played 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 OTHEBYTE from the Cassette Menu, and type RUN and hit Enter in the Main emulator screen.
Similarly OJELLO can be played as per the above. However it can be found by clicking the "8-Bit BASIC A.I. Programs" menu item.
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.
How to Play
LINESOFA can be played 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.
