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 ?

Completing the Number Rendering Functions

Only spent a little time on it today, but got the number rendering thing working reliably - the picture shows it in action.

You can see from the debugger that banks 4,5,6,7 hold the information on each digit - the first number is the actual number, the next 5 the pixel equivalent.

In other, err.... news, I've been dismantling Microvision cartridges (real ones) to see if I can help the MESS dumpers - bit beyond my electronics skills for me - with only limited success.

Looks like a fair few are going to have to be dumped the hard way - carving the top off, using some sort of high power scanner on the chip, and translating that into binary data.

Fun ..... not. But it is worth preserving these things where possible.

Creating some library functions

I always use reusable code where possible , and even a TMS1100 is no exception. I've written a slightly demented bit of code this evening which takes a digit (0-9) and stores a pixel version of it in memory.

Not difficult in most processors, but in an TMS1100 it has to fit in 64 bytes otherwise its pretty useless as a subroutine (branching to another page is possible - you can go the the opposite chapter, I think, but not a different page in the same chapter, because PB is used for the subroutine return address and the page register.

Just need to write some code to physically render it to the LCD.

Not sure what sort of game to write yet. A version of the old Bombing game where you go left to right across the screen trying to flatten buildings, maybe, as a first run. Or maybe something else.

Coding in these things often uses a FSM type approach, rather than a modular approach. It's difficult to be modular when you only have one level of subroutine, and fairly small subroutines.

New Working Versions and Source available

Windows and OSX versions are now available for download. The OSX tar ball contains the source, the Windows just the executable.

You run it with ./mvem test.bin or mvem test.bin . The debugger commands are : 0-9A-F change code address, K set breakpoint, H home to program counter, S single step, V step over. G runs the loaded program - it starts up in debug mode. When running (the debug display will disappear) M returns to debug mode (the other key columns are 1QAZ and 2WSX - a Microvision has a 3 across by 4 down keypad). The P and O keys turn the paddle (position shown by a bar below the main display). 

You can exit either using Escape or the Close button on the window.

There's one oddity. The OSX one worked fine, but when I ran the Windows version it didn't work. It was inserting a 00 value into the first byte of the array used to store the code. This has been fixed, sort of, by inserting a bit of code which effectively does nothing in the reset() code. I am wondering if this is an optimisation bug .... or another bug in my code. But it works, anyway.

Also included are the four ROM images - Vegas Slots, Phaser Strike, Block Buster and Mind Buster. Blockbuster is almost unplayable but then it always was .......

The other things - the assembler, definition file and parser have been updated as well.

Not perfect, but not bad. Next part of the Retrochallenge is to write a new game for the system.