Эмулятор ПК Специалист "SpeciARMlist"

[CityAceE]

Желаю довести проект до финала!

Спасибо! Я действительно переживаю за этот момент. И не из-за лени или потери интереса, а из-за технических моментов. Не вся информация есть по программированию железа. И спросить не у кого. Например, вообще никто и никогда не реализовывал чтение/запись SD-карты на ассемблере. Описания нет, примеров нет. Но у меня есть зацепка! Нашёл пример кода на Си для чтения сектора SD-карты. Скомпилировал, проверил, читает нулевой сектор карты даже под QEMU. А уж если удастся прочитать сектор, то без ощутимых проблем удастся потом реализовать поддержку FAT32 по документации. Однако там в сишном коде есть несколько ассемблерных команд для ARM64, а у меня другая архитектура без этих команд и системных регистров с которыми эти команды работают. Пока ещё глубоко не погружался в эту проблему, но очень надеюсь, что-нибудь придумаю. Но опять же повторюсь, что обсуждать это всё не с кем, советов получать не от кого. А уж если удастся решить эти фундаментальные проблемы, то далее реализовать эмуляцию любого другого компьютера на i8080 уже будет делом техники. Возможно кто-то другой, воспользовавшись моими наработками захочет сделать, например, эмуляцию Вектора-06Ц

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

Это про QEMU, видимо? Эмулятор под эмулятором. Но сейчас я дошёл до стадии, когда всё приходиться уже отлаживать на реальной железяке, так как в QEMU нет поддержки GPIO.

[CityAceE]

Дошло дело до подключения матричной клавиатуры. Оригинальную клавиатуру с матрицей 12*6 я пока отложил в сторону и решил вначале поэкспериментировать с более мелкой клавиатурой от Arduino с матрицей 4*4 (16 кнопок). И не зря! То, что в теории кажется простым, на практике может оказаться сущим адом. Вот так у меня всё и оказалось. Я видел примеры, как записывать в порт GPIO, как оттуда читать, и в теории всё выглядело довольно просто. Но у меня сходу ничего не заработало. Ну и для начала пришлось разобраться с путаницей расположения пинов GPIO на плате Raspberry Pi и их соответствию битам в MMIO-портах. И вот, вроде казалось бы всё сделал: отправляю единицу в порт, на другом конце её встречаю, но что-то идёт не так - на входе всё время единица. Отключил клавиатуру и подключил одиночную кнопку. Ничего не поменялось - единица всё время на месте, независимо от того, нажата кнопка или нет. Написал программу для проверки данного феномена и увидел, что единица на выходе всё-таки не всегда - иногда там бывает и ноль, и даже иногда кнопка срабатывает так, как я ожидаю. При этом, если физически отключить кнопку, то порт успокаивается и на входе всё время 0. Можно даже отвёрткой позамыкать нужные пины и всё работает, как задумывалось. Но стоит только подключить к пину хотя бы единичный провод, то на входе начинается чехарда. Провод от кнопки работает, как антенна, и засылает в порт единицы. Полез читать, что по этому поводу скажет Интернет и нашёл печальную информацию:

Во второй части статей «GPIO для чайников» мы подключали кнопку между двумя портами. Один порт устанавливали на «вывод» и в состояние «1», а другим портом читали эту «1» через кнопку. При отпущенной кнопке на втором порту читался «0», а при нажатой- «1».

Всё вроде бы работало. Но недавно у такого способа подключения обнаружился один неприятный недостаток. Такое подключение кнопки оказалось неустойчивым к помехам. Когда я свою RPI подключил к сети при помощи Wi-Fi USB донгла, то все программы, в которых использовалось такое включение кнопки, просто сошли с ума. RPI детектировал нажатие кнопки даже тогда, когда к ней никто не притрагивался. Виной всему оказался длинный провод, которым была подключена кнопка к RPI. Работающий Wi-Fi адаптер наводил на нём потенциал, с уровнем достаточным для детектирования «1» на порте GPIO. Такое поведение кнопки никуда не годится.

Нужно принимать меры по помехозащищённости. В данном случае поможет использование экранированного провода до кнопки, либо даже простое уменьшение длины проводов, соединяющих кнопку с RPI. Но можно поступить проще. Раз наш RPI реагирует на помехи при отсутствии сигнала на входе, то разумным решением будет перевести порт, которым мы читаем состояние кнопки в состояние логической «1». Раз на нём всегда будет «1», то уже никакая помеха не сможет этот порт перевести в «0». А значит, наш порт станет невосприимчивым к помехам.

Но мне такое решение вообще не подходит! Мне нужно подключаться именно между двумя пинами GPIO. И ведь работает же стабильно геймпад, который я подключил ранее. Но там я воспользовался готовым примером, да и геймпад работает по сути по последовательному интерфейсу - там с данными только один провод. И когда я начал разбираться дальше, то выяснилось, что геймпад подключен к одному из двух GPIO, которые аппаратно притянуты у нулю. В тот момент мне показалось, что всё - приплыли. Но всё-таки я решил не сдаваться раньше времени. Полноценно подключил эту Ардуиновскую клавиатуру, загрузил Linux и запустил пример на Python по обслуживанию этой клавиатуры. Удивлению моему не было предела, так как эта же клавиатура, которая так чувствительна к помехам в моём эмуляторе, абсолютно стабильно работает под Linux'ом! Значит, какое-то решение должно быть!

В общем, выяснилось, что в Raspberry Pi есть возможность программно включить принудительную притяжку любого порта GPIO либо к 0, либо к 1. Что, собственно, программа на Python и делала. Только использовала она для этого внешнюю библиотеку, в недрах которой уже и выполнялась эта притяжка. И никаких примеров на ассемблере, как это осуществить, найти не удалось. Пришлось обращаться к документации по чипу, и уже там я нашёл требуемую информацию по портам и сигналам. Сделал всё, как было сказано в описании. И, вуаля, от помех не осталось и следа! Радости моей не было предела! Клавиатура заработала должным образом. Но и на этом мои мытарства с клавиатурой не закончились. Далее я столкнулся с какой-то таинственной проблемой - при добавлении очередной ассемблерной команды у меня всё ломалось и переставало работать. Я пытался найти закономерность, грешил и на невыровненную память, и на ошибки в макросе загрузки длинного адреса, и на другие моменты, но проблема никак не разрешалась. Убил просто уйму времени и нервов. А причина оказалась до безобразия простой - нужно было просто после записи в порт выдержать некоторую паузу. И вот после того, как я расставил паузы, всё заработало действительно стабильно.

Начал тестировать то, что получилось. И снова столкнулся с неприятным моментом, а именно с фантомными нажатиями на клавиши, так называемым ghosting'ом. Это проявляется в следующем: если нажать три кнопки на вершинах любого прямоугольника в пределах матрицы клавиатуры, то 4-я кнопка будет "нажата" автоматически. Три нажатых кнопки создают цепь для четвёртой:



Я всю голову сломал, пытаясь понять, как это победить. Но здравый смысл подсказывает, что победить это нереально, если только не вмешиваться в саму матрицу клавиатуры и не поставить диоды на каждую кнопку, чтобы они не пускали сигнал по ложному маршруту. Очень смущало то, что клавиатурный тест С.Рюмика под эмулятором Специалиста на PC показывает три нажатых кнопки, а 4-я при этом не "нажимается". Это я ошибочно взял за истину и пытался каким-то образом сделать у себя так же. Но стоило только запустить тот же самый тест на реальном Специалисте, как всё встало на свои места - там и в помине нет того же поведения, как на эмуляторе на PC. Ну, и на этом моменте я уже действительно окончательно выдохнул.

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

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

[lexarr]

есть возможность программно включить принудительную притяжку любого порта GPIO либо к 0, либо к 1

Конечно нельзя размыкать порт и надеяться, что там будет 0. Необходимо наличие цепи (притяжки внешней/внутренней) для чёткой установки потенциала. Если даже в обычный полевик потыкать мультиметром, он может проводить или не проводить ток из-за наличия заряда, который надо куда-то рассасывать.

[CityAceE]

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

[CityAceE]

Снял двухминутное видео по обновлению:

[CityAceE]

Подключил клавиатуру PS/2 с помощью 4-х проводов к разъёму GPIO микрокомпьютера Raspberry Pi, написал драйвер и обучил свой эмулятор работе с этой клавиатурой:



Напоминаю, что пишу всё на ассемблере с нуля под голое железо (не под какую-либо ОС) без использования чьих-то наработок и сторонних библиотек.

[Advertiser]

[CityAceE]

Подключил клавиатуру PS/2 через копеечный преобразователь уровней, тем самым устранил опасность подгорания выводов GPIO от 5-ти вольтовой клавиатуры.

Организовал "умную" раскладку для удобного набора текста в Мониторе.

[CityAceE]

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

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

По моей задумке, такое переключение должно сидеть на кнопке PrintScreen. А эта кнопка наряду с Pause/Break зачем-то имеет нестандартный код отличный по размеры от других клавиш. В итоге, хоть ты тресни, при моей организации опроса клавиатуры, PrintScreen распознавался, как Left Control. Ну с этой проблемой относительно быстро я справился, и уже предвкушал переключение режимов, но что-то снова пошло не так. Режимы вообще не захотели переключаются!

При старте системы нужный режим задать можно. Но! Если уже однажды экран задал, то потом он, как гвоздями прибитым оказывается! Максимум чего мне удавалось добиться - это гасить экран. И что там на этом погашеном экране происходит одному богу известно. То ли эмулятор завис, то ли работает про себя Отсутствие зависания я научился определять, написав процедуру сброса Raspberry Pi. Далее вставлял эту процедуру в интересующие места. И если компьютер перезагрузился, значит до этого момента всё шло правильно. А если перезагрузки не произошло, то он где-то там по дороге завис.

Вся беда, что в Интернете вообще ничего не пишут про смену режимов экрана! Всем достаточно просто раз задать параметры и всё, а чтобы потом что-то менять - это никому не нужно. В общем, с этой проблемой я завис почти на неделю. Перво-наперво пришлось начать с того, чтобы полностью разбираться с тем, как ARM общается с GPU, и вникать во все детали, а не вслепую использовать готовый пример инициализации экрана. Здесь я открыл для себя много интересного. Например то, что будучи подключенным к TV по композитному разъёму Raspberry Pi предлагает задать особое разрешение экрана 656*416. И, кстати, подключение к любому старому TV через композитный кабель, да ещё в цвете - это довольно крутая фишка, которую должны оценить ретрокомпьютерщики. Я потом обязательно сделаю оптимизацию картинки для такого типа подключения.

Ну так вот... Когда у меня что-то более менее улеглось в голове по поводу GPU, при моих дальнейших экспериментах у меня экран стабильно начал гаснуть, ну или комп виснуть - сходу этого понять было сложно. На этом этапе я решил внедрять в эмулятор поддержку UART. И у меня даже уже был готовый рабочий пример, который я выгрыз из одной BareMetal программы. Но, как обычно, всё пошло не по плану. Пример, который я перед этим тестировал, отказался работать, хотя пару месяцев назад всё было ОК. Потратив какое-то время я выяснил, что код для обслуживания UART, отказывается работать с новым загрузчиком от производителя Raspberry Pi. После отката на старую версию я, наконец, снов обрёл возможность отправлять что-то в консоль. Но опять же, этот пример работал только если запускать его с SD-карты, а если же загружать по UART, как я и делаю, то этот код будет молчать. Ну хотя бы так. И вот я начал интегрировать этот код к себе в эмулятор. И что бы вы думали? Правильно! У меня ничего не заработало. И снова время на эксперименты и выяснения. Оказалось - конфликт с инициализацией матричной клавиатуры. Инициализацию клавиатуру я временно отключил и после этого худо-бедно заработало. Таким образом мне удалось понять, что темный экран - это чаще всего просто потеря изображения, а не зависание эмулятора.

Но за два дня я изрядно задолбался записывать каждую сборку на SD-карту. И я решил отложить разбирательство с экраном и сосредоточится на UART. Потратив ещё довольно много времени, мне удалось написать правильную инициализацию UART и отправку в него данных. Зато в итоге я получил неконфликтующий с моей матричной клавиатурой код, который теперь к тому же заработал и с новыми системными файлами, и будучи загруженный через UART. Теперь я обрёл возможность по нажатию кнопки получать по UART содержимое регистров ARM. Если сдержал себя от того, чтобы не начать писать полноценный отладчик типа Скорпионовского монитора-отладчика.

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

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

В процессе написания эмулятора знаний по архитектуре Raspberry Pi становится всё больше. Теперь хоть свою OS пиши Правда пока остаётся одни фундаментальный вопрос, за который я пока даже не брался - это поддержка microSD. И беда в том, что я не не нашёл ни одного BareMetal приложения вне рамок сишной библиотеки Circle, которое поддерживало бы SD хотя бы в режиме чтения. Чувствую, что там будет танцев с бубном не на одну неделю...

[CityAceE]

Матрас на моём Лике:



И его реализация в эмуляторе:



Конечно, не хватает помех, но если откинуть этот момент, то сам матрас побайтово совпадает с реалом.

[CityAceE]

Новая серия моего дневника эмуляторостроения:



Краткий пересказ видео от YandexGPT:

Эмулятор ПК Специалист: переключение режимов экрана

00:00 Создание эмулятора для ПК Специалист

• Автор рассказывает о своем проекте по созданию эмулятора для ПК Специалист, советского компьютера, разработанного в 1985 году.
• Эмулятор написан на языке программирования Assembler и работает на Raspberry Pi.

03:42 Подключение и демонстрация работы

• Автор демонстрирует работу эмулятора на разных типах подключения: композитный и HDMI.
• Эмулятор может работать с разными разрешениями экрана, включая 1366x768.

11:42 Особенности эмулятора

• Эмулятор является безоперационной системой, все данные обрабатываются графическим процессором.
• Автор планирует создать эмулятор для других советских компьютеров, таких как Радио 86РК и Вектор 06Ц.

14:52 Демонстрация работы с эмулятором

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