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.

Sound and Background added.

Slightly further on from the last post.  I have added two things - firstly the ability to use a background rather than just a single colour, and some authentically bad sound effects.

The latter was nicked from the Watchman project - rather than generating a simple tone it's a modulated tone, which gives it that authentic "tuneless Sinclair Spectrum music" sound that goes with cheapo sound hardware.

Sort of working

This is the current working version of the Funtronics emulator. On the left, the debugger window, on the right, a very quick and dirty sample screen. It is written to the design in the documentation.

The screen has 3 LEDs - a Red one, that is on, the Yellow one (top left) and a Green one (bottom centre) that are off. There are two switches - a push button (black square on the left) and a slide switch (on the right).

It is actually running real code - you can see a little bt of it in the window and it doesn't do anything other than switch the RED LED on and off as the slide switch goes from left to right.

There's no sound, yet, though the hooks for it are there.

I really just wrote it for testing so I could see if the whole 'wiring up' thing works. And it appears to work fine. Once the speaker is installed the basic emulator will be finished, and then there is just the matter of writing some code for it. I also want to spruce up the graphic display a bit.

Useless factoid of the day.

The COP411 has an instruction which outputs the current memory location to the "G" port.

Thus in a co-processor system with the CDP1802 one could have the following assembler code.

    OMG
    SEX

.... okay, it's been a long day.

Documentation

Version 0.00001 of the Documentation on how I'm going to make the whole thing wire up together coherently (and some documents regarding the Emulator and Assembler) is now in the links box.

Well, I thought I'd better write some documentation .....

Kevin Savetz's book

As a slightly relevant aside, I did get a prize in the last RC, kindly donated by Kevin Savetz (I'm guessing this is him :) ). Signed copy, no less.

If you ever want an entertaining read and you are a 70s/80s computer geek, it's highly recommended.

Actually a lot of the book could be about me, (if you cross out where it says "Atari" and replace it with "Sharp MZ-80K and BBC Micro."), I never owned any Atari kit before an Atari ST.

First release of Assembler and Emulator

The post title gives it away really.

I've added to the links bar links to zips of the Assembler and Emulator for the Funtronics hardware.

These should be very much considered v0.1 (actually they are .....) but they do work, admittedly you can't do much with them, yet.

The souce is set up for Eclipse and both were developed under Java 7, though 6 will probably work. (not so sure about the audio)

The emulator has no actual hardware so whilst it will run COP411 binaries it won't interact with anything external.

Finding a graphic for Assembly Language isn't that easy and I came up with this stack. I can't really see a HLL for this machine being developed - but having said that, there's a machine called the "Gakken GMC-4" you can get which is a 4 bit Microcomputer based on a Tandy (Radio Shack) trainer from the 1980s. Someone wrote a GCC back end for it and someone else wrote a Basic compiler. So you never know. Given that it has about 80 bytes of program memory (4 bit memory at that) you couldn't do much with it (but then you couldn't with Atari 2600 BASIC either ....)

So, anyway, the next thing is to develop the hardware interface.  This will probably be integrated into the assembler, because there is no consistent hardware for this machine, merely a bunch of LEDs, switches and buttons that appear in various places on the game box.  So there will be some sort of descriptive language for that that is integrated into the assembler.

The hardware will be a sort of crossover between Jacks and Red Light Green Light. It will take the basic design of RLGL and add to it the option of the keyboard matrix in Jacks.  While the patents are pretty similar, there are silly design differences - in RLGL the power switch is connected to G2 and the speaker to G3. In Jacks the power switch is connected to G3 and the speaker to G1. (Port G is a configurable I/O port).

I did have the idea of making the design completely configurable but I thought that was going a bit far. I will basically stick with the RLGL hardware  (4,296,926) with the Switches 16a-f added as in Jacks (4,355,806).  This will be extended slightly on both, so that there are a possible total of 8 switches mapped to L4/L5 and D0/D1/D2/D3 (giving a total of 8 switches, and G0 and G1) and 16 LEDs - with their anodes driven by L0/L1/L2/L3 sinking into D0/D1/D2/D3.

Working COP411 Emulator

As the post title implies, the emulator for the COP411 is now working and here it is.

One oddity is that whilst there are only 32 nibbles of RAM, the mapping actually allows for 64 bits of RAM (Bd is 4 bits, Br is 2 bits).

A consequence of this is that in the map every nibble appears twice - e.g. $00,$08 ... $01,$09 and so on. (The hardware ignores bit 3 of the Bd register).

Now I need to cannibalise the Assembler I wrote for the watch project so it will assemble COP411 assembler. There is actually a working COP411 assembler available, but I want to be able to extend it easily.