Acey Ducey working

"Soon" was a bit later than I thought. The first thing that became troublesome was the encoding of strings as {length,character,character,character,...}. Parsing strings like that requires making sure the length is always kept correct, and given the large number of different parse routines for skipping digits, skipping characters, skipping whitespace and various other tokens the length rarely was correct. Instead of hunting down this error I thought it was more robust to change the encoding of strings as {character,character,character,...,0} which is the usual way strings are encoded in C. This means that 0 can no longer be used as a character, but since this was not something you could input on a keyboard anyway it wasn't very relevant. Of course, changing the code this way was not entirely insignificant, but fortunately everything was structured well enough so the switch was done in an hour or so.

The next issue that I ran into was the keyboard input. The keyboard handling is currently done without an interrupt, disabling and enabling the keyboard using the clock line whenever character input is required. This worked well. However, I also want to check for the "Esc" key during program execution, so the user can interrupt the program if so desired. In order to do this I occasionally release control of the clock line and look if a character comes in. If it does, I read it and checked whether it was "Esc". This worked well, however, if keyboard input happens for a normal reason during execution (in this case, to enter the bet of the player) the last scan code ("Enter key released") will be stalled due to the clock line being pulled low, and will appear as the next character. The routine checking for "Esc" finds this scan code, and assumes that the user entered something and will wait for input, but obviously the user just released the "Enter" key and no characters are forthcoming. This means the program seems to hang. I fixed it by having two versions of the getKeyboard routine (using a status bit), one in case I do want to wait until input takes place, and one which will return after the first scancode has been recognized.

But after that, the Acey Ducey game from the classic computer games website started working. Of course, there were some bugs in this BASIC program, and some minor conversions that were needed, but in general it works, as you can see from the screen shot. Typical conversions include adding % to indicate that the variables are integers, adding LET in front of assignment statements, using RND(number) instead of number*RND(1) and splitting the PRINT part of an INPUT statement, as well as a PRINT statement that prints both constants and variables. Finally some of the constant strings needed to be shortened in order to fit the screen.

I'm happy that the game is running, but obviously I don't want to enter it over and over again. I therefore will have to devise a way to store the program somewhere, and retrieve it. There are two ways: I can add an additional 24LC512 chip and compress and store the code in there, or I can use the upper part of the current 24LC512 for storage. Currently a program can use lines 1-2047, storing it at the top would reduce this. Of course, an alternative would be to use an SD card for storage, allowing easy exchange with a PC as well. Or a serial interface/USB interface for storing it in a PC.

Apart from this a lot will need to happen with the code. String handling. Array handling. Negative number input. Fortunately it is using much less than 3K so far, of the 4K that is available. So a lot of features are still possible, although I might have to divert from usual BASIC syntax in certain cases. For arrays I'm tempted to use square brackets, for example, to distinguish them from functions. For strings I'll probably resort to the ZX-81 method of treating them as arrays to begin with. And it is likely an array like DIM A%(10) will have element A%[1] overlap with variable B%, as the RAM of a PICmicro is, after all, tiny (less than 400 bytes, of which many are used for processing).