Thursday, 4 July 2013

Updated BIOS/System common code

A slight update - I've added a LFSR (4 bit) Random Number Generator to the BIOS / System code.  I got the basic algorithm from here

It's probably mostly complete, though I might add other specific routines like "Increment RAM(B) and set carry if zero" (which is there already).

Anyway, next up, writing a demo game.

BIOS early release

First working version of the BIOS code is available now - it fits in two of the eight pages (which is quite a bit).

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:

do {
  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)
    aisc redled
    jsrp LightLED

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