Some minor changes and thoughts......

Firstly some minor updates. I have changed a couple of things on the assembler and emulator - the assembler now returns an error code on an error (handy for scripts) and the emulator now sounds somewhat better (pitch wise), but also worse as I've made it so it does what the real thing does and modulate another tone. It now sounds generically "cheap buzzer" awful, a bit like playing music underwater.

Now, if you've read this far you are probably wondering who this bloke is (it isn't me, too much hair). This is a fellow called Alan Turing who did a lot of the early development work in computing, including working at Bletchley Park in the war.

He also had this concept of "Turing completeness" which was used to differentiate between "not really computers" like the Code breaking machine Colossus or the work of the German Konrad Zuse. Both of these were nearly-but-not-quite computers, they missed things that meant you couldn't write some programs with it - I think Zuse's early machines didn't have conditional branching.

I nearly abandoned this RetroChallenge because I think the SM-5, while not exactly not Turing complete, is broken.

When I was looking at the COP411 (a NatSemi MCU) I wondered why they had this odd, single, exchange memory location $1F with the accumulator instruction (XAD 3,15). It just looked wierd. Why not allow the swap of any memory location with the accumulator directly ?

Now I know. The SM-5's big problem is that it can't do an indirect write very well.

You have two registers to work with, more or less, known as A and B, A is the accumulator and B is the memory pointer.  Most modern CPUs have an instruction like

sta $4032 

which for a 6502 stores the accumulator at location 0x4032. Most old fashioned 4 bitters don't have this. You load the "Memory Pointer" - B in Sharp/Nat Semi, XY in Texas with the address then write the accumulator, e.g.

lbi $3F
x 0

loads B with $3F and then saves A at that memory location (actually it swaps A and the memory location). 

The big problem with the SM-5 is that it doesn't have a mechanism - that I can work out, that allows you to do an indirect save (in any kind of sensible fashion.

For example, you might want to save the value in A in the memory location whose address is in $40, rather than $40 itself. So suppose memory location $40 contains $17, your 'save' would go to location $17.

I don't think you can do this on an SM-5.  You have the value in A, but to load B, you have to put the address ($40) in B, load memory location into A (then A will be $17), then copy it into B .... but in doing this you have overwritten A. 

If you save A so you can load B this is fine, except that to get A back you have to put the address of where you stored it in B.

That's why (I think) the COP411 has XAD 3,15. It allows you to load A without putting an address in B first.  I reckon this is a last minute "oh XXXX" design decision :)

- there are ways round it but they are all bonkers - e.g. having 16 identical copies of

lbi <some value>
lda 0
lbi 4
x 0
rtn0

except for the save address (the 4) and doing an indexed jump to the right one, and things like that.  But you have to code for the processor you have.

Exclusive OR for example. Neither this nor the TMS1x00 has it (or AND or OR for that matter), and I needed it for the TMS1000 project (Simon). I ended up writing a sort of 'check and rotate in a loop' bit of code to just exclusive or two values, and it took nearly a whole page of the ROM space.


That's why the Sharp SM-5 series is broken (the other things like using T for every instruction going, I can live with .....)

TBH, I did seriously consider abandoning it for another project. But it's not called RetroChallenge for nothing.

 

Another bug fix

The TM, TML and RTN instructions weren't doing their job, this is now fixed.

Additionally there is a procedure mechanism using TM which works as follows:

Definition

    proc pname
    ..
    (do stuff)
    ..
    rtn0

Call

    tm pname

it also has a pseudo operation 'extpage' which works like nextpage except that it skips pages 0 and 16 of ROM memory which are used for this mechanism. Procedures can be defined retrospectively. Only 32 (currently) are allowed.

The point of this is that you can write page independent code. The assembler takes care of patching up the procedure links (it does this via pages 0 and 16, and possibly later 17), and you don't have to bother with TML (which only works in certain pages). This can now just be ignored.

The stack is only two levels deep so it's still not going to be very structured though.....

First (tuneless but working) release of emulator with working code.

Yep, a first release. Only version 0.1 but it does work :)

There are three components. There is the assembler, the emulator (pictured) and the source code and binary for the demo

The latter is a zip with two files in it - an assembler source (hardware.asm) and a binary object (test.bin). You can assemble the source file using the jar file in the assembler using

java -jar sharpasm.jar hardware.asm

This will actually produce a file called hardware.bin. I used test.bin because that's the name of the default file in the emulator , e.g. you can either start it with

java -jar watchman.jar hardware.bin

or

java -jar watchman.jar

the former loading hardware.bin and the latter loading test.bin. It starts off much as shown (the reason for the odd patterns on the watch display is random data in RAM).

If you run it (Debug/Run or press F5) the display will change continually. All it's doing is counting 0000-1111 in binary and filling display memory with that nibble, so you get a cycling pattern. It's a very dull demo, it just is there to test the buttons and buzzer are working.

If you give the watch window the focus the keys will work. They are Z (left), X (right), L (fire) and M (mode). All they do is stop the pattern circulating and fill the display memory with the bit pattern representing those keys. Pressing the mode key causes the buzzer to start as well, this is really bad at the moment and I'll make it better. As it's modulating a 4Khz tone it will sound better on the emulator than it would really.

If the keys don't seem to be working is probably because you don't have the focus on the watch (right hand) window.

But it does work :)

Complex wiring completed.

I've got the wiring done now. This is the mapping between pixels in RAM Memory (actually using the test bed) and the LCD display. I can turn bits off and on and the display mirrors it - as in the game "Blastaway" (Breakout in practice) shown here.

This is not totally consistent because the LCD design is set up for manufacturing not developing. Coders work round oddities to keep the manufacturing costs down.

Next thing to do is to wire this up to the actual emulated CPU and get some real code running.

The CPU core has run real code, mainly to test that it's functioning at the right speed - I set up 16 nibbles as a decimal counter and set it going. Multiplying the number of instruction cycles per loop by the counter gives you a rough total of the cycles done, and it can be timed with a watch (approximately).

This is what the code looks like (the first bit zeros data memory, not guaranteed on reset).

    lbl  0,0           ; clear row 0
clear:   
    lax  0
    exci 0
    t    clear
 
nocarry:               ; come back here to increment counter
    lbl  0             ; point to first digit
increment:
    lda  0             ; add 1 to digit
    adx  1
    exc  0

    lda   0            ; retrieve , add 6 for decimal overflow
    adx   6
    t     nocarry
    exci  0            ; dec overflow, write the zero back and bump BL.
    t     increment    ; loop back don't set B to zero as inc next digit.

The keyboard and sound has to be done too but these are much simpler.

Testing tools.

Today haven't done much. I have created the tool on the right.

It's a picture of a chunk of memory in the Microcontroller - nibbles $60-$7F, modelled on the LCD display area in the datasheet.

It's for testing the display (see ... below ?) - bits in memory correspond to bits on the LCD screen.

It allows me to test the wiring is write by changing bits in memory without having to do it via code - just clicking on a bit toggles it and sends notification of a bit change to a listener. I can connect this to the LCD hardware and check that toggling bits here turns the right bits of LCD hardware on and off

This is one of the joys of interfaces. I have an "IHardware" interface which is basically the external bits of the microcontroller. As long as I stick with the contract it doesn't matter what's driving it or what it drives - it will work.

Hopefully :)

You may wonder with my previous Retrochallenge projects why I choose things with very limited display hardware. The honest reason is that I cannot draw for toffee :) So something with fixed or simple graphics avoids that problem. (It's part of the reason I like writing games for the Studio 2).

Display under construction

So, now there's a display component - sort of - that will act as the display panel for the Watch Display.

This isn't a real Java component though. It's a classic 'game' design - there are a collection of BufferedImages() that draw onto another BufferedImage() which is then copied to the display.

You could split this up into components and layouts, but it would slow it down and it would be interesting to get it right.

Minor updates

Have been testing the CPU Core this morning, and fixed a couple of small bugs round the divider timer (twice as fast as it should be on the flag tests), so the generator code is updated to reflect those features.

Also, the assembler has had the ability to do data statements added. I'm not quite sure why I bothered with this as there appears to be no way of reading from the ROM.

You can create a table because LAX skips subsequent lax instructions. So if you have:

  lax 4
  lax 7
  lax 14
  lax 3
  ..
  ..

and jump in at (say) "lax 7" it executes lax 7 (put 7 in the accumulator) but ignores all subsequent lax instructions.  But if you want to read 8 bit values, you can't. It's a bit wasteful.

It may even make sense to create a psuedo op "table" which generates the above with

  table 4,7,14,3


Next thing is to create the display object which will simulate the LCD screen.