Comments 66
Ну что друзья, вот такой интересный материал у нас с вами сегодня получился. Хотя кто его знает, может и не особо интересный... Всё таки статья слишком примитивная по меркам того самого Хабра: буквально змейка на Arduino...
Проект в опенсорс отправится чуточку позже. Мне всё ещё нужно дописать синхронизацию с ПК и доделать нормальное SDK.
Игры скорее всего переедут из RAM в ROM без необходимости перекомпиляции всей прошивки: 128КБ это нормальный объём для Пак-Мана, или, например, Тетриса со Змейкой, но у меня уже есть зачатки микшера для PCM-звука и для многоканального звука такого объёма памяти не хватит :))
Ссылку на гаджет давать не буду, но если захотите - легко найдете сами :) Только один PiZero стоит под 800 рублей, а тут ещё и клёвый шилд...
Блин, забыл расписать самое главное для моих любимых инженеров: энергоэффективность и потребление!
В RP2040 есть два основных клока: SYSCLK и USB, оба тактируются от PLL с помощью VCO. SYSCLK можно как разогнать, так и затормозить, по умолчанию SYSCLK = 150МГц. При 150МГц, консоль кушает около 60-70мА, при 300МГц МК начинает заметно греться и консоль кушает уже примерно 90мА, а при 54МГц потребление снижается примерно на 5-10мА.
Одна из фич моего BIOS'а - возможность скейлинга клоков по запросу и максимальная экономия энергии. Я всё ещё хочу как минимум установить токоограничивающий резистор на подсветку чуть большего номинала, а как максимум наконец-то воткнуть туда ключ для регулировки подсветки "на лету".
Моя цель - стабильная работа консоли в течении примерно 10ч от аккумулятора 850мАч (BL-4C). Ну а что, инженеры Sony сделали крутейшую консоль с полноценным GPU, которая работает 6-8ч от 1Ач, а я будучи маминым ардуинщиком не смогу добиться хотя-бы такого же времени?!
Ну что же, будем надеяться, что все остальные доработки тоже будут успешными...
128КБ это нормальный объём для Пак-Мана, или, например, Тетриса со Змейкой
У Sega Mega Drive, минуточку, было 64К ОЗУ для игр, 64 для фреймбуфера и 8К для звука. У вашей консоли 115К фрейм-буфер и 150К ОЗУ ещё должно остаться, по идее.
Так в игротеке SMD присутствуют даже 3D-игры а-ля Wolfenstein, которые с построчным сканированием. Сами игры, естественно, ОЗУ своим кодом/ресурсами не занимают, лежат в ПЗУ
Именно эту особенность я хотел использовал за счет того, чтобы указатели на ресурсы получать из ROM, а код и переменные хранить в RAM. Однако нужно минимализировать использование кучи и перейти на статик пулы, а значит вводить шаблоны)
Это как раз и есть следующий шаг для автора. Вместо того чтобы загружать все в SRAM, можно было бы реализовать XIP (eXecute-In-Place) и выполнять код прямо из флеш-памяти, а в SRAM держать только переменные и стек. RP2040 это умеет. Это бы освободило почти все 128КБ под данные
Также хотелось бы выразить отдельную благодарность подписчику Alex. Выручил меня тем, что подогнал iPhone X для использования в качестве камеры, так что фото в статьях теперь снова норм :)
От читателя:
Скрытый текст
Ну как я и думал, статья слишком примитивная для Хабра. И зачем я вообще сюда что то продолжаю писать и публиковать
Картинки можно скрывать в спойлеры.
зажрались вабще... раменом из соседнего топика не иначе
Не переживайте по этому поводу. Надеюсь, вы это восприняли именно с сарказмом :).
Имхо, у вас весьма интересные нескучные технические статьи, как говорится, торт с мясом! Тогда как вы, Богдан, пишите обо всяких устройствах, сравнивает их, а также проводите свои эксперименты с написанием кастомного софта, есть люди, которые пишут откровенный шлак: буквально сегодня видел статью о Tiny11 и прочих бесполезных способах оптимизации Windows (к слову, справедливо собравшую >= 11 минусов, но всё же как-то попавшую в ленту).
Имхо, у вас действительно классно получается рассказывать - продолжайте и не обращайте внимание на hater'ов - они были, есть, и, увы, будут.
И ещё раз спасибо за инвайт! Пока размышляю над написанием интересного и полезного материала, пока не готов опубликовать просто... Надо собраться с мыслями и оформить...
Прикольное устройство. Некогда думал, что ввиду возможностей данной платформы логично будет увидеть консоль на RP2040, а они, оказывается, уже есть. Даже захотелось прикупить экземплярчик.
Будет ещё интересно написать под неё аппаратный эмулятор какой-то существующей платформы. Так как для чипа с такой мощностью это более чем реально.
С эмуляцией всегда одна проблема: ввод-вывод. Нужно будет не только написать эмулятор процессора, но и эмулировать видео- и аудиочипы, мапперы картриджей... Это огромный объем работы. Часто проще написать 10 новых змеек, чем один рабочий эмулятор
Для RP2040 уже сделано много эмуляторов разных платформ, на одном только «Мурмуляторе» их более 10.
Аппаратный эмулятор это как Мурмулятор?
Так даже Flipper Devices делал плату расширения на RP2040 для игр. Не знаю, взлетело или забили
Вот если бы объединить...
такую консоль для любителей мини-игр,
qwerty-клавиатуру или хорошую цифровую (с Т9) для любителей ретро-компьютеров,
осциллограф-анализатор сигналов для любителей ковыряться в электронике,
беспроводные интерфейсы как в fripper zero,
инженерный калькулятор (с CAS),
и графическую оболочку для удобного редактирования кода на самом устройстве, -
то это был бы убер-девайс!
Пока из массово доступного, наиболее приближается к этим требованиям LilyGO T-Deck, для которого существуют прошивки на базе MicroPython (Tulip).
А известны ли автору какие-нибудь подобные девайсы в форм-факторе обычного кнопочного телефона?
С таким функционалом - нет. Но андроид кнопочные телефоны можно хакнуть
CardPuter от M5 Stack. У меня есть данный девайс, даже софт писал. Почти все что ты сказал внутри него есть
получиться решение которое будет не особо удобно никому :) уж с ежом, все такое.. даже если взять отдельно flipper то он сам по себе - компромисс, а к нему еще прилепливают приблуды которые выглядят ну очень неудобно и похоже сделаны "чтобы было", и это еще без клавиатуры.
CardPuter тоже еще тот гибрид, но с интерфейсами богато, можно сделать что то более узкозаточенное, скажем с can/rs485/gpio, но не осциллограф пожалуй, да разрабатывать что то на микросдисплее.. ну не для всех удовольствие.
с клавиатурой и дисплеем побольше есть кстати еще функционал ssh консолии. а для разработки лучше бы туда просто линукс - там ведь и ssh будет и компиляторы. Но для полноценной терминалки пользователям нужны либо интернет, либо rs232/Ethernet. и такой девайс сделали на основе малины, но он довольно громоздкий , ну еще и микроноут GPD WIN позиционировался в эту оперу. Мне понравилось одно решение в Ютубе - Ipad Pro как экран+клавиатура, и к нему по usb подключена малина, на которой есть буквально все. А вот чтобы просто планшет под linux - уже всегда какие то моменты, хотя тоже есть ведь.
Очень грамотное решение с DMA для обновления экрана. Отказаться от попиксельной отправки в пользу полного фреймбуфера - классический компромисс память в обмен на скорость. На RP2040 с его 264 КБ SRAM это абсолютно оправданно. А вот отказ от DMA в оригинальной прошивке это просто криминал) Это показывает, что сэмплы писал человек, который вообще не понимает, как работает микроконтроллер
Можно немного схитрить и сделать виртуальный фреймбуфер с разрешением x2 ниже (120x120, само собой картинка будет апскейлится обычным Nearest-фильтром, зато фреймбуфер будет занимать всего 28КБ), тогда блиттинг будет всё таким же дешевым и памяти расходоваться будет меньше. При этом сама логика DMA будет сложнее: необходимо будет выделить отдельную память под один настоящий сканлайн, где мы будем по прерыванию от DMA по факту передачи сканлайна "растягивать" виртуальную строку фреймбуфера в настоящую. Примерно вот так:
uint32_t scanline[];
void DMAIrq()
{
rowPtr = frameBuffer.Width * currentRow;
for(int i = 0; i < frameBuffer.Width; i++)
{
CColor sample = frameBuffer.Pointer[rowPtr + (i >> 1)]];
uint32_t dwordSample = sample | (sample << 16);
scanline[i] = sample;
}
dmaSetupTransaction(dmaChannel, &scanline, frameBuffer.ScanlineSize, &DMAIrq);
}
Можно оптимизировать ещё дальше и сделать обработку прерывания ещё немного быстрее.
Также у контроллера есть аппаратная поддержка палитровой графики и 8-битного пиксельформата, если для игры хватает 256 цветов (как на SEGA) - то можно использовать и его, тогда фреймбуфер будет весить 57КБ.
Если же подойти к реализации вывода графики с учётом опыта предков, то в целом можно формировать сканлайны и на лету - тогда по памяти вывод графики будет "бесплатным", однако DMA использовать не выйдет. Но это всё равно очень хороший способ для, например, Atmega328P :)
А ещё можно ничего не отрисовать раньше времени, а собирать список объектов для отрисовки: 1) прямоугольник, координаты, 2) битмап с координатами и указатель на битмап. И тд. И отрисовать это все по списку в буфер 1/8 экрана за раз и отправлять дма по частям...
Если очень-очень условно, то PPU так и работает.
Lvgl тоже так работает. То есть мы отдаем ей список ui объектов, а она сама потом их отрисовывает частями в маленький буфер хоть 1/16 даже.
Если у тебя так же то потребление памяти должно быть 240×240×2÷8 = 14400 плюс буфер под список объектов.
Всё не так просто. Чем больше рисуемые спрайты и чем больше их общее число - тем сильнее будет падать производительность. Мне лично больше нравится подход с фреймбуфером т.к памяти хватает с головой :)
Если что, в RAM будет только код игры, в ROM будут ресурсы и благодаря XIP мы сможем без проблем их адресовать с помощью виртуальной файловой системы или другого механизма дескрипторов.
Так на RP2040 мурмулятор работает. А это - возможность эмуляции XT.
Правда это все для пердолинга и я максимально не рекомендую этим заниматься. Только разве что как хобби. Потому что времени это отнимает очень много а результат - немного плачевный
Руководствуясь критериями выше, я решил писать BIOS на C++ (на деле C с классами) с активным использованием интерфейсов и VMT.
И у Вас получился Symbian S40. :-) Спасибо, за интересную статью.
Мне доводилось реализовывать полноценный фрейм-буфер в 1/4 части от размера. Так как у выбранного МК (STM32F405) было недостаточно ОЗУ для хранения всего обьема изображения дисплея, то под изображение выделялось только четверть. Обновление экрана происходило в четыре фазы. При рендеринге изображения в методе Draw() отрисовывалась только та часть экрана, которая необходима для следущего обновления. Само обновление также как и у Вас производилось DMA контроллером - засылалось по SPI в дисплей FTDI FT800 (480x272, RGB565). Получилось чуть более 12 полных FPS, по 48 полей в секунду. Для решаемой тогда нами задачи (HMI для системы управления сложным агрегатом) этого было вполне достаточно.
Также к этой теме была написана небольшая ОС с графическим оконным интерфейсом, минималистичной файловой системой во Flash и запуском ELF с релокацией в SRAM. Исходники доступны тут: https://github.com/Fabmicro-LLC/GroveOS.git
В целом на серьезные технические темы пишете, а каждый второй абзац заканчивается восклицательным знаком, а то и тремя, или смайликом. Пора взрослеть и писать технические статьи серьезно.
Экземпляр CSystem создаётся так называемым «портом» на конкретную плату, который должен заполнить структуру с указателями на реализации подсистем — прямо как machine-файлы в Linux! И RAII не нарушили, и полный контроль без костылей сохранили — ляпота!
а при чем тут RAII?
и называть вашу библиотеку словом BIOS несколько некорректно
Называйте фирмварью, как вам удобно.
Вообще это уже практически ось и отсылки к ПрямоДровам (которые я и по сей день считаю эталоном минимализма, когда уже можно использовать всякие ускорялки блиттинга и наложения чего-то на что-то, но апи ещё не напоминает классификацию животных по Борхесу) сразу в моих глазах прибавили +150% к сему фирмварю :) Меньше только прямая работа с железом -- но такое себе мог позволить только MDA/CGA/EGA/VGA и примкнувшие к ним «Геркулесы», из-за суровой полной стандартизации. Юзебокс и мой воображаемый наследник оного Юзефон тоже предполагают такой подход, но в данной экологической нише он неуместен, а ПрямоДрова прямо-таки идеал :)
А насчёт самих приложух, кстати, идея есть. Я её в статье про юзефон тоже упоминал. Легко откомпилировать бутылочные горлышки по месту при запуске :)
На Nucleo c STM32F746 можно запилить приличную консоль?
нужна подсистема таймера и только тогда можно писать портируемые игрушки.
Разработка этого BIOS для портативок тянет за собой еще и создание SDK для написания игр для таких консолей, и студии для создания игр на базе этого SDK, только с подходом low-code: бОльшая концентрация на содержимом игры, но остается доступ к подкапотке игры, ну, как Unity.
Ну и сделать проект BIOS открытым, чтобы можно было портировать на разные платформы, а игровую студию - даже монетизировать.
Удачи с этим😌
Статья класс! Предложений или замечаний не дам, ибо в этом всём плане слаб, но читать интересно. Ну и довольно мотивирующее.
Автор, тебе бы со своей головой сначала разобраться.
Статья была интересная. Не всем, потому что нельзя угодить всем. Это достаточный повод, для того чтобы быть довольным, а не сносить в истерике контент.
Задам вопрос, витающий в воздухе:
Когда запуск Doom?
Дочитал, ну что супер, ждём от Вас следующих модификаций. Не забрасывайте проект!!
Спасибо за теплые слова! Сейчас дописываю загрузчик программ так, чтобы .text у нас был в SRAM, а ресурсы можно было подтягивать с помощью API BIOS'а.
Плюс надо дописать нормальную поддержку CXX, т.к у меня до сих пор нет инициализации статических переменных, а там может и контейнеры допишу по типу фиксированных пулов.
Вот вроде и не первый год знаком с MCU, а я бы игры написал как раз как в тех сэмплах) После такого начинаешь думать, что вовсе и не знаком с микрухами, когда тут в качестве хобби занимаются уже такими сложными вещами...
Спасибо за статью, было интересно.
По моему наоборот хорошо, что там такой хороший дисплей, а то на эту вашу классику 128*160 без слёз не взглянешь.
стоит ли добавлять в консоль поддержку полноценного UTF-16, если учесть что основной таргет на русскоязычную аудиторию
Обязательно. Либо UTF-8.
Не делай хуйни.
Алсо, тебя читают не так мало людей, не говорящих по-русски (обнимаю одного из).
Да это в любом случае полезно, прост тогда и шрифты растолстеют :)
А это природа не терпит пустоты :) где то килограммы убыли а где то килобайты прибыли :) На этой теме можно каламбурный заголовок придумать
Не обязательно же. Можно сделать кастомный файл шрифтов, в котором прорисована только нужная сотня символов, не обязательно полный Arial-Droid-кто-там ещё тащить. В конце концов, 2040 отлично с SD-карты сможет прочесть нужные символы из файла на десять бегамайт.
Но если заложить в систему баг, при котором для смены языка с русского на немецкий или арабский надо прошивку менять - это очень, очень плохой дизайн.
Я купил игровую консоль и написал для неё… BIOS