Saturday, 15 June 2013

Watchman is a ...... what ?

Well, yes, this is something really obscure and wierd again. Well, I like wierd and obscure bits of hardware.

This thing on the right is an actual "original" Watchman made by Tomy, the predecessor of the machine I'm developing for. Like most "Watches with Games" (see these guys for a ridiculously long list) these ones are single game watches - the most common one was a bowling game.
There are a lot more things like this - Game and Watches (this is a Nintendo classic). These are much better games, but not actually really useable as watches. You can't really fasten one to your wrist - it is more like "Game and Portable Small Clock".

This too has the major issue that the game itself is a one shot based on the LCD - you can't do a different game with it really.

The Watchman I am going to write some games for is more like the above watch in looks - but its display is just about flexible enough to support different games. The original appears to have had four games. There is one major problem with this whole rather mad thing though, which I'll deal with next time.


  1. I found your blog searching for SM510. I've been perusing patents looking for info on Tiger Electronics' R-Zone, and I think it uses that MCU. I decapped an R-Zone game and took pics of the die:
    I found some Konami patents that have SM510 ROM dumps (5137277 for one).
    I agree that the SM510 looks like it's derived from the TMS-1xxx chips: K1/K2/K3/K4 inputs, Test input, RAM and ROM page registers, funky opcodes, and the die looks similar. Kevtris has had some luck dumping the TMS-1xxx chips using the Test input and info from the patents:
    Bitsavers has a Sharp databook with info on the SM510:

    1. I got mine just by googling - there are several copies of the data sheet online. The problem with the SM510 is that I think it is fundamentally broken as a chip. The reason I gave up on this was that I couldn't figure out a way to do an indirect write (without completely mad code). The problem is that you can't load Bl with a memory value without going via A, which of course trashes any value you have in A to write. It meant that writing general purpose code was pretty difficult if not impossible (it bothers me that there's some really easy way of doing it I haven't noticed). There's no equivalent of TMY in the SM510 - I do wonder if this is why the COP420 series has the odd XAD 3,15 instruction.

      I tried dumping the Simon ROM by prodding it with an Arduino - it worked in that you could clock the MCU and see the I/O respond but I couldn't persuade it to do anything - but it may well have been a masked version, it wasn't a real TMS1000.

      It's amazing what's in the patents database if you look - my next RC project will be to write a game for the "Auto Race" hardware - this processor is minimalist in the extreme, makes the Sharp 4 Bit controllers look like a Z80, it's a calculator chip (I think) called a B6001. Had to put together 2 patents and some educated guesswork from the PPS4 documentation, there's nothing else anywhere.

  2. I wonder if any of the code in the patents would shed a light on indirect writes. I grew up on 6502/6800/6809/68000, and the TMS1xxx opcodes hurt my head. SM510 won't be any better.

    I'm going to try to find the patent for the SM510. The TMS1000 patent is great; I'd like to get some of that info about the SM510 - the LFSR used for the program counter, how to use the test pin, etc.

    Thanks for posting all the info. With a little more cleaning, I can do a visual ROM dump of the R-Zone cart, and if I can figure out how to order the bytes correctly (the physical position of the each memory address and the execution order specified by the LSFR), I'll disassemble the game and emulate it using your code.

  3. I think it's impossible - nearly. If you have a value in A that you want to write to M(B) then there's no way to set up B without changing A (hence TMY in TMS1000) - and if you set up M(B) first there's no way to load a value into A. You can do it with a jump table with an entry for each of the 16 addresses, and I came up with a way of shifting it in using the carry flag as a temporary store.

    The LFSR should be fairly easy - it's only a 6 bit LFSR and there probably aren't that many combinations that work. Patent 4339134 has some code - a full listing of an assembler run for a 6 bit LFSR which might be the same. If you download the 'Macro CPU Core' file one of the text files would allow a SM510 disassembler to be put together in ten minutes - it would be pretty obvious whether the code is sensible or not.

    It's also possible it might be stored backwards (e.g. LSB first)