End of show.....

Well, sorry folks, I never really got started up again once I got back from holiday - too many things in real life (TM) got in the way.

A partial success - I did get it working, and a real new game created (albeit a simple one), but not much else.

Roll on Winter 2013 - I'm not going anywhere and I'm going all out to win next time :)

I'm back .....

And have moved to Ubuntu 12.04 LTS (work reasons)

Two problems...... firstly the sound doesn't work, and I've also realised that the Serial Register shifts left not right ..... so some bug fixes needed here :)

L8R: Fixed the emulation bug and modified the utility functions to work differently, but the sound still doesn't work on Java.

Leave of absence

Off on holiday tomorrow, so no more work will be up here for a fortnight or thereabouts.

I may will do a few bits of design though.

Sad I know.

TTFN.

Demo Game

The Demo Game for the Funtronics system is a hand held version of the famous British TV Quiz Game "Numberwang" (as seen here played by a famous British Policewoman).

Not only can you watch the game on your TV and play the board game you can now play it on your home computer.

It is a slightly cut down version, because it is difficult to fit all 37 books of rules into a microcontroller with 512 bytes of ROM memory (I did consider interfacing an SD RAM Card but it was too challenging).

Playing the game is simple. Download the emulator and the "Numberwang" game pack, and unzip both files. Put all the files in the same directory.

Run it with:

java -jar funem.jar numberwang.bin

then select Debug/Run on the menus and click on the Game window. To play the game, choose your number (from 1-8) by pressing the button (keys A-H on the keyboard) and it will tell you whether or not it is Numberwang by lighting the green or red LED at the bottom of the screen. You can also "rotate the board" for added realism (R key), and play it as a 2 or more player game by passing the game around between 2 or more players.

The game zip contains the source and the background SVG, the only files that are actually needed are numberwang.bin (program code and hardware description) and numberwang.png (the backdrop picture).

This is just a test game to check everything that works and that the "BIOS" file is useable. Creating this game took about 20 minutes, but 2-3 times as long was spent tweaking and bug fixing the BIOS. I still haven't cracked the sound yet, it warbles a fair bit :)

I am going away soon ; when I get back I will have a go at writing a "proper" game, probably one of the three original games, then have a go at writing a real original game.

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 {
  light(led1)
  light(led2)
  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)
..
    clra
    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

A neat trick

Usually, no idea in Computing is completely new. Trick bits of coding, like the xor swap algorithm (swap 2 values without an intermediate store) are well known by most people and occasionally rediscovered by rookies.

Yesterday evening, pondering the software for this thing, I came up with something that might actually be original.

It's this:

aisc 14
aisc 14
aisc 15
aisc 5
aisc 8

aisc is add immediate and skip on carry, i.e. aisc 14 adds 14 to the (4 bit) accumulator and skips the next instruction if the result is more than 15 (the largest value in a 4 bit accumulator).

It looks like gibberish. You add 5 numbers in a row. 

But it doesn't do that, because different values skip different instructions. So if  you start with 1 you do the first 2 and skip the third (1->15->13) instructions, but if you start with 2 you do the first and third and skip the second (2->0->15)

What it actually does is to map 0,1,2,3 -> 1,2,4,8 - it converts a bit number to a bit mask. (the results are 0001 0010 0100 1000 in binary). This is going to be very useful in the system routines which access hardware by ID (e.g. LEDs are accessed using two 2-bit values in a nibble, the L line to set to '1' and the D line to set to '0').

I figured it out more or less by trial and error by hand having wondered if it were possible to do this sequence this way (an index lookup or loop would be bigger and slower). Having done that I then wrote a Java program to search for these sort of aisc sequences (combined with comp, the 1's complement instruction) for other useful mappings (e.g. 0,1,2,3 -> 14,13,11,7, the 1's complement of the above). But it didn't turn up anything much of any use.

It's one of the things I like about coding for a 4-bit processor. It makes you think. I learnt to code (on a real machine) on an SC/MP Introkit (basically the same as Sinclair's MK14) and it taught  you about things like efficiency.

When I worked as a pro developer I quite often came up against outrageous wastes of either CPU time or Memory space by other coders that were quite unnecessary. On their own these don't cause a problem, but if you have lots of them in the same system then it drags the whole thing down.

The trick is to get the balance right - don't spend hours optimising every cycle out (unless it is something like an Atari 2600 - or this where space/time is important) versus a quick and lazy solution.

I think this basic fault is why Windows 3.11 (for example) worked on a 386-20 very nicely, but the prettier 32 bit versions are slower on a machine which is umpteen times faster and has thousands of times more memory and much of the drawing work done by a graphics card (I'm old enough to have developed using 32Mb Hard Disk partitions on Windows 3.1). If you read the book "Showstopper" about the development of Windows NT David Cutler (the lead) has one of this as his main premises.