Timeweb.Cloud

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

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

❯ Проблема остатка (Remainder issue)

Первый вопрос: что делать с остатком? Все просто — взять делитель поменьше, потому что чем меньше делитель, тем меньше остаток. Этому меня еще в школе научили. Но я столкнулся с тем, что это не работает с MVx архитектурами, потому что мой делитель, обычно, это набор определенных компонент, и введение новых — значит изменение архитектуры.

Возможно и вы с этим сталкивались, когда вводили всякие мапперы, делегаты, интеракторы (те, что репозитории репозиториев) и прочее. Помогли ли они мне? Нет. Лучшее решение, что я видел — это Flux- и ELM-like архитектуры, которые заявляют «чистую» функцию как единицу деления логики, но со всеми вытекающими отсюда удобствами и следующими за ними «эффектами».

Но решение проблемы остатка, даже если бы оно у меня было, не помогает мне решить проблему масштабирования.

❯ Проблема масштабирования (Scalability issue)

В прошлый раз я упоминал «интуитивный» подход к решению задачи масштабирования и рассказывал почему он не работает. По крайней мере не у меня.

А какой не интуитивный?

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

Так и в MVx архитектурах: можно было бы попробовать реализовывать доработки отдельно, а уже потом объединять их с существующей фичей, вместо того, чтобы вносить изменения в уже написанные компоненты. Что в прошлом не раз приводило меня к череде переписываний тестов, судорожному протыкиванию приложения на предмет того, что ничего не поменялось, и мольбам о том, чтобы очередной баг-репорт был не по моим изменениям.Но вот что я заметил, ведь именно такой подход, когда мы предпочитаем композицию изменениям, я и мои коллеги используем для Data-слоев. Например, новые источники данных оборачиваются в Репозитории, а потом комбинируются в Интеракторы. Но почему-то чем ближе мы подходим к UI-слою, тем больше начинаем изменять, а не комбинировать.

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

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

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

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

❯ Проблема разрывов (Gaps issue)

И вот тут становится интересно. Все дело в Hello World. Мне все никак не дает покоя вопрос: какая у него архитектура?

Hello world

Я видел примеры Hello World в разных языках, фреймворках и архитектурах (кроме Open GL, конечно же), и у них не было проблем с его реализацией. Если не считать проблемой то, сколько усилий надо приложить, чтобы написать изначальный шаблон. Но, если результат одинаковый, не значит ли это, что разница только в том, сколько обвязок надо написать, чтобы Hello World работал? И нужны ли они? Тогда я стал думать: а что общего у всех этих реализаций Hello World в разных архитектурах? И как-то я пришел к мысли, что скорее всего правильный ответ — Алгоритм. И он до безобразия тривиален.

И что интересно, у самого алгоритма нигде не написана архитектура в которой он должен быть имплементирован. Но это Hello World. Как я и сказал: он чересчур прост.

Более интересные примеры

Давайте лучше взглянем на следующий пример, который используют в учебниках по программированию — Hello %username%. У него все та же проблема с архитектурами — его можно написать в любой из них, и общее между всеми реализациями в разных архитектурах — алгоритм.

А вот еще интересное наблюдение: если мы немного обобщим алгоритм Hello World, отделив show от Hello World, то увидим, что он дважды появляется в алгоритме этого примера.

Все еще слишком просто, правда? Следующий учебный пример — работа со структурами данных. И в самом простом виде — это CRUD плюс “показать все” с хранением в списке (он же List). Этот пример, не очень интересный с точки зрения реализации, интересен тем, что он добавляет в предыдущий алгоритм композицию.

По сути здесь мы первый раз сталкиваемся с тем, что нам надо создать пять независимых программ, а потом объединить их под управлением шестой. А еще эти шесть программ делят между собой один блок памяти — сам список структур. И мне кажется, что это уже напоминает решение одной из наших проблем, не так ли?

Появление Gaps issue

Но что происходит даже с этими простыми программами, когда мы пытаемся перенести их в UI-среду?

Легче всего Hello World, потому что он просто обрастает кучей компонент, которые помогают ему “жить” в новой среде. Даже не интересно.

А вот Hello %user name% приходится куда сложнее. Беднягу размазывает по компонентам системы или архитектуры: в одном месте мы слушаем ввод имени, в другом показываем приветствие, а в третьем прописываем реакцию на введенное имя.

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

Но ведь изначально “не было ни единого разрыва”, а алгоритм остался тем же. Почему все стало так плохо?

Причина — асинхронность

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

Многие, если не все GUI-системы построены вокруг event loop, потому что нам надо одновременно и экран рисовать, и ввод от пользователя слушать. А чтобы сюда добавить еще и наш алгоритм, его придется разделить так, чтобы он хорошо встраивался в этот event loop.

Я уже не говорю о том, что мы вообще-то еще должны взаимодействовать с другими асинхронными системами. Кстати, с ними то, обычно, проблем и не возникает. А почему?

Решение — закрытие разрыва

Обратим внимание на графикоподобную картинку, на которой я объяснял проблему разрывов в прошлый раз.

Напомню как всё было, и в этот раз уже не буду лукавить: путь нашей логики начинается в каком-то из callback’ов, а не в абстрактном “начале”. По мере выполнения мы продвигаемся все глубже по стеку вызовов, выполняем одну за другой функции, и в самой верхней точке нашего графика мы обращаемся к источнику данных: бэкенду, файлу, какой-то системе хранения. И что здесь обычно находится?

Обычно это вызов какой-то “асинхронной” функции: корутины, async- или suspend- функции, уж простите мой котлинский, или какой-то функции с callback’ом, или функции возвращающей какой-нибудь Future, Promise или Single.

И вот вопрос: вызывая эту функцию с callback’ом, как часто мы задумываемся, что эта операция может вообще никогда не вернуться в этот callback? Лично я до недавнего времени считал, что управление гарантированно будет передано в наш callback. Не считая случаев “отмены”, конечно же. Но откуда у нас такая гарантия? Возможно все дело в реализации системы? Давайте “заглянем под капот” и посмотрим что же там на самом деле происходит.

Наша функция формирует наш запрос к базе, запрос в сеть или еще что-то. В общем случае формирует какой-то контекст, с помощью которого надо выполнить запрос, и вместе с callback’ом, в который надо вернуть результат, отправляет его на другой поток, и там происходит все выполнение. После завершения выполнения, тот поток вызывает callback, передавая в него результат, что для нас, разработчиков, выглядит как своего рода возврат в точку вызова. Таким образом логика выглядит более цельной, и такого разрыва, как в случае с UI не происходит.

Так вот вопрос: а почему бы нам не повторить этот же трюк с UI?

На картинке это будет выглядеть как параллельный перенос: мы просто поднимем нашу линию, а вот тут, в нижней точке, вместо того чтобы разрывать логику и отдельно задавать на UI какое-то состояние и callback’и, сделаем функцию, которая отправляет запрос на UI и ждет от него ответа. Таким образом мы закрываем разрыв и теперь наша логика будет выглядеть как единое целое.

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

❯ Proposal

Давайте писать функции…

Да, может звучать нелогично, тем более, что я уже говорил о том, что это не помогает Flux- и ELM-like архитектурам, но я объясню. Начнем с проблемы остатка.

Влияние на решение проблемы остатка

Добавлю небольшую аналогию с математикой. Как я и говорил «архитектура» — это делитель. А чтобы при делении не оставалось остатка — нам нужно найти наибольший общий делитель. Чем и является функция, на мой взгляд. Чем больше я смотрю на реализации всех наших «архитектур», тем больше я вижу, что все они, по сути, просто один из способов удобнее объединять и специализировать функции (и тут я подразумеваю, что метод класса — это функция, которая иногда неявно принимает дополнительный аргумент).

Дальше лучше — проблема масштабирования.

Решение проблемы масштабирования

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

А что с разрывами?

Решение проблемы разрывов

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

❯ Концепт

Так что же я предлагаю?

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

Во-вторых, у этой функции (композиции функций) должна быть возможность работать независимо от «сторонних» систем, поэтому я предлагаю вынести ее в свой поток, чтобы у нее была возможность спокойно выполняться, блокироваться при необходимости, параллелиться и тому подобное. Пусть будет “синхронной”. Обычно мне не надо, чтобы логика продолжала свое выполнение, когда она ждет какой-то ресурс. А если такое поведение нужно, то почему-бы его не описать его явно? И назвать бы этот поток Main, но имя уже “занято”. =)

В-третьих, хотя это и самый важный пункт, а у меня видимо есть тенденция оставлять все важное на потом, я предлагаю сосредоточиться на реализации логики приложений, а не экранов и виджетов. Как видите, с таким подходом нет разницы между слоем данных и пользователем. Есть только наша детерминированная логика и внешние системы, которые обмениваются данными через нее. Логика просто ходит между ними и предоставляет им некий контекст для принятия решения и набор возможных действий, а внешние системы в свою очередь “отвечают” нашей логике руководствуясь представленным контекстом. Это похоже на игру в шахматы, где внешние системы — игроки, а логика — доска с фигурами и правила игры.

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

В конце концов, применив этот концепт, я хочу помочь всем нам проектировать и писать кроссплатформенные приложения в самом широком смысле этого слова: разрабатывая и реализуя end-to-end алгоритмы которые прозрачно перескакивают с бэкенда на фронт и обратно, которые не видят различия между разными видами фронтов, будь то Web, iOS или Android, или разными типами вроде UI, CLI, или TalkBack.

Но пока это только концепт и виденье. Пожалуй пора посмотреть на код, но он будет в следующий раз. А сейчас есть время порефлексировать на эту тему. Дайте этим идеям время перевариться. Прочитайте еще раз. Задайте вопросы. И может вы сможете написать код еще до того, как я опубликую продолжение. Хотите посоревноваться?

Увидимся.

• Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей в нашем блоге на Хабре и телеграм-каналах (статьи и новости).

• Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать наши проекты.

Тетрис — одна из самых (если не самая!) известных видеоигр, чьё имя известно даже людям, бесконечно далёким от этой индустрии. Когда в 1989 году «Тетрис» вышел на Nintendo Game Boy, он стал мировым хитом, продавшись миллионами копий и зарекомендовав себя как самая любимая в мире видеоигра-головоломка.

Для старинной видеоигры, которая начиналась как любительский проект компьютерного разработчика из СССР, влияние «Тетриса» по-прежнему сильно, доказательством чему служит огромная база игроков, по сей день пытающихся полностью пройти игру. Его успех также породил желание создать продолжение. Появились побочные продукты: такие как Hatris, Welltris и Wordtris, а также итеративные продолжения, такие как Tetris 2, Tetris DS и Tetris Effect. Но у игры могло бы быть ещё одно продолжение, которое так и не вышло. Сам создатель Тетриса, Алексей Пажитнов, придумал другую, более интеллектуальную версию игры.

На Game Developers Conference (GDC) 2024 Алексей Пажитнов рассказал о своих первоначальных планах по выпуску продолжения «Тетриса» и о том, почему мы только сейчас слышим об этом публично. Это запланированное продолжение, получившее название Tetris Reversed, было призвано изменить способ игры в тетрис. Но сиквел игры уже более десяти лет находится на стадии прототипа.

❯ Создание прототипа

Нет особого смысла приводить здесь историю Алексея Пажитнова и создания им оригинальной игры. При желании эту информацию можно найти в Википедии. Даже фильм сняли про это, многое конечно приукрасили (Голливуд же), но тем не менее. Можно упомянуть, что Пажитнов живет в США с 1991 года, где он участвовал в разработке таких игр, как Pandora’s Box, и работал с такими компаниями, как Microsoft и WildSnake Software. Помимо «Тетрис», он является автором таких игр, как Hatris, El-Fish и Hexic, а также многих других, которые углубили и расширили игровой дизайн. В 2007 году он был удостоен First Penguin Award на церемонии вручения наград Game Developers Choice Awards за прорыв в мире игр.

История продолжения Тетриса началась, когда хорватский разработчик Ведран Кланач посетил фестиваль игр NLGD в Нидерландах в 2011 году. Там Ведран разговорился с Мартином де Рондом из Guerrilla Games. Де Ронд заявил, что у него есть договоренность с Пажитновым о создании прототипа совершенно новой игры «Тетрис». Кланач естественно ухватился за возможность поработать с такой легендарной фигурой.

Пажитнов придумал альтернативную версию игры под названием Tetris Reversed, в которой правила аналогичны обычному тетрису — игроки управляют падающими блоками, перемещая, вращая и размещая их, однако блоки падают перед цветными фоновыми пространствами, которые игрок пытается очистить. Т.е. тетрамино (блоки тетриса) использовались для устранения стены блоков, а не для складывания их друг в друга. Название «Reversed» происходит от того факта, что заполненные и пустые места могут меняться местами, инвертируя игровое поле. Примерный принцип игры можно посмотреть на Реддите, где три года назад уже сделали подобный реверсивный Тетрис.

Де Ронд был посредником между Пажитновым и Кланачем – эти двое впервые лично встретились только в 2024 году. Де Ронд передавал инструкции по проектированию от Пажитнова Кланачу, который в свободное время создавал код игры на своем собственном движке. Кланач ныне является генеральным директором компании Ocean Media. Он был аэрокосмическим инженером, который начал свою карьеру в компании Croteam, где создал игровой движок для Serious Sam 2. За последние 20 лет он, в качестве программиста и исполнительного продюсера, поучаствовал в производстве более чем в 200 проектов.

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

Идея игры возникла вновь только в 2017 году, когда Кланач рассказал о ней Владу Мику, специалисту по развитию бизнеса. Мику решил лично познакомить Пажитнова с Кланачем, когда он и Кланач ужинали в апреле 2023 года вместе с Кейт Эдвардс, генеральным директором Geogrify и говорили о фильме «Тетрис». Тогда Кланач упомянул, что в его личных архивах в компьютерных файлах старого ПК с Windows 7 до сих пор хранится прототип игры под названием Tetris Reversed.

В 2024 году Влад Мику свел Пажитнова и Кланача на GDC 2024. Результатом стала специальная комиссия, в которую вошли Кейт Эдвардс, Влад Мику, Алексей Пажитнов и Ведран Кланач – четыре ключевые фигуры в возрождении прототипа.

Пажитнов, который почти забыл о существовании прототипа, приветствовал возрождение игры. Он сказал, что это Tetris для людей с IQ 300. В оригинальной игре игрок сосредоточен лишь на части экрана: появляется блочок, который нужно куда-то перетащить и разместить. Теперь же игроку придется использовать всё игровое поле на экране сразу. По словам разработчиков, это приближает Tetris Reversed к настольным играм, вдохновившим оригинал. В отличие от оригинального тетриса, в который можно играть в течение длительного времени, Reversed был разработан для более коротких сессий, некоторые из которых длились до десяти минут. Основываясь на уровнях и выборе, Пажитнов заявил, что на некоторых уровнях выиграть может быть «абсолютно невозможно» в зависимости от того, как были установлены фоновые блоки.

❯ Тетрис наоборот

Основная механика игры, описанная и изображенная на фотографиях слайдов, такова:

Поле игры:

• Пользователь имеет игровое поле, состоящее из сетки из 10 столбцов на 20 строк.

• Каждый квадрат имеет два состояния: полный (серый) или пустой (чёрный).

Каждый игровой раунд начинается с появления фигуры на игровом поле. Игрок может выполнить одно из двух действий:

• Разместить фигуру на поле;

• Инвертировать поле.

Существуют также две добавленные механики:

Неразмещаемая клетка:

• Неразмещаемая клетка – это клетка, на которую нельзя поставить фигуру.

• Заполненная неразмещаемая клетка представлена заполненным квадратом со значком желтого шара.

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

Клетка инвертирования поля:

• Клетка инвертирования поля представлена значком молнии.

• Если фигура помещена на клетку «Инвертировать поле», игрок получает +1 действие «Инвертировать поле» для дальнейшего использования.
  

❯ Будет ли официальный релиз Tetris Reversed?

Как говорит Алексей Пажитнов, он и Кланач выполнили свою работу:

«Я завершил концепцию, развитие, идеи и всё, что есть в Tetris Reversed. Это было на предварительном этапе, и с этим прототипом мы были готовы начать производство. Но в данном случае производство так и не началось, поэтому нам пришлось ждать следующего этапа, чего так и не произошло, потому что доводить его до конца — не наша работа. В то время у Мартина де Ронда было слишком много дел, поэтому он отложил этот этап производства, вероятно, потому, что у него были проблемы с The Tetris Company и получением разрешения на продолжение работы над этой версией игры. Он закрыл для себя это дело и пошел дальше, и именно поэтому Tetris Reversed так и не был выпущен».

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

Есть много примеров, когда отменённые проекты видеоигр набирали обороты и выпускались спустя годы после цикла их разработки. Для компании Tetris же оригинальная игра по-прежнему является дойной коровой, и по каким-то неведомым причинам они, почему-то, не смогли найти подходящую возможность для Tetris Reversed.

Увидим ли мы когда-нибудь, как Tetris Reversed будет выпущен как эксклюзив для Nintendo Switch 2? Возможно. А в это время в Интернете уже можно найти и скачать бесплатные неофициальные игры под названием Tetris Reversed. Некоторые загружают на Гитхаб код собственной версии Tetris Reversed.

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

Даже за последние несколько месяцев спидранеры несколько раз превосходили рекорд версии для NES. После того как в январе 2024 года Уиллис «Blue Scuti» Гибсон стал первым человеком, который полностью прошёл игру, другой игрок – Энди «P1xelAndy» Артиага – в феврале набрал 8 952 432 очка, побив рекорд Гибсона. Всего несколько недель спустя Алекс Тач почти удвоил рекорд Артиаги, набрав 16 248 080 очков, выиграв 2600 долларов и став первым человеком, преодолевшим отметку в 10 миллионов очков.

Однако так называемая “последняя задача” — прохождение уровня 255 и перезагрузка игры — остается непобеждённой. Может у вас получится?

• Написано специально для Timeweb Cloud и читателей Пикабу. Подписывайтесь на наш блог, чтобы не пропустить новые интересные статьи.

• Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать наши проекты.

Когда я разбирался с программируемыми калькуляторами, то думал, как бы элегантнее протестировать функциональность устройства. Один из известных способов проверки – это реализация какой-либо игры.

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

Реализовать игру решил на модели HP-32S, поскольку он мне очень полюбился за красоту архитектурной реализации и удобство программирования.

❯ Основа программы

В предыдущей своей статье "Калькуляторы с обратной польской нотацией" я делал обзор литературы для программируемых калькуляторов. Среди которой была замечательная книга А.Г. Гайшут "Калькулятор твой помощник и соперник в играх".

В этой книге приводится огромное количество примеров игр на калькуляторе и, в частности, пример игры в крестики-нолики:

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

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

Описание программы Крестики-нолики из книги:

Главная задача – это перенос этого кода с МК-61 на калькулятор HP-32S. Для начала, разберёмся как эта программа работает.

❯ Проверка программы на МК-61

Первое, что я сделал – это перенабрал код из книги в формате, который понимает онлайн-эмулятор МК-61.

Кстати, если интересно, то можно попробовать поиграть в эмуляторе, чтобы понять принцип работы. Для этого копируем код, вставляем в область «Код программы:» и нажимаем кнопку «Ввести в память». Картинка из книжки выше подсказывает нам, что калькулятор даёт координаты, куда ставить "X", а мы ему в ответ передаём координаты, куда ставить "O".

Чтобы начать играть на клавиатуре калькулятора, нужно нажать кнопку [С/П]. В ответ будет выведено число, первое число всегда «9» (центр поля). В ответ необходимо ввести свою координату, например, «2» и нажать [С/П]. И так далее, пока вы не проиграете (калькулятор выведет «77», либо будет ничья (калькулятор выведет «0»).

Чтобы посмотреть последний ход калькулятора, надо обменять регистры X и Y местами, для этого нужно нажать на клавишу [⟷].

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

❯ Анализ кода программы для калькулятора МК-61

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

Особенность программирования МК-61 в том, что он пропускает команду перехода, если условие истинно, и исполняет — если ложно! Поэтому все условия для python пришлось инвертировать. Плюс, я для удобства ввёл дополнительные функции, которые также перенёс впоследствии в HP-32S: функция вывода координат крестиков и ввода ноликов, функция ничья и победа калькулятора:

Первое – инициализирую регистры калькулятора:

После всех подпрограмм идёт головная программа:

Можно увидеть, что в любом случае в самом начале крестик будет стоять на координате 9. Вся основная логика сокрыта в подпрограмме.

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

Исходный код доступен в репозитории проекта.

И, да, код вполне себе работоспособен, в чём несложно убедиться:

❯ Перенос кода на HP-32S

Напомню, что калькулятор HP-32S, который есть у меня, принадлежит семейству калькуляторов HP10B/14B/17B/17BII/19BII/20S/21S/22S/27S/28S/32S/32SII/42S, таким образом, всё, что приводится ниже, с небольшими адаптациями можно будет перенести и на другие модели этой серии.

Трудозатраты в предыдущей главе, по переносу кода на python, были проделаны с двумя целями:

1. Понять, как же работает этот код (увы, не выполнено).

2. Более удобно переносить на другую модель калькулятора.

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

Вооружившисьдокументацией на калькулятор HP-32S, я переписал программу крестиков-ноликов с питона для него. Для удобства я делал это в таблицах Exel. Как я уже говорил, особенность калькулятора в том, что он маркирует каждую строку буквой и цифрой, а любая метка – это смена буквы. Таблицы идеально подходят для этого.

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

Код программы для калькулятора HP-32S:

В силу того, что на калькуляторе HP-32S можно сделать вывод на экран конкретного регистра (с указанием имени регистра), а также запрос ввода другого конкретного регистра, то ввод-вывод становится чуть более интерактивным и интересным.

Лучше один раз увидеть, чем тысячу раз прочитать.

❯ Выводы

Изначально задача казалась мне такой простой, но заняла у меня достаточно приличное время. Её ценность состояла в том, что мне удалось разобраться — как же программировать для калькулятора HP-32S. В результате оказалось, что из модельного ряда калькуляторов, с которыми я занимался — эта версия оказалась самая дружелюбная и удобная.

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

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

❯ Полезные ссылки:

1. Гитхаб этого проекта

2. Первая часть «Калькуляторы с обратной польской нотацией»

3. Сайта автора «Гайштут и его друзья»

4. Онлайн-эмулятор МК-61

5. Документация на калькулятор HP-32S

Если вам интересна металлообработка, старое железо, всякие DIY штуки, погроммирование и linux, то вы можете следить за мной ещё в телеграмме.

• Написано специально для Timeweb Cloud и читателей Пикабу. Подписывайтесь на наш блог, чтобы не пропустить новые интересные статьи.

• Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать наши проекты.

Однако, рулить дисплеем, как правило, та ещё задача. «Особенно если динамическая индикация, да ну его, влом!» — подумал было я. Но у того же продавца обнаружилась и, судя по всему, управляющая плата:

На фотографии виднеется 8085 процессор, 8251 UART и ПЗУшка — казалось бы, дизассемблируй себе, разбирай протокол, да просто с ардуины выводи что угодно. Да ещё и за одну йену, это прям даром! После этого я решил всё же попытать удачу и выхватить этот дисплей. Тем более, что давно уже хотелось какие-нибудь красивые часики в комнату...

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

❯ Всё уже поломано до нас

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

Первым же делом снимаю ПЗУ, кидаю в MSX, чтобы вычитать на комп, но увы — кроме нулей ничего не вычитывается, да ещё и греется оно очень подозрительно. При подаче питания сама плата тоже ничего не делает.

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

Гуглёж по маркировке (Morio Denki 6M06056) тоже ничего, кроме сайта производителя, не выявил. Судя по всему, они занимаются дисплеями для транспорта — так что, скорее всего, этот стоял в каком-то автобусе или поезде.

Вероятнее всего, это был автобус — ведь в поездах между станциями, как правило, на экране идёт бегущая строка. В старых автобусах же отображается лишь название следующей остановки. Выгоревший текст — 「次は、（неразборчиво）」(«Следующая: (нрзб.)») подтверждает эту догадку.

❯ Плата драйвера панели

Значит, придётся рулить панелью напрямую — благо, какая-то плата, адаптирующая его к какой-то шине, к дисплею уже прилагается.

Судя по наличию микросхемы ОЗУ (MN2114), плата представляет себе какой-то простенький фреймбуфер. Отлично, значит с динамической индикацией на 100+ катодов уже разобрались до меня :-)

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

Пара минут с тестером и карандашом — и вот уже отчётливо видно, где на разъёме шины данных входы, а где выходы.

Верхний ряд группами по 4 пина соединён со входом коммутатора 74LS257 — скорее всего, это вход данных шириной в 1 байт. Нижний ряд же идёт на инвертеры, выполняющие роль буферов — так хотя бы можно понять, что в нём есть 5 входных сигналов, и 2 выходных.

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

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

❯ Конструкция дисплея

Почему-то всё это время мне думалось, что это — ВЛИ, которому нужно около 20-30 вольт для свечения. Однако при прозвонке самой лампы тестером никакие пины между собой соединены не были — в случае ВЛИ так быть не может, ведь ему нужен накал катода. Ну, разве что, если нить накала перегорела…

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

Значит, скорее всего, это газоразрядный индикатор! По горизонтали у него расположены платы с кучей группированных транзисторов. По маркировке «L-S» никакие транзисторы в справочниках подходящих лет, увы, не находятся.

По бокам у дисплея — практически одинаковые платы с диодами, логическим инвертером (7414) и неизвестным модулем Mitsubishi MA7446-01.

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

• Поперёк «12-вольтовой» линии питания стоит конденсатор на 250 вольт — значит, как минимум, там должно быть высокое постоянное напряжение. Очевидно, положительное, если этот конденсатор проектировщики не вставили туда в роли петарды.

• На плате мультиплексора между питанием и выходом на дисплей есть цепь с транзистором 2SC1473 — он тоже рассчитан на 250 вольт.

Значит, скорее всего, на молексе вместо 12 вольт ожидается, как минимум, под сотню с лишним, а значит и индикатору для поджига нужно напряжение где-то такого порядка.

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

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

Ура, значит сам дисплей, как минимум, жив! Можно заказывать повышающий модуль на амазоне, а пока он едет — заняться восстановлением платы мультиплексирования.

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

❯ Диагностика платы мультиплексора

Под такое дело для проекта был куплен аж целый китайский лабораторник на амазоне — и подключение платы к нему показало, что жрёт она как не в себя! Почти что целый ампер, на конструкцию из 38 корпусов. Для логики серии 74LS это уж слишком много. Получается, в плате управления тоже что-то не так.

Так как компаратора навроде HP 10529A у меня нет, пришлось вооружиться осциллографом и таблицами истинности из даташитов.

На шине данных у ОЗУ хоть и завалены фронты, но в принципе всё смотрится не так и плохо:

А вот на прочих чипах местами встречается откровенная дичь — например, сигналы, у которых логический ноль где-то на 1,8 вольтах, а единица на 3,5.

В двоичной логике бывает True, бывает False, но встречается и «Да нет наверное»:

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

Видимо, собирали девайс на 74 логике из альтернативной вселенной.

По итогам пары дней такого копательства, вкупе с тыканием термопарой по всей плате даже туда, где солнечный свет не бывал, обнаружились следующие виновники:

• 107-1 (JK-триггер) — кипятится (60+°C) сразу при включении питания, выход закорочен на вход

• 107-2 — от выхода на вход 1кОм, в первом триггере выходной сигнал просажен (ну ещё бы), а второй вообще выдаёт не то, что в даташите, а погоду на Марсе. До кучи ещё и греется под 40 градусов.

• 107-3 — 2кОм со входа на выход, теплее всего остального.

• 393-1, 393-2 (сдвоенные 4-битные счётчики) — между тактовым входом и Vcc всего лишь 2 кОм, поэтому и сигналы выглядят странно.

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

Возможно, после пробоя там прошёл достаточный ток, чтобы расплавить припой и собрать его в такие горки?

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

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

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

❯ Повторный запуск

Выпаиваем всех подозрительных и заменяем их на панельки — ну вдруг опять вылетит, не паять же по новой :-)

Подаём питание. Один из светодиодов на макетке, раньше постоянно горевший, на сей раз гаснет — это хороший знак. Ставим крутилки в положение 0xFF, от балды трогаем один из джамперов, и…

Оно живое!!! И жрёт со всеми включёнными пикселями аж 25 ватт.

Экспериментально подбираем распиновку коннектора:

Способ управления тоже оказался весьма простым и понятным.

После подачи питания нужно дождаться, пока ~READY не уйдёт в лог. 0. Затем выставляем биты данных и дёргаем ~CLOCK. Этот байт попадёт в верхнюю половину самого левого столбца — пиксели, выставленные в «1», загорятся, а в «0», соответственно, погаснут.

Следующий импульс на ~CLOCK запишет байт в нижнюю половину самого левого столбца, потом — верхнюю половину второго столбца, и так далее — сверху вниз, слева направо. После записи последнего байта (нижняя половина самого правого столбца), следующий байт опять попадёт в верхнюю половину самого левого, т.е. запись идёт в цикле.

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

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

❯ Проба пера

Так как терпения у меня в организме ещё меньше, чем дофамина, то была распотрошена ещё какая-то плата из мусорки. Оттуда были извлечены TC4050B — буферы, которые отлично подойдут для согласования 3.3-вольтовой ESP32 с 5-вольтовой логикой на дисплее.

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

Дописываем ещё простенький рендер шрифтов, обновляем скетч:

Ну а дальше едем в Акихабару закупаться требухой для развития проекта до какого-то полезного состояния :-)

Опытный читатель уже догадался по содержимому этого хабара из Акихабары, что дисплею уготована типичная радиолюбительская участь — стать будильником-метеостанцией %)

Операционная система же обрела рабочее название Plasma Information System OS — или, если коротко, PIS-OS.

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

Но о сборке девайса и написании прошивки — уже в следующей части :-)

В реалтайме за обновлениями, среди тонны фоток еды и Мику, вы можете также следить в моём телеграме.

Также, можно посмотреть ход описанного в статье «в реалтайме», прочитав тему на EEVBlog.

• Написано специально для Timeweb Cloud и читателей Пикабу. Подписывайтесь на наш блог, чтобы не пропустить новые интересные материалы.

• Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать наши проекты.