Aarrrggghhhhh !

What task has taken me the longest in the Challenge so far ?

Is it :

(1) finding the data sheet for the Hughes LCD ?
(2) writing the emulator for the TMS1100 ?
(3) getting the assembler working ?

or is it :

(4) getting code that compiles perfectly under Mac OSX and (probably) Linux, is syntactically correct and uses standard libraries in the proper way to compile in bl**dy Windows.

All answers on a postcard.

I gave up on the command line, I did it in Code:Blocks in the end, following a guide this bloke had written.  Apparently, in s**ding Windows (I'm an MCPD so I'm certified in how bl**dy awful it is) it matters what order you put libraries and command line options. Get it wrong and you get 700 linker errors because it can't find things in a library that you've linked to which is definitely there. Gawd alone knows why.  Why it can't just work like it does on Linux and Mac OSX I do not know.

Anyhow, tomorrow, you will be able to play with the emulator on Windows and MacOSX. It appears to work okay in Windows XP / VirtualBox. The source code will be available for those who think its a virus.

Probably.

Sound and Keyboard now working

I've now got the sound and keyboard working - except for a few tweaks (the emulator still always loads a file called 'test.bin') it is essentially complete.

There will always be a few bugs. I found that (for example) the assembler was compiling TKA as $0B rather than $08 which caused some chaos, as $08 (COMC) is the command to switch to the upper 1k of ROM (sort of).

But hopeful I will release the source later today or early tomorrow - I'll set up XP in a VirtualBox machine and build a DOS version as well, because it's built for a Mac.

Slowwwwwww.......

Another day, another step forward. I've synchronised the Emulator to the timer now, so instead of running at 50Mhz, it's running at 50 kHz.

I must check to see if its over clocked, because they can run up to about 65khz (400Khz clock, 6 cycles per instruction)

Drawing the pixels on the screen above, and doing nothing much else, runs about about 32 Frames a second.

Now, it is fairly slow as a method, because there are loops and lookups in that pixel drawing code, it would be much quicker just outputting four nibbles, but still, it's going to be like programming for the Studio 2 ; do the graphics first and get the frame rate passable, and then fit the game around it.

It lives !

Drawing a line on the Microvision LCD

Okay, perhaps not the most exciting screen grab ever - a diagonal line - but it is done using TMS1100 code, programming the LCD driver, and it reverses the polarity.

There's a routine I'm quite pleased with at the heart of it (it starts at $3E0 on the picture) - it takes a value 0..15 (e.g. a coordinate) and pumps out a nibl sequence to the LCD Driver which is 4 x 4 nibbles, with a '1' bit at the appropriate position as specified by the coordinate (11,11) in this particular case (why there's a $B at $0F)

Expanded Emulator

The Emulator Screen has expanded a bit as I start to emulate the LCD - this is mostly done now, I just need to write some code to test it.

A,X,Y are TMS1100 Registers - XY is a composite of X and Y, and M is the contents of memory location XY (the only way you can access data memory), this is also highlighted on the Memory display in yellow.

ST is the Status Flag, CL the call link Flag (set when in a subroutine), and SL the Status Link flag (which is probably not going to be used).

CA, PA, and PC form the 11 bit program counter (1 bit + 4 bit + 6 bit), CB, CS, PB and SR are used for long branches, and subroutine call storage and return.

RL is the R-Latch - the output pins, the currently selected one (Y) is highlighted, O is the parallel output register.

The rest belong to the LCD Controller. CT is the Latch Address Counter (and points into the 8 Address Latches marked as AL), DB is the values on the Hughes0488 Data Bus, LP the level of latch pulse, DC the level on the inverse Data Clock line (why it's purple) and PO the polarity (switches between + and -).

BK is the breakpoint.

I have to admit to enjoying programming these things, it's a form of masochism really :) Mark Lesser, who wrote Auto Race (the handheld) which requires similarly arcane levels of coding, said that it was the thing he was most proud of. I think it's because there's a challenge involved, not only in coming up with algorithms, but tailoring them to the hardware and the processor.

It's much easier in some ways coding for an Xbox or Playstation :)

Coda to the Hughes LCD Driver.....

I've been pondering the questions in the wiring.

Looking at the Hughes Data sheet

Arduino Shield with 84 x 48 Pixel LCD

two things spring to mind. The numbering of D0-D3 is backwards to how these things are normally done - D0 is normally the least significant bit, but in this its the most significant bit - this matches up with the TMS1100 'O Register' interface, as Dan Boris has it, where O0 is connected to D3 and O3 is connect to D0 (on a TMS1100 O0 is the least significant bit). It is also consistent with section 10 - "Data 0" is put in R1 (e.g. the first row), which would be horribly messy  if this was actually a least significant bit - so the first nibble is R1/R2/R3/R4 and the second R5/R6/R7/R8 etc.

Also the rows and columns are numbered from 1 to 16. If they were numbered 0-15 it is not implausible that these are bit numbers (e.g. R0 is the least significant bit), but the document appears to have been done 'counting' left to right - so D0 is on the left of the nibble, R1 on the left of the LCD, and C1 at the top of the nibble.

So, having said all that, I'm fairly sure that :

• (R1,C1) is the top left pixel on the LCD.
• D0 is the most significant data bit.

The latter actually doesn't matter. The TMS1100 has an instruction TDO that outputs a 5 bit word composed of the Status Latch (1 bit) and the Accumulator (4 bits).

This doesn't however, go straight onto the output lines O0-O4 - a TMS1100 has a built in 32 x 8 mask  ROM, and what happens is the TDO 5 bit value is an address into this ROM, and the data is output on O0-O7. This comes from its early use as a calculator chip - the idea being that you put a digit value using TDO and it outputs a 7 segment bit pattern on O0-O7. So it operates a bit like a 7447. This on the TMS1100 used in the Microvision is probably a 1-1 thing, so putting a value n in the accumulator produces n on O0-O3 irrespective of the Status Latch (O4-O7 aren't connected). If it is backwards, and it is not likely IMO, then you could just reprogram the Mask ROM to reverse the nibble bits anyway.

I did wonder about using the 32 x 8 ROM to hold digit data, but there just isn't enough space to fit it in.

So, next thing is to write the interface code between the CPU emulation and the physical emulation of the keyboard, beeper and LCD, and write some basic code to test it. This means that porting it to an Arduino just involves compiling the interface code and the processor code, leaving the physical emulation, obviously different on an Arduino, to be written.

(I've found somewhere that will sell me one of these (see picture) cheaply - its an 84x48 LCD and a little joystick, which I can make do the same job as buttons - maybe :)  which will minimise the wiring and make me feel less bad about using a TFT LCD)

All about the Hughes LCD Driver

So, this morning's little bit of light reading is my rewriting/explanation of the Datasheet of the Hughes 0488 LCD Chip.

Hopefully it's a bit more readable than the Datasheet itself, which isn't the clearest document I've ever read, and has at least one significant error in it, I think :)

I have also revised the tms1100.def file as it had some errors in it - when I first put it up it hadn't actually been generated / compiled.

The Hughes Document is at http://www.studio2.org.uk/mv/HughesNotes.pdf

NB: I have just noticed that on Dan Boris's document and the Hughes data sheet the pins are the same but in the reverse order - so what is marked as "Row 1" (pin 39 on the Datasheet) is R15 on Dan's (the bottom one). I will need to give this some consideration.