It started with an email from Greg Dionne that he had triggered an error in my ACHESS program with these moves:
Choose "0"
Then do the following moves:
E2 E4
B1 C3
G1 F3
D2 D3
C1 C2
OO
It gave a ?BS ERROR IN 4200.
This got me looking at the program again. First thing I did was rename and move AChess to CChess, since this title had been bugging me a little. I had initially called the the program AChess because it was written in Apple Integer Basic, but the programmer had titled the program "Computer Chess" so I thought I should rename it and put it in a renamed directory reflecting its internal title:
https://github.com/jggames/trs80mc10/tree/master/quicktype/Board%20Games/CChess
I think the error Greg noticed was a problem in the original program. It didn’t clear some variables used in the input routine until after the branch taken by the “OO," which left those variables in states that couldn’t be handled by the 4200 routine, which was called after the return from the input routine after an "OO" is entered, but before the initiation of the "castling function," which would set those variables to some specific values. Or so I think after having tried to chase down the assignments of all the variables involved that were causing the error and comparing them to the original code. Nothing would seem to account for them being miss-assigned. But by simply zeroing them before the check for the input of “OO”, since they were zeroed right after that branch anyway for processing the input of regular moves, the problem went away. As I said, those particular variables would eventually be set to specific values by the castling routine, but before that routine was reached after the return from the input routine, flow had to get past a call to 4200 (basically a routine subroutine needed to display pieces in their designated new locations).
I was a little surprised that such an error might have existed in the code, since after a little investigation I discovered that the programmer Mark Watson had made the program back in 1978, and it had been distributed on a sample disk by Apple. He apparently was programmer who made contributions to AI and computer game development. Perhaps Integer BASIC is more tolerant of array variables going out of range or something like that, so it might never have triggered a catastrophic error. It was neat to discover that the code was an interesting contribution to early chess AI coding in BASIC. Hopefully, it is a program more people will try out now. My impression is that getting an Apple emulator up and running to run the early Integer BASIC can be a bit of a challenge, so it might be helpful having it converted to Micro Color BASIC.
In the midst of conversing with Greg about this minor bug, he also pointed out another in another program I had converted from a while back:
In the midst of conversing with Greg about this minor bug, he also pointed out another in another program I had converted from a while back:
Hi Jim!...noted a few funnies in OTHO36.TXT* line 1350 when using MID$ .. an extra ')' in front of the ",2".* line 1440. extra parenthesis.
There were definitely typos there. Not sure if they were fatal in Coco BASIC, but in the MC-10 they certainly triggered errors under certain somewhat rare circumstances. I also found another error in line 1430. The assignment of the array variable had a 9 instead of a right bracket for the array variable. That definitely caused an error. So I looked back at the original source (from the Coco archive) and all the errors were there in the original source. So I decided to look at the code more closely, since I now suspected that my conversion had involved too little checking.
I found a few more quirks. Not major errors, but obvious oversights by the programmer,
probably just because he didn’t have the luxury of a full screen editor view of
the code. The message to display “THE COMPUTER WINS” for example, didn’t
work. The IF checked an incorrect variable. Stuff like that.
Also, in two player mode, there was no win check for the two human
players. They would have to both agree when someone had won and then break out of the program and type RUN to start a new game. So I added a quit
option so that players could more neatly begin another match. I also modified the “THINKING”
flashing message as I found it too flickery. I added some speed-ups, such as converting IF AND constructs to IF THENIF constructs.
OTHO36 is by Alain Dussault from 1982. It's an Othello game that plays a very strong game, at least from my limited experience as player. Like CCHESS it is another interesting example of an AI opponent programmed in BASIC in the early days of 8-bit computing. I really hope people will give it a try and that my edits might help folks to have a less frustrating experience with it. They mostly involve dummy proofing. For example, I discovered an error that I think would only happen if you triggered two consecutive input errors (move onto an existing piece, move to an invalid location) on the first move of the game. Unlikely and rare, but nice to get rid of it.
I hope I have actually improved these two neat programs, and not actually damaged them in some way. They can be played here under the "Classic 8-bit Games" and the "Other 8-Bit Basic Game Ports" menu selections after you choose "Play Game": https://gamejolt.com/games/jgmc-10games/339292
No comments:
Post a Comment