Bomber , part the first.

First bit of working bomber code, showing the 'buildings' (okay single square pixels) that  you have to flatten with your bomber and bomb (both single square pixels).

Not much for the Graphics Artists here.

Showed up one bug though. The LCD rendering/latency code is optimised for column data writes (e.g. writing a line horizontally) - this renders lines vertically (so it can keep the building heights as a table - see bank 1, the numbers correspond to the building heights), but of course that doesn't work properly.

I don't want to do it a la MESS where it tracks each pixel individually, so I'll have to have a row based renderer and a column based renderer and switch between the two depending on the data in the latch. Which will be basically the same thing, might blink at switch over.

It's not a cycles issue for a PC or a Mac, but I still hope to get an Arduino version working, and that might be short of CPU cycles. No big problem really :)

Fix for tomorrow I think.

Minor Updates

Couple of fixes to the assembler - it didn't handle page overflows properly following the conversion to the LFSR program counter, and labels can now have underscores in them.

I have also uploaded the current version of the system routines on the links page as well.

Further to the weird Windows only bug, I'm going to code read the emulator source in case I've done something daft, wouldn't be the first time :)

Okay, so I decided to do something a bit different

This is a mock up of the first new Microvision game in 30 years ...

It won't ever be done on a real Microvision, though - probably.

Not because it's technically impossible, actually it's technically not that difficult, but because the Microvision main units are so fragile that it's a rather expensive experiment.

This is a Cheetah3D model.

(Note that I'm not quite sure how you do the insert round curve at the top yet ....)

Library routines move onward

The support library is coming along quite well, I'm quite pleased with it. It currently occupies only four pages of ROM memory, and wastes only about 6 bytes - this is because a TMS1100 divides memory into pages of 64 bytes and you can't cross to a different page without a jump, it's not like a Z80 where memory is contiguous.

The screenshot uses about 12 bytes to - clear the screen, play a beep, display a number and increment it (the latter is for keeping scores and so on) - you can actually see most of the code in the screen shot. It operates like a fast counter. I suspect on a real Microvision it would be extremely blurry in the least significant digit because the LCD isn't one of the greatest available.

Functionality at present is :

• Microvision hardware initialisation
• Writing a row or column bit pattern to the LCD latches given a row or column number
• Performing a Display Update
• Performing Display Polarisation switching
• A sound system that runs in the background (sort of - it toggles the speaker on the update and does the timing on the polarisation) which allows beeps of about 0.5 seconds or so and half a dozen different beeps, all dependent on how frequently you update the screen :)
• 3 x 5 digit font for scores / settings and the code to select it.
• Render a four digit number to the screen at any vertical position, optionally updating font data
• Clear screen routine / Zero score routine
• 4 bit Random Number Generator - bit rubbish but useable.
• Add 1, 10 or 100 to the 4 digit number (for scoring, mostly)

There's no keyboard routines or other utility functions - not sure what to provide, rotate functions maybe ?