Реверс-инжиниринг первых умных часов Seiko UC-2000

Где-то в конце 1983 — начале 84 года, японская компания Seiko начала продавать первые в истории компьютеризированные часы — Seiko Data-2000 и Seiko UC-2000. Data-2000 имели возможность хранить 2КБ заметок, их нужно было вводить с помощью специальной компактной клавиатуры, которая шла в комплекте. UC-2000, по сути, те же Data-2000 с корпусом другого цвета, но они уже позиционировались как часть Наручной Информационной Системы, которая, среди прочего, включала терминал UC-2200, который представлял из себя компьютер с Z80-совместимым процессором, интерпретатором Бэйсика и термопринтером, но без экрана, в качестве которого использовались часы (как это не странно). Среди прочего, терминал давал возможность загружать на часы приложения со специальных картриджей. Подробнее о линейке ранних умных часов Seiko можно почитать, например, в этой статье. В этом же посте я расскажу, как написал (возможно) первую, за более чем 33 года, программу для этих часов.

Заметка о часах в журнале Popular Science 84 года, на левой нижней фотографии представлена вся периферия.

Небольшое введение

О UC-2000 я узнал пару лет назад, примерно тогда же оставил такой комментарий на GT. С тех пор меня не покидала мысль купить часы и попытаться для них что-то написать. Изначально я склонялся к покупке Epson RC-20, но они настолько редкие, что за это время я видел только одно предложение на Ebay которое по глупости упустил. В итоге, мне надоело ждать и я купил гораздо более доступные UC-2000, без терминала и клавиатуры, которые для моих целей были не нужны. На самом деле, конечно, мне пришлось бы покупать док-станцию, для того чтобы снять дамп ПЗУ из картриджа с приложениями и понять работу беспроводного интерфейса который часы использовали для связи с периферией. Но, к моему счастью, эту работу сделал один человек еще в 2002 году, у него был проект по созданию собственных электронных часов, а у Seiko он хотел позаимствовать экран. Не знаю чем закончилась его работа, но то, что опубликовано у него на сайте, мне очень помогло. Этот человек (к сожалению, не знаю его имени) опубликовал приложения с комплектного картриджа, описал протокол беспроводного индуктивного интерфейса, а также написал приложение, во многом реализующее функционал терминала.

Итак, имея эти вводные, я выписал часы и приступил к поиску информации. Тут надо уточнить, что я не силен ни в ассемблере (за всю жизнь до этого написал на нем, может быть, полторы программы) ни, тем более, в электронике, но как обычно бывает, отсутствие знаний компенсировалось большим желанием. Из-за этого, мои методы и терминология могут показаться странными или вовсе быть ошибочными, надеюсь, в комментариях вы меня поправите.

Реверс-инжиниринг

Что же было известно об архитектуре этих часов?
Вот на этом рекламном постере, пожалуй, отображена вся доступная техническая информация:

4bit CPU, 6KB ROM, 1.5KB LCD ROM, 2KB RAM.
И все.

Фотографии внутренностей не дают какой-то дополнительной полезной информации — все микросхемы ожидаемо бескорпусные без какой-либо маркировки:

Сверху вниз, слева направо: катушка индуктивности используемая для беспроводного интерфейса и отсек для батареи; печатная плата с процессорным модулем на керамической подложке — 2 микросхемы, ЦПУ и ОЗУ; матричная ЖК панель — 4 строки по 10 символов, 5x7 точек каждый; обратная сторона платы — 4 микросхемы контроллера дисплея.

Ничего не остается, как попытаться вручную дизассемблировать программы со штатного картриджа, всего их 5:

• Amida — игра, японский лабиринт;
• Сard — карточная игра;
• Hit — игра, отстреливаемся от врагов;
• Race — симулятор тотализатора;
• Scheduler — ежедневник, единственное практичное приложение.

Судя по рекламе, был еще картридж, с Японско-Английским словарем, но видимо продавался он только на японском рынке, поэтому найти его не легко.

Если бы я раньше программировал контроллеры AVR на ассемблере, я бы сразу принял первые 14 пар байт за таблицу векторов прерываний, но я не программировал AVR на ассемблере, поэтому посчитал это просто неким набором вызовов подпрограмм, т.е. предположил, что:

• инструкции занимают 2 байта (это очевидно еще и потому, что четные байты часто повторяются, а нечетные носят гораздо более случайный характер);
• опкод находится в первом байте, а операнды во втором и, скорее всего, частично в первом;
• инструкции вида 0xC*** это команда CALL с адресом подпрограммы.

После этих 28 байт идет пара 0xB000, эта же инструкция встречается далее по всей программе, в том числе в самом конце (не считая последних двух байт, которые оказались просто неким индексом программы в ROM), я предположил, что это возврат из подпрограммы, команда RET.
Это все, что я понял из бинарных файлов после первого наскока, еще до приезда часов. Я пытался найти строковые константы, но, к моему удивлению, ничего похожего на нужные последовательности кодов символов найти не смог.
Тогда попытался зайти с другой стороны и начал смотреть наборы инструкций всех подряд 4-битных микропроцессоров и микроконтроллеров 70-80-ых годов до которых мог дотянуться гугл — ничего похожего. Я, по-моему, вообще не встретил ни одного 4-битного процессора с двухбайтовыми инструкциями постоянной длины. Была некоторая надежда на современные 4-битные контроллеры от Epson, думал, что их система команд могла восходить к началу 80-х, но нет, и тут ничего. В итоге, решено было ждать часы и действовать методом тыка.

Приехали часы, на скорую руку собрал такой передатчик:

С катушкой от первого подвернувшегося трансформатора не заработало, точнее работало только без задней крышки часов, со второй подвернувшейся катушкой удалось получить стабильную передачу. Для загрузки программ использовал немного модифицированное приложение опубликованное на sigma957.org.
В последствии, я намотал катушку и собрал передатчик на ATtiny85, более пригодный для практического применения:

Первым делом поигрался со всеми штатными приложениями, затем начал заменять подозрительные инструкции на 0x0000 (тогда я ошибочно предположил, что это NOP) и буквально через пару замен наткнулся на участок с выводом текста. В копилку добавил две инструкции, установка позиции курсора:

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

и непосредственно вывод символа:

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

Вот из-за этого интересного расположения битов и вышло то, что я не смог найти строки сразу.
Я был на седьмом небе, тут же написал «Hello world», который работал как-то странно из-за того, что я не понимал назначения таблицы переходов в заголовке, но это уже было что-то.

Дальше разобрался с адресацией команды CALL — оказалось, что подпрограммы, которые вызывают такие инструкции из заголовка, не заканчиваются на RET, как можно было бы предположить, а заканчиваются они вызовами подпрограмм из ПЗУ. Получается, я ошибся, инструкции вида 0xC*** больше похожи на безусловный переход JMP A:

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

а вызовом подпрограммы CALL A оказалась инструкция:

1010 AAAA AAAA AAAA

Дальше процесс опять застопорился. Уже можно было делить программу на отдельные блоки, функции которых были в целом понятны, например, можно было точно определить, что такой-то набор инструкций выводит счет в игре HIT, но вот понять что делает каждая инструкция мне никак не удавалось.
Потупив над hex'ами пару дней, решил воспользоваться старым добрым методом — выкидывать из программы все, что ее не ломает, таким образом максимально ее упростив, а параллельно изучать то, что ломает. Для препарирования я выбрал программу Scheduler, она имеет минимальный размер (код занимает только 2/3, оставшееся место используется для хранения 31-ой заметки по 20 символов) и выглядела она проще остальных.

Такая тактика сразу начала приносить плоды. Найдя подпрограммы обработки нажатий кнопок, стало понятно, что таблица в заголовке это переходы на адреса обработчиков событий (не прерываний), с этой таблицей я до сих пор до конца не разобрался, вот что на текущий момент мне известно:

Благодаря тем же обработчикам кнопок, которыми пользователь выбирал нужную заметку, идентифицировал инструкции сложения и вычитания — 0x221A и 0x2A1A, правда, еще не разобравшись с операндами. Затем был опознан один из условных переходов, опять же без операндов.

При этом программа практически полностью сохранила функционал работы с заметками. Как я позднее понял, были выпилены блоки ввода заметок с клавиатуры, различные проверки на граничные условия и тому подобный «избыточный» код. Оставшиеся подпрограммы я перетасовал в удобный для работы и компактный вид, благо инструкции переходов мне уже были известны. Компактность, кстати, была очень актуальна, т.к. передача 2048 байт на часы занимает порядка 30 секунд. Представьте процесс — обнуляем два байта, отправляем на часы, ждем 30 секунд, смотрим что получилось — если все сильно ломается, то возвращаем инструкцию, если не ломается то высматриваем следующую жертву и опять 30 секунд. Медленно, очень медленно. Поэтому с Scheduler'ом сокращенным до 512 байт работа пошла гораздо быстрее.

Дальнейшее тыканье палкой привело к пониманию того, что инструкциями 0x8AE4 0x8ADC 0x8AA0 в обработчике запуска программы задается адрес текущей заметки, их я интерпретировал как загрузку непосредственного значения в регистр LDI R, I

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

Теперь стало понятно, что у нас есть 32 четырехбитных регистра, к тому же маячившие по-всюду инструкции 0x3C00, 0x3C08, 0x3С10, 0x3C18 по некоторым признакам я принял за выбор текущего банка регистров, что в дальнейшем подтвердилось. Итого, имеем 4 банка по 32 регистра. Нахождение регистров было одним из ключевых моментов, после которого я действительно поверил в возможность дизасемблировать программы этих часов.

Расположившиеся рядом 0x8257 0x8236 0x8215 оказались инструкциями копирования регистров MOV Rd, Rs

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

После этого, я не без труда разобрался с операндами ранее найденных операций сложения и вычитания, это оказались операции над группами регистров ADM Rd, Rs и SBM Rd, Rs (M — от Multiple). Эти инструкции, оперирующие группами регистров, показали, что каждая банка регистров делится еще на 4 страницы по 8 регистров. Каждая инструкция, работающая с группами регистров, может оперировать любым количеством регистров в пределах страницы, при этом индексы начального и конечного регистра группы должны совпадать для обоих операндов. Я, наверно, не совсем понятно объясняю, поэтому попробую еще раз на картинке:

Получается, некоторые команды могут оперировать сразу 4-байтными значениями — неплохо для четырехбитного процессора. Для простоты использования групповых команд, я решил именовать регистры по типу RA0, RA1… RA7, RB0, RB1 и т.д. и т.п.

Итак, в целом синтаксис инструкций стал примерно понятен, осталось дело техники — формально описать как можно больше инструкций. Для этого, во-первых, я сделал список всех инструкций из штатных программ в двоичном виде и разделил его на группы по шести первым битам, так можно было сразу прикинуть, какими данными оперирует команда, например, если правый бит в группе всегда 0, то почти наверняка второй операнд является непосредственным значением. Во-вторых, к этому моменту я уже знал достаточно инструкций, чтобы написать в машинных кодах программу для часов, которая бы отображала текущие значения регистров всех банков — нажимаешь на одну кнопку — отображается значения регистров 0-го банка, на другую 1-го итп. Это была моя первая полезная программа для UC-2000!

Содержимое нулевого банка регистров

В процессе написания этой программы я ловил какие-то ужасные глюки со значением нулевого регистра каждого банка и никак не мог понять в чем дело. Как выяснилось, причина была в том, что я использовал 0x0000 в качестве NOP, а на самом деле это команда сложения регистров, т.е. я постоянно в разных местах складывал нулевой регистр сам с собой)
С этими двумя инструментами, через пару дней я уже формально описал более 40 инструкций. Много времени отнимали инструкции с нестандартным синтаксисом, типа INC и DEC.
Еще больше времени заняла инструкция с опкодом 010101, которая всегда шла первой в обработчиках кнопок и встречалась в некоторых других местах. Как оказалось, она копировала значение в регистр текущего банка из некоей группы регистров, которую я назвал регистрами ввода-вывода. Опытным путем установил, что этих регистров всего 16, описание назначения тех, что мне удалось понять в следующей таблице:

Еще, с помощью программы отображения значений регистров я выяснил, что первые два банка регистров используются внутренней программой часов, поэтому, по понятным причинам, в качестве регистров общего назначения лучше использовать только 2 и 3 банки.

Назначение регистров 0-го банка:

Во 1-м банке интересны только регистры RB0 — RB3, они используются для указания событий, на которые будет реагировать загруженная программа. Остальные регистры этого банка используются по-разному в разных режимах работы часов, поэтому я не стал их анализировать (хотя, конечно, там может быть что-то интересное)

Итогом всей этой работы стал набор из 61 формально описанной инструкции. К сожалению, мне не удалось восстановить все, что видно из таблицы (которая чуть ниже под спойлером), есть пробел на интервале 5800-5BFF, может быть, там спряталась одна или даже несколько инструкций. Есть очень специализированные команды, типа пикнуть пьезодинамиком, за ними, скорее всего, стоит что-то большее, я даже не стал давать имена таким инструкциям. Под вопросом NOP. Во многих инструкциях есть незначащие биты, помеченные мной как "-", на самом деле, конечно, некоторые могут влиять на что-то, что я упустил.

Набор инструкций

Много времени отнял подбор подходящих мнемоник, некоторые команды названы довольно некрасиво (особенно в середине таблицы), я сам же их постоянно забывал.

Тут я вплотную подошел к возможности писать приложения, но для этого очень нужен был ассемблер, писать что-то сложнее просмотра значений регистров в машинных кодах, когда размер опкодов и операндов не кратен байту, мягко говоря, не удобно.

Ассемблер

Я наивно предполагал, что существуют готовые реализации универсальных ассемблеров, в голове крутилось когда-то слышанное словосочетание «табличный ассемблер» по которому я и начал гуглить. Оказалось да, действительно, есть такой класс ассемблеров, называемых «table driven assembler», но я не смог найти ничего подходящего — это были либо давно заброшенные продукты из 90-х типа TDASM, либо современные сильно ограниченные проекты «на коленке». И это бы все ничего, но у всех этих табличных ассемблеров был серьезный недостаток — они имели каждый свою нотацию, которая прекрасно описывала инструкции процессоров из поддерживаемого списка, но никак не хотела описывать набор инструкций UC-2000: некоторые просто не могли работать с операндами не кратными байтам, некоторые не могли адресовать одновременно и байты и двухбайтовые команды и т.п.

Я уже склонялся к написанию своего предельно простого ассемблера, но наткнулся на axasm (статья с описанием автора). Кратко суть в том, что для описания инструкций используются макроподстановки С, за счет чего получается большая универсальность, а весь разбор кода ложится на препроцессор, нам остается только предварительно конвертировать код вида «MOV Rd, Rs» в MOV(Rd, Rs), для этого автор использует AWK, а автоматизируется весь процесс Bash-скриптом. При этом, конечно, у этого метода есть минусы — невозможно на одну ассемблерную команду повесить несколько инструкций, под Windows придется использовать MinGW (хотя можно конечно все переписать, но мне было лень), ну и вообще, все это довольно громоздко.

Итак, сделал описание известных мне команд для axasm и дело пошло гораздо лучше, не хватало только дизассемблера для удобного разбора штатных приложений, что я быстро исправил написав свой совсем простенький, но полностью функциональный.
К тому времени я уже описал большинство инструкций, и можно было браться за написание чего-нибудь «серьезного».

Программирование

В качестве первой программы я опять выбрал Тетрис.

Конечно, никаких иллюзий на счет возможностей 4-битного процессора в электронных часах 83 года я не питал, но все равно был неприятно удивлен отсутствию казалось бы элементарных команд:

• Нету битового сдвига! Ни в каком виде. Вроде бы, базовая операция, отсутствие которой многое усложняет. Левый сдвиг, допустим, можно заменить сложением регистра самого с собой, но вот чем заменить правый сдвиг?(
• Нет ни одной логической операции над двумя регистрами! AND, OR и XOR только регистра с непосредственным значением. Да что уж там, нет даже отрицания.
• Ни в одной команде нельзя использовать косвенную адресацию регистров, это наверно не сильно удивительно, но сильно неудобно.
• Глубина стека вызова подпрограмм всего 3 уровня, это тоже не удивительно, но я, не привыкший к таким ограничениям, сначала ловил непонятные зависания программы и долго не мог понять в чем дело.

Вот, например, как пришлось извращаться для реализации дизъюнкции двух регистров 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 бита

А ведь каждая инструкция отнимает у нас 2 байта из 2048, кошмар.

Зато все арифметические команды имеют аналоги с десятичной коррекцией. Это наводит на мысль, что микропроцессор изначально разрабатывался и использовался инженерами Seiko-Epson для чего-то типа часов с функцией калькулятора и уже потом был адаптирован для UC-2000.

Еще одним неприятным сюрпризом, для меня, было отсутствие доступа к отдельным пикселям дисплея, хотя фотографии часов, на которых видно, что время отображается нестандартными символами цифр, занимающими сразу два знакоместа, казалось, намекают на такую возможность. Правда, как только я увидел таблицу символов, никаких иллюзий не осталось — половинки цифр просто отдельные символы.
Поэтому, для Тетриса пришлось использовать символы псевдографики, благо их достаточно, чтобы используя символы "█", "▀", "▄" и " " разбить экран на 8x10 «пикселей», игровое поле получается примерно таким:

«Стакан» повернут и занимает весь экран, но даже так, конечно, сильно не дотягивает до классических 10x20 клеток.

Не смотря на этот ограниченный набор инструкций, Тетрис уместился в 700 байт, хотя, когда я только приступил к нему, опасался, что не уложусь и в 2 КБ.

        ;Даем регистрам более подходящие имена
        ##define brdAdr RA2 
        ##define brdValTop RA3  
        ##define brdValBtm RA4  
        ##define ind RA5    
        ##define drawLine RA6
        ##define appState RA7
        
        ##define curLine RB0
        ;9, 10
        ##define preLine RB3
        ##define scoresL RB4
        ;13, 14
        ##define scoresH RB7
        
        ##define piceAngle RC0
        ##define piceNum RC1
        ##define piceSelecter RC2
        ##define piceShift RC3
        ##define scoresAddL RC4
        ;21;22
        ##define scoresAddH RC7
        ##define curPosL RC4
        ##define curPosH RC5
        
        ##define piceLn0t RD0
        ##define piceLn0b RD1
        ##define piceLn1t RD2
        ##define piceLn1b RD3
        ##define piceLn2t RD4
        ##define piceLn2b RD5
        ##define piceLn3t RD6
        ##define piceLn3b RD7
        
        ;Вычисляем адрес игрового поля
	##define brdAdr2b (((board*2)>>8) & 0x0F)
	##define brdAdr1b (((board*2)>>4) & 0x0F)
	##define brdAdr0b (((board*2)   ) & 0x0F)
        
        ;Вычисляем адрес фигур
	##define picesAdr2b (((pices*2)>>8) & 0x0F)
	##define picesAdr1b (((pices*2)>>4) & 0x0F)
	##define picesAdr0b (((pices*2)   ) & 0x0F)

        ORG 0 
    
        ;Таблица переходов на обработчики событий
        JMP start                         ;Адреса обработчиков нужных событий
        JMP timer
        JMP 0x11A                         ;или адреса штатных обработчиков для ненужных событий
        JMP 0x109
        JMP 0x0E0
        JMP btn_mode
        JMP btn_transm
        JMP btn_right
        JMP btn_left
        JMP 0x2A9
        JMP 0x307
        JMP 0x39C
        JMP 0x09B
        JMP update_screen
        RET

        ;Обработчик запуска приложения
start:
        CLRM RB1, RB3%8
        LDI RB2, 0xF                      ;Подписываемся на события нажатия всех 4-х кнопок
        LCRB B2
        LDI appState, 1
        JMP 0x227                         ;Все обработчики должны завершаться переходом на определенные адреса 
    
        ;Обработчик нажатия MODE
btn_mode:
        CPJR RB3, 0, btn_mode_startapp    ;Если приложение уже запущено, то отписываемся от всех событий
        CLRM RB1, RB3%8                   ;иначе обработчики так и будут вызываться даже после "выхода" из программы
        JMP 0x243
    btn_mode_startapp:
        LDI RB3, 8                        ;А если запуск только произошел то подписываемся на таймер
        LDI RB1, 1                        ;и перерисовку экрана
        JMP 0x243

        ;Обработчик TRANSMIT
btn_transm:
        LARB B3
        LCRB B2
        ADI piceAngle, 4                  ;Поворачиваем фигуру
        JMP update_screen
    
        ;Обработчик правой кнопки
btn_right:
        LARB B3
        LCRB B2
        CPJR appState, 2, btn_right_c1
        CALL prepareNewGame
        JMP 0x2DF
    btn_right_c1:
        INC piceShift, piceShift%8        ;Перемещаем фигуру вправо
        JMP 0x2DF
    
        ;Обработчик левой кнопки
btn_left:
        LARB B3
        LCRB B2
        DEC piceShift, piceShift%8        ;Перемещаем фигуру влево
        JMP 0x383
    
        ;Обработчик секундного таймера
timer:
        LARB B3
        LCRB B2
        CPJR appState, 2, timer_draw
        CPJR appState, 3, timer_clear_lines_screen
        JMP 0x190
    timer_clear_lines_screen:
        LDI appState, 2                   ;Возвращаемся к игре после отображения очков
        JMP update_screen
    timer_draw:
        INC curLine, curLine%8            ;Падение фигуры
        JMP update_screen
    
update_screen:
        LARB B3
        LCRB B2
        CPJR appState, 2, update_screen_draw
        PLAI 125                          ;Очищаем
        STLI 0                            ;экран
        CPJR appState, 0, update_screen_gover
        CPJR appState, 3, update_screen_clear_lines
    update_screen_start:
        PLAI 12
        PSAI STR_TETRIS                   ;Пишем TETRIS на заставке
        CALL OS_PRINT0-6                  ;используя функцию внутренней программы часов
        JMP 0x98F
    update_screen_gover:
        PLAI 10                           ;GAME OVER
        PSAI STR_GAMEOVER
        CALL OS_PRINT0-10
        JMP update_screen_print_scores
    update_screen_clear_lines:
        PLAI 10                           ;После каждой сброшенной линии
        PSAI STR_SCORE                    ;на секунду показываем заработанные очки
        CALL OS_PRINT0-8
        STL scoresAddL+1
        STL scoresAddL
        PSAI STR_TOTAL
    update_screen_print_scores:
        CALL OS_PRINT0-6                  ;Выводим Total
        STL scoresH                       ;и
        STL scoresH-1                     ;общее
        STL scoresH-2                     ;количество
        STL scoresL                       ;очков
        JMP 0x98F
    update_screen_draw:
        CALL updatePice                   ;Обновляем состояние фигуры
        CALL draw                         ;и все перерисовываем
        JMP 0x98F

        ;Инициализация новой игры
prepareNewGame:
        CALL OS_CLRCB
        LDI appState, 2
        LDI brdAdr, brdAdr2b
        LDI brdAdr-1, brdAdr1b
        LDI brdAdr-2, brdAdr0b
        PSAM brdAdr-2, brdAdr%8 
        CLRM scoresL, scoresH%8
        CLRM brdValTop, brdValBtm%8
        LDI ind, 10
    prepareNewGame_loop:
        STSM brdValTop, brdValBtm%8
        DEC ind, ind%8
        JNC prepareNewGame_loop
        
        ;Подготовка новой фигуры
prepareNewPice:
        CLRM curLine, preLine%8
        LDI piceShift, 2
    prepareNewPice_random:
        IN piceAngle, 14
        ADD piceNum, piceAngle
        CPI piceNum, 7
        JNC prepareNewPice_random
        LDI piceAngle, 0
        CMP scoresAddL, scoresAddL+1
        JZ updatePice
        ADBM scoresL, scoresAddH
        LDI appState, 3
        JMP update_screen
    
        ;обновляем фигуру
updatePice:
        LDI brdAdr, picesAdr2b
        LDI brdAdr-1, picesAdr1b
        LDI brdAdr-2, picesAdr0b
        ADM brdAdr-2, piceSelecter
        PSAM brdAdr-2, brdAdr%8 
        LDSM piceLn0t, piceLn0b%8
        LDSM piceLn1t, piceLn1b%8
        LDSM piceLn2t, piceLn2b%8
        LDSM piceLn3t, piceLn3b%8
    
        ;двигаем фигуру влево-вправо
shiftPice:
        MOV ind, piceShift
    shiftPice_loop:
        CPJR ind, 0, shiftPice_end
        ADM piceLn0t, piceLn3b            ;Замена левого сдвига на сложение регистра самого с собой
        BTJR piceLn1t, 0, +4              ;По ходу движения проверяем выход фигуры
        BTJR piceLn2t, 0, +3              ;за левую границу
        BTJR piceLn3t, 0, +2              ;игрового поля
        DEC ind, ind%8
        JMP shiftPice_loop
        JMP processCollision
    shiftPice_end:
  
        CPI preLine, 15
        JNZ checkCollision
        ;Объединяем упавшую фигуру с содержимым игрового поля и сохраняем полученное в board
storePice:
        LDI brdAdr, brdAdr2b
        LDI brdAdr-1, brdAdr1b
        LDI brdAdr-2, brdAdr0b
        ADM brdAdr-2, curLine+2
        CLRM scoresAddL, scoresAddH%8
    
        LDI ind, 3
    storePice_loop:
        PSAM brdAdr-2, brdAdr%8 
        LDSM brdValTop, brdValBtm%8
        
        XORI piceLn0t, 0xF                ;ужасный OR двух пар регистров  
        XORI piceLn0b, 0xF
        BTJR piceLn0t, 0, +1
        ORI brdValTop, 1
        BTJR piceLn0t, 1, +1
        ORI brdValTop, 2
        BTJR piceLn0t, 2, +1
        ORI brdValTop, 4
        BTJR piceLn0t, 3, +1
        ORI brdValTop, 8
        BTJR piceLn0b, 0, +1
        ORI brdValBtm, 1
        BTJR piceLn0b, 1, +1
        ORI brdValBtm, 2
        BTJR piceLn0b, 2, +1
        ORI brdValBtm, 4
        BTJR piceLn0b, 3, +1
        ORI brdValBtm, 8
        
        PSAM brdAdr-2, brdAdr%8 
        STSM brdValTop, brdValBtm%8
        
        CMP piceLn0t, piceLn0b            ;заодно проверяем нет ли заполненных линий
        JZ storePice_loop2_end
        CPI brdValTop, 0xF
        JNZ storePice_loop2_end
        CPI brdValBtm, 0xF
        JNZ storePice_loop2_end
        MVACM brdAdr-2, brdAdr%8
        ADBM scoresAddL, scoresAddH       ;и подсчитываем
        INCB scoresAddL, scoresAddH%8     ;очки если есть
    storePice_loop2:
        DEC brdAdr-2, brdAdr%8            ;и удаляем заполненные линии
        PSAM brdAdr-2, brdAdr%8 
        LDSM brdValTop, brdValBtm%8
        STSM brdValTop, brdValBtm%8
        CPJR brdValBtm, 0, +1
        JMP storePice_loop2
        CPJR brdValTop, 0, +1
        JMP storePice_loop2
        MVCAM brdAdr-2, brdAdr%8
    storePice_loop2_end:
      
        LSHM piceLn3b, 0
        LSHM piceLn3b, 0
        
        INC brdAdr-2, brdAdr%8
        DEC ind, ind%8
        JNC storePice_loop
    
        JMP prepareNewPice
    
        ;проверяем столкновение фигуры с содержимым игрового поля
checkCollision:
        LDI brdAdr, brdAdr2b
        LDI brdAdr-1, brdAdr1b
        LDI brdAdr-2, brdAdr0b
        ADM brdAdr-2, curLine+2
        PSAM brdAdr-2, brdAdr%8 
        
        MVACM piceLn0t, piceLn3b
        LDI ind, 4
    checkCollision_loop:
        LDSM brdValTop, brdValBtm%8
       
    checkCollision_loop2:
        CMP piceLn0t, piceLn0b
        JZ checkCollision_end2
        ADM piceLn0t, piceLn0b
        JC checkCollision_compare
        ADM brdValTop, brdValBtm
        JMP checkCollision_loop2
    checkCollision_compare:
        ADM brdValTop, brdValBtm
        JC processCollision
        JMP checkCollision_loop2
    checkCollision_end2:
        
        LSHM piceLn3b, 0
        LSHM piceLn3b, 0
        DEC ind, ind%8
        JNZ checkCollision_loop
        MVCAM piceLn0t, piceLn3b    
        
        MVACM piceAngle, piceShift        ;сохраняем валидную
        MOV preLine, curLine              ;позицию фигуры
        RET

        ;обрабатываем столкновение
processCollision:
        CPJR curLine, 0, gameOver
        CMP curLine, preLine
        JZ processCollision_pre
        MOV curLine, preLine              ;восстанавливаем валидную позицию фигуры
        LDI preLine, 15                   ;маркер, что фигура уперлась в пол и нужна новая
        processCollision_pre:
        MVCAM piceAngle, piceShift        ;восстанавливаем валидную позицию фигуры
        JMP updatePice

        ;конец игры
gameOver:
        LDI appState, 0
        JMP update_screen

        ;рисуем игровое поле
draw:
        LDI brdAdr, brdAdr2b
        LDI brdAdr-1, brdAdr1b
        LDI brdAdr-2, brdAdr0b
        PSAM brdAdr-2, brdAdr%8           ;Указываем на адрес игрового поля
        MVAC curLine, curLine             ;Копированием в дополнительный банк удобно бэкапить регистры
        LDI curPosL, 0xE                  ;Значение регистров с позицией экранного курсора
        LDI curPosH, 0x1                  ;на 4 строку первого столбца
    
        LDI ind, 0
    draw_loop0:                           ;проходим поочередно все строки игрового поля сверху вниз [...]
        LDSM brdValTop, brdValBtm%8       ;Загружаем регистры brdValTop и brdValBtm первой строкой игрового поля,
                                          ;указатель после этого перейдет на следующий байт автоматически
        CMP curLine, ind                  ;если фигура пересекается с текущей отображаемой строкой то рисуем и ее
        JNZ draw_ORend
        XORI piceLn0b, 0xF                ;еще один ужасный OR
        XORI piceLn0t, 0xF
        BTJR piceLn0b, 0, +1
        ORI brdValBtm, 1
        BTJR piceLn0b, 1, +1
        ORI brdValBtm, 2
        BTJR piceLn0b, 2, +1
        ORI brdValBtm, 4
        BTJR piceLn0b, 3, +1
        ORI brdValBtm, 8
        BTJR piceLn0t, 0, +1
        ORI brdValTop, 1
        BTJR piceLn0t, 1, +1
        ORI brdValTop, 2
        BTJR piceLn0t, 2, +1
        ORI brdValTop, 4
        BTJR piceLn0t, 3, +1
        ORI brdValTop, 8
        LSHM piceLn3b, 0                  ;Вместо отсутствующей косвенной адресации регистров, сдвигаем регистры с фигурой
        LSHM piceLn3b, 0                  ;на байт влево на каждом шаге цикла, и получаем нужное значение всегда в piceLn0t-piceLn0b
        CMP piceLn0t, piceLn0b
        JZ draw_ORend
        INC curLine, curLine%8  
    draw_ORend:
   
        CPJR ind, 0, draw_b1
    draw_loop1:                           ;[...] слева направо
        PLAM curPosL, curPosH%8           ;устанавливаем экранный курсор на нужную позицию
        BTJR brdValBtm, 2, +5
        BTJR brdValBtm, 3, +2
        STLI 0x20                         ;и 
        JMP draw_else2
        STLI 0xE8                         ;рисуем
        JMP draw_else2
        BTJR brdValBtm, 3, +2
        STLI 0xE7                         ;подходящий
        JMP draw_else2
        STLI 0xFF                         ;символ
    draw_else2: 
        ADM brdValTop, brdValBtm          ;Сдвигаем текущую строку игрового поля на 2 бита
        ADM brdValTop, brdValBtm          ;т.к. каждое знакоместо у нас отображает состояние 2 бит
        SBI curPosL, 0xA                  ;Вот так сложно на
        JNC draw_loop1                    ;4-битном процессоре
        DEC curPosH, curPosH%8            ;вычесть 10
        JNC draw_loop1                    ;у пары регистров (так переходим к предыдущей строке на экране)
    
        LDI curPosH, 0x1                  ;после того, как нарисовали линию
        ADI curPosL, 0x9                  ;возвращаем курсор опять на 4 строку
        JNC draw_b1                       ;но уже на
        INC curPosH, curPosH%8            ;следующее знакоместо
    draw_b1:
    
        INC ind, ind%8                    ;переходим к следующей строке игрового поля
        CPI ind, 11                       ;если еще не все
        JNZ draw_loop0
        
        MVCA curLine, curLine             ;восстанавливаем curLine
        RET
    
        ;Область данных
STR_TETRIS:
        DS "TETRIS"
        
STR_GAMEOVER:
        DS "GAME OVER!"
        
STR_SCORE:
        DS "Score  +"
        
STR_TOTAL:
        DS "Total "
    
        ;игровое поле, каждая строка аккуратно умещается в байт
board:
        DB 0b00000000
        DB 0b00000000
        DB 0b00000000
        DB 0b00000000
        DB 0b00000000
        DB 0b00000000
        DB 0b00000000
        DB 0b00000000
        DB 0b00000000
        DB 0b00000000
        DB 0b00000000
        DB 0b11111111
    
        ;Фигуры вместе с поворотами
        ;Конечно, сильно избыточно, но при этому получается очень удобно:
        ;на адресацию каждой фигуры нужно использовать минимум 3 полубайта (в 3-х регистрах),
        ;при этом, просто сложив младший полубайт с 4 мы меняем поворот фигуры,
        ;а инкрементируя средний меняем фигуру.
        ;Красиво и никаких проверок выхода за границы и прочих усложнений кода.
pices:
        DB 0b00000000 ;o 0°
        DB 0b00000011
        DB 0b00000011
        DB 0b00000000
        DB 0b00000000 ;o 90°
        DB 0b00000011
        DB 0b00000011
        DB 0b00000000
        DB 0b00000000 ;o 180°
        DB 0b00000011
        DB 0b00000011
        DB 0b00000000
        DB 0b00000000 ;o 270°
        DB 0b00000011
        DB 0b00000011
        DB 0b00000000
        DB 0b00000000 ;I 0°
        DB 0b00001111
        DB 0b00000000
        DB 0b00000000
        DB 0b00000001 ;I 90°
        DB 0b00000001
        DB 0b00000001
        DB 0b00000001
        DB 0b00000000 ;I 180°
        DB 0b00001111
        DB 0b00000000
        DB 0b00000000
        DB 0b00000001 ;I 270°
        DB 0b00000001
        DB 0b00000001
        DB 0b00000001
        DB 0b00000000 ;s 0°
        DB 0b00000011
        DB 0b00000110
        DB 0b00000000
        DB 0b00000010 ;s 90°
        DB 0b00000011
        DB 0b00000001
        DB 0b00000000
        DB 0b00000000 ;s 180°
        DB 0b00000011
        DB 0b00000110
        DB 0b00000000
        DB 0b00000010 ;s 270°
        DB 0b00000011
        DB 0b00000001
        DB 0b00000000
        DB 0b00000000 ;z 0°
        DB 0b00000110
        DB 0b00000011
        DB 0b00000000
        DB 0b00000001 ;z 90°
        DB 0b00000011
        DB 0b00000010
        DB 0b00000000
        DB 0b00000000 ;z 180°
        DB 0b00000110
        DB 0b00000011
        DB 0b00000000
        DB 0b00000001 ;z 270°
        DB 0b00000011
        DB 0b00000010
        DB 0b00000000
        DB 0b00000000 ;L 0°
        DB 0b00000111
        DB 0b00000100
        DB 0b00000000
        DB 0b00000010 ;L 90°
        DB 0b00000010
        DB 0b00000011
        DB 0b00000000 
        DB 0b00000001 ;L 180°
        DB 0b00000111
        DB 0b00000000
        DB 0b00000000
        DB 0b00000011 ;L 270°
        DB 0b00000001
        DB 0b00000001
        DB 0b00000000
        DB 0b00000000 ;J 0°
        DB 0b00000111
        DB 0b00000001
        DB 0b00000000
        DB 0b00000001 ;J 90°
        DB 0b00000001
        DB 0b00000011
        DB 0b00000000 
        DB 0b00000100 ;J 180°
        DB 0b00000111
        DB 0b00000000
        DB 0b00000000
        DB 0b00000011 ;J 270°
        DB 0b00000010
        DB 0b00000010
        DB 0b00000000
        DB 0b00000000 ;T 0°
        DB 0b00000111
        DB 0b00000010
        DB 0b00000000
        DB 0b00000010 ;T 90°
        DB 0b00000011
        DB 0b00000010
        DB 0b00000000 
        DB 0b00000010 ;T 180°
        DB 0b00000111
        DB 0b00000000
        DB 0b00000000
        DB 0b00000001 ;T 270°
        DB 0b00000011
        DB 0b00000001
        DB 0b00000000
        
        END

Итог: через три с небольшим недели, после получения посылки с часами, я уже смог поиграть в Тетрис на UC-2000:

В процессе написания Тетриса стало ясно, что обработчики событий вызываются всегда, пока они указаны в регистрах RB0-RB3 второго банка (о них я говорил выше), независимо от того, запущена программа или нет. Благодаря этому, можно полностью переделать функционал часов, просто рисуя то, что нужно поверх штатных режимов. Для демонстрации этого, я написал программу, которая добавляет к дефолтному циферблату 6 дополнительных, переключение между которыми происходит комбинацией левой кнопки + MODE. При этом, дополнительные циферблаты органично вписываются в работу остальных функций часов:

Одна из самых востребованных функций современных умных часов — пользовательские циферблаты, потенциально была доступна уже в 83 году, удивительно! Странно, что Seiko никак не развила это направление. И вообще, немного обидно, что потенциал этих часов остался так и не раскрытым полностью. Хотя, конечно, ничего странного в этом нет, из 2017 года все выглядит совсем не так, как из 83-го. Тем более, если вспомнить, сколько не очень успешных попыток изобрести умные часы было после них. Но это, как говорится, уже другая история.

Все описанное я опубликовал на GitHub'е.

Автор: Azya

Источник