Ретроконсоль MK-61s

Было время, когда меня захватила идея реализовать поддержку «Юникода» на «Флиппере Зеро». Я много тогда над этим работал и одна из вещей, которую я тогда делал — пытался ускорить измерение длины строки в кодировке «ЮТФ-8». Не то чтобы это было реальной проблемой, но мне хотелось этим заняться, вот я и занимался.

Тогда я познакомился с расширением DSP SIMD, которое помогает на армовских процессорах параллельно обрабатывать несколько значений одновременно. Вчера мне этот опыт пригодился.

Сейчас я занят ускорением работы встроенных в ретроконсоль «МК-61s» языков программирования — Бейсика и Фокала и вспомнил об этих инструкциях, так как процессор «MK-61s» их тоже поддерживает.

Чтобы измерять оптимизации я, как это у меня водится, портировал по эту задачу на ретроконсоль очередную игру. На этот раз шахматы Алана Тьюринга и Дэвида Чемперноуна (есть восстановленный алгоритм по мотивам их идей 1948 года). Нейросеть их перевела на Бейсик и это очень хороший тест, так как там очень много вычислений — первая версия делала ход за 162 секунды.

Шахматы Алана Тьюринга на виртуальном экран ретроконсоли «MK-61s»

Я занялся ускорением, так как по предложению одного из членов нашей команды, Алексея Сугоняева, перевёл интерпретаторы Бейсика и Фокала в трансляторы, формирующие специально разработанный байт-код, который затем и выполняется. Оказалось, что я неправильно понял его идею, но дело уже сделано, и этот подход принёс неожиданные преимущества.

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

Все низковисящие плоды в плане оптимизации я уже сорвал, остались довольно сложные вещи, типа джит-компиляции, но перед этим я хочу убедиться, что сделаны все более простые вещи. Вот тут я и вспомнил про SIMD.

«Юникода» в «MK-61s» уже нет — я недавно перевёл код на однобайтовую кодировку, но тем не менее есть что ускорить. Эксперименты показали, что эффект есть при трансляции, когда Бейсик и Фокал ищут пробельные символы и переводы строки, что немного ускоряет холодный старт программ:

К слову, оптимизированная версия Бейсика сейчас делает на холодную первый ход в шахматах за 104 секунды, а при прогретых кешах — за 87,5. Это пока всё равно медленно, но куда лучше 162 секунд, которые были в начале.

Что-то никак не оставляла меня мысль сделать более «честную» самораспаковывающуюся программу — без дополнительного регистра и чтобы умещалась в стандартную память калькулятора. Чтобы она работала в том гипотетическом сценарии, если бы авторы «Электроники МК-61» всё-таки позаботились доделать инструкции для работы с дополнительной памятью Ms.

В прошлый раз игра вместе с распаковщиком занимала диапазон в 110 ячеек, включая нестандартные адреса, которые есть только в ретроконсоли. Теперь весь образ помещается в 105 ячеек, нестандартный регистр Rf не используется, а начальные значения регистров устанавливает сама программа.

Больше всего удалось убрать из игровой части. Там были четыре отдельных вывода значений R1, R2, R3 и R9, каждый из двух команд: чтение регистра и остановка. Такие же выводы уже есть в распаковываемой части, нейросеть переназначила клетки карты на них. Это освободило восемь байт.

Сообщения о результате игры — числа 30 и 20 — теперь вводятся командами цифр. Каждый такой вывод стал на одну команду длиннее, зато для самих чисел больше не нужны регистры. Из восьми освобождённых байтов потратил два, после чего неизменяемый хвост игры сократился с 27 до 21 байта.

У распаковщика удалось убрать три команды: 8, x→П0 и X↔Y. Начальное значение счётчика теперь закодировано в первом числовом блоке упакованной программы. При обменах оно само попадает в R0, поэтому вводить и сохранять восьмёрку отдельными командами больше не требуется.

Чтобы отказаться от Rf, пришлось перенести хранившийся в нём шаг распаковки в Rd — регистр, где во время игры хранится здоровье. Во время распаковки здоровье ещё не нужно, а перед запуском игры его устанавливают две команды: 5 и x→Пd. Три команды ушло, две добавилось, в итоге распаковщик сократился с 20 до 19 байт.

Итого из игры и распаковщика удалось убрать семь команд. В новом расположении между распаковываемой частью и игровыми процедурами оставлены две пустые ячейки. Поэтому занимаемый диапазон сократился на пять ячеек: со 110 до 105.

Подготовку регистров удалось поместить в свободные места первых 63 ячеек. С адреса 08 выполняется цикл: в Rc записывается 9, затем значение Rc + 10 косвенно сохраняется в регистр с номером Rc, а счётчик уменьшается. Так R9–R1 получают необходимые для игры числа 19–11. Затем устанавливаются остальные начальные значения и адреса игровых процедур.

Эти значения перед распаковкой уже находятся в регистрах. Первый К ПВ сохраняет значения R0–R8 в Ms, последний возвращает их обратно. R9, Ra и Rb остаются на месте. Отдельных команд сохранения и восстановления не понадобилось. А сам код подготовки стирается при распаковке — его место занимает игра.

Для перехода к распаковщику нейросеть приспособила игровой переход в ячейке 35, заменив его на БП. До распаковки следующий байт содержит адрес 86. После распаковки там оказывается код 65 — П→x5, который для БП служит адресом 65. Поэтому процедура сбора детали теперь размещена именно там, для этого пришлось перед ней оставить две пустые ячейки. Один переход служит сначала подготовке, потом игре.

Для запуска нужно записать в память 79 ненулевых байт кода и данных. Сюда входит и код подготовки игровых регистров. Остальные ячейки должны быть обнулены. После распаковки игра размещается по адресам 00–85, распаковщик — в 86–104. Запуск начинается с 08, а после распаковки управление возвращается в 00. Ниже показано выполнение всего этого варианта.

Осталась одна нерешённая проблема: используется 63 байта Ms, доступных в «MK-61s», тогда как в исходном калькуляторе эта область рассчитана на 56 байт. Нынешнему распаковщику нужны девять блоков этой памяти, а в исходном калькуляторе их восемь. Поэтому для работы в таком гипотетическом «МК-61» программу ещё придётся доделать.

У меня была давно идея попробовать сделать самомодифицирующуюся программу на программируемом калькуляторе «Электроника МК-61». Ничего готового для этого там нет, но я надеюсь, что используя различные недокументированные возможности, этого можно добиться.

Своей цели я ещё не достиг, хоть и продолжаю пытаться, а пока экспериментирую с командами доступа в область Ms — это недоделанные команды, которые я разблокировал в ретроконсоли «MK-61s».

Там всего две команды — одна обменивает Ms с содержимым памяти, вторая с регистрами. Таким образом вырисовывается путь — меняем что-то в регистрах, выгружаем в Ms, оттуда — в память. Так как в «MK-61s» на один регистр больше, то и Ms пришлось расширить — теперь там может храниться не 56 шагов программы, как в настоящем калькуляторе, а 63.

Выглядит просто, но есть особенности — калькулятор хранит числа в особом формате и при переносе в программную память этот формат создаёт проблемы. Байтами команд становятся не только цифры числа, но и его знак и порядок. Поэтому записать в регистр какое-нибудь число и получить из него произвольную последовательность команд не получится — приходится подбирать числа под нужный код, а иногда и сам код под представление чисел.

Например, число 690050,68 после такого переноса даёт последовательность кодов 68 50 00 69 50 00. Для калькулятора это уже программа: прочитать регистр 8, остановиться, ввести ноль, прочитать регистр 9, снова остановиться и ввести ноль. Кроме этих шести байтов у каждого блока есть ещё один служебный байт, который команда обмена с регистрами не меняет. Его можно заранее заполнить нужной командой.

Теперь самое интересное: если вычесть из этого число 10000,01, получим 680050,67, а в памяти — 67 50 00 68 50 00. Команды остались прежними, но оба номера регистров уменьшились на единицу. Продолжая вычитать ту же константу, можно получить целую серию похожих участков программы.

Я решил попробовать использовать это для программы, которая не просто сама себя модифицирует, а, в идеале, сама себя распаковывает, то есть занимает меньше команд при вводе, чем в памяти.

Для этого я взял игру «The Land of Psycho Lamers» и переставил её код так, чтобы повторяющиеся участки укладывались в вышеупомянутый шаблон. Получился распаковщик длиной всего двадцать байт: он берёт начальное число и шаг, заполняет девять регистров, а затем двумя обменами переносит результат в программную память. Так восстанавливаются 63 байта команд.

Правда, тут надо честно посчитать всё остальное: исходные числа, заранее расставленные служебные байты и код подготовки. С учётом этого выигрыш получился скромным — 75 загружаемых байт против 80 у исходной игры. Это если в обоих случаях не загружать нули. Сам текстовый файл стал даже больше, да и занимаемый диапазон программной памяти вырос. Так что до практичного архиватора далеко, но работающая игра, которая сама собирает часть своего кода из чисел, уже получилась.

Ниже можно пройти распаковку по шагам. Хорошо видно, как сначала исходные данные уходят в Ms, затем из чисел строятся будущие команды, а в конце они одним обменом появляются в основной памяти.

Как и во всех остальных случаях, специально чтобы оттестировать новые команды, я перенёс на «MK-61s» игру. У меня это уже проверенный метод для разных интерпретаторов, который даёт хорошие результаты — и баги становится проще найти, и оценить насколько удобно использовать сами команды

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

Безусловно, графику оригинальной игры, как ни расширяй калькулятор, тут не повторить, но можно реализовать больше логики и кодировать происходящее в игре более понятным образом.

Заставка «Элиты» на двенадцатиразрядном индикаторе

Как первый результат расширенных команд вывода на экран — на индикаторе теперь можно вывести заставку и подписать, что игра ожидает нажатия кнопки C/П для старта. Всё это выводится в стандартных двенадцати знакоместах, просто нестандартным образом.

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

Имя начального мира

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

Имена при этом несут двойную функцию. Они связаны с устройством мира, в том числе с торговлей, поэтому постепенно можно научиться узнавать полезные места.

Торговля устроена просто: смотрим цены, покупаем товар, выбираем соседний мир, летим, продаём. Топливо, которое лежит в трюме, — товар, бак заправляется отдельно.

Цена еды: слева номер товара, справа цена, про «СП» я уже рассказывал

С управлением получилось по-калькуляторному: вводишь номер действия и нажимаешь С/П. Например, 10 показывает цену еды, 30 покупает одну единицу, а 40 продаёт. Для остальных товаров меняется последняя цифра. Во время ввода предыдущая картинка остаётся на экране, набираемый код её не затирает.

Состояние корпуса, щита, бака, нагрев и заполнение трюма показываются ещё и шкалой из пяти секций. Точное значение остаётся рядом: шкала нужна, чтобы с первого взгляда понять, много у тебя осталось или мало.

Состояние корпуса: шкала и точное значение

Бои пошаговые. За один ход выбираешь и манёвр, и действие: сблизиться или отойти, выстрелить из лазера или пустить ракету, восстановить щит или готовить бегство. Это снова две цифры: первая отвечает за движение, вторая — за действие. Можно, например, отходить и одновременно заряжать прыжок.

Это, конечно, самое слабое место, калькулятор есть калькулятор, буквенного ввода нет, а цифры запомнить куда сложнее.

Дистанция имеет значение: лазер не достаёт до далёкой цели, а вблизи стреляет сильнее. Кроме того, он ещё и греется. Ракет мало, щит держит конечно количество ударов, так что бесконечно повторять одну и ту же команду не получится.

Схема дистанции в бою: свой корабль и противник

Для расстояния я сделал отдельную схему: U («you») обозначает наш корабль, H («hostile») — противника, а точка отмечает границу, до которой достаёт лазер. Так посмотреть приборы или выбрать цель можно без расходования хода.

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

Носитель и дроны на одном индикаторе

Маленькие кольца слева показывают живых дронов. Правее — выбранная цель и её оставшаяся броня. Для носителя это H, для дрона — его номер. То есть даже в двенадцать знакомест помещаются несколько противников, выбор цели и число, которое помогает решить, стоит ли тратить на неё ракету.

После уничтожения всех противников: YES. CLEAr

Победу я обозначил надписью «YES, CLEAr» . За победу дают награду, после сражения можно закончить перелёт и вернуться к торговле.

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

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

Игра и короткая инструкция лежат в репозитории. Нужна свежая прошивка с новыми командами; открываешь папку ELITE на устройстве, закрываешь памятку и нажимаешь С/П. Пока не решил стоит ли делать сохранения. С одной стороны это логичный следующий шаг, с другой стороны уже слишком далеко отходит от исходной идеи.

Как я писал два дня назад, мне стало интересно пофантазировать на тему, как бы я расширил калькулятор «Электроника МК-61», если бы мне поручили доработать его под написание игр. Я решил, что нарастил бы ему память и позволил бы программисту гибче управлять выводом на экран.

Правда, я думал, что добавлю всего несколько команд, заняв неиспользуемые коды калькулятора, но когда начал писать программу для теста, оказалось, что набор надо расширять серьёзно, иначе быстродействие программ будет крайне низким, «МК-61» и так-то производительностью не отличается.

Поэтому пришлось расширять команды по префиксному типу — код 1F используется как префиксный для работы с новыми банками памяти, а 2F — для работы с экраном.

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

Поскольку экран «МК-61» заменить в те годы было не на что, я бы оставил его тем же, но сделал бы две вещи.

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

Во-вторых, позволил бы программисту управлять каждым сегментом двенадцатиразрядного индикатора. Это даёт возможность выводить какое-то подобие букв и рисунков. Весь алфавит так не выведешь, но некоторые буквы и знаки — запросто.

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

И, конечно, стоит подумать об расширении памяти. Тут действительно настоящая проблема. Ретроконсоль «МК-61s» уже давно умеет в специальном режиме добавлять к традиционным 105 байтам ещё семь практически без нарушения обратной совместимости, а недавно в ней появились даже новые команды для работы с областью памяти Ms, которая была предусмотрена в калькуляторе «Электроника МК-61», но ранее не использовалась. Однако и этого всё равно недостаточно.

Поэтому я добавил этой памяти ещё несколько дополнительных банков, выделив префикс 1F для переключения. Сначала я думал, что обойдусь одной командой вызова подпрограммы, но оказалось, что для программирования это неудобно, так что в этом наборе появились еще циклы и команды условных переходов.

В итоге в расширенном режиме теперь доступно: 112 байт обычной памяти, резерв Ms в 63 байта (в обычном калькуляторе там 56 байт, но тут пришлось расширить из-за добавленного регистра Rf, который есть в «MK-61s»), плюс 31 банк памяти по 112 байт каждый. Всего 3647 байт.

Правда, сами команды удлинились — новые команды занимают от двух до четырёх ячеек. Самые длинные — команды перехода по адресу: префикс, код команды, выбор банка и адрес ячейки. Я теории их можно сократить, но тогда придётся жёстко завязаться на количество банков, а мне бы этого не хотелось.

Я на днях под влиянием книги «Сфера-80…», про которую недавно рассказывал, решил пофантазировать, как можно было бы гипотетически расширить «Электронику МК-61», если бы я, подобно герою книги, попал в то время и мне бы довелось его разрабатывать.

Поскольку этот калькулятор изначально не задумывался для игр, однако для него написано более шестисот игр, которые были опубликованы, и неизвестно сколько ещё пропало, мысли мои пошли в сторону того, что именно я бы добавил туда, чтобы на нём было интереснее играть.

Расширил набор команд двумя префиксами, в другой раз покажу какими, а для тестирования, как водится, написал при помощи нейросети игру — простой клон известной «Элиты». Для «МК-61» это не диковинка — в моём каталоге их четыре штуки, но тут новый уровень.

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

Вспомнил, конечно, про Base64, а также более редкий Base85, но оказалось, что есть ещё чуть более экономный формат Base91. Я, вроде, про него слышал, но крепко про него забыл. Все они, по сути, решают одну проблему — кодируют бинарную информацию так, чтобы её можно было хранить внутри текстовых файлов.

Самый простой вариант — шестнадцатеричная запись. Каждый байт превращается в два символа от 00 до FF. Это очень удобно для человека: файл можно открыть в редакторе, посмотреть и при некотором опыте даже что-нибудь исправить. Но за удобство приходится платить — размер данных увеличивается ровно вдвое.

Base64 работает экономнее. Он собирает три байта, то есть 24 бита, и превращает их в четыре символа по шесть бит каждый. Отсюда и название: шесть бит позволяют выбрать один из 64 символов. Размер файла при этом вырастает примерно на треть.

Base85 упаковывает четыре байта в пять символов. Тут уже нет такого красивого соответствия битам, зато 85⁵ чуть больше 2³², поэтому любой четырёхбайтовый блок в эти пять символов помещается. Накладные расходы уменьшаются до 25%.

Алгоритм, который обычно называют Base91, на самом деле называется «basE91» — именно так, с заглавной «E» посередине. Его написал Йоахим Хенке. В качестве алфавита он взял почти все печатные символы ASCII, кроме дефиса, апострофа и обратной косой черты.

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

Зато хорошо работают пары символов.

В двух символах Base91 гарантированно помещаются 13 бит, причём после этого остаётся ещё 89 незанятых комбинаций. Автор алгоритма решил их не выбрасывать.

Обычно очередная пара символов хранит 13 бит. Но если значение этих бит попадает в диапазон от 0 до 88, кодировщик прихватывает ещё один, четырнадцатый бит. Для каждого из 89 маленьких значений получается две версии: с нулём и единицей в дополнительном бите. Декодер по получившемуся числу понимает, сколько бит надо забрать из входного потока — 13 или 14.

В исходном коде вся эта математика превращается в очень короткую проверку:

(v & 8191) > 88 ? 13 : 14

Без объяснения числа «88» и «8191» выглядят как магические константы. На самом деле первое число это те самые 89 оставшихся комбинаций, только нумерация начинается с нуля, а «8191» — это 2¹³ − 1, или тринадцать единиц в двоичной записи для выделения тринадцати младших бит.

Из-за такого устройства размер результата зависит от содержимого. В худшем случае Base91 добавляет около 23%, а на данных с большим количеством нулевых байтов накладные расходы могут уменьшаться примерно до 14%. Для обычного смешанного бинарного потока получается около 22,97%.

Если взять тысячу байтов, то без учёта заголовков и переносов строк выйдет примерно так:

• шестнадцатеричный формат — 2000 символов;
• Base64 — 1336;
• Base85 — 1250;
• Base91 — обычно около 1230.

То есть по сравнению с Base85 выигрыш совсем небольшой — около двадцати символов на килобайт. Зато по сравнению с исходным шестнадцатеричным форматом файл уменьшается почти на 40%.

Для обычной программы «МК-61» размером 105 байтов цифры  такие: 210 символов в шестнадцатеричном виде, 140 в Base64, примерно 132 в Base85 и около 129 в Base91. Всего три символа выигрыша у Base85, зато 81 — у старого формата. На одной программе можно было бы не обращать внимания, но на большой игре и целом каталоге разница постепенно накапливается.

У меня программа получилась побольше — несколько килобайт, мои расширения такое позволяют, поэтому я перед кодированием ещё и сжимаю программу уже испробованным алгоритмом «ZX0».

Вот так выглядит половина сжатой и закодированной «Элиты», половина, потому что из-за ограничений файловой системы она разбивается на 2 файла

Добавлено позже: один из читателей предложил вариант хранить программу в бинарном виде. Я такой вариант отбросил в самом начале, потому что мне больше нравилась идея всем управлять из текстового файла терминала, кроме того по расчётам тогда получалось, что в один файл всё равно всё не уместится.

Но я тогда не учитывал сжатие, плюс сама «Элита» была больше, я потратил немало токенов, чтобы её ускорить (первые версии рисовали экран секундами), а по пути она ещё и меньше стала. В общем, эту идею точно надо было рассмотреть.

В итоге, от команд  ztart и zin я избавился в пользу одной команды load, которая загружает сжатый заранее бинарный образ.

Сжег половину недельных токенов на задачу уменьшения размера прошивки для «МК-61s». У нас есть конфигурация, куда давно ничего не помещается, для нее я делал поддержку внешних запускаемых программ, но все равно из нее всё вываливается.

Поэтому на выходных начал делать две вещи, которые давно напрашивались, — переход на однобайтовую кодировку и выделение «USB-диска» в отдельное приложение. Хотя вторая задача оказалась инженерно сложнее, зато потребовала меньше моего участия — я просто подключил одну из своих консолей к ноутбуку, описал набор тестов и ждал, пока нейросеть устранит все проблемы.

В задаче перевода кодировании символов на один байт мне пришлось участвовать постоянно.

Для начала для чего это нужно. Для нескольких вещей.

Во-первых, в прошивке достаточно много различных строк, которые приходится хранить. На одном этом удалось сэкономить около килобайта. Во-вторых, у меня ограниченные буферы редактирования. Тексты на русском в Юникоде занимают по два байта на символ. В-третьих, внутренний «диск» небольшой — всего 512 килобайт. И хотя используется сжатие, программы, использующие один байт на символ, всё равно занимают меньше места.

Поэтому пришлось придумать свою кодировку. Я её назвал «M8» («MK-61», 8 бит), но по сути это — CP1251 с добавленными специальными символами на позиции 0E…1F. Я выбрал как базу CP1251, потому что у большинства членов команды, а также у редких пользователей из сообщества — «Винда», поэтому при работе в терминале нам ничего не придётся перекодировать (специальные символы используются в интерфейсе, поэтому в терминал не попадают).

Теперь у «МК-61s» есть своя однобайтовая кодировка частично совместимая с так называемой «CP1251», для краткости я её называю «M8»

Файловая система, которая видна через «USB-диск», при этом работает как и раньше — длинные имена и содержимое файлов на лету преобразуются в «Юникод» и обратно. Поскольку для каждого файла у нас хранится метаинформация, чтобы мы знали, чем его запускать, бинарные файлы от перекодировки не страдают.

У меня есть идея поместить на свободные места все национальные символы, используемые внутри России — места хватает, однако она разбивается о сомнения, как поступить с их отображением в терминале. То ли показывать там знак «вопроса», то ли предусмотреть режим переключения терминала в «Юникод». Пока отложил эту идею, всё равно пользователей таких символов пока не наблюдается.

На днях решил навести порядок в высокоуровневых языках программирования внутри ретроконсоли «MK-61s». Там внутри сейчас аж три языка — «Бейсик», «Фокал» и собственный язык, который постепенно образовался из системы команд встроенного терминала.

Сначала я попытался сократить размер интерпретаторов, упростив синтаксический парсер, а потом занялся ревизией самих языков.

Начал с «Бейсика». Тот диалект, который сейчас используется, это реализация «Palo Alto Tiny BASIC v3» Ли-Чэнь Вана 1977 года — не побитовая эмуляция исторического интерпретатора, а компактный совместимый диалект с математикой и доступом к регистрам «МК-61».

Оказалось, что в прошлый раз я реализацию «не дожал», уже не помню почему, видимо не умещалось по памяти. Поменяв парсер на более компромиссный, удалось и оригинальный синтаксис реализовать в полном объёме, и все расширения сохранить.

И чтобы протестировать «Бейсик» более тщательно, я решил портировать игру «High Noon», точнее свой же порт, который я в 2020 году перевёл на «Фортран».

Эту игру написал американский школьник Крис Гайло из школы Сайоссета на Лонг-Айленде. Исходный текст датирован 9 декабря 1970 года и работал в системе коллективного доступа компании «Call-a-Computer». Пользователь общался с ней через телетайп, так что никакой графики в игре не было — только медленно печатающийся текст. Игра понравилась настолько, что её поместили в общую библиотеку системы.

По нынешним меркам это совсем простая игра.

Дело происходит на Диком Западе. Вас вызывает на дуэль ковбой-бандит Чёрный Барт. В начале противники стоят в ста шагах друг от друга, у каждого по четыре патрона, а меткость считается одинаковой. На расстоянии ста шагов попасть невозможно, в упор — невозможно промахнуться. Чем ближе вы подходите, тем выше ваши шансы, но ровно настолько же растут шансы Барта.

Начало игры, список ходов и первые шаги к Чёрному Барту. Тут и дальше я склеил по три экрана для наглядности

autoexec.m61 работает дирижёром: запускает нужную часть, а состояние игры передаётся между ними через регистры «МК-61», у него есть такой синтаксис.

Заодно в папке игры появился свой узкий пиксельный шрифт. Сценарий загружает его перед стартом и возвращает прежний при выходе. Без этого длинные английские фразы просто не помещались бы на экране 192×64 (игра запускается только на консоли с графическим экраном).

В показанной партии я в основном шёл вперёд по десять шагов. Барт тоже приближался, несколько раз стрелял и в конце концов остался без патронов. Потом он умудрился пройти мимо меня — расстояние стало минус три шага. Эту странность исходной программы я тоже честно сохранил. Следующий выстрел попал Барту точно между глаз.

Барт приближается, расходует все патроны и получает пулю между глаз

После победы появляется мэр Додж-Сити и от имени благодарных граждан вручает награду — чек на двадцать тысяч долларов. Номер чека и дата каждый раз случайные. На телетайпе 1970 года такой чек можно было получить на бумаге; на экране ретроконсоли он выводится в несколько строк, но всё равно вполне узнаваем.

Награда за Чёрного Барта. «Не трать всё в одном месте»

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

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

Пришлось делать что-то вроде оверлеев — подгружаемых модулей, располагающихся по заданным адресам. Это решило проблему, но позже мне захотелось большего — сделать полноценные запускаемые файлы, желательно, чтобы они могли работать в любом месте памяти, как в обычных операционных системах.

Для тестов я решил навайбкодить какое-нибудь интерактивное приложение, чтобы было веселее тестировать взаимодействие приложения с остальной системой. Для этого я выбрал «Элизу», программу 1964 года, написанную учёным-компьютерщиком Джозефом Вейценбаумом.

Когда-то она очень неплохо имитировала психотерапевта, читал в одной книге, что некоторые люди не могли поверить, что это компьютерная программа.

«Элиза» на виртуальном экране, я его когда-то добавлял, чтобы можно было работать над графическим экраном без него, теперь его удобнее скриншотить

Самому мне тестировать быстро наскучило, поэтому я поручил тестирование «Солу» («ГПТ-5.6»), объяснил с чем он имеет дело, попросил обсудить с «Элизой» какою-нибудь проблему, а позже просмотрел лог общения разных поколений искусственного интеллекта.

Там есть весьма… интересные фразы. Это выдернуто из разных мест диалога:

И хотя я понимаю, что это не человек, мне сложно отделаться от неприятного ощущения, будто я подсмотрел реальную психотерапевтическую сессию, где мой сотрудник поделился со своим психотерапевтом всеми своими страхами.

Кстати, сам «Сол» невысоко оценил своё общение с «Элизой» — всего на три из десяти. 

Дошли руки наконец-то заняться в ретроконсоли «МК61s-classic» шрифтами. У этого устройства относительно большой графический экран, там есть где разгуляться. Первое, от чего хотелось избавиться — от моноширинности шрифта интерфейса. На таком экране это смотрится плохо.

Сначала я взял обычные векторные шрифты, но результат оказался ужасным — у экрана довольно крупный пиксель и всего два цвета, поэтому при масштабировании у некоторых букв часть штрихов была толще, чем нужно. Смотрится такое очень неаккуратно. К счастью, нашёлся несколько вариантов пиксельных не моноширинных шрифтов. Больше всего мне понравился «Ark Pixel Font», оставил пока его, но буду ещё экспериментировать.

Второе — давно хотелось попробовать выводить цифры в стиле калькулятора. Задача несложная, однако важно выбрать подходящий шрифт, который будет выглядеть эстетично. Ниже представлены несколько вариантов, вдохновлённых разными устройствами с цифровым отображением на сегментных индикаторах.

В итоге мы выбрали последний вариант — тонкий шрифт с увеличенным интервалом. Сохраню себе варианты для истории.

Сегодня утром в группе, посвящённой советским программируемым калькулятором возникло очень интересное обсуждение, которое вылилось в небольшое исследовании и добавления специального режима в ретроконсоль «MK-61s».

Я как-то давно задумывался над тем, почему в калькуляторе «МК-61» есть три команды, идущие подряд, которые ничего не делают — К НОП, К 1 и К 2, но всерьёз этой темой не заинтересовался. Все три комбинации дают разные коды — 54, 55 и 56, и если первая «честная» команда без операции, то зачем нужны ещё две?

Ответ нашёлся в книге Я. К. Трохименко и соавторов «Программируемые микрокалькуляторы. Устройство и пользование» (1990):

В последовательной памяти калькулятора предусмотрена область Ms. Для семейства МК-61/52 это восемь страниц по семь байтов. Она размещена рядом со стеком, но отдельно от обычных 105 шагов программы. Получаются ещё 56 байтов, которые потенциально можно было бы использовать для чисел или программного кода.

Что опять-таки вызывает вопросы: почему разработчики не сделали один-единственный шаг, если аппаратно и программно всё, по сути, было готово.

При помощи нейросети я связал эти команды с соответствующими участками микропрограммы в ретроконсоли «MK-61s». Чтобы сохранить совместимость, этот код работает только в расширенном режиме «112ШГ+ПF». У этого режима уже есть дополнительная страница кольца: 16 вместо 15. Семь страниц области M2 занимают метка, канал связи и стек; для Ms выделено девять страниц. Поэтому исторический замысел в «MK-61s» расширен до девяти чисел или 63 шагов программы.

Надо упомянуть, что до этой же памяти энтузиасты добирались и без работающих команд обмена — с помощью «пустышек», особых некорректных чисел. Они сбивали поиск служебной метки в кольцевой памяти, заставляя обычные стековые операции обращаться к участкам Ms. Так удавалось сохранять дополнительные числа сверх паспортного количества регистров. Сколько именно зависело от модели калькулятора и самих чисел.

Правда, так можно было сохранить всего несколько цифр, полностью использовать этот участок памяти этим способом невозможно. Да и такой способ работы с ним занимает слишком много команд, в реальной программе его использовать крайне сложно. Одну из статей, описывающих этот способ, можно найти в «Технике — молодёжи», № 7 за 1986 год.

Жаль, что разработчики не довели эту задумку до серии, расширение памяти в полтора раза и обмен регистров — это, думаю, подарок, о котором программисты того времени не могли и мечтать.

Меня тут один читатель натолкнул на идею рассказать вот о чём.

Что можно было бы дёшево улучшить в «МК-61», если бы в своё время стояла такая задача? Понятно, что неплохо было бы исправить ошибки, например зацикливание генератора случайных чисел при взятии целой части. Да и сам генератор неплохо было бы сделать по-настоящему случайным, чтобы он не начинал при включении свою работу всегда с одного и того же числа. Но это тоже, наверное, можно считать багом.

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

Ретроконсоль «МК-61s», которую я помогаю программировать, точно эмулирует железо. Эта эмуляция основана на работе Феликса Лазарева, который, вооружившись снимками разводки плат и ПЗУ, снятого под микроскопом, за год сделал точный эмулятор, полностью программно повторяющий аппаратную часть «Электроники МК-61».

Позже в одном из эмуляторов появился и ответ на вопрос, заданный в начале этой заметки.

Позже Сергей Фролов провёл эксперимент и, как результат, в некоторые эмуляторы были добавлены семь дополнительных ячеек памяти и дополнительный регистр f. Казалось бы, не бог весть что, но не в том случае, когда доступно всего 105 ячеек.

Я разобрал очень много оптимизаций для своего другого проекта — языка высокого уровня для «МК-61» — и знаю, как люди изощрялись, чтобы сэкономить всего лишь один байт, которого не хватает, чтобы впихнуть программу в существующие ограничения.

Так что семь байт и ещё один регистр — это очень большое подспорье.

В «МК-61s» я сделал три режима: без этого расширения, с включённым расширением и автоматический режим. Последний включает расширение адресов и дополнительный регистр, если обнаруживает, что загружаемая программа не помещается в стандартные 105 байт или использует команды с кодами 0x4F и 0x6F. Это неиспользуемые в обычной программе коды, которые в этом режиме заняты под работу с дополнительным регистром.

Дополнено 22 августа: оказывается, эксперимент провёл не Сергей Фролов. Статью я напишу позже. Мне сегодня сделали операцию, отхожу, ещё и горло заболело из-за безответственного коллеги.

Экран WEH001602AGPP5N00100 и попытка подать на него другое питание

Дошёл сегодня новый экран для ретроконсоли «MK-61s», в разработке прошивки для которой я принимаю участие. У меня сейчас стоит LCD1602-A00, а я всё хотел попробовать что-то более современное, желательно с поддержкой графического режима.

Купил WEH001602AGPP5N00100: у него есть оба режима — более простой алфавитно-цифровой и графический. Заказал на адрес одного из участников нашей команды: там надо было припаять контакты, а мне зрение уже не позволяет нормально паять. По питанию и прочим характеристикам экран вроде бы должен был подойти.

Сегодня экран от него доехал до меня, но не заработал — не подаёт никаких признаков жизни. Мы попробовали отладить его дистанционно, я даже в одном месте припаял другое питание, но всё тщетно.

Он, судя по статьям, вообще довольно проблемное устройство, на «Хабре» есть несколько статей, ему посвящённых. Мы их с нейросетью проштудировали и заранее подготовили прошивку с обходом всех известных проблем. Жалко не помогло. Впрочем, он может оказаться просто неисправным. Чтобы проверить, нужна «Ардуинка», а у меня её нету.

Отправил экран обратно, тому же сокоманднику, который мне контакты паял, у него всё есть, посмотрим, жив ли экран или просто не подходит.

Когда я только присоединился к проекту разработки ретроконсоли «МК-61s» и я не подозревал, что у неё есть несколько исполнений, разных по своим возможностям. Сейчас-то это всё учтено в коде, но какое-то время я пребывал в уверенности, что тот инженерный образец, который мне выслали — единственная аппаратная платформа, на которой прошивка будет работать.

Позже оказалось, что только экранов может быть три разновидности, одна из которых даже имеет графический режим. Чтобы посмотреть как всё на нём смотрится, мне пришлось сделать его эмуляцию, которая транслирует видео ретроконсоли в приложение, запущенное у меня на ноуте.

К сожалению это не даёт понимание как в точности будет выглядеть изображение на реальном экране. А это мешает мне всерьёз заняться шрифтами графического режима — я совсем не уверен, что в жизни всё будет так же хорошо, как на моём виртуальном экране.

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

Содержимое посылки, которая мне доедет примерно через неделю

Хочу чуть подробнее рассказать о том, как сделана инструкция к играм для «MK-61s».

Как я уже говорил, если при входе в папку Проводник ретроконсоль обнаруживает внутри файл autoexec.m61, она запускает его. Файл содержит инструкции для терминала. Это существовавший ещё до моего прихода в проект простой язык, который я довольно сильно расширил под свои нужды. Сейчас в нём есть даже условные конструкции и подпрограммы. То есть это аналог BAT-файла из мира «Виндоуса» или шелл-скрипта из мира «Линукса» и «Мака».

В данном случае autoexec.m61 первым делом командой open открывает для просмотра маркдаун-файл manual.md. Маркдаун — хорошо документированный и широко используемый формат. В ретроконсоли реализовано лишь его подмножество, так как полная поддержка не имела смысла.

На скриншоте видно оба файла. В маркдауне видно всю разметку, которая потом во что-то превращается на экране (например, символы «решётки» выделяют заголовки) и ссылки на картинки в формате WBMP — был такой очень простой формат однобитной графики во времена интернета для кнопочных сотовых телефонов. На графическом экране графика внедрённая, то есть на месте, где в файле находится ссылка на картинку, будет выведена сама картинка.

После того как пользователь выйдет из инструкции, запустится сама игра — в данном случае она вводится в шестнадцатеричных кодах командой hin, потом выставляются регистры, а в конце подаются команды для старта.

В принципе, таким сценарием мы не ограничены, всё зависит от фантазии — можем выводить что-то не экран, опрашивать клавиши, проигрывать звук, запускать программы на всех трёх встроенных языках программирования и вообще реализовывать любую логику.

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

У меня давно была мысль сделать для ретроконсоли «MK-61s» возможность собирать игры в некий пакет, в который будут включены как сама игра, так и её описание, а по возможности — даже иллюстрации. Мне это виделось как папка в файловой системе, при открытии которой автоматически запускается файл, показывающий инструкцию, после чего запускается сама игра.

Я давно, шаг за шагом начал реализовывать этот проект и вчера вечером наконец-то его завершил. Для этого пришлось последовательно сделать файловую систему, потом папки на ней, расширить команды терминала и сделать из этого псевдоязык для управления устройством, добавить виртуальный графический экран, просмотр графических файлов в формате WBMP, поддержку файлов в формате «маркдаун» и автозапуск файла autoexec.m61 — это как раз файл, содержащий управляющие команды терминала.

Тут я склеил три экрана для наглядности

Вышло, на мой взгляд, очень здорово и уместно. Я в качестве теста сделал инструкцию к одной из игр, мне понравилось как это всё смотрится, возможно только листание надо переделать по более плавное, чтобы можно было прочитать разрезанные фразы. Но это уже косметика, которая легко правится.

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

Уже сейчас такое оборудование существует — у тех, кто собирает эту ретроконсоль на контроллере STM32F401CC, полная прошивка не собирается: не хватает памяти. Мне давно хотелось сделать для этого случая подгружаемые модули, и вчера, просидев с нейросетью до двух ночи, удалось запустить первую версию, в которой заработали два тяжёлых модуля — языки программирования «Фокал» и «TinyBASIC».

Туда же я вынес просмотрщик картинок в формате WBMP, который прикрутил недавно. Не самая нужная в этой ретроконсоли штука, но у меня есть задумка, которая может сделать её полезной.

В итоге для 401-го контроллера модули лежат на файловой системе, которую я делал для поддержки загрузки файлов по USB (правда, это уже её пятая версия), и подгружаются в оперативную память по требованию. А чтобы это происходило быстрее, я решил чем-нибудь их сжимать. Вопрос — чем.

Внутри уже есть реализации RLE для сжатия шрифтов (я хочу подобрать какие-нибудь симпатичные шрифты для графического экрана, но пока руки не дошли) и LZSS для сжатия файлов других типов. Конечно, сначала я смотрел в сторону того, что уже есть, но потом решил почитать «Википедию» и «Хабр» — вдруг найдётся что-то более подходящее.

Основные требования — хорошо сжимает бинарные файлы, а распаковщик быстрый и маленький.

Таблица с тестами по сжатию разных модулей

Я покидал в нейросетку всё найденное, добавил то, что помнил сам, и мы провели эксперимент — сжали все три получившихся модуля и выбрали победителя. Победил алгоритм ZX0, разработанный для восьмибитных компьютеров (прежде всего — «Спектрума») программистом Эйнаром Саукасом.

Утром мы ещё поработали над большей универсальностью этого подхода — хотелось устранить шероховатости и сделать его более универсальным, чтобы писать такие программные модули было проще.

На целевом оборудовании я решение не испытывал — у меня его нет, но на своей ретроконсоли всё проверил: работает. Дальше займусь специализированными инструментами, чтобы упростить создание модулей, а потом перейду к другим пунктам своего уже довольно сильно поредевшего плана развития прошивки.

Как можно было понять из моих прошлых текстов, у ретроконсоли «MK-61s» несколько исполнений. У меня на руках вариант «mini» — устройство с алфавитно-цифровым дисплеем в две строки, но есть, например, «classic», у которого экран графический. Я для графического экрана прошивку программирую «на ощупь», что неудобно. Конечно, всё работает, но визуально результат я не представляю.

Но когда у тебя в руках молоток, всё вокруг превращается в гвозди нейросеть, все такие проблемы превращаются в токены, которые надо забить в код.

У «MK-61s» есть текстовый терминал, через который устройством можно ограниченно управлять. Я его давно расширяю под разные нужды: теперь через него можно получать экран устройства и отправлять нажатия на клавиатуру.

Через терминал такое делать неудобно, поэтому мы с нейросеткой написали клиентское приложение на «Флаттере» с виртуальным экраном и клавиатурой.

Та самая картинка, фрагмент которой я пытался вывести на «MK61s-mini» в прошлой заметке

По пути пришлось решить множество проблем, самой серьёзной из которых было научить устройство нормально переключаться со своего алфавитно-цифрового дисплея на графический и обратно. Сложная задача, потому что изначально такое не планировалось, но решаемая — надо только все баги найти.

Как я уже упоминал выше, в этом режиме также можно передавать нажатия клавиш прямо с клавиатуры компьютера или ноутбука — набирать программы в «Фокале» и «TinyBASIC», которые я когда-то встраивал, теперь значительно удобнее.

Во внутреннем хранилище видно несколько игр в формате ретроконсоли

Ну и «на сдачу» написал также аналог «Нортона Коммандера» на шелле. В принципе уже есть возможность примонтировать ретроконсоль как диск, но тут принцип другой — всё делается командами терминала. Вышло забавно, пусть будет.

Поддерживаются все горячие клавиши, видимые на скриншоте, удалённый запуск программ в терминале и просмотр изображений WBMP, который моими стараниями теперь понимает ретроконсоль. В консоль моего «Макбука» такие картинки выводятся через протокол iTerm2 или азбукой Брайля.

У меня давно вертится в голове идея попробовать вывести графику на алфавитно-цифровом экране «МК-61s». Он хоть и алфавитно-цифровой, но у него, как я уже неоднократно писал, есть восемь программируемых символов. В теории можно было бы разбить графику на эти восемь символов, но это будет куцо смотреться — экран-то рассчитан на 32 символа.

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

Потом я попробовал показывать по восемь символов за раз, быстро чередуя их и отображая полное изображение за четыре кадра. Изображение стало узнаваемым, но очень низкоконтрастным. Чтобы наглядно показать, что получилось, мне пришлось сильно скорректировать уровни изображения в редакторе:

Это — «Пакман», гоняющийся за привидением.

Следующая идея была сложнее: первым проходом показывать максимум общих точек, а последующими — «добивать» оставшиеся, также перепрограммируя символы «на лету». Идея могла бы сработать, тем более, что на фрагменте эталонного изображения Лены Сёдерберг вместо четырёх кадров, по нашим с нейросетью расчётам, потребовалось бы всего три.

В реальности изображение стало чётче, но отображалось полосами. Я попросил нейросеть сделать подстройку частоты кадров и попытался подобрать её, как в старом телевизоре, но всё сильно зависело от того, какой кусочек Лены был на экране. Впрочем, контрастность явно выросла. Пакман тоже стал виден лучше.

Под конец я решил разделить экран на четыре блока по восемь символов по горизонтали и отрисовывать их один за другим. Этот вариант мне понравился меньше остальных, хотя контрастность была самой высокой — блоки слишком сильно мигали.

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

Не уверен что мне с этим всем делать, но пока оставил реализацию в экспериментальном режиме.