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.

In which I admit idiocy.....

So, I've fixed the bug. Apart from the LCD Reversal in Vegas Slots, all is now hunky dory.  (though I still haven't implemented the rotary control yet).

All that time spent double checking the TMS1100 code, it wasn't that. The problem was not that some of the games had backward controls, they all did, and I hadn't noticed. So that's my own stupid fault really.

The reason was simple enough ; Dan's schematics are either wrong or from the back perspective .... so all the wiring is back to front and upside down, so when I used those connections (it is correct in the MV technical document) unsurprisingly everything came out the wrong way round......... the CPU core always worked fine.

So, anyway, after all that idiocy I will implement the rotary control - Block Buster works fine but you can't actually play it and you can't remove the control.

A consequence of this is, I think , the O-PLA is doing the job of reversing the output on cartridges other than Vegas Slots.

This is kind of understandable. The LCD Datasheet does use "Data 0" "Data 1" "Data 2" and "Data 3" for its connectors, but they are the 'wrong way round' from normal, e.g. I think Data 0 is actually the most significant bit. I wonder if somewhere in the early development of these games - which would have been on a separate machine without real test hardware I guess - someone made that mistake.

On the trail of the Lonesome Bug

Block Buster PCB (Track side)

Well, a few steps forward, a few steps backward.

I've dismantled a BlockBuster and Vegas Slots cartridges and they are identical. So it's not a wiring issue.

I've also run the MESS Microvision Emulator. (MESS is a program which emulates virtually every computer and console ever made ....)

This , interestingly, has exactly the same problem with 'Vegas Slots' that I do, viz. the display is backwards - it behaves as if every nibble written to the LCD is backwards, other than that it works fine.

So it may not be just me, it might be the PLA for the O-Lines.

The MESS author derived his technical information from a different source from me, and implements his processor emulation differently, so it is odd that we have the exact same 'bug'. If it is a bug.

However, it does have the keyboard the right way up on Phaser Strike, which suggests that its an error on my part, which I will have to track down.

MESS works well, except for it tries to fit the 16x16 screen to the whole display, which makes the pixels very very big indeed.

A fairly quiet day

Not done a lot today - tweaked the assembler so the changes I made yesterday are the same - I've also made the assembler generate code in TMS1x00 PC order, rather than normal counter order so I don't have to maintain two lots of code, but it's still flattened in the emulator so it looks normal.

Thanks to Sean's scan of the output PLA I know that the mapping of O register -> O lines is 1:1 on Vegas Slots, need to check the physical wiring tomorrow - I do have a couple of Microvisions and most of the cartridges made.

Oddly MB seem to have made different cartridge designs rather than just two - a TMS1100 and an Intel8021 one.

In which I make a stupid mistake.

Vegas Slots running

I've solved the puzzle of the difference between the manual and the code, and a couple of things that nearly but didn't quite work.

I noticed when running BlockBuster there appeared to be a second ball image running in parallel with the first one. I wondered if this was a feature of the rendering rather than the actual code, but it appears not.  So I did a review of the TMS1100 Code.

There's two dumb errors there. On TMS1100 with operands, some operands are reversed. So YNEC 4 is actually

0101 0010

where 0010 is the operand, backwards (e.g. 0100, 4 in binary). What I've only just noticed is that the bit test operands (RBIT, SBIT and TBIT1) and the Load X immediate LDX also have backwards 3 bit and 2 bit operands respectively. The only ones that aren't reversed at Branch and Call, with their 6 bit operands.

This explains much. I thought it strange that LDX 4 was used when according to the documentation it shouldn't work. But it was right, because LDX 4 was actually LDX 1 (e.g. it is 00101 100 - I interpreted 100 as 4 but it's actually 001 , e.g. 1) - so X was in the range 0-3, so the book is right (and the Microvision emulation in MESS is wrong).  Apart from this it didn't matter, it just put the rows in the wrong order because LDX is the only way you can load the X register, you can't increment it, decrement it, load it from memory or accumulator, all you can do is put a constant in it.

The bits were worse, it's remarkable anything worked at all. These are also reversed, so I was interpreting SBIT 1 (which is 001100 10) as SBIT 2 (e.g. the 10 should have been reversed), hence it set the wrong bit.

This was the cause of the spurious ball in Block Buster and also the weird cocked up display in MindBuster, which now looks right.

Of course there are still problems. Phaser Strike works perfectly except that the keypad is upside down - the setup keys are at the bottom rather than the top. It's possible that this might be because in Phaser Strike the cartridges are wired differently. Vegas Slots too works perfectly except it has the same problem that Block Buster did originally, viz. all the graphics or back to front and upside down. This might be simply because the 32 x 8 bit O mask ROM is wired differently. Or it might be another bug. I will have to investigate more closely.

Anyhow, I'm going to try to emulate the rotary control, then I will release another emulator so you can have a go at playing the Microvision games for real.