Моддинг-сцена с разработкой и портированием кастомных прошивок для Android-устройств существует вот уже более 10 лет. В основном, энтузиасты пытаются проапгрейдить свои устройства путем портирования более свежих версий Android, чем предлагает производитель девайса. Чего уж говорить, если Galaxy S III, которому уже 12 лет стукнуло, получил неофициальный апгрейд до Android 14. Порой мне в голову приходят различные, весьма странные моддерские мысли: например, почему бы не портировать на старенький смартфон… ещё более старую версию Android, дабы посмотреть «что будет». Казалось бы «портировал и портировал», но в процессе работы я столкнулся с множеством интересных нюансов и особенностей работы Android, о которых хотел бы рассказать и вам — моим читателям! Сегодняшняя статья будет в классическом «научпоп»-стиле без кода, зато с подробными объяснениями одной из техник портирования Android-прошивок путем патчинга скриптов для конфигурации системы и подмены Board-specific библиотек, дабы система «увидела» всё необходимое железо! Интересно? Тогда жду вас под катом!

❯ Мотивация

У меня, как и у многих моих читателей, одной из первых версией Android в жизни была 2.x. Наверное, я уже никогда не смогу забыть первые впечатления от использования своего новенького, пусть и бюджетного и слабого Android-смартфона после простеньких китайских кнопочников. Эти ощущения были прекрасными: вот я разблокирую смартфон, потянув «замочек» вправо, свайпаю рабочие столы и тапаю на значок приложения браузера, выполненный в стиле скевоморфизма, загружаю полноценную страницу Википедии через GPRS-сеть (мой первый смартфон не имел 3G) и плавно скроллю страницу, не забывая смахнуть шторку вниз и проверить статус уведомлений в пока ещё совсем простенькой панели нотификаций… Это были по настоящему ламповые впечатления, которые не смог превзойти ни один современный девайс: ни AOSP, ни MIUI, ни OneUI.

Моим первым смартфоном была китайская реплика Samsung Galaxy S III Mini, купленная в самом начале 2013 года. Возможно, кто-то из вас помнит, как подобные дешевые смартфоны и планшеты «Sumsanc» можно было купить на рыночных развалах, в метро и прочих местах, где допускается торговать несертифицированными гаджетами. Даже с учётом накрутки, эти смартфоны стоили всего 2 000 рублей, что было просто «подарком» для цены абсолютно нового гаджета. Девайс был крайне простым для начала 2013 года и имел следующие характеристики:

• Процессор: Spreadtrum SC6820. Одно ядро Cortex-A5 на частоте до 1ГГц, Mali400 MP в качестве GPU. Чипсет был крайне высоко-интегрированным для своих лет: в одном корпусе располагалось ARM-ядро, GPU, контроллер питания, GPS, множество периферии (например, DAC), а также Baseband-часть GSM-радиотракта. BT/Wi-Fi реализовывались в отдельном комбочипе разработки RDA.

• Память: 256Мб DDR1 ОЗУ/256Мб NAND-памяти в одном чипе eMCP от Hynix. Предположительно, эти чипы остались на складах ещё со времен первых Android-смартфонов, но очень быстро потеряли актуальность и их, вероятно, отдавали «за бесценок» что позволило ещё сильнее снизить цену производства таких смартфонов.

• Дисплей: безоговорочно, TFT, обычно с разрешением не выше 480x320, что для 3" дисплея было нормальным, но для 5" — уже несколько маловато. Тем не менее, сами дисплеи были нормальными и глаза от них не «вытекали». Тачскрин обычно ёмкостной, на 2 касания.

• Android: 2.2, на некоторых похожих моделях встречался 2.3.

• Аккумулятор: ~1.500мАч, не больше. По форм-фактору напоминает BP-4L, без проблем подходит от многих S60 смартфонов Nokia тех лет.

Не густо, да? Уже в апреле того же года вышел Galaxy S4 с Snapdragon 600, 2Гб ОЗУ и 32Гб встроенной памяти, а мы тут с одноядерным чипсетом и 256Мб ОЗУ сидим. Но мне, будучи школяром, это было за счастье — чего я на нём только не делал, и на PHP какие-то WAP-сайты динамические пытался писать и на FTP заливать, и даже ADT Bundle скачал, дабы попытаться что-то своё запилить под собственный смартфон! В общем, я был счастлив, несмотря на лаги девайса. Именно того девайса у меня уже давным-давно не осталось… но память я всё ещё храню и стараюсь дать новый дом таким китайчикам, которые в большинстве своем оказались на свалке истории в новом мире современных смартфонов!

Но на самом деле, смартфоны 10+ летней давности могут быть интересны и своим форм-фактором: в современном мире едва ли можно найти хоть какие-то телефоны с полноценной QWERTY-клавиатурой (исключение — смартфоны UniHertz, которые стоят недешево) и уж тем более, боковые слайдеры. Поэтому мой интерес к подобным девайсам очень легко объяснить!

Однако, порой мне самому хочется снова пережить эти эмоции и ещё раз походить с подобным девайсом «на каждый день», даже когда на Android 2.2 особо никакие сервисы уже не работают. Отчасти, я решаю свои проблемы сам и пишу клиенты нужных мне сервисов, если они действительно нужны, дабы рано или поздно всё таки вдохнуть новую жизнь в «старенькие» девайсы. И казалось бы, это можно списать на синдром утёнка и банальную ностальгию, но мои ощущения «ламповости» отнюдь не мимолетны и всё равно меня тянет именно на те смартфоны, с тем самым интерфейсом, которые я когда-то увидел впервые!

Пожалуй, сказать что я решил портировать старый Android на отнюдь не новый смартфон «просто так» было бы ложью. Я всё ещё верю в то, что смогу в одиночку хотя бы частично вдохнуть новую жизнь в эти девайсы и позволить им работать с современными сервисами, дабы они могли приносить пользу не только мне, но и другим людям, которые намеренно занимаются дауншифтингом или вынуждены сидеть на девайсах с старыми версиями Android! Сегодняшним нашим подопытным станет один из представителей подобных noname-смартфонов тех лет, реплика Galaxy S III Mini на том самом железе, на котором работал мой первый смартфон. Однако с завода на нём стоял Android 2.3 — слишком свежая, по моему мнению, версия системы, которую я конечно-же захотел откатить до Android 2.2!

Задача облегчалась тем, что смартфоны на этом чипсете с Android 2.2 уже выходили, что позволило мне портировать прошивку путем несложных патчей скриптов инициализации и копирования Platform-specific файлов, дабы завести все необходимые для смартфона модули. А поскольку о таком простом способе портирования свежих и старых прошивок знают далеко не все мои читатели — я решил написать об этом отдельный подробный материал! Давайте же перейдём к практической части нашей статьи.

❯ Первые шаги

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

• Загрузчик: при включении смартфона, первичный загрузчик BootROM, аппаратно-прошитый в чипсет ещё на этапе изготовления чипа, инициализирует некоторую периферию, загружает вторичный загрузчик из NAND (коим может быть SPL — Second Program Loader, занимающийся инициализацией контроллера DDR и UART) и передаёт ему управление. Вторичный загрузчик в свою очередь передаёт управление U-Boot — в задачи которого входит также инициализация периферии, обработка устройств постоянной памяти (например, NAND или контроллер SD), загрузка ядра Linux и конфигурация самого процесса загрузки. U-Boot можно считать эдакой альтернативной UEFI/BIOS в мире не-x86 устройств. В смартфонах на базе чипов MediaTek и Qualcomm, роль U-Boot выполняет LK — маленькая ОС, в задачи которой входит инициализация периферии и передача управления ядру Linux с помощью программы aboot.

• Ядро Linux: после загрузки образа ядра с initrd (небольшая файловая система, которая загружается сразу в память и содержит в себе скрипты для конфигурации всего остального) и передачи управления ядру, Linux начинает выполнение программы с PID 0 — /init, в задачи которой входит выполнение скриптов инициализации userspace-окружения системы в init.rc. При этом смартфон уже фактически готов к работе — в одной из своих статей я показывал, как можно приостановить загрузку Android и выполнять свой код, используя все ресурсы смартфона для своих целей.

• zygote и app_process: помимо запуска необходимых для работы смартфона служб, динамической загрузки драйверов (с помощью insmod) и определения режима загрузки (например, если телефон подключили выключенным к зарядке — необходимо показать анимацию этой самой зарядки), init.rc запускает две программы, одна из которых необходима для функционирования системы. Первая — это bootanimation, которая проигрывает анимацию включения смартфона и app_process, который в одном из режимов работы превращается в zygote — самый важный процесс для работы Android, который предварительно при старте системы загружает системный Java-байткод, отвечающий за отрисовку интерфейса, проигрывание звука и т. п. из framework.jar и другие системные ресурсы (например темы и изображения), а затем при запуске каждого приложения просто клонирует сам себя (с уже загруженными ресурсами) и начинает выполнение байткода любого запущенного Android-приложения или службы.
  
  Каждое запущенное приложение или служба — это отдельный app_process, в том числе и лаунчер, и Google-сервисы и клиент любого мессенджера.

Всё выглядит просто и логично, не так ли? Подытожив, можно сказать что для того, чтобы система минимально стартовала, нам необходима подходящее ядро для нашего устройства, рабочий init.rc и адекватно запускающийся init.rc. Кроме того, Android зависит от некоторых платформо-специфичных библиотек: в основном, они находятся в /lib/hardware и без них система может не запуститься или что-то может не работать. Особенно осторожно надо подходить к libhardware.so.

Как я уже сказал выше, прошивку мы будем портировать от другого смартфона на том-же чипсете и что забавно — такую же реплику, просто более-раннюю! «Из коробки», мой смартфон работает на Android 2.3, значительно более стабильной, чем изначальный порт 2.2 на эту платформу. Отличий 2.3 от 2.2 достаточно: например, на 2.2 совсем иной цвет шторки, по умолчанию стоит Light-тема, нельзя закрывать уведомления смахиванием и в целом система несколько отличается внешне. Для работы нам нужно будет два образа прошивки: ту, которую будем портировать и та, которая стоковая. Прошивки в смартфонах на платформе Spreadtrum распространяются в формате pac, однако нет никаких проблем подменить образ раздела в ResearchDownload — фирменной утилите для прошивки смартфонов на этом чипсете.

Я решил взять прошивку от FeiTeng N9300 Mini, родная для моего смартфона — M-Horse 9500 Mini. В случае моего девайса, разметка и список разделов между устройствами никак не отличалась, поэтому изначально я напрямую прошил раздел system.img, дабы посмотреть что будет с устройство. Не забывайте, что ядро и init.rc хранится в образе boot.img — поэтому прошивка раздела system безопасна!

❯ Первый запуск

После прошивки чужого раздела system, смартфон стартовал… однако работал несколько странно: во первых, у нас не было сети, во вторых не работал тачскрин (при родном то ядре), а в третьих, Android ни в какую не видел аккумулятор, вися на 0% и моментально отключаясь, если смартфон не стоит на зарядке, а при попытке воткнуть кабель — смартфон показывал индикацию зарядки, но потребление было на нуле.

Поскольку тачскрина у нас нет, root доступ через adb придется включать «ручками» — для этого нам необходимо перепаковать наш родной раздел boot. Для распаковки и запаковки образов, я пользуюсь MtkImgTool — весьма удобная «кухня» для работы. Вытаскиваем boot.img из pac, закидываем в Unpack/Image/ и распаковываем с помощью Boot -> Unpack -> boot.img

В Unpack/boot/ramdisk/default.prop нам необходимо изменить ro.debuggable на 1, а ro.secure на 0. Это даст возможность отлаживать устройство даже если Android фактически не загрузился.

Теперь у нас есть root-консоль устройства, даже если смартфон висит на заставке. Прошиваем обратно образ, пишем adb shell в консоли и смотрим, что же тут не так… Вообще, драйвер тачскрина обычно статически слинкован с ядром, но в случае устройств Spreadtrum — они вынесены в динамические модули ko, которые можно найти в папке /lib/modules/, либо /sps/. Давайте глянем init.sp6820a.init.3rdparty.rc, который отвечает за специфичную для этой модели смартфона инициализацию.

Ага, видим insmod gt868.ko? Это команда загрузки драйвера тачскрина, в нашем случае — это вышеупомянутый GT868. Иногда встречаются другие модели тачскринов, но главное отличие прошивки 2.2 от 2.3 — разные названия папок с драйверами и некоторые службы. Достаём из родного образа драйвер gt868.ko, используя всё тот-же MtkImgTools, распаковывая его как обычный ext2 раздел:

Пишем в консоли устройства:

adb push / gt868.ko
adb shell
insmod /system/lib/modules/gt868.ko

И наслаждаемся тем, что у нас теперь появился тачскрин! Android сам подхватил новое устройство ввода, поскольку драйвер тачскрина — обычное устройство в /dev/input/. Чтобы драйвер грузился при загрузке, его достаточно добавить в init.sp6820a.3rdparty.rc, предварительно закинув в раздел /system/. Перед этим, раздел нужно перемонтировать для возможности записи:

on boot
insmod /system/gt868.ko

adb shell
busybox mount -o remount,rw /system/
mkdir /lib/modules/
exit
adb push gt868.ko /lib/modules/

После модификации rc-скрипта, нужно обратно запаковать boot.img с помощью MtkImgTools и прошить его с помощью ResearchDownload — тачскрин будет работать даже после перезагрузки!

❯ Поднимаем зарядку и сеть

Переходим к отсутствию связи с аккумулятором и нулевым потреблением АКБ. Здесь мне пришлось несколько покопаться и почитать логи ядра с помощью команды dmesg. Я обратил внимание на то, что некая служба пишет что-то об аккумуляторе, но разобраться было несложно: в папке /system/bin я нашёл программу charge, которая, очевидно, отвечает за настройку КП для старта зарядки. Что она точно делает — мне неизвестно, возможно корректирует какие-то значения в sysfs, возможно с помощью ioctl общается с драйвером КП и даёт разрешение на старт зарядки и обновление информации в sysfs. В любом случае, после замены /system/bin/vcharged на оный из родной прошивки, зарядка заработала.

Для этого мы снова перемонтируем /system/ в режим записи и копируем vcharged, не забыв вернуть обратно необходимые права:

adb push charge /system/bin/
adb shell
chmod 777 /system/bin/charge

Перезагружаем устройство и… зарядка с индикацией появилась!

Вроде всё работает на первый взгляд: и звук, и вибро, и Wi-Fi с Bluetooth… однако сети-то нет! Девайс не определял наличие SIM, а вместо IMEI у нас был null/null:

Чтобы её поднять, нам необходимо разобраться в том, как работает подсистема взаимодействия с радиомодулем в Android, которая называется ril — Radio Interface Library. RIL предоставляет API для системы, дабы оперировать не напрямую AT-командами (которые могут быть проприетарными, а на некоторых чипсетах, как, например, Qualcomm вообще отсутствовать), а удобным набором функций — например о запросе статуса радиомодуля, начале звонка, поиска сети и т. п. RIL состоит из сервиса rild в /system/bin/ и библиотеки libril.so, которую можно найти в папке /system/lib/. При запуске системы, TelephonyManager открывает сокет с rild и опрашивает его состояние. Именно из TelephonyManager система берет информацию о силе сигнала, название оператора, IMEI и другие данные.

Путем ковыряния в dmesg я понял, что система флудит из-за невозможности запустить проприетарный сервис Spreadtrum — sprd_monitor. При попытке позвонить в 112, смартфон бесконечно пытается включить радиомодуль. Я ковырялся в UI-части исходного кода Android, дабы понять логику работы, но проблема крылась как раз в упомянутых выше службах sprd_monitor. Берём их из /system/bin/ оригинальной прошивки, закидываем их в устройство, не забыв установить права и отправляем систему в ребут:

adb push engappclient /system/bin/
adb push engmodemclient /system/bin/
adb shell
chmod 777 /system/bin/engappclient
chmod 777 /system/bin/engmodemclient

Ошибки в dmesg пропали, IMEI появился, но устройство до сих пор не хочет никуда звонить и просто висит на экране звонка. В настройках смартфон говорит о том, что уровень сигнала недоступен, а значит, радиомодуль до сих пор не работает :(

Но и мы так просто не сдаемся! Поковыляв по файловой системе, в директории /system/opl/telephony/bin/ я нашел скрипт, отвечающий за инициализацию радиотракта, который вызывает родной 3rdparty.rc! Запускаем sh-скрипт и обнаруживаем, что сеть появилась и девайс дозвонился в 112, а также увидел SIM-карту!

sh init.tel

Теперь всё полностью работает :) Дабы радиотракт запускался при старте устройства, я перенес часть инита из boot.img от прошивки, которую мы портировали. Для кого-то, казалось бы, это всё достаточно сложно и долго. Но у меня ушел всего один день на полную отладку и запуск такой кастомной прошивки на своем устройстве! Можно сказать, это самый базовый и краткий экскурс в такое нелегкое дело, как моддинг Android-устройств.

Но мы ведь это всё не просто так делали! Давайте глянем, как будет работать такой девайс на Android 2.2 в 2024 году — спустя 14 лет после выхода системы. Всё ли так плохо, как кажется?

❯ Знакомимся с девайсом

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

Конечно, изначально может показаться, что устройство плохо подходит для выполнения современных задач: браузер не способен загрузить большинство страниц, а из альтернатив есть только Opera Mini, где вообще нет динамического контента, а официальные клиенты ВК, WhatsApp и YouTube уже давно не работают. Опечаленный читатель может подумать, что девайс, как и многие его ровесники уже давно превратились в звонилки…

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

Пожалуй, многие читатели удивятся — но на таких девайсах есть YouTube! Мой самопальный клиент не поддерживает стриминг из сети (да и многие девайсы объективно не потянут), поэтому предварительно загружает видео на MicroSD-флэшку и затем уже их воспроизводит. Как приятный бонус — видео потом можно посмотреть в любой момент в галерее.

Я помню насколько было лампово слушать музыку с таких девайсов. И если претензии к основному динамику не очень актуальны, то к качеству звука в наушниках были придирки — звук был громкий, но ему не хватало низких частот, из-за чего он звучал несколько плоско, хотя мне и этого хватало — ведь я слушал музыку в наушниках по 200-300 рублей с рынка! Я всё ещё помню те времена, как качал mp3-треки по 2-3 мегабайта через 2G-интернет… слушаешь один трек — как раз загрузится другой и так по кругу наполнял свою фонотеку. Эх времена то какие были! Тем не менее, для некоторых базовых мультимедийных возможностей девайс подходит и сейчас, например в машину в качестве BT-хоста с музыкой.
А ещё на таких девайсах порой клёво скачать какой-нибудь Temple Run образца 2011 года и вспомнить самое начало смартфонного гейминга тех лет… ведь далеко не все игры того времени запускаются на свежих версиях Android!

❯ Заключение

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

Для кого-то это просто проявление синдрома утенка или картинки «вот кому-то делать не.»… ну а для меня — это крайне интересное, захватывающее и кайфовое времяпровождение: начиная от аппаратного ковыряния с такими девайсами и копания исходников ядер/драйверов, заканчивая написанием оптимизированных клиентских приложений, которые весят не 100-200Мб, а 100-200Кб :)

Друзья, если у вас есть подобные китайчики и вы не разделяете желания пытаться вдохнуть в них жизнь, но выбрасывать их жалко — можете задонатить их мне :) Как сами видите — девайсы попадают в хорошие руки. Из недавнего — я взял нерабочую, утопленную китайскую копию 14 Pro Max из под СЦ в качестве основного смартфона. Также у меня есть канал в Telegram, куда я выкладываю бэкстейджи статей, различные заметки о ремонте, моддинге, программировании и реверс-инжиниринге и свои мысли. Кому интересно — залетайте!

Понравилась ли вам статья? Какими были ваши первые Android-смартфоны? Пишите в комментариях, будет интересно почитать!

Пожалуй, многие из вас помнят, какими были мобильные игры до и после выхода первого iPhone. В начале 2000-х годов, ещё до появления яблочного смартфона, игры для телефонов в основном были весьма интересными, но тем не менее, достаточно простенькими с точки зрения графики и реализации в целом. После запуска AppStore в 2008 году, на iPhone начали выходить самые разные красочные, невиданные раннее по уровню детализации и проработке 2D и 3D игры. Но появление таких игр — отнюдь не заслуга Apple, а относительной малоизвестной компании PowerVR (подразделение Imagination Tech), которая смогла разработать на базе видеочипа Dreamcast и внедрить один из первых действительно массовых мобильных 3D-ускорителей, имя которому — PowerVR MBX! Сейчас мы с вами привыкли, что почти любой дешевый смартфон может отрисовывать графику уровня PS3 в 1080p, а то и выше, но когда-то даже уровень PS2 был роскошью… Сегодня мы с вами: узнаем предысторию появления аппаратно-ускоренной 3D-графики на телефонах, рассмотрим такую фирменную фишку PowerVR, как тайловый рендеринг, а в практической части статьи нам поможет легендарный КПК Dell Axim X51v с MBX на борту, под который мы напишем 3D-игру «про жигули» с нуля! Интересно? Тогда добро пожаловать под кат!

❯ Мобильная 3D-графика. Начало

Пожалуй, 3D-графика на мобильных устройствах начала развиваться ещё с самого начала 2000-х годов. К тому моменту, как мобильные телефоны научились запускать сторонние Java-приложения, практически сразу же появился прибыльный рынок мобильных игр. Ещё до появления поддержки jar-приложений, люди ставили рекорды в «Змейке» на телефонах Nokia, таскали ящики в «Строителе» на Siemens и играли в другие предустановленные игры на девайсах других брендов, поэтому было очевидно, что игры на мобильных телефонах рано или поздно смогут занять немалую часть сегмента портативных игровых устройств.

Именно появление J2ME дало тот самый толчок для развития мобильного гейминга. Производители телефонов активно развивали и дорабатывали мобильную платформу, добавляя в неё различные API-расширения — например, активацию приложений через СМС и доступ в WAP-интернет. Сама платформа J2ME была достаточно простой для изучения и имела низкий порог вхождения не только для людей, имевших какой-то опыт программирования, но даже для совсем новичков, которые никогда не писали код и тем более игр! Благодаря этому, появились сотни игр, многие из которых до сих пор помнят и любят: это и легендарный «мячик» Bounce, и «зайчик с морковками» Bobby Carrot, и весьма крутой Gish, а также множество различных платформеров по известным фильмам и «большим» играм!

В 2003 году появился Nokia N-Gage — первый массовый телефон, ориентированный именно на мобильный гейминг, который поддерживал не только Java-игры, но и собственные Symbian-игры с достаточно крутой 3D-графикой! Примерно в том же 2003 году, для платформы Java вышло сразу два API-расширения, которые добавляли поддержку симпатичной 3D-графики даже в самые простенькие и бюджетные телефоны: Mobile 3D Graphics (M3G, была почти везде) и Mascot Capsule (эта платформа была только на Sony Ericsson и Motorola). Именно благодаря этим API, мы с вами увидели такие легендарные игры, как V-Rally, Galaxy on Fire, Deep3D и многие другие! Но тем не менее, эти API были относительно медленными из-за программной растеризации на процессоре без отдельного 3D-ускорителя и весьма ограниченными в функционале. Ближайший пример по функционалу — уровень софтрендера первой кваки на первом Pentium! Кстати, про 3D на мобильных телефонах я писал отдельную статью, там в практической части мы пишем 3D-бродилку для Sony Ericsson!

Но помимо кнопочных телефонов, существовал сегмент High-end мультимедийных устройств, которые предоставляли гораздо больший функционал и производительность за немалые деньги. И речь, конечно же, о КПК! Девайсы, работавшие на базе шустрых процессоров Intel PXA и Samsung S3C с Windows Mobile на борту были заметно более перспективными для игр… но как-то не задалось из-за отсутствия нормальных каналов для распространения. Но тем не менее, Intel (иронично, но один из самых больших производителей ARM-чипсетов для КПК в те годы), которая уже занималась развитием десктопной графики GMA и PowerVR активно работали в этой сфере и результатом стало появление видеоускорителя 2700G, который представлял из себя не только 3D GPU PowerVR MBX Lite, но и аппаратный декодер видео, позволявший смотреть видео в высоком качестве! MBX Lite позволял запустить даже Quake 3 в 640x480 (!), пусть и в 10-15 FPS… Ещё за 5 лет до этого, далеко не все десктопные видеокарты могли выдать больше 30 FPS в 800x600!

Конечно в 2004 году уже вышел PSP, выставивший новую планку уровня 3D-графики для портативного гейминга, однако для смартфонов и КПК, уровень графики, разрешение и производительность 3D-игр на MBX Lite был просто немыслимым! Одним из самых легендарных и популярных устройств с 2700G, которое вы можете приобрести достаточно дешево и сейчас, был КПК Dell Axim X51v, флагманская модель с VGA-дисплеем тех лет. Но нельзя сказать, что только PowerVR работала в этом направлении. Параллельно NVidia выпустили GoForce, крайне редко попадающийся в «полноценном» виде (NVidia предлагала дешевле лицензировать только видео-декодер с отключением 3D-части, как это было в Toshiba Portege G900) и ATI Imageon, который чаще всего можно встретить в виде Adreno на ранних Android-чипсетах Qualcomm (Adreno — анаграмма Radeon :)).

Тем не менее, решение PowerVR было действительно массовым: компания не предлагала отдельный чип (что обычно было дороже), как конкуренты, а лицензировала другим компаниям уже готовые IP-ядра, которые производители чипов могли синтезировать и использовать в своих собственных чипсетах, или, сопроцессорах, как в случае с 2700G. Благодаря этому, MBX появился в чипсете TI OMAP 2430, использовавшийся в легендарных Nokia N93i и Nokia N95, Samsung INNOV8, Asus Lamborghini, Nokia E90 и некоторых других. Кроме того, PowerVR MBX использовался в процессоре Samsung S5L8900, судя по всему, разработанный для iPhone 2G и 3G! Благодаря этому, его можно считать одним из первых массовых 3D GPU в телефонах!

Весьма симпатично, согласитесь?

❯ Под капотом

Но MBX, конечно же, не появился «из ниоткуда» и был основан на более ранних разработках компании Imagination Tech, а именно GPU из полноценной домашней консоли SEGA Dreamcast — PowerVR CLX2, который в свою очередь был основан на ранних десктопных GPU PowerVR из середины-конца 90-х годов. Основная фишка PowerVR была в использовании так называемой техники отложного тайлового рендеринга (TBDR), которая, в отличии от классической растеризации и сортировки с помощью Z-буфера (или ручной сортировки треугольников) всех примитивов «в лоб» (методика, используемая в PSP, PS2 и большинстве видеокарт 2000-х годов), сначала ждёт от программы списка всех рисуемых треугольников в кадре, разбивает весь экран на тайлы (небольшие прямоугольные области), которые содержат в себе информацию о пересекающихся треугольниках, а затем процессом, несколько схожим с рейтрейсингом, определяет, какой из пикселей треугольника ближе всего находится к камере наблюдателя. Таким образом, мы избавляемся от необходимости сортировки геометрии с помощью Z-буфера (который сам по себе занимает достаточно много, по меркам тех лет, памяти и страдает от проблем точности и Z-fighting'а), а также такой метод позволяет реализовать более дешевый альфа-блендинг без ручной сортировки полупрозрачных примитивов и имеет ещё одну приятную фишку — «бесплатный» Occlusion Query, который можно использовать для реализации продвинутых техник отсечения невидимой глазу геометрии.

Производительность PowerVR MBX была весьма достойной для своих лет: при частоте работы в 200МГц, видеочип обеспечивал филлрейт в 100Мп, обрабатывал до 1млн треугольников в секунду. Нативным графическим API MBX был OpenGL ES 1.1 — специальная урезанная версия OpenGL для встраиваемых устройств, из которой выбросили все ненужное и которая заточена не только под floating-point, но и под fixed-point арифметику. В остальном, особо никаких отличий для программиста по сравнению с обычными GPU не было, можно было без проблем портировать уже существующие приложения для десктопого OpenGL для мобильные девайсы, чем и пользовались энтузиасты при портировании Quake 3 на Nokia E90, КПК и другие девайсы. Также, PowerVR MBX поддерживал D3DM — графический API Windows Mobile, о котором мы поговорим позднее.

Однако PowerVR MBX был GPU с фиксированным конвейером (FFP), а не программируемым, как принято в современных 3D-ускорителях. Что-же такое программируемый и фиксированный конвейер? Давайте разберемся:

• Фиксированный конвейер: для того, чтобы задать визуальную составляющую рисуемой геометрии, программист оперирует набором заранее определенных при проектировании видеочипа параметров, которые позволяют управлять внешним видом растеризуемых примитивов. Например, для реализации света, программист задает параметры каждого из 8 источников света влияющих на рисуемый объект. Если программисту необходимо наложить несколько текстур за один проход (например, для реализации плавных переходов текстур на ландшафте или нанесения карты отражений на модель), он оперировал комбайнерами, которые позволяли задавать для каждого сэмплера параметры наложения. Такой подход использовался на десктопных GPU эпохи до GeForce 3 (т. е. примерно до 2000 года), до PS3 на Sony PlayStation (Xbox сразу вышел с GeForce 3) и до PSP включительно на портативках. Очевидно, что такой подход сильно ограничивает программиста в том, как будет выглядеть его игра на той или иной видеокарте.

• Программируемый конвейер: в программируемом подходе, для управления визуальной составляющей программист пишет небольшие программы для видеокарты, называемые шейдерами. Всего есть два базовых (в современных GPU их больше) этапа программируемого конвейера: первый из них — вершинный шейдер, отвечающий за трансформацию геометрии (перевод из мировой системы координат в экранную) и, например, анимацию. Трансформированные вершины отправляются в следующий этап конвейера — растеризацию, где выполняется уже пиксельный шейдер, который определяет цвет пикселя (или более корректно — фрагмента в терминологии 3D графики) — т.е например, окрас объекта в определенной цвет, текстуру (или несколько текстур), рассчитывает попиксельное освещение, накладывает тени и т. д. Кроме того, такой подход позволяет реализовать сложные техники типа Ambient Occlusion, SSR, а также пост-эффекты (например блюр/блум, правда эти два можно «сэмулировать» и на FFP при определенной сноровке).

К 2007 году, Khronos выпустили спецификацию второй версии OpenGL ES, которая добавляла в мобильные устройства поддержку программируемого конвейера и шейдеров. Таким образом, мобильные GPU всё ближе приближались к уровню консолей и могли выдавать вполне годную графику, близкую к консолям. Даже была когда-то такая консоль, как Zeebo, которая работала на базе смартфонного чипсета Qualcomm с графикой ATI Imageon (!). PowerVR уже в 2009 выпустила серию SGX, которая также использовалась в iPhone, iPad, многих Android-смартфонах и планшетах, а также PS Vita!

Но статья с пересказом фишек PowerVR MBX была бы не особо интересной без практической части с написанием 3D-игры под этот GPU с нуля! Поэтому предлагаю посмотреть на нашего сегодняшнего гостя, легендарный флагманский КПК Dell Axim X51v из далекого 2005 года! Для тех лет, это настоящий «жир»:

Его мне подарил мой читатель Сергей с Хабра, за что ему огромное спасибо! Девайс был в полной комплектации, даже с флэшкой и усиленной АКБ, которая до сих пор неплохо держит заряд, однако у него не работал тачскрин. Если вам интересен только процесс программирования игры, а не аппаратного ремонта, то листайте ниже сразу до следующего абзаца :)

❯ Практическая часть: ремонтируем КПК

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

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

А вот и виновник наших проблем: рычажок переключателя был отломан, но все еще находится в положении «разблокирован». Даже если в выжать в упор — он все равно не работал. Ну что ж, фен в руки, сдуваем переключатель и ставим вот такую перемычку (на фото флюс ещё не отмыт):

Включаем девайс и смотрим — теперь всё работает! Вот такой простой и быстрый ремонт Axim'а. КПК мне сразу очень понравился, я и ранее знал о его легендарности, но теперь узнал и о том, что он очень круто спроектирован и собран! Кстати, есть смысл сразу сдуть концевой выключатель, который прижимает задняя крышка и заменить на перемычку.
GPU не очень хорошо работает на кастомных прошивок, на которую прошиты многие Axim X51v. Поэтому есть смысл прошить сток: качаем прошивку (Файл отката), закидываем на SD-карту и ребутим девайс нажатием клавиш Wi-Fi + включение + Reset. После этого, девайс пойдет прошиваться.

Теперь девайс чистый, как с завода! Можно приступить к написанию небольшой демки-игрушки, которая сможет продемонстрировать нам перспективы нашего КПК в 3D!

❯ Практическая часть: подготовка

Изначально, в практической части статьи должна была участвовать не менее легендарная Nokia N95. Однако вот незадача: несмотря на то, что под Symbian сохранился SDK (который работает нормально только под Windows XP), на устройствах с системой старше 9.x необходимо взламывать installserver, дабы иметь возможность ставить хоумбрю программы (к которым относится и наша игра) и отладчик TRK.

И хотя свой девайс я пропатчил, дебаггер нормально поднять мне так и не удалось. Я смог проинициализировать контекст GLES, запилить примитивный рендерер с загрузкой ассетов из памяти устройства но потом решил перевести проект на WinMobile… Проблем с разработкой под Symbian много: если приложение крашится — то оно просто закрывается, без сообщений и логов. Добавьте к этому то, что в Symbian вообще нет исключений и не всегда можно записать ошибки в лог и отладка превращается в ужас. Ситуацию исправляет Qt, который работает на N95, но в котором нет поддержки GLES (по крайней мере, в виде обычного QOpenGL, хотя возможность юзать API системы из Qt есть и дебаггер там работает нормально, так что не всё потеряно). Если вы когда-то что-то пилили под Symbian, особенно в Carbide — пишите свой опыт в комментариях, интересно почитать :)

WinMobile не менее интересен тем, что в нём поддерживается сразу два графических API: классический OpenGLES в профиле Common Lite (только fixed-point арифметика) и мобильная версия Direct3D — D3DM.dll, которая предоставляет API очень похожее на DX9, но без поддержки шейдеров. Что не менее приятно — есть официальные биндинги от Microsoft к D3DM в .NET Compact Framework, что позволяет легко писать 3D-игры под WM на C#/VB.NET.
Поскольку WinMobile — достаточно открытая для пользователя система, хватит лишь накатить VS2005/2008 на машину с WinXP/WinVista/Win7/Win8 и сразу начать разрабатывать под неё приложения, никаких проблем с отладкой и запуском приложений тут нет. На Win10/Win11 совместимость с WM5 поломали :(

Создаём приложение для смарт-устройств, выбираем в качестве целевой платформы WM5-устройство (эмулятор будет слишком медленным для наших целей, он даже для 2D-игр не подойдет) и, наконец-то, приступаем к написанию игры!

Что же за игра у нас будет? Я решил сделать эдакое 3D-переосмысление популярного в прошлом бесконечного раннера из «тетриса», где мы едем на машинке F1 и обгоняем другие машины, стараясь в них не врезаться. Основной целью является набрать как можно больше очков. Подобные игры достаточно популярны на мобильных девайсах и сейчас: вспомнить хотя-бы Highway Traffic, однако мой вариант будет весьма колоритным: ведь в моей демке мы будем кататься на ТАЗе 21099 и уворачиваться от гнилых «вторых гольфов». Ну а почему бы и нет, я просто очень люблю старые гнилые жигули и это не первый мой проект про машины этого производителя :)

❯ Практическая часть: «движок»

Как и у настоящей машины, у каждой игры должен быть собственный движок! Однако в случае конкретно нашей игры, это скорее небольшой фреймворк, который предоставляет ровно тот функционал, который нужен игре без каких либо излишеств. Необходимо изначально распланировать требования для будущего фреймворка, дабы написание игры не скатилось в процесс, известный в узких кругах как «движкописание» :)

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

• Звук: воспроизведение wav-звуков и музыки из файлов. Да и всё пожалуй — что ещё нужно от звуковой подсистемы? :) Стерео ведь нет, поэтому и 3D-звук не нужен.

• Ввод: обработка нажатий на тачскрин и аппаратные кнопки устройства, маппинг кейкодов в виртуальный «геймпад». GUI-подсистему тоже частично можно отнести именно сюда!

• Физика: AABB и Sphere vs Sphere столкновения. Никакого полноценного солвера тут и не нужно :)

Начинаем, пожалуй, с реализации рендерера. Сначала нам необходимо создать окно и контекст D3DM. Процесс практически идентичен D3D8 и D3D9: передаём информацию о нужном адаптере (видеочипе) и заполняем структуру PresentationParameters, однако есть важные нюансы: аппаратный FSAA лучше всего отключить (MultisampleQuality), а также передавайте точный размер окна, в которое собираетесь рендерить изображение, иначе система начнёт софтварно (!) скейлить рендертаргет до размера окна каждый кадр, что, как сами понимаете, крайне медленно.

Из форматов Depth-Stencil форматов поддерживается D16, D24S8 и D32. Желательно использовать D16 (несмотря на тайловую архитектуру, насколько мне известно, в MBX все равно есть fallback до классического рендеринга при некоторых условиях). Практически на всех КПК и коммуникаторах использовался 16-битный цвет, т.е RGB565, но можно указать Unknown — тогда GAPI подцепит тот формат пикселя, что используется в остальной системе.

PresentParameters pp = new PresentParameters();
pp.AutoDepthStencilFormat = DepthFormat.D16;
pp.BackBufferCount = 1;
pp.BackBufferFormat = Format.Unknown;
pp.BackBufferWidth = parentForm.ClientSize.Width;
pp.BackBufferHeight = parentForm.ClientSize.Height;
pp.EnableAutoDepthStencil = true;
pp.FullScreenPresentationInterval = PresentInterval.One;
pp.MultiSample = MultiSampleType.None;
pp.PresentFlag = PresentFlag.None;
pp.SwapEffect = SwapEffect.CopyVSync;
pp.Windowed = true;

device = new Device(0, DeviceType.Default, parentForm.Handle, CreateFlags.None, pp);
device.RenderState.Lighting = false;

aspectRatio = (float)parentForm.ClientSize.Width / (float)parentForm.ClientSize.Height;

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

public void BeginScene()
{
device.Clear(ClearFlags.Target | ClearFlags.ZBuffer, System.Drawing.Color.SkyBlue, 1.0f, 0);
device.BeginScene();

device.TextureState[0].MinFilter = TextureFilter.Point;
device.TextureState[0].MagFilter = TextureFilter.Point;
device.RenderState.TexturePerspective = true;

// Prepare projection
Matrix matrix = Matrix.PerspectiveFovLH(60.0f * MathUtils.DegToRad, aspectRatio, 0.1f, 350.0f);
device.SetTransform(TransformType.Projection, matrix);
}

public void EndScene()
{
device.EndScene();
device.Present();

System.Threading.Thread.Sleep(16);
}

Чтобы какую-то модельку нарисовать, нам нужно сначала её загрузить! Для возможности напрямую прочитать треугольники из файла и сразу записать их в вершинный буфер, я написал небольшой конвертер из формата SMD (GoldSrc) в собственный, очень простой и легковесный формат, который состоит из позиции вершины и её текстурных координат:

public struct BoundingBox
{
public float MinX, MinY, MinZ;
public float MaxX, MaxY, MaxZ;
}

public sealed class ModelConverter
{
public const int Header = 0x1234;

static BoundingBox CalculateBBox(SmdMesh mesh)
{
BoundingBox ret = new BoundingBox();
ret.MinX = float.PositiveInfinity;
ret.MinY = float.PositiveInfinity;
ret.MinZ = float.PositiveInfinity;
ret.MaxX = float.NegativeInfinity;
ret.MaxY = float.NegativeInfinity;
ret.MaxZ = float.NegativeInfinity;

foreach (SmdTriangle triangle in mesh.Triangles)
{
for (int i = 0; i < 3; i++)
{
ret.MinX = Math.Min(ret.MinX, triangle.Verts[i].Position.X);
ret.MinY = Math.Min(ret.MinY, triangle.Verts[i].Position.Y);
ret.MinZ = Math.Min(ret.MinZ, triangle.Verts[i].Position.Z);

ret.MaxX = Math.Max(ret.MaxX, triangle.Verts[i].Position.X);
ret.MaxY = Math.Max(ret.MaxY, triangle.Verts[i].Position.Y);
ret.MaxZ = Math.Max(ret.MaxZ, triangle.Verts[i].Position.Z);
}
}

return ret;
}

private static int FloatToFixedPoint(float x)
{
return ((int)((x) * 65536.0f));
}

public static void Convert(string fileName, Stream stream)
{
Console.WriteLine("Converting mesh " + fileName);

Smd2Bmd.SmdMesh mesh = new Smd2Bmd.SmdMesh(stream);
BoundingBox bb = CalculateBBox(mesh);

using(Stream outStrm = File.Create(Path.GetFileNameWithoutExtension(fileName) + ".mdl"))
{
BinaryWriter writer = new BinaryWriter(outStrm);

writer.Write(Header);
writer.Write(mesh.Triangles.Count * 3); // Verts count

// BBox
writer.Write(bb.MinX);
writer.Write(bb.MinY);
writer.Write(bb.MinZ);
writer.Write(bb.MaxX);
writer.Write(bb.MaxY);
writer.Write(bb.MaxZ);

foreach (SmdTriangle triangle in mesh.Triangles)
{
for (int i = 0; i < 3; i++)
{
writer.Write(FloatToFixedPoint(triangle.Verts[i].Position.X));
writer.Write(FloatToFixedPoint(triangle.Verts[i].Position.Y));
writer.Write(FloatToFixedPoint(triangle.Verts[i].Position.Z));

writer.Write(triangle.Verts[i].UV.X);
writer.Write(triangle.Verts[i].UV.Y);
}
}
}
}
}

Обратите внимание, PowerVR MBX оперирует fixed-point арифметикой! D3DM, конечно, может автоматически преобразовывать float-координаты вершин в числа с фиксированной точкой, вот только реализовано это криво и косо: драйвер будет конвертировать все вершины в fixed-point каждый вызов отрисовки, вместо того, чтобы один раз преобразовать их после Unlock'а вершинного буфера. Теперь представьте, насколько это тормозно для хоть сколь-либо комплексной модели :)

При этом загрузчик модели при таком подходе будет очень простым и будет работать шустро даже на таком слабеньком железе:

public Model(string debugName, Stream strm)
{
BinaryReader reader = new BinaryReader(strm);

int hdr = reader.ReadInt32();
int numVerts = reader.ReadInt32();
int vertSize = 20;

Bounds = new BoundingBox(reader.ReadSingle() * 2, reader.ReadSingle() * 2, reader.ReadSingle() * 2,
reader.ReadSingle() * 2, reader.ReadSingle() * 2, reader.ReadSingle() * 2);

PrimitiveCount = numVerts / 3;

byte[] data = new byte[numVerts * vertSize];
strm.Read(data, 0, (int)(strm.Length - strm.Position));

Buffer = new VertexBuffer(Engine.Current.Graphics.device, vertSize * numVerts, Usage.None, VertexFormats.PositionFixed | VertexFormats.Texture1, Pool.SystemMemory);
GraphicsStream gs = Buffer.Lock(0, Buffer.SizeInBytes, LockFlags.None);
gs.Write(data, 0, data.Length);
Buffer.Unlock();

DebugName = debugName;
}

Переходим к текстурам. Грузить напрямую png/jpg на КПК слишком долго, поэтому их я тоже перегоняю в собственный примитивный формат, который состоит из описания ширины/высоты, а также формата текстуры и собственно, самих пикселей. На данный момент поддерживаются только RGB565 текстуры — с ними MBX работает лучше всего:

public sealed class TextureConverter
{
public const int Header = 0x1234;

public static unsafe void Convert(string fileName, Stream stream)
{
Console.WriteLine("Converting texture " + fileName);

Bitmap bitmap = (Bitmap)Image.FromStream(stream);
byte[] pixels = new byte[bitmap.Width * bitmap.Height * 2];

System.Drawing.Imaging.BitmapData data = bitmap.LockBits(new Rectangle(0, 0, bitmap.Width, bitmap.Height),
System.Drawing.Imaging.ImageLockMode.ReadOnly, System.Drawing.Imaging.PixelFormat.Format16bppRgb565);
Marshal.Copy(data.Scan0, pixels, 0, pixels.Length);

bitmap.UnlockBits(data);

using (Stream outStrm = File.Create(Path.GetFileNameWithoutExtension(fileName) + ".tex"))
{
BinaryWriter writer = new BinaryWriter(outStrm);

writer.Write(Header);
writer.Write(0); // 0 - 565, 1 - RGBA
writer.Write(bitmap.Width);
writer.Write(bitmap.Height);

writer.Write(pixels);
}
}
}

Загрузчик тоже получился примитивным и шустрым донельзя, пусть и без какой либо компрессии. PowerVR MBX поддерживает собственный формат компрессии — PVRTC:

BinaryReader reader = new BinaryReader(strm);

int hdr = reader.ReadInt32();
int fmt = reader.ReadInt32();

Width = reader.ReadInt32();
Height = reader.ReadInt32();

byte[] data = new byte[Width * Height * 2];
strm.Read(data, 0, data.Length);

Handle = new Texture(Engine.Current.Graphics.device, Width, Height, 1, Usage.Lockable, Format.R5G6B5, Pool.VideoMemory);

int pitch;
GraphicsStream gs = Handle.LockRectangle(0, LockFlags.None, out pitch);
gs.Write(data, 0, data.Length);
Handle.UnlockRectangle(0);

strm.Close();

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

public void DrawModel(Model model, Transform transform, Material material)
{
Matrix matrix = Matrix.RotationY(transform.Rotation.Y * MathUtils.DegToRad)
* Matrix.Translation(transform.Position);
device.SetTransform(TransformType.World, matrix);

// Setup renderstate
device.RenderState.ZBufferWriteEnable = !material.DepthWrite;
device.SetTexture(0, material.Diffuse.Handle);

device.SetStreamSource(0, model.Buffer, 0);
device.DrawPrimitives(PrimitiveType.TriangleList, 0, model.PrimitiveCount);
}

И рисуем модельку:

Model model;
Material mat;
Transform t;

void Start()
{
model = Model.FromFile("model.mdl");

mat = new Material();
mat.Diffuse = Texture2D.FromFile("test.tex");
}

void Update()
{
t = new Transform();
t.Position.Z = 150;
t.Rotation.Y += 0.1f;

graphics.DrawModel(model, t, mat);
}

Результат: у нас есть крутящийся кубик или любая другая произвольная 3D-модель!

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

public Input(Form parentForm)
{
keyState = new bool[(int)GamepadKey.Count];

parentForm.KeyPreview = true;

parentForm.KeyDown += new KeyEventHandler(OnKeyDown);
parentForm.KeyUp += new KeyEventHandler(OnKeyUp);
}

private GamepadKey ResolveKeyCode(Keys key)
{
GamepadKey k = GamepadKey.Count;

switch (key)
{
case Keys.Left:
k = GamepadKey.Left;
break;
case Keys.Right:
k = GamepadKey.Right;
break;
case Keys.Up:
k = GamepadKey.Up;
break;
case Keys.Down:
k = GamepadKey.Down;
break;
case Keys.Return:
k = GamepadKey.OK;
break;
}

return k;
}

void OnKeyUp(object sender, KeyEventArgs e)
{
GamepadKey key = ResolveKeyCode(e.KeyCode);

if (key != GamepadKey.Count)
SetKeyState(key, false);
}

void OnKeyDown(object sender, KeyEventArgs e)
{
GamepadKey key = ResolveKeyCode(e.KeyCode);

if (key != GamepadKey.Count)
SetKeyState(key, true);
}

public bool GetKeyState(GamepadKey key)
{
return keyState[(int)key];
}

private void SetKeyState(GamepadKey key, bool state)
{
keyState[(int)key] = state;
}

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

В наше время большинство портативных устройств работает на базе достаточно мощных микроконтроллеров, которые способны запускать даже интерпретируемый код на Lua/Python. Чего уж там говорить — даже современная кофеварка или умный электрочайник может быть в разы мощнее оригинального IBM-PC, не говоря уже о автомобильных бортовых компьютерах, которые зачастую мощнее топовых ПК из начала нулевых. Но давайте вспомним конец 90-х и начало 2000-х, когда разработка собственной электроники была практически недоступна рядовому пользователю, а микроконтроллеры программировались в основном только на ассемблере. Недавно я нашёл некоторую информацию о том, какой процессор вероятно использовался в таких знакомых нам приставках Brick Game, которые мы называли «Тетрисами»! Более того, мне удалось найти полный даташит с описанием всех модулей этого процессора, который гордо можно назвать «система на кристалле». Какой была разработка микроэлектроники в 90-х? Читайте в статье!

❯ Немного о «Тетрисе»

Пожалуй, Тетрис или Brick Game был одной из самых популярных портативных игровых консолей в странах СНГ. Появившись где-то в конце 90-х, этот гаджет быстро стал бестселлером среди детишек благодаря наличию сразу нескольких игр, полноценного ЖК-экрана, звука и невероятной дешевизны. Не знаю, сколько Тетрис стоил в момент выхода, но в нулевых цена на него была крайне низкой — около 100-200 рублей в зависимости от корпуса. Типичный школяр мог накопить на собственный Тетрис за несколько недель, что делало его самым доступным игровым девайсом на рынке.

Конечно же, на рынке уже были различные консоли с гораздо более богатым функционалом — например GameBoy и даже GameBoy Color с цветным дисплеем, а люди, родившиеся в конце 90-х или начале 2000-х уже застали PlayStation Portable с реально крутой 3D-графикой и телефоны с хорошим игровым потенциалом — как, например, SE K500i. Однако цена на них была непозволительной роскошью для небогатых семей: PSP стоила 250$ (около 7-8 тысяч рублей по тому курсу), плюс каждый UMD-диск с игрой стоил около 1.000 рублей, GameBoy были относительно редкими в России, а телефоны — это всё же прерогатива более юных ребят, да и в нулевых далеко не всем перепадал крутой K500i — чаще всего покупали телефон попроще типа Siemens A55 (грузчика помним?) или Motorola C350 (а мотоциклиста?). Поэтому тетрисы оставались чуть ли не единственным средством развлечения у небогатых ребят.

Ощутимым плюсом было и то, что Тетрис работал от батареек: они были не слишком дорогими в то время, а если носить с собой в кармане парочку, то можно не бояться, что консоль сядет в долгой дороге и продолжать себя забавлять, да и сам Тетрис работал довольно долго, мне хватало на неделю игры (может и меньше). Несмотря на низкое разрешением всего в 10x20 пикселей, Тетрис обладал достаточно большим монохромным дисплеем без подсветки, на котором было комфортно играть.
Ещё одним немаловажным плюсом консоли была возможность «кооперативной» игры и эдакого азарта: будучи неискушенными детьми, многие из нас пытались поставить рекорды и выбить как можно больший счёт в каждой из доступных игр. Чем больше счёт, тем ты круче среди друзей!

Но что же у Тетриса «под капотом»? На чём он работал внутри? Недавно я нашёл информацию о том, что потенциально в Тетрисе могла использоваться 4х-битная система на чипеHoltek HT1130, которая использовалась в самой разной носимой электроники: от часов на батарейках, до полноценных игровых консолей. Причём я ничуть не преувеличиваю, это действительно SoC: уже в 90-х, тайваньская компания смогла объединить звуковой модуль, контроллер ЖК-дисплея, ввод/вывод и таймер в один чип! Однако тут важно понять, что 100% сказать, на чём работал Тетрис, нельзя — процессор спрятан под компаундом и у него нет корпуса с маркировкой, лишь «голый» кристалл. Тем не менее, мы можем предположить, что это был один из чипов Holtek и посмотреть, на чём же работала портативная электроника тех лет поближе!

Заранее прошу прощения за отсутствие нормальных фотографий. Под рукой у меня не оказалось «старого» Тетриса, а на новодельных показывать как-то не очень.

На данный чипсет есть «утёкший» в сеть даташит с полным описанием регистров микроконтроллера и его ТТХ. Чип был спроектирован так, чтобы не требовать практически никакой обвязки в виде конденсаторов/резисторов и других SMD-элементов — он работал фактически напрямую от пальчиковых батареек и его легко было развести на плате даже начинающему инженеру. Микроконтроллер стабильно оперировал при напряжении от 2.4в до 3.3в, что позволяло просто вставить две последовательно соединенные AA или AAA батарейки с напряжением 1.5-1.6в и получить необходимое питание для работы всей «приставки».

❯ Вычислительное ядро

Саму систему на кристалле можно разделить на несколько соединенных модулей в один чип. Основным, конечно же, является 4х-битное вычислительное ядро неизвестной архитектуры, которое компания Holtek разработала сама или лицензировала как IP-ядро у другой компании для использования в собственном чипе (как, например, MediaTek лицензирует у ARM ядра Cortex). Система команд, по крайней мере, описание мнемоник ассемблера в даташите наводят на мысли о некоторой схожести с микроконтроллером Intel 8051 (однако 8051 был 8-битным) и в целом, напоминают типичную интеловскую архитектуру из 80х. Однако только по мнемоникам точно определить архитектуру невозможно: здесь есть «проприетарные» команды типа SOUND и TIMER.

Чип работает на частоте 1мгц от встроенного тактового генератора, большинство команд выполняется за один такт, максимум — два. Если говорить совсем грубо, то даже ATMega328 в Arduino условно в 16-раз мощнее HT1130, хотя это совсем некорректное сравнение.

Длина машинного слова HT1130 — 4 бита, что отсылает нас в начало 70х годов, если мы говорим о компьютерах. Это означает, что процессор «аппаратно» мог выполнять операции только с числами от 0 до 16, хотя при программной реализации мог пересчитывать хоть 32х-битные числа. Ширина шины данных — 12 бит, что позволяло адресовать вплоть до 4Кб встроенной ROM-памяти. Кроме того, в МК было встроено 128 ячеек оперативной памяти (или 64 байта), где в00H..7FHхранились временные данные программы (например, позиция танчиков на экране) и сE0H..FFHхранился «буфер» кадра, который определял текущую на экране. Также у микроконтроллера были следующие регистры:

1. R0-R4 — регистры общего назначения. Пары из регистров используются для адресации памяти.

2. ACC — регистр-аккумулятор, который хранит результаты текущей операции.

3. PC — указатель на текущую инструкцию в ROM, которую выполняет процессор.

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

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

Выбор 4х-битного процессора очевиден — они очень недорогие в производстве и достаточно простые. Примеры использования 4х-битных архитектур можно найти даже в советских играх: например, в игре «Волк и яйца» (клоне Nintendo Game & Watch) использовалась «микроЭВМ» КБ1013ВК1-2.
В встраиваемой и переносной электронике, 4х-битные вычислительные ядра продолжают использоваться и сейчас: в калькуляторах, в пультах для управления техникой, в часах. Связано это с простой и дешевизной подобных решений, да и если честно, реализация этих устройств была готова ещё в прошлом веке. Зачем дополнительно тратить деньги на R&D существующих решений? :)

❯ Графика

HT1130 специально разрабатывался для переносимых устройств с новомодными LCD-дисплеями. В те годы было нормой, когда на дисплейной матрице не было собственного контроллера с распространенным интерфейсом по типу 8080 или MIPI: частенько, драйвер дисплея либо выделялся в отдельный чип, либо реализовывался прямо в системе на кристалле. У Brick Game был дисплей разрешением в 10x20 пикселей, причём кастомизированный — с «захардкоженными» значками и сегментными индикаторами:

Работа с дисплеем была не особо сложной: один сегмент памяти был отведен специально под эдакий «фреймбуфер» — всё, что мы записывали туда, контроллер дисплея моментально отображал на нашу ЖК-матрицу. Поскольку дисплей был одноцветным, без градаций цвета, память была организована 1 бит — 1 пиксель. Работать со всем этим было как-то так:

MOV A, 0 ; Первая часть адреса (если я не напутал endianness)

MOV R1, A

MOV A, 0b0111 ; Вторая часть адреса. Не удивляйтесь, что по факту получается 224 при 128 байт ОЗУ - часть адресного пространства была как-бы зарезервирована

MOV R0, A

MOV A, 1 ; Закрасим первый пиксель в строке

MOV [R1R0], A ; И запишем это значение в ОЗУ

Частичным доказательством того, что этот чип мог использоваться в Brick Game — это то, что компания Holtek производила готовые «игры на кристалле» — вероятно, уже запрограммированные с завода HT1130 с определенными играми:

Примечательно, что даташит на готовые игры датируются ноябрём 1998 года, в то время как даташит на HT1130 — 1999. Если у вас появился Тетрис раньше этого времени — напишите пожалуйста в комментариях!

❯ Звук

Помимо этого, чипсет имел собственный генератор звука, или как вы вероятно подумаете — «пищалку». В чип (или SDK, если честно, не особо понятно из даташита) была уже встроена звуковая библиотека — причём половину из них как раз таки для игр, что ещё раз косвенно подтверждает догадки об использовании этого чипа в «Тетрисе». Всего поддерживалось до 16 «каналов», в которых было по 3 тональности. В звуковой библиотеке содержались следующие звуки:

• Шумы

• Мелодии

• Выстрелы

• Будильники

Управлять звуковым трактом было очень просто — буквально несколькими командами на ассемблере. Команда SOUND <номер канала> выбирала один из предопределенных звуков (причем не совсем ясно, где они хранились — возможно в ROM), а команда SOUND ONE/LOOP воспроизводила его в одном из режимов — один раз или повторяющийся. SOUND OFF же выключала звук совсем. Как-то так:

play:

SOUND A

SOUND ONE

SOUND OFF

CLC ; А если нет, то снова выполняем, пока не переполнится, эта операция очищает флаг переноса

loop:

INC A ; Увеличиваем значение в аккумуляторе

JC play ; Если флаг переноса установлен, то наш "таймер" как-бы переполнился и пора снова проиграть звук

JMP loop;

Совсем немудрено, согласитесь? :)

❯ Порты ввода/вывода и кнопки

Кроме этого, HT1130 имел несколько портов ввода-вывода, которые, однако, назвать GPIO нельзя — было 12 портов для вывода, которые могли читать логический уровень (для кнопок), и 4 пина, который мог задавать логический уровень (например, управлять вибромотором или светодиодом). Настройки портов задавались с помощью флагов: можно было настроить встроенные pull-up резисторы и они могли вызывать прерывания при переходе из высокого уровня в низкий.

Выходной порт мог быть сконфигурирован под тип выхода — CMOS или NMOS. Работа с портами шла с помощью команд IN и OUT — как в x86, а обрабатывать их можно было как-то так:

loop: IN A,0b00110010 ; Загрузить в аккумулятор значение порта PM

AND A,0b0001 ; Отсекаем биты состояний других кнопок и проверяем, нажата ли первая кнопка?

JNZ A, btn_pressed ; Если в аккумуляторе не 0 (а значит кнопка нажата) - то переходим на другую метку

JMP loop ; Если нет - то проверяем по новой

btn_pressed:

SOUND 0

SOUND ONE ; Воспроизвести звук при нажатии

❯ Таймер

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

Это позволяет регулировать скорость работы таймера, а посчитать количество тиков в таком случае не особо сложно. Однако учтите, что чем выше делитель таймера (а значит и обратно-пропорционально снижается точность таймера) — тем реже вызываются прерывания и меньше «кушают» наше процессорное время!

❯ Можно ли написать свою программу для Тетриса?

К сожалению, написать какую-нибудь свою игру для этой консоли в домашних условиях невозможно — таких удобных инструментов для прошивки, как у AVR ещё не было. Holtek предлагала собственный SDK, в которое входила IDE, ассемблер и симулятор отладки финальной программы. Однако дабы получить настоящее «хардварное» устройство, необходимо было заказывать у компании Holtek производство кастомизированного чипа с вашей программой на борту.

Чипсет использовал настоящую масочную Read-Only Memory, которая прожигалась один раз и навсегда на заводе. Производитель электроники отсылал скомпилированную программу Holtek, а они в свою очередь производили кастомный чип с прошитой программой. Несмотря на всю простоту ассемблера и устройства в целом, самому под него ничего написать не получится — внешних шин то у него нет. :(

Однако, в наше время можно разработать и собрать «Тетрис» самому: в том числе, с цветным дисплеем и на базе гораздо более мощного железа! Тут тебе и готовые мощные микроконтроллеры, и возможность собрать приставку на базе легендарного процессора Z80, да при желании можно симулировать почти настоящий HT1130 на FPGA!

❯ Заключение

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

Однако embedded-разработка тех лет была весьма интересной: когда полноценные игры вмещали в ПЗУ размером пару килобайт, на ремейки Space Invaders на современных движках весом в под сотню мегабайт смотришь с некоторой улыбкой. :)

Спасибо за наводку ресурсу retroscene:
Пост Legnahar, который один из первых опубликовал предположения насчет HT1130 и комментарию =A=L=X= под тем же постом.