Thursday, 4 July 2013
BIOS early release
It does, however, do quite a lot of the work.
The main part is the light generation. The idea is that the main loop does something like:
if (something) light(led3)
} while (!timeOut)
i.e. lighting each light in turn. Decoding and lighting the leds takes roughly the same amount of processor time each time. So we can create a timing system that has a counter which counts up to 15x16 (technical reasons) "led lighting instances" and this will take a predictable amount of time.
We can also use this to track audio. By having an audio counter and adding a pitch value on it, we can turn the sound off and on again on overflow, giving 15 different reasonably predictable pitches. You couldn't play a tune on it much,but it's okay for simple sound FX.
When the timeout occurs the coder can scan the buttons (functions available for this) and update the status of the game accordingly.
I am a bit undecided about this. Writing code from scratch for each game allows more efficiency - one can use SKGBZ and so on, rather than doing it the way I've done it. But it does, after a fashion promote some hardware independence, so you have code like
redled = @redLED(L2:D3,120,200)
The first isn't 'real' assembler, it is a directive to put a red LED at 120,200 on the game space, and connected it to L2 and D3 (so it lights when L2 = 1 and D3 = 0). The code then uses that provied ID "redled" to light it without actually knowing how the led is connected. It works it out from the ID.
This is a good way to program, it's just when using 1/4 of the available ROM on these routines you start to worry about whether it will fit or not. Hopefully it will, because these routines do a lot of the heavy lifting. If not I can always use a COP420/421 as a sort of "COP410/1 with more ROM memory" - the connections and code are binary compatible.
The missing feature is a random number generator. I wrote one for the TMS1000 Simon game, which hopefully can be used. It wasn't brilliant, but it's good enough