Reverse engineering of the first smart watch Seiko UC-2000

Somewhere in late 1983 - early '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 2KB notes, they needed to be entered using a special compact keyboard that came in the kit. UC-2000 is essentially 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, BASIC interpreter and a thermal printer, but without a screen, in which quality the clock was used (as it is not strange). Among other things, the terminal made it possible to load applications with special cartridges on the watch. You can read more about the lineup of the early Seiko smartwatch, for example, in this article . In the same post, I will tell you how I wrote (maybe) the first, for more than 33 years, program for this watch.


A note on the clock in the journal Popular Science for 84 years, the entire lower periphery is shown in the bottom left photo.

Small introduction

About UC-2000, I learned a couple of years ago, at about the same time left such a comment on the GT. Since then, the thought to buy a watch and try to write something for them has not left me. Initially, I was inclined to buy Epson RC-20, but they are so rare that during this time I saw only one offer on Ebay which I missed out of stupidity. 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 dump of the ROM from the cartridge with applications and understand the operation of the wireless interface that the clock used to communicate with the periphery. But, to my happiness, this work was done by one person back in 2002, he had a project to create his own electronic clock, and he wanted to borrow a screen from Seiko. I do not know how his work ended, but what was published on his website helped me a lot. This person (unfortunately, I do not know his name) published applications from a complete cartridge, described the wireless inductive interface protocol, and also wrote an application that largely implements the functionality of the terminal.
')
So, having these introductory, I wrote out the clock and began to search for information. Here it is necessary to clarify that I am not strong either in assembler (I wrote one and a half programs on it for my entire life before), especially in electronics, but as usually happens, the lack of knowledge was compensated by a great desire. Because of this, my methods and terminology may seem strange or even erroneous, I hope you will correct me in the comments.

Reverse engineering

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


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

Photos of the entrails do not provide any additional useful information - all the chips are expected without package without any marking:






From top to bottom, from left to right: an inductor used for the wireless interface and a battery compartment; PCB with a processor module on a ceramic substrate - 2 chips, CPU and RAM; matrix LCD panel - 4 lines of 10 characters each, 5x7 dots; reverse side of the board - 4 display controller chips.

Nothing remains but to try to manually disassemble programs from a regular cartridge, there are 5 of them:

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

Judging by the advertisement, there was still a cartridge, with a Japanese-English dictionary, but apparently it was only sold on the Japanese market, so it is not easy to find it.


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

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

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

This is all that I understood from binary files after the first swoop, even before the arrival of hours. I tried to find string constants, but, to my surprise, I couldn’t find anything like the necessary sequences of character codes.

Then I tried to enter from the other side and began to watch the instruction sets of all 4-bit microprocessors and microcontrollers of the 70-80s in a row that Google could reach - nothing like that. I, in my opinion, 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 system of commands could go back to the beginning of the 80s, but no, and there is nothing. As a result, it was decided to wait for the clock and act by typing.

The clock arrived, quickly assembled such a transmitter:




It didn’t work with the coil from the first transformer that turned up, or rather it worked only without the watch’s back cover, with the second coil turned up it was possible to get a stable transmission. To download programs, I used a slightly modified application published on sigma957.org .
Subsequently, I wrapped the coil and assembled the transmitter on the ATtiny85, more suitable for practical use:




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

0111 10ii iii0 0iii, i - ,

and directly output the character:

0111 11ii iii1 0iii, i -

It was because of this interesting arrangement of bits that it turned out that I could not find the lines right away.
I was in seventh heaven, I immediately wrote “Hello world”, which worked somehow strangely because I did not understand the purpose of the jump table in the heading, but it was already something.

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

0011 AAAA AAAA AAAA, A - ,

and the CALL A subroutine call was the instruction:

1010 AAAA AAAA AAAA

Then the process again stalled. It was already possible to divide the program into separate blocks, the functions of which were generally understood, for example, it was possible to determine exactly that such a set of instructions displays the score in the HIT game, but I could not understand what each instruction was doing.

Having put down the hexes for a couple of days, I decided to use the good old method - throwing everything out of the program that does not break it, thus simplifying it as much as possible, and at the same time studying 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 by 20 characters) and it looked simpler than the others.


Such tactics immediately began to bear fruit. Having found the subroutines for handling keystrokes, it became clear that the table in the heading is transitions to the addresses of event handlers (not interrupts), I haven’t figured out this table until now, that's what I know by now:

Index in title	Description	Standard handler address
0	Application launch	0x227
one	Second timer	0x190
2	-	0x11A
3	-	0x109
four	-	0x0E0
five	Pressing the Mode Button	0x243
6	Pressing the Transmit button	0x283
7	Right click	0x2DF
eight	Left click	0x383
9	-	0x2A9
ten	-	0x307
eleven	Received bytes per coil	0x39C
12	-	0x09B
13	I did not fully understand it, but screen redrawing is usually implemented in the handler.	0x98F
14	On the external keyboard, the APL button is pressed (application launch)	-

Thanks to the same button handlers with which the user chose the desired note, he identified addition and subtraction instructions - 0x221A and 0x2A1A , although without understanding the operands. Then one of the conditional transitions was identified, again without operands.


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

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

1000 10RR RRRi iii-, R - , i -

Now it became clear that we have 32 four-bit registers, besides, instructions 0x3C00 , 0x3C08 , 0x3C10 , 0x3C18 were everywhere , according to some signs, I accepted the choice of the current bank of registers, which was later confirmed. Total, we have 4 banks in 32 registers. Finding the registers was one of the key points, after which I really believed in the possibility of disassembling the programs of these watches.

Located near 0x8257 0x8236 0x8215 turned out to be instructions to copy the registers MOV Rd, Rs

1000 00dd ddds ssss, d - , s -

After that, I could not easily figure out the operands of the previously found addition and subtraction operations; these turned out to be operations on the ADM register groups 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 with 8 registers. Each instruction operating with register groups can operate with any number of registers within a page, and the indices of the initial and final register of the group must be the same for both operands. I probably explain not quite clearly, so I will try again in the picture:



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

So, in general, the syntax of the instructions has become approximately clear, it remains the case of technology - to formally describe as many instructions as possible. To do this, first, I made a list of all instructions from the regular programs in binary form and divided it into groups of six first bits, so you could immediately figure out what data the command operates, for example, if the right bit in the group is always 0, then almost certainly the second operand is an immediate value. Secondly, by this time I already knew enough instructions to write a program for clocks in machine codes that would display the current values ​​of the registers of all banks - press one button - the values ​​of the registers of the 0th bank are displayed, the other of the 1st and others . It was my first useful program for UC-2000!


Content of the zero register bank

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

With these two tools, in a couple of days I have formally described over 40 instructions. A lot of time was taken away by instructions with non-standard syntax, such as INC and DEC.
Even more time was taken by the instruction with opcode 010101 , which was always the first in button handlers and was found in some other places. As it turned out, she copied the value to the current bank's register from some group of registers, which I called the I / O registers. It was 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	The 0th bit is set if the left or right button is pressed; 2nd - the MODE or TRANSMIT button is pressed; 3rd - received bytes per coil
IO1	Receive Data Flag
IO2	Transmission error flag
IO3	-
IO4	-
IO5	Senior nibble taken on a coil
IO6	Junior Nibble Taken by the Coil
IO7	Button interrupt flags, 0th bit - left button, 1st - right. 2nd - MODE, 3rd - TRANSMIT
IO8	Flags of pressed buttons, the same sequence as in IO7
IO9	-
IO10	-
IO11	-
IO12	-
IO13	-
IO14	1/16 second counter
IO15

Also, using the register value mapping program, 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 registers.

The purpose of the registers of the 0th bank:

Register	Description
RA0	Current minutes, low order, BCD
RA1	Current minutes, high order, BCD
RA2	The current hour in 12-hour format
RA3	12-hour interval, 0 - AM, 1 - PM
RA4	Current date, low order, BCD
RA5	Current date, high order, BCD
RA6	Current month
RA7	The current day of the week. 0 - Sunday and beyond
RB0	Minutes of the alarm, low order, BCD
RB1	Minutes of the alarm, senior level, BCD
RB2	Alarm clock in 12-hour format
RB3	0th bit - AM / PM alarm, 1st - on / off
RB4	Current mode, 0 - clock, 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 registers RB0 - RB3 are interesting, they are used to indicate events to which the loaded program will respond. The remaining registers of this bank are used differently in different operating modes of the clock, so I did not analyze them (although, of course, there may be something interesting)

The result of all this work was a set of 61 formally described instructions. Unfortunately, I was not able to restore everything that can be seen from the table (which is just below under the spoiler), there is a gap in the interval of 5800-5BFF, maybe one or even several instructions were hidden there. There are very specialized commands, such as peep with piezo dynamics, most likely, there is something more behind them, I did not even give names to such instructions. Questionable NOP. In many instructions there are insignificant bits labeled by me as "-", in fact, of course, some may influence something that I have missed.


A lot of time was spent on selecting suitable mnemonics, some teams were called rather ugly (especially in the middle of the table), I myself constantly forgot them.

Then I came close to the ability to write applications, but for this I needed an assembler, writing something harder to view register values ​​in machine codes when the size of 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 “tabular assembler” was spinning around in my head, which I started to google. It turned out yes, indeed, there is such a class of assemblers, called the “table driven assembler”, but I could not find anything suitable - these were either long-abandoned products from the 90s of the TDASM type, or modern highly limited projects “on the knee”. And it would be all nothing, but all these tabular assemblers had a serious drawback - they each had their own notation, which perfectly described the instructions of processors from the supported list, but did not want to describe the set of UC-2000 instructions: some simply could not work with operands multiple bytes, some could not address both bytes and two-byte commands, etc.

I was already inclined to write my extremely simple assembler, but I came across axasm ( an article describing the author). Briefly, the macro-substitutions C are used to describe the instructions, due to which a great versatility is obtained, and all the code analysis is placed on the preprocessor, we just have to convert the MOV Rd, Rs code into MOV (Rd, Rs), for The author uses AWK for this, and the entire process is automated by a Bash script. At the same time, of course, this method has drawbacks - it’s impossible to hang several instructions on one assembler command, under Windows you have to use MinGW (although you can rewrite everything, of course, but I was lazy), well, in general, all this is rather cumbersome.

So, I made the description of the commands known to me for axasm and it went much better, all I needed was a disassembler for convenient parsing of standard applications, which I quickly corrected by writing my very simple but fully functional one.
By that time I had already described most of the instructions, and it was possible to start writing something “serious”.

Programming

As the first program, I again chose Tetris.

Of course, I had no illusions about the capabilities of the 4-bit processor in the 83rd electronic clock, but I was still unpleasantly surprised by the seemingly elementary command lack:

• There is no bit shift! In no way. It seems to be a basic operation, the absence of which complicates a lot. The left shift, for example, can be replaced by adding the register to itself, but what can we replace the right shift? (
• There is no logical operation on two registers! AND, OR and XOR are only register with immediate value. What is really there, not even denial.
• No team can use indirect addressing of registers, it is probably not very surprising, but very inconvenient.
• The stack depth of the subroutine call is only 3 levels, this is also not surprising, but I, who were not used to such restrictions, at first caught incomprehensible program hangs and could not understand for a long time what the matter was.

Here, for example, how I had to be perverted 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 us 2 bytes from 2048, a nightmare.

But all arithmetic commands have analogues with decimal correction. This suggests that the microprocessor was originally developed and used by Seiko-Epson engineers for something like a clock with a calculator function and was later adapted for the UC-2000.

Another unpleasant surprise, for me, was the lack of access to individual pixels of the display, although photos of the clock, which show that time is displayed with non-standard characters of numbers that take up two familiarities at once, seemed to hint at this possibility. However, as soon as I saw the symbol table , there were no illusions left - the halves of the numbers are just separate characters.
Therefore, for Tetris, we had to use pseudographic characters, since they are enough to use the characters "█", "▀", "" and "" to split the screen into 8x10 "pixels", the playing field turns out like this:



The “glass” is rotated and occupies the entire screen, but even so, of course, it is not much enough down to the classic 10x20 cells.

In spite of this limited set of instructions, Tetris fit in 700 bytes, although, when I started it, I feared that I would not fit in 2 KB.


Bottom line: after a little over three weeks, after receiving the parcel with the clock, I was already able to play Tetris on UC-2000:



In the process of writing Tetris, it became clear that event handlers are always called as long as they are listed in the registers RB0-RB3 of the second bank (I spoke about them above), regardless of whether the program is running or not. Because of this, you can completely redo the functionality of the clock, 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 them by a combination of the left button + MODE. At the same time, additional dials organically fit into the work of the other functions of the watch:



One of the most popular features of modern smart watches - user dials, was potentially available as early as the year 83, amazing! It is strange that Seiko did not develop this direction. And in general, it is a little insulting that the potential of these watches has not been fully disclosed. Although, of course, there is nothing strange in this, from 2017 everything looks completely different from the 83rd. Especially, if you remember how many not very successful attempts to invent smart watches were after them. But this, as they say, is another story.

I posted everything described on GitHub .