Геймдев, про который мы забыли: как работали 2D-игры на кнопочных телефонах нулевых
Друзья! А вы помните, какими были мобильные игры в 2000-х годах? Помните, как разработчики умудрялись уместить целые миры в устройство с небольшим дисплеем, аппаратной клавиатурой, весьма слабым железом и парой сотен килобайт памяти? Но задумывались ли вы, как в своё время работали эти сами игры «под капотом»? В сегодняшней статье-ретроспективе предлагаю вспомнить мобильный геймдев нулевых и узнать, как же работали 2D Java-игры, какие API были доступны и что из себя представлял средний телефон тех лет! Интересно? Тогда добро пожаловать под кат!
❯ Предисловие
Пожалуй, геймдев всегда был одной из самых интересных сфер программирования. Множество нестандартных задач, возможность применить профильные математические и алгоритмические познания, а также огромный простор для архитектов в продумывании архитектуры будущей игры, ведь, например, в больших студиях комплексные и большие игры обычно очень сложные и нередко тянут за собой целый пласт легаси-кода и наработок чуть ли не из 90-х.
Но помимо десктопных и консольных игр, существуют и мобильные игры, которые в последние 5 лет вплотную приблизились к уровню AAA на консолях (привет порту GRID, AC Mirage, RE4 на мобилки). А ведь ещё 15-20 лет назад мы играли на кнопочных телефонах с небольшими дисплейчиками, которые в свое время подарили нам множество эмоций и кайфа от прохождения этих самых игр, несмотря на простенькую графику, не особо комплексный геймплей и относительно простой левел-дизайн. Продвинутые мобильные геймеры играли уже на Symbian-смартфонах и WinMobile-коммуникаторах (да, в какой-то момент времени, устройства на WM были весьма перспективными), но чаще всего — на Java-телефонах Nokia, Sony Ericsson, Siemens и, конечно-же, Samsung с LG!
По правде сказать, игры на смартфонах — тема отдельная, например на Symbian был полноценный телефон-игровая консоль Nokia N-Gage, о которой я писал отдельный материал, а о разработке игры под Windows Mobile я относительно недавно написал отдельную статью. У смартфонов обычно было несколько больше ресурсов: шустрее процессор, значительно больше памяти доступной игре, а также возможность запуска нативного кода, но и игры для них было разрабатывать значительно сложнее.
Зато о том, как работали игры на Java-телефонах информации практически нет и этот недостаток нужно исправлять, ведь это была одна из первых попыток унифицировать формат приложений на телефонах вне зависимости от архитектуры их процессоров и ОС на борту. Недавно я писал о том как работали 3D-игры на Java-телефонах, но там затрагивалась только 3D-часть без 2D, звука, обработки ввода и иных модулей, без которых игра не может работать!
❯ Каким был телефон?
В середине 2000-х годов, обычно телефон представлял из себя девайс в корпусе моноблок/раскладушка/слайдер и «флип» с весьма большим цветным дисплеем, одним/двумя (привет Motorola E398) динамиками и несколькими аппаратными кнопками. В зависимости от ценового сегмента устройства, обычно менялся корпус, разрешение и размер дисплея, а также материалы, из которого был изготовлен девайс. При этом у многих больших вендоров были собственные программные платформы — у Nokia это был S40, у Sony Ericsson своя, у Samsung и LG тоже свои.
В среднем, характеристики телефонов были следующими:
Процессор: ARMv4/ARMv5 на частоте ~100-200МГц. Есть исключения — Siemens E-Gold работал на базе архитектуры C166, а платформа Motorola работала на 66МГц (что и объясняет небольшую тормознутось).
ОЗУ: ~8Мб SDRAM. Эта память распределялась под все нужды системы, в том числе и обработку GSM, Java и пользовательский интерфейс. Java-приложениям было доступно ~1Мб ОЗУ.
Постоянная память: в среднем ~10-30Мб, плюс возможность расширения памяти за счет MicroSD или MS Pro Duo (Sony Ericsson).
Казалось бы, не густо. На самом деле вполне достаточно, учитывая все ограничения телефонов тех лет. Но почему именно Java?
Ещё в начале нулевых, когда прогресс развития телефонов шёл семимильными шагами, перед разработчиками телефонов встал вопрос, какой формат для программ выбрать, дабы привлечь как можно больше разработчиков на рынок мобильных приложений. Очевидно, что нативные программы на C/C++ точно не подойдут (разные архитектуры, большие отличия в платформах), поэтому нужна была виртуальная машина с собственным байткодом. Вариантов было несколько: Mophun, некая корейская виртуальная машина (точного названия, увы, не помню и инфы очень мало) и, конечно-же, Java с JVM. Со временем именно J2ME стала стандартом благодаря оптимальной скорости работы, хорошему и простому API и низкому порогу входа.
❯ Какие API существовали?
Несмотря на то, что игры под кнопочные телефоны писались на Java, набор API и поддерживаемых пакетов отличался от обычной JVM на ПК, которую использует, например, Minecraft. Всего существует три профиля — J2SE (Android и ПК), J2EE (серверы и энтерпрайз) и J2ME (встраиваемая электроника и телефоны). Однако сам по себе J2ME делится ещё на два стандарта — CLDC/CDC (набор поддерживаемых фишек языком — например, ранние телефоны не поддерживали float) и MIDP (набор поддерживаемых телефоном фишек — работа с дисплеем, проигрывание звуков, доступ в сеть и обработка ввода — всё это часть MIDP). За всё время существования было две версии MIDP — 1.0, которая была весьма ограничена в возможностях (например, нельзя было развернуть игру на весь экран) и использовалась с 2001 по ~2003 год и MIDP 2.0, которая использовалась вплоть до кончины J2ME.
Теоретически, появление J2ME должно было стандартизировать игры на телефонах разных производителей… но был нюанс — ведь функционал телефонов рос как на дрожжах, разрешение дисплеев тоже, у телефонов появлялась собственная память и файловая система, возможность подключения к интернету и Bluetooth и появился целых ворох API…
Несмотря на то, что игры по большей части были одинаковыми (или почти одинаковыми) на всех кнопочных телефонах, тем не менее набор поддерживаемых API каждым устройством значительно отличался. Вероятно, вы помните как многие игры подразделялись не только на версии для разных разрешений дисплея, но и на версии для каждого производителя отдельно: Nokia, SE, Samsung и т. п. Для реализации каких-то особых фишек (например, быстрая отрисовка изображений с регулируемой прозрачностью) требовалось использовать пакеты, неподдерживаемые в базовом профиле MIDP. И подобные пакеты делились на два типа — JSR и Vendor-specific пакеты.
JSR — это расширения-спецификации (то есть просто описание классов без какого либо кода), которые вносились в специальную базу Java community process и формально стандартизировались среди всех нормальных производителей телефонов. Среди таких JSR есть и поддержка 3D-графики (JSR184 — M3G, JSR239 — OpenGLES Bindings for J2ME), и доступа к файловой системе устройства (JSR75), и возможность использования Bluetooth для реализации мультиплеера (JSR82). Говоря простыми словами, это опциональные «фишки», которые могли быть доступны на каких-то телефонах, а на каких-то не поддерживались и соответственно игры, которые их используют, в большинстве случаев просто вылетают с ошибкой (однако особенно «умные» игры используют рефлексию и определяют поддерживается ли та или иная функция с помощью метода Class.forName).
Vendor-specific пакеты обеспечивали очень крутой функционал, характерный не просто одному производителю телефонов, а зачастую даже одной линейке телефонов на определенной платформе. На SE такие пакеты практически не использовались (кроме, конечно, Mascot Capsule), а вот на Nokia постоянно (Nokia UI, Nokia S40 API), позволяя на изначально «слабеньких» s40-телефонах рисовать в буфер дисплея напрямую, а также отрисовывать треугольники, рисовать полупрозрачные картинки и выполнять некоторые другие операции, недоступные на других телефонах. У Samsung, же, например, в свое время была поддержка MMF-звуков в мобильных играх, что в начале и середине 2000х годов было просто нереально крутым, даже несмотря на другие ограничения корейских телефонов.
❯ Графика
Возможности по отрисовке графики на кнопочных телефонах были не сказать что сильно широкие, но тем не менее позволяли легко реализовать графику уровня SNES или даже PlayStation 1. Например, в отличии от современных смартфонов, мы не могли использовать шейдеры, умножить спрайт на цвет (дабы придать ему другой оттенок) и даже использовать аффинные трансформации (поворот, скейлинг) — исключительно полупрозрачные спрайты даже без возможности плавно «растворить» спрайт путем изменения его альфы! Поэтому многие разработчики шли на «хак» и предварительно рисовали в редакторе 8-16 положений одного спрайтов с разным углом поворота, дабы потом выбрать нужный в зависимости от физического угла поворота в градусах!
Для графики использовался пакет javax.microedition.lcdui, в котором были классы для построения нативного интерфейса (выглядело так себе на большинстве телефонов), а также механизм фреймов (Form, Canvas).
Для игр же предлагался Canvas и GameCanvas, которые позволяли развернуть поверхность для рисования на весь экран и предлагали инстанс объекта Graphics, который сразу предоставлял механизм двойной буферизации! В свою очередь, Graphics предоставлял методы для отрисовки спрайтов (Image и drawRGB для «сырых» картинок не в нативном-формате, может быть медленно), примитивов (линии, прямоугольники, овалы), текста и… всё! Например, картинку можно было нарисовать вот так:
getGraphics().drawImage(img, 0, 0, Graphics.LEFT | Graphics.TOP);
При этом с шрифтами вопрос был отдельный: у каждого устройства был свой набор поддерживаемых шрифтов и свои фишки, о которых клиентская программа даже могла и незнать: например поздние телефоны поддерживали сглаживание шрифтов (что дико лагало на устройствах типа Nokia Asha), но что самое забавное — шрифты не могли быть произвольного размера, лишь 3х типов (один из них — моноширинный) и 3х размеров (маленький, средний, большой). Немудрено, что многие вендоры реализовывали свои рендереры битмапных шрифтов, которые точно будут нужного разработчику размера.
Но откуда же грузить картинки? Для этого, в Java был использован встроенный механизм открытия ресурсов из JAR: никакого кэша, никаких OBB, все нужные данные сразу в пакете с игрой. Да, это накладывало некоторые ограничения: например на телефонах Samsung долгое время было ограничение ~250Кб на приложение, зато было просто и портативно. Выглядело это вот так:
InputStreamReader reader = new InputStreamReader(getClass().getResourceAsStream('/img.png");
Или в случае картинок так:
Image image = Image.createImage("/img.png");
Всё очень легко и понятно, согласитесь?
❯ А звук?
Помните диалог «включить звук» при запуске почти каждой игры? Конечно же помимо графической части, в каждой игре должен быть и звук! И с его реализацией были свои нюансы: ведь в MIDP 1.0 звук поддерживался только с помощью Vendor-specific API (то есть его вообще могло и не быть, зато на телефонах Samsung поддерживался MMF, что, как я уже и говорил раннее, было очень круто).
MIDP 2.0 уже стандартизировал нормальный протокол для общения с мультимедийной подсистемой устройства с помощью пакета javax.microedition.media, в котором было три класса: Player (собственно, сам звук или музыка), PlayerListener (прослушиватель событий от плеера) и Control для управления различными параметрами воспроизведения (громкость, тональность и, вероятно, прочие расширения от производителей типа эквалайзера).
Конечно-же набор поддерживаемых форматов был невелик, но почти все устройства хотя-бы поддерживали wav (для коротких эффектов) и midi (для музыки), на ранних телефонах ни о каком mp3 и речи не шло (именно в Java-приложениях). При этом на некоторых телефонах, насколько мне известно, не было возможности воспроизводить одновременно звуки и музыку из-за отсутствия программного или аппаратного микшера. Интерфейс для воспроизведения звуков был один: мы создаём Player с помощью метода createPlayer, которому передаём адрес нужного ресурса и проигрываем его. Это мог быть как и трек на удаленном сервере (стриминг поддерживался не везде), так и в ресурсах программы:
InputStream is = getClass().getResourceAsStream("/music.wav");
Player player = Manager.createPlayer(is, "audio/x-wav");player.prefetch();
player.start();
Так почему-же в большинстве игр на телефонах тех лет были midi-мелодии вместо wav? Всё дело в размере и ресурсах: во первых, midi-мелодия на пару минут может весит пару десятков килобайт. Помните «бумер.mid», «europa.mid» и другие известные тогда файлы? Эти треки весили совсем немного благодаря тому, что в отличии от оцифрованных сэмплов (т.е аналоговых данных с микрофона), вес которых зависит от разрешения, наличие стерео и частоты дискретизации, midi оперировали лишь наборами инструментов: что где и когда нужно проиграть. Во вторых, в Java-телефонах был ограниченный объем памяти, а heap мог быть менее 1 мегабайта, поэтому загрузка даже небольшого wav-файла могло быть крайне проблематичным на таком устройстве. Поэтому выкручивались как могли!
Но в целом, аудио-возможности были хорошими. Java-игры славились весьма неплохим звуковым сопровождением для уровня телефонов, явно не хуже GBA.
❯ Мультиплеер! Давай про мультиплеер!
Вероятно многие читатели помнят, что локальный мультиплеер в Java-играх был зачастую Must-have: возможность игры с друзьями по «локалке» собирала все лавочки и подоконники в школах на переменах в жёстких баталиях на бипланах, или, например, в матчах CS для Java!
И для реализации мультиплеера у Java было довольно немало возможностей: в первую очередь, это наличие полноценных TCP-сокетов и Http-подключений с помощью класса Connection. Да, были некоторые ограничения (например на Nokia нельзя было установить TCP-соединение на порт 80 в обход встроенного клиента Http), но тем не менее даже через GPRS можно было создать с кем-то матч и попробовать поиграть, а чуть позже, к 2009 году, в РФ уже появился +- стабильный 3G и можно было поиграть в игры с достаточно быстрым и стабильным интернетом! Но интернет был дорогой, да и смысл ради сессионного матча подключаться к интернету, когда есть Bluetooth?
Появление Bluetooth в телефонах значительно расширяло возможности телефонов в обмене информации на короткой дистанции. Конечно и до этого уже был ИК-порт, который позволял передавать файлы на относительно низкой скорости, но у него была не самая большая стабильность, да и далеко не все можно было успеть перекинуть за время школьной переменной (и не все давали свой телефон «на урок»). Появление OBEX и возможности передачи файлов друг-другу через беспроводной канал дало возможность скидывать музыку и игры прямо на уроке, что было очень круто и позволило некоторым школьникам с флэшкой или телефоном с большим объемом встроенной памяти даже торговать контентом и скидывать, например, эротику за пирожок или школьную пиццу (я застал когда она уже стоила около 10 рублей — весьма немало!). Особо красноречивые ребята умудрялись уболтать друзей себе скидывать весь контент, что был у них на телефонах и становились центром внимания с новым крутым треком — я и сам в некоторой степени таким был (у меня была флэшка на 2 гигабайта!).
Но помимо возможности обмена файлами, Bluetooth также поддерживал некоторые профили: например, подключение к наушникам или протокол L2CAP/RFCOMM для установки соединения клиент-сервер между устройствами, которое и использовалось в Java-играх. Именно оно позволяло сделать один телефон сервером (хостом), а другому — клиентом, который подключается к серверу и они инициируют сессию игры!
❯ Проблемы мультиплатформенности
На бумаге все было хорошо: Java-машина была стандартизированной, поддерживаемые профили тоже и по идее игры и программы должны без проблем запускаться на большинстве Java-телефонов. Но как-бы не так: проблемы с кроссплатформенностью имели место быть. Начиная от упомянутых выше Vendor-specific API и версиями MIDP, заканчивая… как это ни странно, разрешениями экрана.
Да, сейчас игры не зависят от разрешения дисплея благодаря возможности скейлинга картинок до любого размера. Таким образом достаточно заранее нарисовать спрайты для, например, FHD разрешения и просто скейлить их по размеру дисплея в меньшую или большую сторону. Никто не мешает и отдалять камеру в зависимости от разрешения дисплея, впрочем, это считается не очень хорошей практикой (и зависит от игры).
Во времена Java-телефонов, зависимость от разрешения дисплея была критичной и поэтому игры для «не того» разрешения либо выходили за экран, либо наоборот — выглядели слишком маленькими и игрались в небольшом окошке. Многие вероятно вспомнят как устанавливая игру для малого разрешения дисплея, можно было заметить как шлейфом уезжают спрайты за виртуальный экран и остаются на белом фоне…
Небольшие проблемы были и с обработкой ввода. И если резистивные тачскрины поддерживались еще в MIDP 2.0 с помощью обработки определенных событий, то с мультитачем (во времена Asha и поздних телефонов Samsung) было уже сложнее. Другой вопрос что даже коды кнопок почему-то не унифицировали, из-за чего возникало деление на Samsung, Sony Ericsson и Nokia: разработчики J2ME предполагали что смартфоны будут в разных форм-факторах и предоставили лишь механизм для унификации «игровых» кнопок. Таким образом, некоторые игры, собранные под телефоны конкретного производителя могли не реагировать на нажатие кнопок клавиатуры из-за отличающихся кодов клавиш.
❯ Заключение
Друзья! Вы, вероятно, думаете что если телефоны с поддержкой J2ME больше не производятся, значит и коммьюнити уже «всё»? Как-бы не так: после моих статей мне продолжают писать читатели и спрашивать детали реализации тех или иных техник или игровых механик! Да, энтузиастов мало, но они есть, как и у ретро-компьютеров: например, спектрума, или консолей типа NES… А значит наше дело будет жить и Java-телефоны с их играми останутся в наших сердцах, а Java-телефоны останутся на скрижалях истории! Берегите своих кнопочных красавцев и восстанавливайте по возможности, благо пока-что даже корпуса на популярные модели кнопочных телефонов найти относительно легко.
Надеюсь, сегодняшний материал вам был интересен, писал его специально так, чтобы было понятно даже тем читателям, которые не пишут код или знакомы с программированием поверхностно. Подписывайтесь на мой Telegram-канал, куда я публикую различные мысли и советы по ремонту и программированию под гаджеты прошлых лет, подсъемы с новых видосов и всегда актуальные ссылки на новые статьи!
Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю!
Красивый?) Nokia 6233
Сможете найти на картинке цифру среди букв?
Справились? Тогда попробуйте пройти нашу новую игру на внимательность. Приз — награда в профиль на Пикабу: https://pikabu.ru/link/-oD8sjtmAi
Исходников нет, но мы не сдадимся: как и зачем я портировал более старый Android, чем стоял «с завода»?
Моддинг-сцена с разработкой и портированием кастомных прошивок для 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-смартфоны? Пишите в комментариях, будет интересно почитать!
Я это сделал. Починил Sony Ericsson S700
Всем привет. Могу сообщить радостное известие: я наконец-то починил свой Sony Ericsson S700, который давно у меня лежал и требовал ремонта. Лежал вот в таком виде
Первоначальный разбор телефона привел к пониманию того что без донора не обойтись. Поэтому пришлось очень долго его искать по приемлемой цене и с возможностью доставки в мой город. Проблема в том, что такие старые телефоны не очень массовые, найти их не очень лёгкое дело, а уж найти донора, так и вовсе тяжело. Но донор был найден и заказан. Оставалось дело за малым. Дождаться и починить. И вот сегодня я забрал донора с почты. А сейчас могу сказать, что Sony Ericsson S700 ожил и работает прекрасно
Только посмотрите на этого красавца. Я от него в восторге, а моя коллекция продолжает пополняться ретро телефонами
На старой аналоговой телефонной станции
Если вы профи в своем деле — покажите!
Такую задачу поставил Little.Bit пикабушникам. И на его призыв откликнулись PILOTMISHA, MorGott и Lei Radna. Поэтому теперь вы знаете, как сделать игру, скрафтить косплей, написать историю и посадить самолет. А если еще не знаете, то смотрите и учитесь.
Игровая легенда из нулевых: каким был Nokia N-Gage QD? Обзор, аппаратный ремонт и программирование под Symbian
Друзья! Многие ли из вас помнят такой телефон, как Nokia N-Gage? В начале нулевых финская компания сделала смелую попытку ворваться на рынок игровых консолей, создав устройство, которое сочетало в себе сразу две функции: полноценный смартфон на базе аппаратной платформы WD2 с Symbian на борту и игровая консоль с собственными картриджами! Год назад читатель подарил мне N-Gage QD с некоторыми аппаратными проблемами, которую я успешно оживил и подготовил подробную статью, в которой мы: узнаем историю появления N-Gage на свет и на чём он работал «под капотом», отремонтируем устройство и узнаем о самых частых аппаратных «болячках» смартфонов Nokia на платформе WD2, а также посмотрим на местную игровую библиотеку подробнее и выясним особенности разработки игр под Symbian! Интересно? Тогда добро пожаловать под кат!
❯ Что за N-Gage и как он появился?
Пожалуй, в истории мобильного подразделения Nokia, N-Gage один из самых желанных и неоднозначных устройств, когда либо разработанных компанией. Девайс прошёл долгий путь от смартфона, который ругали чуть ли не все, до легендарного устройства, которое ценится некоторыми людьми и сейчас.
По сути, N-Gage является уникальным смартфоном. За всё время существования мобильного рынка, по настоящему игровых телефонов почти и не выходило: можно вспомнить телефоны Sony Ericsson с геймпадом EGB-30,Xperia Play, японские и корейские телефоны, о которых мало кто слышал, да и китайские реплики Nokia с эмулятором NES на борту.
Я писал материал о Xperia Play год назад
В начале нулевых, рынок мобильных игр начинал активно развиваться. С ростом мощностей мобильных девайсов и появлением цветных дисплеев, стали появляться самые разные платформы для запуска мобильных приложений и продажи игр через операторские сети. Например, довольно большим успехом пользовалась перспективная платформа Mophun (Sony Ericsson T310, T610), которая использовала собственный платформо-независимый байткод. Помимо этого, в платформе были уже готовые библиотеки для упрощения разработки игр: вывод 2D спрайтов, 3D графики (программный рендеринг), звука и обработка ввода. Нельзя также не вспомнить о Qualcomm BREW — который использовался во многих CDMA-телефонах в США и была по настоящему нативной, позволяя использовать все ресурсы телефона. Но самой популярной стала, конечно же, J2ME, которая предустанавливалась на большинство телефонов до ~2014 года.
Sony Ericsson T610 - один из девайсов, поддерживающих Mophun
Само собой Nokia не могли упустить момент и не попытаться занять нишу на мобильном рынке игр. У Nokia было две основные платформы: S40, используемая в кнопочных телефонах и S60, платформа основанная на Symbian, которая использовалась в смартфонах компании. Уже в 2003 году, в платформах S40 и S60 была полноценная поддержка J2ME игр и Java показывала себя как достаточно перспективная платформа. Nokia даже реализовали свои собственные расширения для J2ME, дабы игры могли использовать больше возможностей устройства, чем предоставляет MIDP. В целом, телефоны Nokia были очень популярными, благодаря чему почти все J2ME игры имели собственную версию под S40 (а иногда и более навороченные под S60).
N-Gage, который должен был объединить телефон и игровую консоль, был анонсирован ещё в ноябре 2002 года, однако вышел в свет 7 октября 2003 года.
Первая версия N-Gage
Однако N-Gage был отнюдь не первым устройством в подобном дизайне. Его предком принято считать Nokia 3300 — смартфон, который в первую очередь был ориентирован для использования в качестве мультимедийного устройства и прослушивания музыки. Тем не менее, устройство тоже поддерживало J2ME и на нём вполне можно было проходить Symbian-годноту из нулевых.
N-Gage был встречен весьма неоднозначно. В устройстве было достаточно много как аппаратных, так и программных недоработок, которые вызывали недовольство среди пользователей. Первая и пожалуй самая главная для игровой консоли — отсутствие возможности горячей смены картриджей с играми. Сами игровые картриджи были реализованы в виде обычных MMC-карт памяти, однако, судя по всему в S60 не было поддержки «горячей» замены карт памяти как таковой, из-за чего для смены игры необходимо было сначала достать аккумулятор, заменить флэшку с игрой, установить аккумулятор, включить устройство и дождаться его загрузки (секунд 15) и только потом уже начинать играть. А учитывая, что это был телефон, то довольно длительное пребывание вне сети устраивало далеко не всех пользователей.
Картриджи были проблемой и для жителей отдаленных регионов. В России, насколько мне известно, картриджи можно было купить только в Москве и СПБ, хотя возможно и ещё в каких-то больших городах. Но вот, например, у меня, жителя Ейска, едва ли была возможность купить картридж «физически» — разве что только под заказ. Другое дело Java игры, которые весили по 50-100 килобайт в те годы и без проблем скачивались даже через мобильный интернет. Впрочем, судя по всему, никакого особого DRM в N-Gage играх не было и после того, как энтузиасты научились сливать игры с MMC-карточек — на N-Gage начало процветать пиратство.
Даже с точки зрения звонков у девайса были свои нарекания. Конструктивно инженеры Nokia решили расположить слуховой динамик не с лицевой части, а с боковой. Из-за этого для разговоров приходилось переворачивать телефон боком. Выглядело это весьма необычно для прохожих, незнакомых с N-Gage. :)
Тем не менее, в устройстве были и революционные решения: вспомнить хотя-бы N-Gage Arena, который объединял мобильных игроков в одну сеть с друзьями, таблицами рекордов и т. д.
Чуть меньше чем через год, в мае 2004 года вышла N-Gage QD: исправленная и доработанная версия N-Gage, в которой заметно изменили дизайн, добавили поддержку замены картриджей без выключения девайса и добавили слуховой динамик на переднюю часть корпуса. Именно эта версия N-Gage стала популярной и её чаще всего можно найти на онлайн-барахолках.
И хотя N-Gage ругали за недоработки, мобильным игрокам она полюбилась за высокий уровень игр для телефонов тех лет: графика была гораздо лучше чем на GBA и была близка по уровню к PS1, геймплей разнообразнее, чем в Java-версиях, да и сами игры имели довольно большой полноценный сюжет. Это был действительно замах на уровень таких мастодонтов, как Nintendo! Приятным бонусом была полноценная поддержка Java-игр, благодаря чему на телефоне можно было гораздо удобнее проходить уже вышедшие игры для MIDP 1.0, даже если вся библиотека игр N-Gage уже была пройдена!
Не менее интересно девайс устроен и «под капотом». Как я уже говорил выше, N-Gage был построен на базе зарекомендовавшей себя платформы Nokia WD2, которая использовалась в смартфонах 3650, 3300, 3230, 6600 и.т.д. Многие годы смартфоны Nokia работали на базе чипсетов OMAP, в случае WD2 это скорее всего (не точно, есть вероятность что UPP собственной разработки — как и в случае с S40) были специализированные версии OMAP с «перевернутыми» регистрами для предотвращения портирования Linux на устройства Nokia, поскольку OMAP были доступны рядовым энтузиастам.
Характеристики N-Gage были следующими:
Процессор: ARMv4 ядро на частоте 104МГц, что было стандартом для многих телефонов в те годы (например Siemens на платформе S-Gold работали на той же частоте, а E-Gold — вдвое меньшей). Скорее всего, процессор собственной разработки Nokia.
Память: 16Мб SDRAM ОЗУ и 16Мб ПЗУ, раздельно. Иногда флэш-память изнашивалась и в СЦ её нередко меняли. Мои читатели, которые в нулевых работали в СЦ наверняка вспомнят о "бутербродах" на некоторых телефонах :)
Дисплей: 2.1" матрица с разрешением 176x208 и глубиной цвета 12-бит (4096 цветов), выполненная по технологии CSTN (хотя возможно и TN). Для тех лет, диагональ дисплея и его разрешение были оптимальными, круче были только коммуникаторы с 2.4" дисплеями 240x320. Фактически все (или почти все) смартфоны Nokia на Symbian тех лет использовали одну и ту же матрицу, с чуть разной длинной шлейфа (просто где-то её переворачивали вверх-тормашками, как на N70).
ОС: Symbian 6.1
Аудиовыход: 2.5мм джек (моно)
Как видите, ни о каком GPU и речи не шло. Вся отрисовка полагалась исключительно на процессор и результат того, что даже такие крутые 3D-игры как Tony Hawks и Tomb Raider идут на N-Gage — заслуга программистов, которые оптимизировали свои рендереры для работы на 104МГц ядре! А ведь некоторые телефоны тех лет (например, Motorola) использовали отдельные 2D GPU для ускорения отрисовки интерфейса и работы с камерой — ATI Imageon!
Благодаря тому, что девайс строился на смартфонной платформе, на нем можно было не только играть, но и слушать музыку, а также смотреть видео и серфить интернет. Весьма и весьма для тех лет!
Даже спустя несколько лет после выхода телефон N-Gage, сам бренд и платформа N-Gage Arena продолжила существование на флагманских смартфонах Symbian, которые уже не имели такой игровой дизайн. Одним из N-Gage 2.0 девайсов была легендарная Nokia N95, которая в плане игровой направленности была гораздо круче, поскольку в устройстве использовался GPU PowerVR MBX Lite. Да, точно такой же, как и в iPhone 2G!
❯ Как он ко мне попал?
Конечно же, рано или поздно я и сам хотел обзавестись собственной N-Gage, с чем мне помог мой читатель, причём всё как я люблю: девайс был полурабочим и требовал некоторого ремонта. Более года назад мне написал подписчик на DTF с никнеймом «Improved white bonkle» и предложил заслать N-Gage QD и ещё одну плату под ремонт с некоторыми аппаратными проблемами: первая плата висела на белом экране, а вторая просто висела на логотипе Nokia без подсветки экрана. Помимо N-Gage, читатель положил «толстую» зарядку и флэшку на 1Гб, за что ему огромное спасибо.
Читатель рассказывал, что девайс он покупал у некого коллекционера «гаг» в России и довольно много играл на ней в эксклюзивные игры для данной платформы. После поломки устройства, девайс лежал у него какое-то время, пока он не заметил мои статьи и не решил заслать устройство под ремонт в хорошие руки. :)
Ну что-ж, давайте оживим девайс!
❯ Ремонтируем устройство
Я не зря отметил то, что девайс подарили мне более года назад. Мне удалось сразу продиагностировать N-Gage и обнаружить неисправности, однако фактически отремонтировать устройство у меня не вышло: в то время я откровенно «бомжевал» и у меня даже более-менее адекватной паяльной станции не было. Дабы было понятно: тогда я перепаял коннектор АКБ, сейчас я восстановил BTEMP. На данный момент мне материально активно помогаете вы, мои читатели, поэтому за год я смог обустроить небольшое рабочее место, пригодное для проведения большинства ремонтных работ.
Разбирается девайс очень просто, как и большинство телефонов Nokia тех лет: снимается передняя часть корпуса (панелька), откручиваются винты, снимается пластиковая часть с клавиатурой, дисплей и затем плата из задней части корпуса. Кстати, панельки очень часто любили менять для придания свежего вида устройству: эдакие скины тех лет. :)
Обратите внимание на то, что некоторые детские болячки пользователь и сам мог отремонтировать. Не работает разъём ЗУ, наушники, вибромотор или динамик? Пошёл, купил за 10 рублей на ближайшем радиорынке и сам поменял! Вот уж настоящий right to repair. :)
Визуально осмотрев плату, я пришёл к выводу, что плата скорее всего не копанная китайцами: компаунд UPP'а (процессор) и Mjoelner (радиотракт) был не тронут, флэша с виду тоже в норме, все элементы стояли ровно. Однако около коннектора аккумулятора, я обнаружил следы канифоли: кто-то явно вручную перепаивал коннектор АКБ. Спросив у читателя, я получил утвердительный ответ: он действительно пытался перепаять коннектор аккумулятора с помощью советского паяльника.
Но почему же тогда устройство виснет на заставке Nokia без подсветки? Давайте взглянем на схему:
У коннектора АКБ три контакта: плюс питания, масса и BSI, который уходит напрямую в UEM (контроллер питания). Смартфоны Nokia на платформе WD2 были очень капризны к сопротивлению на BSI и UEM отказывался давать разрешение на старт при установке несовместимого аккумулятора. Казалось бы, BL-4C, BL-5C и BL-5CB по размерам почти одинаковые, но имеют разное сопротивление на BSI.
Однако даже при установке совместимого АКБ, устройство отказывалось включаться. Вывод простой: линия BSI находится в обрыве. Первым делом я сдул коннектор АКБ, перепаял его и девайс наконец-то нормально включился… ненадолго.
Произошло падение в «белый экран», как и вторая плата. Причиной этому стала «стекляшка» рядом — токовый датчик LM3820: вероятно, в ходе ремонта коннектора, читатель умудрился неравномерно поплавить шары под стекляхой, из-за чего контакт нарушился. Стекляха среагировала на прогрев с флюсом и девайс снова включился…
Коннектор АКБ уже был, в скажем так, не идеальном состоянии, поэтому для точного исключения влияния коннектора я залудил контакты. Я люблю, когда платы не уколхожены, а весь ремонт близок к заводскому - поэтому коннектор "за кадром" будет заменен на норм.
Но не заряжался. :( При попытке зарядить девайс, система показывала сообщение «не заряжается» и потребление падало в ноль. Ремонт я проводил ещё тогда, когда у меня и станции нормальной не было, из-за чего я умудрился сколоть NTC-термистор прямо под коннектором аккумулятора (обычно он расположен либо с обратной стороны коннектора АКБ, либо с обратной стороны платы), прямо с пятачками.
Я знаю, что иногда меня читают опытные мастера с многолетним опытом, которые уже тянутся написать «Рукожоп! Мы в нулевых в ещё более тяжелых условиях умудрялись мобилки ремонтировать, а ты вон люкей себе не смог купить!». Но я лично считаю, что если косяк нормально исправлен, даже через год — то это не косяк. :) Поэтому лезем в схему и смотрим, куда у нас уходит BTEMP:
BTEMP идёт в UEM через обвязку в виде конденсатора C230, который расположен с обратной стороны платы, около КП. Найти его можно в Component finder'e, который можно найти в самом конце почти любой схемы на телефоны Nokia:
Подпаиваемся, включаем и девайс и… всё снова работает, в том числе и зарядка. :)
На этом ремонт устройства закончен.
Отдельное слово хотелось бы сказать о дисплеях: для N-Gage обычно их принято считать достаточно редкими. Однако есть нюанс: практически все смартфоны Nokia на платформе WD2 (и пару на BB5 — например, N70) использовали одну и ту же матрицу с параллельным интерфейсом. Различия были лишь в форме шлейфа. В N70, например, этот дисплей ставился «перевернутым», однако длины шлейфа не хватало для того, чтобы поставить дисплей в N-Gage. Тем не менее, теоретически можно попробовать поставить куда менее редкий дисплей от 6630.
В процессе подготовки материала и изучения схемы, я вывел небольшой мануал по базовой диагностике N-Gage и любого телефона Nokia на платформе WD2:
Белый экран, есть звук включения и реакция кнопок. Чаще всего виноват EMIF-фильтр COM01F2: хрупкая «стекляха», которая повреждается при попадании влаги или падении устройства. Реже — обрыв сигнальных линий дисплея до коннектора дисплея, а то и отвал омапа.
Белый экран, ноль реакции: из-за бага в первых версиях прошивки, при полном заполнении внутренней памяти девайс виснул на белом экране. Реже — проблемы с питанием на OMAP, отвал процессора. Из-за попадания воды может пострадать токовый датчик.
Нет подсветки, лого Nokia: обрыв BSI или неподходящий аккумулятор.
Нет реакции на кнопку включения: замерить напряжение на входе кнопки включения (должно быть близко к VBAT), дальше смотреть в сторону UEM и его обвязки. На некоторых смартфонах Nokia (уже чуть более поздней платформы — например N70) кнопка включения идёт через EMIF-фильтр вместе с клавиатурой, из-за чего убитая стекляха может стать причиной отсутствия напряжения на PWRON.
Нет подсветки, есть изображение: проверить напряжение на C130 — если там есть 13.3В, значит бустер работает нормально. Если напряжение более 13В, то нет фидбека (т. е. катода с подсветки на самом дисплее), необходимо проверить обрыв на коннекторе дисплея. Проверить драйвер подсветки D130, при необходимости заменить (подходит с многих Nokia тех лет, иногда кустарно заменяют на драйверы подсветки с других телефонов).
❯ Знакомимся с девайсом поближе
Как я уже говорил выше, читатель задарил мне ещё и флэшку, на которой было установлено куча игр: как портов игр с других платформ, так и нативных «дампов» с картриджей, а также эмуляторов. Было ли во что поиграть на N-Gage? Давайте узнаем:
Именно на платформу N-Gage вышло не так уж и много игр: всего около 50. Однако среди них всё равно найдется во что поиграть: многие известные издатели решили рискнуть и разработать игры по собственным вселенным для N-Gage. В каких-то случаях это были порты с других платформ (например, Asphalt 2 с PSP, хотя это не совсем верно, поскольку Asphalt изначально мобильная игра), в каких-то уникальные игры, дополняющие ЛОР той или иной вселенной (например, TES Travellers). Не забываем про игры для обычных Symbian-смартфонов, порты и J2ME игры: таким образом, библиотека получается весьма и весьма обширной!
Ну и не стоит забывать и о эмуляторах! С играми для NES и SMD, игровой потенциал N-Gage увеличивается в разы. Ещё бы дисплей был чуть-чуть побольше и хотя-бы классический TN, а не немного блеклый CSTN и было бы вообще идеально.
Помимо игр, на многих Symbian-смартфонах стояли некоторые приложения, которые были must-have для тех лет: например, файловый менеджер X-Plore с диспетчером задач, а также сторонний плеер LCG JukeBox (нормальный плеер с плейлистами появился только в Symbian 8). Иногда диспетчер задач не спасал и девайс приходилось перезагружать.
Давайте же глянем на игры подробнее. Как я уже говорил ранее, все 3D-игры были софтварными: т. е. вся трансформация, обработка освещения и растеризация треугольников с текстурированием и перспективной коррекцией (если была) происходила исключительно на ЦПУ. Поскольку FPU в процессоре не было, использовались fixed-point числа.
Переходим к гоночкам. Тут у нас аж две части Asphalt, ещё тогда, когда серия не стала донатным «фритуплеем». Asphalt 2 весьма занимательная игра с оптимальной производительностью, кое-где конечно бывают просадки, но в целом более чем играбельно. Как это игралось в нулевых? Сравните скриншоты с j2me-версией, которая напоминает гоночные 2.5D игры с SMD и NES (при этом, в ней есть 3D-элементы и игра использует M3G) и версию для Symbian/PSP/NDS, думаю тут всё итак будет понятно:
Однако большинство читателей наверняка интересуют игры в известных вселенных. Взять, например, полноценный порт первой Tomb Raider. Насколько я понимаю, оригинальная TR славилась тем, что изначально разрабатывалась с расчетом на легкое портирование между разными платформами (да чего уж там говорить, игру отреверсили и переписали с нуля как минимум два раза!). Первый Pentium неплохо тянул TR в софтваре, а N-Gage справляется явно не хуже:
Не забываем и про 2D! В некоторых телефонах Motorola, Siemens и Samsung использовались внешние 2D видеоускорители ATI Imageon. В их задачи входила обработка изображения с камеры, функции контроллера дисплея, а также аппаратное ускорение некоторых 2D-операцией: блиттинг, отрисовка линий, прямоугольников и возможно ещё каких-то примитивов. Однако N-Gage, даже без помощи аппаратного блиттинга был способен выдавать приемлемый FPS и уровень графики в 2D играх. Например, в Sonic, где у нас есть параллаксовые фоны с покадровой анимацией:
Ну и нельзя не вспомнить про уникальную игру на N-Gage: TES Travels Shadowkey, которая была разработана специально для N-Gage и поиграть в неё можно только на оригинальном N-Gage, пропатченном Symbian-девайсе или EKA2L1. Вообще, это полноценная RPG от первого лица, расширяющая лор игры в Хаммерфелле и как минимум из-за этого она достойна к ознакомлению. Игра стилистически заметно напоминает Morrowind, графика близка по уровню к PS2. FPS, конечно, колеблется в районе 10, из-за чего игру можно считать пошаговой… но тем не менее, полноценная FPS RPG на мобилках — это многого стоит!
Есть также примеры отличной графики и… очень низкой производительности. Если в TES ещё можно попробовать поиграть в пошаговой манере, то как насчет шутера от первого лица в 5-6 кадров? Речь, конечно же, о Call of Duty. Игра получилась очень красочной (с трушными полигональными ландшафтами и кучей пропов), но крайне медленно работало на желез N-Gage.
❯ А как насчёт хоумбрю?
С разработкой своих приложений под N-Gage дела обстоят сложно. С одной стороны, в Symbian 6.1 ещё не было сертификатов, необходимости делать джейлбрейк и менять дату в устройстве. С другой стороны, для разработки под N-Gage требуется установка оригинального SDK для S60: приложения скомпилированные с помощью более свежих версий SDK работать не будут! Ни о каком Qt и речи не идёт и даже Carbide окажется слишком свежим для нашего устройства.
Оригинальный SDK можно скачать здесь.
Кроме того, SDK использует весьма своеобразную систему сборки, написанную на Perl, которая поддерживает только древнюю версию ActiveState Perl 5.6.1 аж от 2001 года и не работает на Windows 7/8/10! С отладкой на реальном устройстве тоже возникнут проблемы: для этого необходим относительно редкий FBus-кабель (который устанавливается вместо аккумулятора и подключается к ПК через RS232-преобразователь), либо использование программатора а-ля UFS HWK. Хотите отлаживать игру на ПК? Тут есть симулятор, прямо как при разработке под iOS: однако этих симуляторов целых два (для Visual C++ 98 и CodeWarrior) и с каждым возникают проблемы при сборке (то линкер крашнется, то разработчики забудут положить часть реализации системных либ для разных симуляторов в разные версии SDK). Хотите разрабатывать игры? С симулятором об этом можно забыть — отрисовка слишком медленная. Готовьтесь писать кроссплатформенный рантайм, который под Windows будет использовать GDI, а под Symbian нативное API для графики! Программа крашнулась на реальном устройстве и инструментов для отладки у вас нет? Ничего подробнее «приложение остановлено» вы не получите!
Ну а вишенкой на торте станет весьма своеобразный сабсет C++, который используется для написания приложений. Сама система полностью построена по принципам ООП, однако ради уменьшения размера выходного кода была полностью убрана поддержка исключений: предполагается, что программист будет вручную помещать объекты на стек (для Stack unwinding'а), полностью убран RAII как концепция с введением NewL и ConstructL, где L — означает Leave (т.е исключение может выбросить только функция-фабрика, а не фактический конструктор) и кодов ошибок, а также полное отсутствие поддержки глобальных переменных (но есть частичная поддержка констант — из преинициализированных данных, судя по всему, поддерживаются только строковые литералы). Да, никакого .data и .bss, что серьёзно усложняет портирование существующих приложений под Symbian. Спасибо что есть пакет для совместимости с POSIX и реализовали часть stdlib.
Почему нет глобальных переменных?
Приложения в Symbian — это, по сути, dll-библиотеки, с которыми общается UI-фреймворк. Ради сохранения памяти, в Symbian решили сделать все загружаемые библиотеки доступными для любых процессов в системе. Поэтому Symbian и не позволяет библиотекам иметь собственную статическую память, зато можно свободно использовать динамический аллокатор. У exe таких ограничений нет, однако там свои сложности при взаимодействии с системным API. Тем не менее, с Quake поступили своеобразным грязным хаком: Приложение в меню лишь «значок», который фактически запускает соответствующий exe-файл на флэшке!
Дело улучшает кастомный SDK для хоумбрю от энтузиаста из Германии. Он портировал SDL2, Lua и адаптировал тулчейн для работы в современных системах. Но лично для меня это не трушно — нужно использовать оригинальный SDK. :)
В целом — это одно из объяснений того, почему N-Gage стала относительно провальной как платформа для игр. Конечно в своё время был жив форум разработчиков Nokia, где были как официальные сэмплы от Nokia, так и мануалы от других разработчиков, однако базовые косяки при проектировании архитектуры платформы портили всю малину. Чего уж стоит обратная совместимость: для быстрой отрисовки графики предполагалось рисовать картинку в обход графического сервера, напрямую получая указатель на фреймбуфер. В начале фреймбуфера лежала структура с описанием разных пиксельформатов, которые были отнюдь нестандартными: 12-битный, 16-битный, 18-битный. Из-за этого, игры для старых версий Symbian могли давать артефакты на 9.x, например.
Написание полноценной, пусть и небольшой игры — материал для отдельной статьи. Есть идея написать кроссплатформенную игрушку, которая работала под разными платформами кнопочных девайсов: от Motorola ROKR на Linux и китайских клонах Nokia (E71 все помнят?), до эльфов на Siemens'ах и Motorola E398. Таким образом, мы рассмотрим особенности разработки под каждую платформу (например, на моторах был 2D-ускоритель ATI Imageon).
❯ Заключение
Вот таким был легендарный N-Gage. Девайс, конечно, действительно весьма своеобразный. С одной стороны это гениальное решение: взять смартфонную платформу и сделать на её базе игровую консоль. С другой стороны, с разработкой игр под N-Gage, или, например, прямыми функциями телефона были свои проблемы. Девайс получился немного сыроватым, но лично я считаю, что концепция имеет право на жизнь, но пока ни у кого не получилось сделать действительно массовый девайс. По моему мнению, нужно сохранить как можно больше N-Gage живыми. Сложно даже представить сколько потенциально оживляемых плат уехало в чермет…
А вам понравился N-Gage?
P. S.: Друзья! Время от времени я пишу пост о поиске различных китайских девайсов (подделок, реплик, закосов на айфоны, самсунги, сони, HTC и т. п.) для будущих статей. Однако очень часто читатели пишут «где ж ты был месяц назад, мешок таких выбросил!», поэтому я решил в заключение каждой статьи вставлять объявление о поиске девайсов для контента. Есть желание что-то выкинуть или отправить в чермет? Даже нерабочую «невключайку» или полурабочую? А может, у этих девайсов есть шанс на более интересное существование! Смотрите в соответствующем посте, что я делаю с китайскими подделками на айфоны, самсунги, макбуки и айпады!
Понравился материал? У меня есть канал в Телеге, куда я публикую бэкстейдж со статей, всякие мысли и советы касательно ремонта и программирования под различные девайсы, а также вовремя публикую ссылки на свои новые статьи. 1-2 поста в день, никакого мусора!
Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю!