Day 3 : Unit testing

A processor emulation is an odd thing to try to Unit test. I've done it in the past by using a psuedo RNG to seed the machine status, and running an instruction and checking before/after statuses.

This approach has worked okay with this emulator but it's a bit thrown by the fact that the PC is a register like any other, so you can Shift it Left, or Exclusive Or it, which produces rather odd results. Some processors are just bad for this ; the 1802 has all kinds of wierd cases where X or P are the same (for example STXD with P=X effectively stops the processor because it keeps decrementing it).

To save myself going completely bonkers by coding test results for countless utterly wierd examples I've just not tested these odd border cases and it seems to have worked quite smoothly, just the odd bug fix.

The worry with these things is that you've misinterpreted the CPU docs twice, so your emulation does what it's supposed to do, but doesn't actually do what it should. For odd cases I've used the MAME/MESS CP1610 processor core as a reference.

So I left it running for a while testing a few million instructions and it seems fine. This will be enough for the code to run the virtual machine interpreter (actually I reckon it's pretty goo anyway).  It's way way too fast so I'll have to sync it to the system clock, but that's not hard.

For a bit of a change I also wrote some Java code to mimic the screen using the fonts on day 1. I've implemented it as a 19 x 12 display which is memory mapped and has each character in white with four different backgrounds (green, red, black,white). I then wrote a superclass/adaptor for it so it could be written to to mimic the wierd split screen design of the Gimini console (left half 6 x 12, right half 13 x 6) - when it writes to certain areas it updates two cells on the 19x12 display so effectively it's the same thing.
This is what it looks like - writing values 0-226 into equivalent locations 0-226 (It is just write only, I will mirror the 256 bytes of RAM for r/w access)

There's actually very little else to do to make it work. I've already got working key tracking classes and beeper classes, and a working debugger framework, so I've just really got to glue it all together.

I've also found a useable CP1610 assembler that's part of the Intellivision Development Kit, so I won't have to write my own.