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

Делюсь промежуточными результатами своей работы над эмулятором ПК Специалист.

https://pic.maxiol.com/images2/16950...eciarmlist.png

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

На текущий момент эмулятор имеет размер 26667 байт, из которых 4096 байт занимает ПЗУ Специалиста, а 7734 байта игра Зоопарк.

kernel.img - файл для запуска на реальном железе Raspberry Pi 1 или Raspberry Pi Zero
speciarmlist.img - файл для запуска под QEMU

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

https://www.youtube.com/watch?v=NIyWZqYi538

P.S. В видео я оговорился, сказав, что игра занимает 12 Кб. Это я перепутал с размером экранной области Специалиста, то есть с размером скриншота из этой игры в формате ПК Специалист.

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

Цитата:

---

Сообщение от HighLander

Проект закрытый? Исходников в общем доступе нет?

---

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

Цитата:

---

Сообщение от HighLander

Народ пилит под мурмулятор разные прошивки, может решите поучаствовать?

---

Да, знаю я этот проект. Весьма интересный. Но, во-первых, там всё пишется на С++, с которым я сильно на "вы". И мои ассемблерные наработки там вряд ли пригодятся. А, во-вторых, у меня элементарно нет готового устройства.

Удалось найти и поправить все грубые ошибки эмуляции i8080. Теперь полностью проходят все тесты 8080 INSTRUCTION EXERCISER. Очень полезная программа!

https://pic.maxiol.com/thumbs2/16951...uctionexer.png https://pic.maxiol.com/thumbs2/16951...uctionexer.png

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

Ещё много крови попила моя глупая ошибка в команде JP P,nn (JP a16). Я ошибочно проверял флаг чётности - P, в качестве условия. Ну правильно же, в условии присутствует буква P ;) А нужно было проверить совсем другой флаг - флаг знака S. И вот вроде почти все программы работали, но что-то было не так.

Научился работать с таймером Raspberry Pi и замедлил эмулятор до реальной скорости. Сейчас эмулятор рисует 50 кадров в секунду, а виртуальный КР580ВМ80А работает на скорости 2 МГц.

Первые опыты оказались неудачными, так как оказалось, что мой эмулятор работал медленнее нужного. Выяснилось, что скорости не хватало не только из-за включенной отладочной информации, но и из-за медленной отрисовки экрана Специалиста. Я использую 8-ми битный цвет, то есть 1 пиксель отрисовывается 1 байтом. Хотел для ускорения снизить битность, но выяснилось, что QEMU, на котором идёт большая часть отладки, не поддерживает эмуляцию ниже 8 бит. Да и сама Raspberry Pi минимально может только 4 бита на точку (16 цветов из палитры 32 бита). Пришлось как-то выкручиваться. И после того, как я сделал вывод графики по табличке вместо расчётов на лету, всё существенно ускорилось и появился серьёзный запас по скорости.

https://www.youtube.com/watch?v=DweYMHuUakY

После долгой и упорной борьбы сегодня пал последний (?) баг в эмуляции 8080. На текущий момент все игры, которые я запускал, запускаются и работают. Баг был в команде RAR (или RRA, если выражаться языком Z80). В процессе эмуляции этой команды я забыл обнулить верхнюю часть 32-х битного регистра. В результате при этой операции ошибочно устанавливался старший бит регистра А, когда не нужно, если в регистре С младший бит был установлен :v2_eek: Я сильно ограничен в средствах отладки, так как всё ещё не могу вводить никакую информацию в эмулятор (нажимать кнопки), а только выводить что-то на экран. Но каким-то чудом изловил этот баг и уничтожил его. Просто гора с плеч! Причём, что интересно - Exerciser проходил все тесты без ошибок! Но при этом программы на Basic'е не работали - Basic выводил какие-то осознанные ошибки, была ошибка в игре Almaz, и начисто отказывались работать все рекомпиляции ivagor'а и Тимохи - там, как потом уже выяснилось, начальная распаковка не то распаковывала.

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

Цитата:

---

Сообщение от CityAceE

Exerciser проходил все тесты без ошибок!

---

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

Да не, вопросов к Exerciser'у вообще никаких! Невозможно же вообще все варианты предусмотреть. У меня вот так хранение регистров было организовано, у кого-то иначе. Всегда можно допустить ошибку, которую никто никогда не увидит. А Exerciser в очередной раз сильно помог в борьбе с другими багами.

Но, кстати, в этот раз я допустил существенно меньше ошибок. Видимо, сказывается тот факт, что это уже мой 4-й раз, когда я с нуля пишу эмуляцию процессора ;) До этого были Z80 на ассемблере MC68000, далее 4-х битный процессор Game&Watch на Python, далее был i8080 на Python, и вот теперь i8080 на ассемблере ARM.

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

Цитата:

---

Сообщение от CityAceE

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

---

И, естественно, через несколько лет, прошедших с момента написания той процедуры, понимания у меня не добавилось, а оно только окончательно улетучилось. Ну, а если добавить к этому слишком ограниченные возможности по отладке создаваемого эмулятора, то становится ясно, что эмуляция клавиатуры в конкретном случае - дело непростое. Поэтому я взял и особо не вникая в логику переложил текст, написанный на Python, на ассемблер. Несколько раз перепроверил и прогнал в голове код :) И далее начал прикручивать геймпад в надежде, что процедура работает правильно. И оказалось, что она действительно работает правильно! Я реально кайфанул, когда увидел результат.

https://www.youtube.com/watch?v=LfY_C-9FhXU

Очень интересно читать про процесс разработки! Спасибо что делится этим! Не останавливайся!
Желаю довести проект до финала!
Прикольно что ты как бы пишешь проект с двумя уровнями эмуляции. Надеюсь что скоро у тебя получиться проверить работу на разбери!

Цитата:

---

Сообщение от parallelno

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

---

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

Цитата:

---

Сообщение от parallelno

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

---

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

Дошло дело до подключения матричной клавиатуры. Оригинальную клавиатуру с матрицей 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-я кнопка будет "нажата" автоматически. Три нажатых кнопки создают цепь для четвёртой:

https://pic.maxiol.com/thumbs2/16969...1010180921.jpg

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

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

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

https://youtu.be/VWODDZg6Gac

Цитата:

---

Сообщение от CityAceE

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

---

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

Изначально собирался сделать по-максимуму эмуляцию базового (журнального) варианта Специалиста без каких-либо наворотов. Однако, в очередной раз переделывая внутреннюю архитектуру эмулятора, получилось так, что добавить поддержку цвета стало относительно несложно. Решил вопреки изначальным планам не откладывать воплощение в дальний ящик:
https://pic.maxiol.com/thumbs2/16981...27.colors1.png https://pic.maxiol.com/thumbs2/16981...27.colors2.png https://pic.maxiol.com/thumbs2/16981...27.colors3.png

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

https://youtu.be/DotMjfrdGY0

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

https://youtu.be/gZHQHBIwrBk

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

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

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

https://www.youtube.com/watch?v=NC_Pw3ZIHjU

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

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

По моей задумке, такое переключение должно сидеть на кнопке 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 хотя бы в режиме чтения. Чувствую, что там будет танцев с бубном не на одну неделю...

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

https://pic.maxiol.com/thumbs2/17001...matrasreal.jpg

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

https://pic.maxiol.com/thumbs2/17001...384.matras.png

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

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

https://youtu.be/lrWOd91VsiA

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

Цитата:

---

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

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

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

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

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

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

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

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

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

---

Очень интересно смотреть, спасибо за подробный рассказ!

Интересно, у меня немного без дела лежит BPI-M2 Zero с Allwinner H3. Подозреваю, что совместимость с RPi заканчивается на наборе инструкций?

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

Цитата:

---

Сообщение от svofski

Очень интересно смотреть, спасибо за подробный рассказ!

---

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

Цитата:

---

Сообщение от svofski

Интересно, у меня немного без дела лежит BPI-M2 Zero с Allwinner H3.

---

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

Цитата:

---

Сообщение от svofski

Подозреваю, что совместимость с RPi заканчивается на наборе инструкций?

---

Ну, примерно так. Самое сложное у всех эти Banana, Orange и прочих Pi - это вывод картинки. Raspberry Pi хорош тем, что я могу просто запросить у GPU нужный мне графический режим и далее он всё сделает сам. Мне не нужно париться как переключить RCA на HDMI, как масштабировать экран и т.д. Всё это берёт на себя GPU, и делает это без моего участия. В то же время на других микрокомпьютерах формировать картинку должен я сам. При этом я нигде не находил никаких примеров как это можно сделать вне драйверов Linux. Вот мне сейчас было бы безумно интересно написать что-то подобное под Sipeed Lichee RV с процессором RISC-V на борту, но я не могу этого сделать всё по той же причине - нет возможность инициализировать HDMI и вывести на него картинку своими средствами.

Цитата:

---

Сообщение от svofski

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

---

Спасибо! Я на это очень надеюсь. Без вашей помощи я, безусловно, обойтись не смогу.

Цитата:

---

Сообщение от svofski

А ivagor все равно потом напишет тест, который твой эмулятор разоблачит.

---

Я в этом даже не сомневаюсь :)

Цитата:

---

Сообщение от CityAceE

Я даже не понимаю читает кто-то мою писанину или нет.

---

Я читаю. Просто обычно добавить ничего не могу. Просто созерцаю в изумлении.

Цитата:

---

Сообщение от CityAceE

В то же время на других микрокомпьютерах формировать картинку должен я сам.

---

GPU у Allwinner H3 точно есть, но готовых примеров его программирования я не нашел. Хотя Allwinner H3 и baremetal определенно гуглятся в одном контексте, что там на самом деле лежит в этих репах мне совершенно непонятно. Более-менее ясные только мигалки светодиодами на Си.

https://www.youtube.com/shorts/URbsU4x194Y

Цитата:

---

Сообщение от CityAceE

https://www.youtube.com/shorts/URbsU4x194Y

---

Расстраивает только одно. Сейчас то, что показано в этом ролике в обособленном виде занимает объём 5625 байт. Как по мне, так это очень много. А ведь это всего лишь чтение одного сектора флешки. Правда, где-то четверть, или может быть даже треть, от этого объёма занимают процедуры инициализации UART, а также формирование 16-тиричного дампа и вывод их в этот порт, ну и текстовые сообщения.

Начал было писать процедуру с нуля по описаниям протокола чтения SD. Но потом решил всё-таки упростить себе жизнь и оттолкнулся вот от этого примера. Однако там приводится кода на языке Си. Кроме того код жёстко привязан к архитектуре Raspberry Pi 3 и 64-битному процессору. Этот пример даже скомпилировать под RPi 1 невозможно - в коде даже присутствуют ассемблерные вставки критичных мест с кодами, которых отсутствуют в процессорах с 32-х битной архитектуре и некоторые другие нюансы, типа деления. По итогу все сложности преодолел и получил ту же самую процедуру, но уже на ассемблере, и без привязки к конкретной модели Raspberry Pi и 64-х битной архитектуре.

И ещё столкнулся с интересным моментом. Есть у меня консолька SF2000, которая очень капризна к картам памяти. Консолька не захотела загружаться только с одной microSD из моего зоопарка. Так вот процедура чтения сектора также отказалась читать данные с этой карточки - просто не может её проинициализировать. Хотя сама Raspberry Pi прекрасно с неё загружается. Наверное, не учтены какие-то нюансы.

Следующий этап - распознавание и чтение файловой системы FAT12/16/32. Я, безусловно, нашёл разные описания системы - с информацией по этому вопросу точно проблем нет. Но может быть кто-то может порекомендовать от себя реально толковое описание, возможно, которым когда-то пользовался сам?

Когда-то был проект "MP3 в кармане", там было использовано чтение FAT с карты SD именно на ассемблере, но для PIC-ов.
Сама страница с проектом давно недоступна, но тут есть архив с исходниками : https://tehnopage.ru/mp3_pleer_na_karte_pamjati

Да нет, мне интересна не столько какая-то конкретная реализация, а толковое описание системы "на пальцах", некое словесное описание алгоритма работы с FAT.

Комментарии в исходнике ? Нет, не то ?

Спасибо! Скачал. Поизучаю. Правда там не так много комментариев, как хотелось бы, и ассемблер мне незнакомый.

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

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

Petit FatFs http://elm-chan.org/fsw/ff/00index_p.html

- - - Добавлено - - -

Цитата:

---

Сообщение от CityAceE

Наверное, не учтены какие-то нюансы.

---

Может быть слишком высокая частота на начальной стадии переговоров? Вроде как начинать надо с 400 кГц, потом можно переходить на что побыстрее.

Цитата:

---

Сообщение от svofski

Вроде как начинать надо с 400 кГц

---

Да, там именно с 400 кГц и начинается. Но я в качестве эксперимента попробую понизить частоту. Спасибо за наводку!

Цитата:

---

Сообщение от CityAceE

Да, там именно с 400 кГц и начинается. Но я в качестве эксперимента попробую понизить частоту. Спасибо за наводку!

---

моя практика показывает что не обязательно. на ZX работает с частотой 14МГц всегда (Esxdos, но он без исходников), на Специалисте - 2МГц всегда (Sdos, https://zx-pk.ru/threads/29710-sd-ca...st-m-i-os.html)
железо для Специалиста - отсюда: http://специалист-пк.рф/index30.html
может поможет чем...