Reverse engineering of the first Seiko UC-2000 smart watch

Around the end of 1983 - the beginning of 84, the Japanese company Seiko began selling the first-ever computerized watch - Seiko Data-2000 and Seiko UC-2000. Data-2000 had the ability to store 2K notes, they had to be entered using a special compact keyboard that came with it. UC-2000, in fact, are the same Data-2000 with a different color case, but they were already positioned as part of the Wrist Information System, which, among other things, included the UC-2200 terminal, which is a computer with a Z80-compatible processor, the Basic interpreter and thermal printer, but without a screen, which was used as a clock (as it is not strange). Among other things, the terminal made it possible to download applications from special cartridges to the watch. You can read more about the Seiko line of early smart watches, for example, inthis article . In the same post I will tell you how I wrote (possibly) the first, for more than 33 years, program for this watch.


A note on watches in Popular Science magazine, 84 years old, the entire periphery is presented on the lower left photo.

Small introduction

I learned about the UC-2000 a couple of years ago, and about the same time I left such a comment on the GT. Since then, the idea to buy a watch and try to write something for them has not left me. Initially, I was inclined to buy the Epson RC-20, but they are so rare that during this time I saw only one offer on Ebay which I foolishly missed. As a result, I was tired of waiting and I bought a much more affordable UC-2000, without a terminal and keyboard, which were not needed for my purposes. In fact, of course, I would have to buy a docking station in order to remove the ROM dump from the application cartridge and understand the operation of the wireless interface that the clock used to communicate with peripherals. But, to my happiness, one person did this work back in 2002, he had a projectto create his own electronic clock, and he wanted to borrow a screen from Seiko. I don’t know how his work ended, but what was published on his site helped me a lot. This person (unfortunately, I don’t know his name) published applications from a complete cartridge, described the protocol of a wireless inductive interface, and also wrote an application that implements terminal functionality in many respects.

So, having these introductory notes, I wrote out the hours and started searching for information. Here it is necessary to clarify that I am not strong in assembler (all my life before that I wrote on it, maybe one and a half programs) nor, especially, in electronics, but as usual, the lack of knowledge was compensated by a great desire. Because of this, my methods and terminology may seem strange or even be wrong, I hope you correct me in the comments.

Reverse engineering

What was known about the architecture of this watch?
Here, on this advertising poster, perhaps, all the available technical information is displayed:


4bit CPU, 6KB ROM, 1.5KB LCD ROM, 2KB RAM.
And that’s all.

Photos of the insides do not provide any additional useful information - all microchips are expectedly open without any marking: From top to bottom, from left to right: inductance coil used for the wireless interface and battery compartment; a printed circuit board with a processor module on a ceramic substrate - 2 microcircuits, a CPU and RAM; matrix LCD panel - 4 lines of 10 characters, 5x7 pixels each; the reverse side of the board is 4 display controller chips. There is nothing left but to try to manually disassemble the programs from the standard cartridge, there are 5 in total:

• Amida - a game, a Japanese maze;
• Card - a card game;
• Hit - a game, shoot back from enemies;
• Race - tote simulator;
• Scheduler is a daily planner, the only practical application.

Judging by the advertisement, there was also a cartridge with a Japanese-English dictionary, but apparently it was only sold in the Japanese market, so finding it is not easy.


If I had previously programmed AVR controllers in assembler, I would immediately have taken the first 14 bytes for the interrupt vector table, but I did not program AVR in assembler, so I thought it was just some kind of set of subroutine calls, i.e. suggested that:

• instructions occupy 2 bytes (this is also obvious because even bytes are often repeated, and odd bytes are much more random);
• the opcode is in the first byte, and the operands are in the second and, most likely, partially in the first;
• instructions of the form 0xC *** is a CALL command with a subroutine address.

After these 28 bytes there is a 0xB000 pair , the same instruction is found throughout the program, including at the very end (not counting the last two bytes, which turned out to be just some kind of program index in ROM), I assumed that this is a return from the subprogram, the command Ret .

This is all that I understood from the binary files after the first attack, even before the arrival of the clock. I tried to find string constants, but, to my surprise, I could not find anything similar to the desired sequence of character codes.

Then I tried to enter from the other side and started to look at the instruction sets of all 4-bit microprocessors and microcontrollers of the 70-80s that Google could reach - nothing like that. I, in my opinion, have never met a single 4-bit processor with double-byte instructions of constant length. There was some hope for modern 4-bit controllers from Epson, I thought that their command system could go back to the beginning of the 80s, but no, and there’s nothing. As a result, it was decided to wait for the clock and act by typing.

The watch arrived, whipped up such a transmitter:




It didn’t work with the coil from the first transformer that turned up, more precisely, it worked only without the back of the watch, and with the second coil that turned up, we managed to get a stable transmission. To download programs I used a slightly modified application published on sigma957.org .
Later, I reeled up the coil and assembled the transmitter on the ATtiny85, which is more suitable for practical use:

First I played around with all the standard applications, then I started replacing suspicious instructions with 0x0000 (then I mistakenly assumed that it was NOP) and literally after a couple of replacements I came across a section with text output. I added two instructions to the piggy bank, setting the cursor position:

0111 10ii iii0 0iii, где i - позиция курсора, начиная с верхнего левого угла

and directly outputting the character:

0111 11ii iii1 0iii, где i - код символа

That's because of this interesting arrangement of bits, it turned out that I could not find the lines immediately.
I was in seventh heaven, I immediately wrote “Hello world”, which worked somehow strange due to the fact that I did not understand the purpose of the transition table in the header, but it was already something.

Then I figured out the addressing of the CALL command - it turned out that the routines that call such instructions from the header do not end with RET, as one might assume, but they end with calls to the routines from the ROM. It turns out, I was mistaken, instructions of the form 0xC *** are more like an unconditional jump of JMP A :

0011 AAAA AAAA AAAA, где A - адрес перехода, адресация двухбайтовая

but the call to the CALL A subroutine turned out to be an instruction:

1010 AAAA AAAA AAAA

Then the process stopped again. It was already possible to divide the program into separate blocks, the functions of which were generally clear, for example, it was possible to precisely determine that such and such a set of instructions displayed the score in the HIT game, but I could not figure out what each instruction did.

Having stumbled over hexes for a couple of days, I decided to use the good old method - to throw out from the program everything that does not break it, thus simplifying it as much as possible, and at the same time study what breaks. For preparation, I chose the Scheduler program, it has a minimum size (the code takes only 2/3, the remaining space is used to store the 31st note of 20 characters each) and it looked simpler than the others.


Such tactics immediately began to bear fruit. Having found the button click processing routines, it became clear that the table in the header is the transitions to the addresses of event handlers (not interrupts), I still have not figured out this table to the end, here is what I know at the moment:

Index in title	Description	Standard Handler Address
0	Application launch	0x227
1	Second timer	0x190
2	-	0x11A
3	-	0x109
4	-	0x0E0
5	Pressing the Mode Button	0x243
6	Click Transmit	0x283
7	Right click	0x2DF
8	Left click	0x383
9	-	0x2A9
10	-	0x307
eleven	Received byte to reel	0x39C
12	-	0x09B
thirteen	I didn’t fully understand, but the handler usually implements a screen redraw	0x98F
14	APL button (application launch) is pressed on the external keyboard	-

Thanks to the same button handlers by which the user selects the desired note, he identified the addition and subtraction instructions - 0x221A and 0x2A1A , although he has not yet figured out the operands. Then one of the conditional transitions was identified, again without operands.


At the same time, the program almost completely retained the functionality for working with notes. As I later realized, blocks for entering notes from the keyboard, various checks for boundary conditions, and the like “redundant” code were cut. I shuffled the remaining subprograms into a convenient and compact form, since the transition instructions were already known to me. Compactness, by the way, was very relevant, because transmitting 2048 bytes per clock takes about 30 seconds. Imagine the process - we zero out two bytes, send it to the clock, wait 30 seconds, see what happened - if everything breaks badly, then return the instruction, if it does not break then look for the next victim and again 30 seconds. Slow, very slow. Therefore, with Scheduler reduced to 512 bytes, work went much faster.

Further sticking with a stick led to the understanding that the instructions 0x8AE4 0x8ADC 0x8AA0 in the program launch handler set the address of the current note, I interpreted them as loading the direct value into the LDI R register , I

1000 10RR RRRi iii-, где R - регистр назначения, i - загружаемое значение

Now it became clear that we have 32 four-bit registers, besides for instructions everywhere looming everywhere 0x3C00 , 0x3C08 , 0x3C10 , 0x3C18 I took for some signs as the choice of the current bank of registers, which was later confirmed. Total, we have 4 banks of 32 registers. Finding registers was one of the key points, after which I really believed in the ability to disassemble the programs of this watch.

Located nearby0x8257 0x8236 0x8215 turned out to be instructions for copying the registers MOV Rd, Rs

1000 00dd ddds ssss, где d - регистр назначения, s - исходный регистр

After that, I easily sorted out the operands of the previously found operations of addition and subtraction, these turned out to be operations on the groups of registers ADM Rd, Rs and SBM Rd, Rs (M - from Multiple). These instructions, operating with groups of registers, showed that each bank of registers is divided into another 4 pages of 8 registers. Each instruction working with groups of registers can operate with any number of registers within the page, while the indexes of the initial and final register of the group must coincide for both operands. I’m probably not completely explaining it, so I'll try again in the picture:



It turns out that some commands can operate directly with 4-byte values ​​- not bad for a four-bit processor. For ease of use of group commands, I decided to name registers by type RA0, RA1 ... RA7, RB0, RB1, etc. etc.

So, in general, the syntax of the instructions has become more or less understood, it remains a matter of technique to formally describe as many instructions as possible. To do this, firstly, I made a list of all the instructions from the standard programs in binary form and divided it into groups of the first six bits, so you could immediately figure out what data the command is operating on, for example, if the right bit in the group is always 0, then almost certainly the second operand is an immediate value. Secondly, at this point I already knew enough instructions to write a clock program in machine codes that would display the current values ​​of the registers of all banks - click on one button - the values ​​of the registers of the 0th bank are displayed, on the other the 1st etc. . This was my first useful program for the UC-2000!


The contents of the zero register bank

In the process of writing this program, I caught some terrible glitches with the value of zero register of each bank and could not understand what was happening. As it turned out, the reason was that I used 0x0000 as a NOP, but in fact it is a register addition command, i.e. I constantly added the zero register to myself in different places).

With these two tools, in a couple of days I already formally described more than 40 instructions. Instructions with non-standard syntax, such as INC and DEC, took a lot of time.
The instruction with opcode 010101 took even more time ., which always went first in button handlers and was found in some other places. As it turned out, she copied the value to the register of the current bank from a certain group of registers, which I called I / O registers. Empirically established that there are only 16 of these registers, a description of the purpose of those that I managed to understand in the following table:

Register	Description
IO0	0th bit - set if the left or right button is pressed; 2nd — the MODE or TRANSMIT button is pressed; 3rd - byte per coil received
IO1	Reception data flag
IO2	Transfer Error Flag
IO3	-
IO4	-
IO5	Senior nibble taken to the reel
IO6	Low nibble taken to the reel
IO7	Button interrupt flags, 0th bit - left button, 1st - right. 2nd - MODE, 3rd - TRANSMIT
IO8	Flags of the pressed buttons, the same sequence as in IO7
IO9	-
IO10	-
IO11	-
IO12	-
IO13	-
IO14	1/16 second counter
IO15

Also, using the program for displaying register values, I found out that the first two banks of registers are used by the internal clock program, therefore, for obvious reasons, it is better to use only 2 and 3 banks as general purpose registers.

Purpose of registers of the 0th bank:

Register	Description
RA0	Current minutes, low order, BCD
RA1	Current minutes, high order, BCD
RA2	Current hour in 12 hour format
RA3	12 hour interval, 0 - AM, 1 - PM
RA4	Current date, low-order, BCD
RA5	Current Date, High Rank, BCD
RA6	Current month
RA7	The current day of the week. 0 - Sunday and onwards
RB0	Minutes of the alarm, low order, BCD
RB1	Alarm Minutes, High, BCD
RB2	Alarm clock in 12-hour format
RB3	0th bit - AM / PM alarm, 1st - on / off
RB4	Current mode, 0 - hours, 1 - downloadable program and further, alarm clock, stopwatch, time setting, data transfer
RA5	Current seconds, low-order, BCD
RA6	Current seconds, high order, BCD
RA7 ... RD7	-

In the 1st bank, only the RB0 - RB3 registers are of interest, they are used to indicate events that the loaded program will respond to. The rest of the registers of this bank are used differently in different hours of operation, so I did not analyze them (although, of course, there might be something interesting)

The result of all this work was a set of 61 formally described instructions. Unfortunately, I could not restore everything that is visible from the table (which is slightly lower under the spoiler), there is a gap in the interval 5800-5BFF, maybe one or even several instructions were hidden there. There are very specialized teams, such as a piezodynamic speaker, most likely there is something more behind them, I did not even give names to such instructions. Questionable NOP. Many instructions have insignificant bits marked by me as "-", in fact, of course, some can influence something that I missed.


It took a lot of time to select the appropriate mnemonics, some teams are named rather ugly (especially in the middle of the table), I myself constantly forgot them.

Then I came close to the possibility of writing applications, but assembler was very necessary for this, writing something more difficult than viewing register values ​​in machine codes, when the size of the opcodes and operands is not a multiple of a byte, to put it mildly, is not convenient.

Assembler

I naively assumed that there are ready-made implementations of universal assemblers, the once heard phrase “table assembler” was spinning in my head, by which I started to google. It turned out yes, indeed, there is such a class of assemblers called “table driven assembler”, but I could not find anything suitable - these were either long-abandoned products from the 90s such as TDASM, or modern, very limited projects “on the knee”. And that would be all right, but all these table assemblers had a serious flaw - they each had their own notation, which perfectly described the instructions of the processors from the supported list, but didn’t want to describe the set of instructions of the UC-2000: some simply could not work with operands multiple bytes, some could not address both bytes and double-byte commands, etc.

I was already inclined to write my extremely simple assembler, but came across axasm ( article with a description of the author). Briefly, the macro substitution C is used to describe the instructions, due to which greater versatility is obtained, and the entire analysis of the code falls on the preprocessor, we only need to first convert the code of the form “MOV Rd, Rs” to MOV (Rd, Rs), for This author uses AWK, and the entire process is automated with a Bash script. At the same time, of course, this method has disadvantages - it is impossible to hang several instructions on one assembler command, under Windows you will have to use MinGW (although you can certainly rewrite everything, but I was too lazy), and in general, all this is quite cumbersome.

So, I made a description of the commands I know for axasm and things went much better, there was only a disassembler for convenient analysis of regular applications, which I quickly corrected by writing my very simple, but fully functional.
By that time, I had already described most of the instructions, and you could start writing something “serious”.

Programming

As the first program, I again chose Tetris.

Of course, I didn’t have any illusions about the capabilities of the 4-bit processor in the 83-year electronic clock, but I was still unpleasantly surprised by the absence of seemingly elementary commands:

• No bit shift! In no form. It seems to be a basic operation, the absence of which complicates a lot. Let’s say the left shift can be replaced by adding the register to itself, but what is the replacement of the right shift with? (
• There is no logical operation on two registers! AND, OR, and XOR are case-sensitive with an immediate value. But what is there, there is not even a denial.
• You cannot use indirect register addressing in any command, this is probably not very surprising, but very inconvenient.
• The depth of the subprogram call stack is only 3 levels, this is not surprising either, but I, not used to such restrictions, first caught strange program hangs and for a long time I could not understand what was the matter.

Here, for example, how I had to pervert to implement the disjunction of the two registers RA0, RA1:

	XORI RA0, 0xF       ;вместо отрицания
	BTJR RA0, 0, +1     ;тестим 0-й бит
	ORI RA1, 1          ;если не установлен то OR'им с единицей
	BTJR RA0, 1, +1     ;а если установлен то сразу прыгаем сюда
	ORI RA1, 2          ;и дальше в том же духе
	BTJR RA0, 2, +1
	ORI RA1, 4
	BTJR RA0, 3, +1
	ORI RA1, 8          ;как хорошо, что у нас всего 4 бита

But each instruction takes 2 bytes out of 2048, a nightmare.

But all arithmetic instructions have analogues with decimal correction. This suggests that the microprocessor was originally developed and used by Seiko-Epson engineers for something like a watch with a calculator function, and only then it was adapted for the UC-2000.

Another unpleasant surprise for me was the lack of access to individual display pixels, although the photos of the clock, which show that the time is displayed with non-standard digits, occupying two familiarities at once, seemed to hint at such an opportunity. However, as soon as I saw the symbol table , there were no illusions left - the halves of the numbers are just separate symbols.
Therefore, for Tetris I had to use pseudo-graphic symbols, since they are enough to use the symbols █, ▀, and "to split the screen into 8x10 пикселей pixels’, the playing field turns out to be something like this:



The "glass" is rotated and occupies the entire screen, but even so, of course, does not reach the classic 10x20 cells.

Despite this limited set of instructions, Tetris fit in 700 bytes, although when I first started it, I was afraid that I could not fit in 2 KB.


Bottom line: three weeks later, after receiving the package with the clock, I was already able to play Tetris at UC-2000:



In the process of writing Tetris, it became clear that event handlers are always called as long as they are indicated in the registers RB0-RB3 of the second bank (I spoke about them above), regardless of whether the program is running or not. Thanks to this, you can completely redo the functionality of the watch, just by drawing what you need on top of the regular modes. To demonstrate this, I wrote a program that adds 6 additional ones to the default dial, switching between which is a combination of the left button + MODE. At the same time, additional dials organically fit into the work of other watch functions:



One of the most sought-after features of modern smartwatches is custom dials, which were potentially available as early as 83, amazing! It is strange that Seiko did not develop this direction in any way. In general, it’s a little disappointing that the potential of this watch has not been fully revealed. Although, of course, there is nothing strange about this, from 2017 everything looks completely different from the 83rd. Moreover, if you recall how many not very successful attempts to invent smart watches were after them. But this, as they say, is another story.

I published everything described on GitHub'e .