It started with an email from Greg Dionne that he had triggered an error in my ACHESS program with these moves:
Then do the following moves:
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 in renamed directory reflecting its internal title:
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).
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.
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 ride of it.