Пилили софт для LG:

Добавляли в Android поддержку CDMA помимо GSM (комdпания Teleca):

Помогали пилить Maemo и Meego (которая теперь стала Sailfish и в последствии Авророй):

И по заявлению комментатора с Хабра даже Nokia X (тот самый Android-смартфон) помогали доделать :)

Помните мою статью про историю моддинга и аппаратную платформу Motorola E398? Если ещё не читали, то рекомендую ознакомиться. А тем временем у EXL нашёлся редчайший прототип E398, который работал на Linux! Если интересно почитать его историю - жду вас под катом.

Что за девайс?

Прототип, разработанный в 2003-2004 году, на первый взгляд представлял из себя самый обычный E398 (также известный как D398 или E399) с немного измененным дизайном. Отличия по большей части минорные: немного другая форма клавиатуры, синий цвет корпуса и кнопка меню, которая больше напоминает оную из C350.

На самом же деле, это корпус от раннего прототипа E398, который разрабатывался параллельно с Linux-моделью:

Однако при включении этого экземпляра, нас встречает не классическая заставка Hellomoto, а загрузчик, который радостно сообщает о запуске AP-процессора...

Что такое AP-процессор?

В обычных телефонах для работы всего устройства достаточно лишь одного процессора - так называемого Baseband'а. Чаще всего это один чип, который содержит в себе одно ядро общего назначения - например ARM7TDMI, которое занимается задачами отрисовки интерфейса, высокоуровневой работой с GSM-стеком и обработкой AT-команд, и вспомогательное ядро DSP, в задачи которого входит низкоуровневая работа с сетью, кодирование/декодирование звука и иногда некоторые другие задачи. Baseband-процессоры всегда работают исключительно на RTOS, поскольку при работе с GSM-стеком необходима гарантированная и строгая по времени выполнения реакция на события в сети.

В смартфонах же всё работает чуточку по другому: там задача запуска операционной системы, пользовательских программ и обработка ввода ложится на отдельный Application-процессор. На нём можно использовать любую операционную систему, включая по большей части не-реалтаймовые по типу Linux, Windows NT и Windows CE. Однако в смартфонах Baseband-процессор всё равно присутствует, только теперь он подключен к AP-процессору через шину по типу UART (в современных шин несколько, а сам Baseband переехал в основной SoC).

После этого, телефон показывал логотип MontaVista Linux и загружал самый обычный рабочий стол, почти как в E398... Но это только на первый взгляд!

Дело в том, что у Motorola существовало сразу несколько программных платформ для телефонов:

• Знакомый нам P2k, который использовался в основной линейке телефонов компании.

• Motorola EZX, который был построен на базе дистрибутива MontaVista Linux и UI-фреймворка Qt с кастомной оконной системой. Эта платформа встречалась в флагманских устройствах компании с 2003 по 2007 год: Moto E680, Moto A1200 Ming, Moto A780, Moto ROKR E2 и ROKR E6.

• MotoMAGX, который также был построен на базе дистрибутива MontaVista, только уже под названием Mobilinux. Как и EZX, MotoMAGX использовала Qt в качестве UI-фреймворка, но изнутри значительно отличалась от EZX и предназначалась для флагманских телефонов Moto вышедших в 2007-2009 годах: RAZR2 V8, EM30, ZN5.

• JUIX, который по сути света так и не увидел. Это была промежуточная разработка между EZX и MAGX на без той-же самой MontaVista, однако теперь вместо Qt использовалась Java, а весь интерфейс и окружение были написаны с использованием профиля CDC (урезанная Java 1.3). По сути, это была некая попытка написать Android ещё до самого Android, только с заделом сразу под кнопочные устройства и без возможности лицензирования...

И этот прототип как раз использовал раннюю версию JUIX. Однако несмотря на то, что внешне телефон кажется полностью функциональным, у него вообще не работали кнопки навигации. Скорее всего, инженеры Motorola просто не успели написать драйвер для обработки клавиатуры, поэтому EXL написал небольшую программу для проброса ввода через telnet:

Но как вы понимаете, у раннего прототипа особо никакого функционала и не было, а проект довольно быстро отменили. Но самое интересное скрывается у него внутри. На первый взгляд кажется, что у прототипа с серийными телефонами нет никаких отличий:

Однако если присмотреться, то можно заметить что вместо слота MicroSD выглядывает какой-то чип... И при ближайшем рассмотрении оказывается, что это не просто какая-то eMMC-флэшка, которую повесили на MMC-шину устройства, а тот самый AP-процессор! Причём сама аппаратная платформа осталась до боли знакомой: в качестве Baseband'а используется всё тот же Neptune LTE, практически вся схемотехника идентична оригинальному устройству, однако в телефоне отсутствует чип, отвечающий за Fun lights и вместо него разведен отдельный драйвер подсветки дисплея.

Поскольку это прототип, Neptune LTE здесь сразу же установлен инженерный и следовательно загрузчик устройства разблокирован с завода. Однако в его модификации смысла нет, так как P2k здесь не используется, да и пока неизвестно есть ли что-то на микросхеме его Flash-памяти.

Зато AP-процессор здесь очень даже знакомый! Это легендарный Intel PXA272, который также использовался в других Linux-телефонах Motorola на платформе EZX, как, например, A1200 Ming, а также в подавляющем числе Windows Mobile смартфонов. По своей сути, это один из самых мощных мобильных процессоров тех лет, который применялся в флагманских КПК и коммуникаторах. Внутри него скрывается:

• Одно вычислительное ядро Intel XScale, реализующее набор инструкций ARMv5. Да, когда-то Intel не просто выпускала ARM-процессоры, но и разработала свою собственную микроархитектуру, отличную от ядра ARM9. XScale способен работать на частоте до 624МГц (это огромная частота и MIPS по меркам телефонов тех лет, процессор мало в чём уступал пока ещё не совсем устаревшим младшим Pentium III), использовал относительно короткий 7-ступенчатый конвейер инструкций (для сравнения, P III имел около 10 стадий, P4 - аж 20-30 стадий в зависимости от ядра, что его значительно замедляло из-за "сломанного" Branch Prediction), имел 32КБ кэша инструкций и 32КБ кэша данных и поддержку одного из первых мобильных SIMD - набор инструкций Wireless MMX (за ~7-8 лет до массового появления NEON в смартфонах). Однако у PXA был и минус - не было FPU, поэтому все операции с плавающей точкой были относительно медленными.

• 32 или 64 мегабайта NOR-памяти по технологии Intel StrataFlash, плюс 32 или 64 мегабайта SDRAM-оперативной памяти прямо на борту процессора! Да, бутербродные процессоры придумали задолго до Qualcomm, только раньше в них ещё и Flash устанавливали :)

• Контроллеры USB (включая хост), AC97, I2S, I2C, SPI, UART, SD/MMC, ШИМ и GPIO.

• Контроллер дисплея. С ним связана отдельная особенность в E398.

• И всё это построено по техпроцессу ~130нм!

Если вы читали статью о E398, то могли узнать, что телефоны на платформе Neptune LTE использовали отдельный GPU ATi Imageon, поскольку процессор работающий на частоте 52МГц, не вывозил отрисовку графики своими силами. В этом прототипе необходимость в нём отпала, поскольку контроллер дисплея в XScale напрямую умеет работать с параллельными RGB-матрицами и способен быстро отрисовывать графику самостоятельно. Именно поэтому я сказал что дисплей в E398 носит явные коммуникаторные корни!

По итогу у EXL получилось хакнуть устройство, портировать на него и SDL и запустить Doom. Результатами он пока ещё не поделился... Но факт остаётся фактом, если E398 Linux Edition вышел бы в свет, он мог потенциально стать не менее популярным гиковским устройством. Но увы, в стенах R&D-лабораторий компаний погибает множество интересных и перспективных устройств, отправляясь в шреддер или по счастливой случайности попадающие в руки гиков.

Так и получилось с этим прототипом, который EXL'у подарил бывший сотрудник подрядчика Motorola в России - компании Telma в Нижнем Новгороде. Приятно знать, что немалую часть в разработку E398 вложили именно в России :)

А если вам интересна тематика ремонта, моддинга и программирования для гаджетов прошлых лет — подписывайтесь на мой Telegram-канал «Клуб фанатов балдежа», куда я выкладываю бэкстейджи статей, ссылки на новые статьи и видео, а также иногда выкладываю полезные посты и щитпостю. А ролики (не всегда дублирующие статьи) можно найти на моём YouTube канале.

Если вам понравилась статья и вы хотите меня поддержать, у меня есть Boosty, а также виджет на Пикабу ниже. А ещё мне можно отправить какое-нибудь интересное железо: устройства на WinCE/WinMobile, китайские кнопочники, китайские подделки на iPhone/Samsung из начала 2010-х, ретро-ПК железо - всё это я очень люблю :) Всем огромное спасибо!

Осторожно: данная статья - одна из моих лучших работ, посвященных истории моддинга мобильных телефонов. Если вам интересно узнать о том, как команда студентов хакала загрузчик E398, как инженеры Motorola разработали настоящее чудо и каким образом команда хакеров превращала простую "звонилку" в смартфон - приглашаю вас к прочтению!

Многие ли из вас помнят о легендарном музыкальном телефоне из далёкого 2004 года - Motorola E398? На момент выхода, модель буквально не имела аналогов на рынке и за относительно скромную цену в 150$ предлагала два огромных динамика, слот для MicroSD-карты, возможность проигрывания MP3-треков и даже неплохую поддержку 3D Java-игр. Однако Moto E398 гораздо интереснее, чем кажется на первый взгляд...

❯ Предисловие

Пожалуй давно у нас не было статей в рубрике «устройства, которые мы потеряли». В прошлом году, мы успели с вами посмотреть на самые разные гаджеты: Nokia 6600, Siemens C65, HTC Wallaby и этот список далеко не конечный. Мы узнали с вами о том, на каких аппаратных и программных платформах были построены эти устройства, на что они были способны на практике и даже хакнули один из телефонов, научив его запускать нативные программы с MicroSD-флэшки:

Однако изучая моддинг-сцену телефонов нулевых, мы незаслуженно с вами забывали о телефонах Motorola. И зря: «моторолки» были одними из самых интересных устройств с точки зрения кастомизации, а коммьюнити моддеров существует до сих пор, спустя более чем 20 лет после выхода самых популярных телефонов компании. MotoFan всё ещё жив, в нём каждый пень пишут более 500 сообщений и общается около 30 постоянных участников, а из недавних значительных достижений — порт Doom и эмулятора NES...

Но конечно такие возможности моддинга стали доступны отнюдь не сразу. Это результат тысяч часов реверс-инжиниринга и хакинга прошивок, сборки общей базы данных и паттернов по аппаратной и программной платформе телефонов Motorola, а также сотни замыканий тест-поинтов и уходов телефона в ресет из-за испорченной памяти... Но начнём, пожалуй, с предыстории.

❯ Появление платформы P2k

Практически всю свою долгую историю телефоны Motorola строились на базе чипсетов собственной разработки. В моделях 90-х годов использовались самые разные аппаратные и программные платформы, и уже тогда предпринимались первые попытки моддинга. Конечно сам моддинг был утилитарный и в основном заключался в удалении симлока, русификации, изменения графики — но факт остаётся фактом.

Развитию моддинга способствовало использование знакомой процессорной архитектуры m68k, которую разработала также Motorola. В те годы, процессоры этого семейства были очень популярными и использовались не только в телефонах, но и в КПК Palm, компьютерах Amiga и даже в Mac'ах. Конечно ARM уже существовал в те годы, и легендарное ядро ARM7TDMI-S понемногу лицензировалось чипмейкерами, но превосходство на рынке портативных гаджетов всё ещё оставалось за m68k и Hitachi SuperH.

В 1999 году, Motorola представила новую линейку CDMA-телефонов построенных на процессорах с новой архитектурой M-Core (в какой-то степени наследник m68k, разработанный для переносимых устройств). Архитектура отличалась от m68k тем, что была RISC (что кратно снижало комплексность декодера инструкций) и имела фиксированный размер инструкции — 2 байта, что позволяло заметно экономить флэш-память. Но самое интересное было то, что для этих телефонов Motorola разработала новую программную платформу, имя которой было P2k (Platform 2000)!

В 2001 году, Motorola продолжает выпускать телефоны с m68k и M-Core «под капотом», однако к ним добавляются модели Timeport, которые использовали чипсеты разработки Texas Instruments под названием Whitecap и построенные на совершенно другой оболочке — EMMI/Legacy. По сути, это был предшественник мегапопулярного TI Calypso, который использовался с 2003 по, как минимум, 2010 год! В свою очередь, платформа P2k всё так же продолжала развиваться и использоваться в новых моделях, а к CDMA-устройствам также добавилась первая GSM-модель под названием V60.

И вот, в 2002 году, Motorola наконец-то представляет новую платформу — Neptune LCA (Low Cost Advance), построенную на базе ARM ядра. Первым телефоном с этим чипсетом стал бюджетный Motorola C330, который получил умеренный успех, но настоящим бестселлером стала последующая модель, которая получила имя C350! Телефон был невероятным прорывом для 2003 года в сегменте ультрабюджетных устройств: за 60$ (или 4.444 рубля), C350 предлагал цветной дисплей с 12-битным цветом (как у Symbian смартфонов тех лет!), поддержку GPRS с WAP-браузером, некоторый объём встроенной памяти для хранения анимации, картинок и полифонии, и даже 2.5D игру MotoGP. Такие крутые программные фичи появились благодаря новой версии MMI, которая всё также берёт корни от той самой P2k из 1999 года...

Что такое MMI?

MMI в кнопочных телефонах — это оболочка, которую видит пользователь, или если говорить простыми словами — «операционная система». В основе MMI лежит фреймворк для построения пользовательского интерфейса и разработки приложений, менеджер окон, рендерер шрифтов и изображений, декодеры аудио/видео, иногда аудио-микшер и абстракция над API конкретной операционной системы. У Motorola такая абстракция называлась suapi.

Сам MMI разрабатывается отдельно от телефона и отлаживается в специальном симуляторе на ПК. Например для Symbian — это вариация ядра EKA под Windows (не смейтесь, так и было!), для Siemens — билд оболочки под Windows (её также распространяли в SDK для J2ME), а для Motorola — полный эмулятор Neptune LTE, включая ARM-процессор. Такие вот инженеры Motorola молодцы :)

Из серьёзных конкурентов у C350 был разве что Samsung C100, но даже он стоил значительно дороже. Однако время шло, и уже в конце 2003 года, Motorola продолжила развитие ARM-платформы Neptune, представив следующее поколение — Neptune LTE (Low Tier EDGE), которое отличалось поддержкой стандарта связи EDGE. Первым устройством на LTE стала раскладушка V600 — продолжение той самой V60, в которую инженеры Motorola установили аж 5 мегабайт встроенной памяти и, только вдумайтесь, добавили поддержку воспроизведения MP3 с битрейтом в 320кбит/с!

Однако у V600 не было слота под SD-карту, так что наличие поддержки MP3 было не особо оправданно. Но уже в 2004 году, Motorola представляет телефон, который просто перевернул мобильный рынок в бюджетном сегменте. И как вы уже поняли, речь идёт о E398! Устройство, построенное на чипсете Neptune LTE, позиционировалось как специально предназначенное для прослушивания музыки и просмотра роликов. Помимо слота под MicroSD-карты и поддержки MP3, Motorola оснастила E398 двумя огромными стереодинамиками, поддержкой воспроизведения 3GP и MP4-роликов, а также довольно шустрой Java-машиной JBlend с поддержкой MIDP 2.0. Интересно было и то, что E398 стал одним из пионеров трёхмерной графики на кнопочных телефонах благодаря поддержке программного растеризатора Mascot Capsule v2 (да, как у Sony Ericsson, но чуть постарше)...

❯ Первые шаги

Немудрено что у такой недорогой и при этом нафаршированной с точки зрения функционала модели появились свои фанаты, и как в случае с телефонами Siemens, среди них были молодые студенты-гики, которые постигали искусство реверс-инжиниринга и моддинга... Но вот незадача: в отличии от тех же самых Samsung и LG, у Motorola с Siemens загрузчики были заблокированы с завода. У Siemens'ов задача разблокировки решалась генерацией специального ключа BootKEY на основе двух других значений, уникальных для каждого процессора Infineon S-Gold: ESN и Hash:

У «моторов» же вообще была неприступная стена без возможности пользовательской разблокировки, и BootROM с вторичным загрузчиком имели сразу несколько степеней защиты с проверкой RSA-подписи выполняемого кода. Но был очень важный нюанс: загрузчик нельзя было разблокировать никаким способом, а инженерность (и возможность запуска неподписанного кода) каждого процессора определялась всего лишь одним фьюзом, который прожигался на заводе при производстве чипа!

И вот всего один бит, один прожженный фьюз отделял целое коммьюнити от возможности модифицировать свои телефоны... Но затем один 24х-летний парень под никнеймом @Vilko с другими ребятами умудрился отреверсить загрузчик и обнаружить, что он:

• Не проверял подпись, если прошивка зеркалировалась выше первых 16МБ Flash-памяти (работало только на моделях с 16МБ — как, например, C350). Можно было пропатчить заголовки в CG1 и просто указать базовый адрес XIP контроллера + 0xFFFFFF.

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

• В вспомогательном RAM-загрузчике, который загружается через USB, была уязвимость переполнения стека, благодаря которой можно было изменить адрес возврата и заставить загрузчик прыгнуть на произвольный код. С помощью этой уязвимости можно было понизить версию загрузчика на более старую, которая обходится одним из методов выше.

И уже в 2004 году, Vilko с командой Motofan успешно хакнули загрузчики первых версий на E398. А что началось после этого... сложно описать в рамках одной статьи! Патчили конфигурацию усиления динамиков (делая их ещё громче!), драйвер камеры, меняли графику и даже писали патчи, которые так или иначе изменяли поведение телефона. Прошивку активно реверсили в IDA Pro, изучали её архитектуру, находили сигнатуры функций и по паттернам выискивали их в других телефонах на той же платформе...

В 2005 году, как бы это не звучало парадоксально, Motorola выпустила первый «Apple-телефон» — ROKR E1. По сути, это был тот-же самый E398, однако в него добавили дополнительную кнопку для запуска проигрывателя, модную белую тему и плеер iTunes, знакомый нам по продукции Apple. При этом сам iTunes был реализован в виде Java-приложения — corelet'а и тем самым привлек внимание владельцев обычных E398'ых. Гений в лице @Vilko в одиночку умудрился пропатчить прошивку от E1 и запустить её на E398...

Но всё равно сообществу Motofan было мало существующего функционала и они начали думать: как бы превратить E398 в полноценный смартфон и добавить возможность запуска нативных программ, написанных на C? Поскольку функции UI-фреймворка P2k ещё были недостаточно изучены, подступиться решили к Java-машине: примерно в 2005-2006 году, предположительно с R&D подразделения Motorola в России, утекли Elf-бинарники прошивки со всей информацией о символах: имена и адреса функций, глобальных переменных, информация о секциях прошивки и другие полезные данные. Там же были найдены реализации абстракции над графической подсистемой в JBlend (Aplix JBlend использовалась во многих мобильных телефонах нулевых и отличалась относительной простотой портирования благодаря абстрагированию вообще всего что можно), а также нативные реализации методов из CLDC и MIDP.

Стоп... R&D Motorola в России?

Да! Когда-то части прошивки P2k разрабатывались в офисах в Санкт Петербурге и Владивостоке. В Питере команда занималась портированием JBlend для P2k, дабы в C380 и E398 появилась поддержка Java-приложений, а вот чем занимался офис в Владивостоке мне неизвестно. Так что первая тайна E398 заключается в том, что к её созданию приложили руки в России :)

В российских R&D явно работали ребята, которые поддерживали не только бизнес-процессы транснациональной корпорации, но и идеи сплоченного коммьюнити моддеров, так что через некоторое время после закрытия отделов, в сети оказались те самые сливы Elf'ов прошивки, а чуть позже — исходный код порта JBlend для P2k. Спасибо вам ребята, которые решили поделится этим добром, именно благодаря вам спустя 22 года моддинг-сцена Motorola продолжает развиваться на полную катушку!

К слову, разработку прошивки в РФ аутсорсила не только Motorola. У нас точно был R&D-центр LG: ко мне в комментарии пару лет назад приходил инженер-хабровчанин, который рассказывал о том, как они писали программную реализацию OpenGL ES 1.0 для телефонов на чипсетах Qualcomm для западного рынка. Есть также догадки о том, что какую-то часть разработки могла аутсорсить Nokia (или её подрядчик), но железных доказательств у меня нет :(

Некий моддер из Польши под ником elektro255 додумался, что можно пропатчить одну из функций JVM так, чтобы она при вызове с определенными аргументами загружала нативную программу по заранее определенному адресу и передавала ей управление. Это был первый простейший бинлоадер, который позволял писать несложные программы по типу игр и разных демок — но это был большой задел на будущее...

В 2007 году, в моддинг-сцене Motorola случается огромный прорыв: появляется самый первый эльфлоадер, библиотека функций и EP1 (ElfPack 1). Благодаря сливу дебаг-информации, моддеры разобрались в сложной оконной системе UIS (UI-фреймворк P2k, сложность заключается в огромном количестве стейт-машин) и научились писать полноценные программы, которые работали как нативные приложения, собранные вместе с прошивкой! Помимо этого, были найдены функции для управления потоками и щедуллером RTOS, благодаря чему появилась возможность реализовать полноценную многозадачность. Теперь эльфы могли делать полезную работу в фоне: например обновлять почту, сообщения в аське (почти пуши!) или заставить по рабочему столу бегать овечку :)

Ну а дальше процесс моддинга пошёл семимильными шагами: эльфпаки были портированы на Razr V3, V360 и другие популярные модели, а затем раскопали и модели на базе процессоров M-Core. Дело в том, что в Россию попадали исключительно «бюджетные» по видению Motorola модели на платформе Neptune LTE/LCA, в то время как на западном рынке использовались флагманские M-Core'ы. Энтузиасты получили в свои руки несколько таких телефонов, умудрились точно также их отреверсить, портировать ElfPack1 и получить почти идентичный функционал на куда более мощных телефонах с процессорами, построенных на проприетарной и почти неизвестной архитектуре... Вот это я называю высшим пилотажем!

Ну что-ж, вот такая длинная предыстория моддинга телефонов Motorola у нас с вами получилась. Но вы же не думаете, что у E398 больше не осталось тайн?!

Разбираем

Следующим делом мы разберем с вами E398 и узнаем что у него находится «под капотом». Для разборки я решил взять донорский телефон, который ко мне когда-то попал из утиля, а он в свою очередь туда попал после неудачной попытки ремонта.

Разбирается телефон очень легко: достаточно лишь открутить несколько винтов по периметру корпуса и расщелкнуть клипсы, после чего устройство разделяется на две половинки. В целом, ремонтопригодность E398 была на очень достойном уровне: заменить дисплей, динамики или клавиатуру можно было без особых навыков буквально за 5-10 минут работы. Единственное исключение — джойстик, но он на этой модели никогда не был проблемным. Также радует частичная унификация запчастей: например в E398 свободно устанавливался дисплей от E1 и L7.

Первым делом в глаза бросается блок из двух огромных динамиков. Они большие даже по нынешним меркам, а уж сам факт наличия стереозвука в внешних динамиках в 2004 году был нонсенсом даже для флагманов, не говоря уже о среднебюджетной модели. К сожалению, мне нечем замерить их уровень dB, но с патчами E398 был способен заменить среднестатистическую колонку или даже бумбокс, и при всём этом звучал качественно!

Чуть ниже, под защитным экраном скрывается сердце устройства — тот самый процессор Motorola Neptune LTE под маркировкой SC29332VG. И как бы это парадоксально не звучало для телефона с поддержкой MP3, по своим инженерным решениям он был ну очень своеобразным. Состоял он из:

• Основного вычислительного ядра ARM7TDMI-S, работающего на частоте 52МГц с возможностью разгона до ~64. Для 2003 года, сам факт использования ARM7TDMI родом из 1994'го в не самом бюджетном телефоне уже был некой диковинкой: более свежее ядро ARM9T с 1999 года активно вводилось в эксплуатацию и было производительнее в 2-2.5 раза с возможностью работы на частоте до ~416МГц. Однако за сам факт использования столь старого ядра Motorola корить не стоит: те же самые бюджетные чипсеты Sysol (Samsung), Analog (LG, Hyundai) использовали аналогичное ядро, просто телефоны на их базе метили в не столь функциональный сегмент.

• Вспомогательного DSP-ядра S-ONYXU 56600 собственной разработки Motorola, работающего на частоте 130МГц. В его задачи входит низкоуровневая работа с GSM-стеком, декодирование и кодирование голоса, а также декодирование MP3! При этом DSP способен легко обрабатывать треки с частотой дискретизации до 320кб/с. Именно поэтому на всех телефонах с процессорами Neptune LTE была поддержка MP3, в отличии от тех же самых Siemens'ов, где несмотря на мощный DSP, поддержку воспроизведения музыки реализовывали костылями (то через сторонний декодер, то программно, даже несмотря на заявленную поддержку MP3 в DSP S-Gold и даже E-Gold).

• 256 килобайт встроенной RAM и аж 1.79МБ ROM! Такой большой размер BootROM'а здесь неспроста: по заявлению @EXL, в нём хранится не только загрузчик, но и своя небольшая прошивка с самостоятельным GSM-стеком. Когда-то ходили слухи о закладках со стороны Motorola, но на практике скорее всего просто хотели выпускать ультрабюджетные телефоны вообще без флэш-памяти. У DSP есть своя дополнительная память — 381КБ ROM и 191КБ ОЗУ.

• Встроенный RF-фронтэнд как для RX, так и TX-части. В его задачи входит вся «магия» по превращению цифровых GSM-пакетов из DSP в аналоговый сигнал, который затем отправляется на усилитель (PA) и далее уходит в эфир. Однако в E398 всё равно используется внешний фронтэнд, разработанный самой Motorola

• Контроллеры SPI, 8080, а также USB. Из-за аппаратной поддержки USB, Neptune LTE буквально был одним из самых продвинутых мобильных чипсетов тех лет и Motorola активно продвигала использование обычного USB без UART-преобразователей. Интересно то, что контроллер RAM не поддерживал динамическую оперативную память вообще. То есть по сути, контроллера памяти и не было: из процессора напрямую выходила классическая 16-битная 8080-шина с парой чипселектов исключительно на статическую память без рефреша. Тут можно провести прямую параллель с FSMC в STM32.

• Встроенный референсный кварцевый резонатор, формирующий клок для набора из двух PLL (Phase Locked Loop), которые используются для тактирования и управления частотой работы различных подсистем чипсета. Например разгон мобильных процессоров — это чаще всего перезапись регистра управления PLL (если необходимо переключить на другой источник, зависит от процессора), настройка делителей, а также напряжения VCO. Вообще, мне всегда было интересно как чисто теоретически возможно встроить полноценный кварцевый резонатор прямо в кристалл, если у кого-то есть такая информация, прошу поделится в комментариях!

Такой высокий уровень интеграции для 2003 года был очень крутым. Единственное слабое место чипсета — понемногу устаревающее на момент релиза ядро ARM7TDMI, а учитывая комплексный UI-фреймворк и сложную модульную архитектуру системы в целом, 52-х мегагерцовый процессор буквально не справлялся с таким тяжелым интерфейсом, из-за чего телефоны заметно подтормаживали и плохо показывали себя в Java-играх. Это вторая тайна E398 :)

Чуть ниже процессора расположилась микросхема комбо-памяти производства Intel под маркировкой L18SCSP. На одной подложке скрывается 32МБ NOR-памяти StrataFlash и 8МБ PSRAM. NOR-память можно было напрямую подключить в адресную шину процессора и использовать XIP (eXecute In Place) для выполнения кода напрямую с чипа памяти без сложных кэшей и необходимости предварительной загрузки в RAM. PSRAM же внутри представляла из себя обычную DRAM, плюс Refresh-контроллер с обычной 8080-шиной наружу. Именно поэтому, такая память называется псевдостатической. К слову, такие чипы памяти прекрасно поддаётся апгрейду и расширению: можно просто поставить чип большего объёма и обращаться к новым верхним адресам (если линии под них, конечно, разведены).

Правее процессора расположился Bluetooth-модуль 95L14CN. Он в свою очередь требует отдельный 26МГц кварцевый резонатор для работы и несколько конденсаторов с резисторами, а к процессору он подключен по шине UART. Именно поэтому скорость работы была не слишком высокой (сейчас BT-модули чаще подключают через SDIO или USB). Правее расположился чип LP3933, который отвечает за Fun-lights (светодиоды, подмигивающие в ритм музыки) и подсветку дисплея. Так что если у вашего «мотора» не работает подсветка — смотрите в сторону этого драйвера... или переделывайте подсветку на LM-ку с Samsung C100 :)

С верхней части платы скрывается усилитель сигнала Skyworks SKY77501-14. Есть один важный момент: обычно усилители всегда подключаются напрямую к VBAT (питанию аккумулятора) без каких либо внешних DC-DC преобразователей и ключей, и иногда они могут выходить из строя, даже если телефон выключен. Так что если ваш «мотор» ни с того ни с сего перестал включаться — проверьте PA на нагрев и если нужно — замените. Чуть левее усилителя расположился RF-фронтэнд MC13777P в паре с ещё неким модулем, который в схеме помечен как фронтэнд. К сожалению о деталях реализации RF-части ничего подробнее рассказать не смогу :)

С обратной стороны платы нас поджидает ещё одна, уже третья тайна Motorola E398... и это — чип ATi Imageon 2250. Да, в телефоне за 6 тысяч рублей был установлен полноценный GPU. Однако несмотря на то, что в 2003 году, 3D-графика в телефонах и КПК только зарождалась, именно этот Imageon является 2D-ускорителем. В его задачи входит быстрая аппаратная отрисовка изображений (блиттинг), спрайтов, линий, прямоугольников и всё это с аппаратным альфа-блендингом и поддержкой различных растровых операций (умножение, суммирование, прозрачность через колоркей). Помимо этого, чип поддерживает работу с камерой, декодирование MJPEG и содержит в себе встроенную память для фреймбуфера. Дело в том, что чипсет Neptune LTE со своим ARM7TDMI ядром не был способен на быструю отрисовку графики исключительно силами процессора на телефонах с разрешением дисплея выше 128x128, поэтому инженерам пришлось прибегнуть к использованию стороннего GPU.

Чуть ниже ATi расположился контроллер питания, который также разработан Motorola. По плате видно что его грели в первую очередь — это часто делали некоторые олдовые ремонтники в нулевых годах (да и сейчас делают). На него даташита я не нашел, однако судя по схеме он отвечает за зарядку литиевых аккумуляторов, транзисторную защелку разрешения подачи питания, содержит в себе несколько LDO для формирования шин питания различных подсистем телефона, АЦП для микрофона, а также усилитель для динамика. И вот тут есть интересное инженерное решение: дело в том, что усилитель в КП только один и предназначен он для одного внешнего динамика. А поскольку в E398 их два, для второго используется дополнительный усилитель LM4879IBLX.

В качестве дисплея используется TFT-TN матрица неизвестного производителя (скорее всего Sharp) с разрешением 176x220, которая подключается к GPU с помощью параллельной 16-битной RGB-шины (GPU устанавливает пиксель, дергает CLK, когда одна строка изображения подготовлена — дергает HSYNC, затем когда кадр подготовлен — дергает VSYNC).

Вот такой был конструктив у Motorola E398! Причем эта же платформа использовалась без изменений и в других легендарных телефонах компании: например Razr V3 и V3i, V360, KRZR K1, SLVR L3, SLVR L6, SLVR L7...

❯ Прошиваем...

По правде сказать, я практически не встречал E398'ые без какого-либо моддинга. Может быть не у всех были монстрпаки (кастомные прошивки) с EP, но во многих были установлены различные твики и самый главный — усиление громкости динамика.

Перед прошивкой «мотора» необходимо сначала забэкапить раздел PDS (калибровки радиотракта) с помощью программы Flash & Backup, проверить версию загрузчика ( @EXL в комментариях напишет их отличия) и выбрать монстрпак на выбор. @EXL рекомендует прошивку DAR-Test как самую нафаршированную и собранную частично из хаков и частично из слитого исходного кода P2k. По сравнению с оригинальной прошивкой, кастом в себя включает:

• Поддержка 2ГБ MicroSD вместо стандартного ограничения в 1ГБ

• Поддержка Bluetooth в Java-приложениях

• Хак плеера для включения поддержки 320кбит/с в MP3-треках.

• ElfLoader с диспетчером задач и возможностью загрузки эльфов первой и второй версии. Именно этот патч превращает E398'ой в смартфон!

• Три альтернативных музыкальных плеера. Почему бы и нет? :)

• Возможность разгона процессора до 65МГц.

Далее необходимо прошить специальный файл — Flex. По сути, это файловая система с пользовательскими данными. Прошивка Mini Flex форматирует телефон до заводских настроек, дабы точно ничего не мешало прошить монстрпак. Теперь можно установить и саму прошивку. Скачать DAR можно с всё ещё живого мотофана по прямой ссылке. Файл с расширением fsw открываем в Flash & Backup, переводим телефон в бутлоадер, зажав * и # при включении и если у вас версия загрузчика — 07.D0, то можно спокойно прошивать телефон. Если отличается — напишите @EXL и не шейте вслепую, иначе возможно придется замыкать тест-поинт!

Если после прошивки телефон включается без проблем — поздравляю, вы только что превратили свой E398'ой почти в полноценный смартфон!

❯ Включаем...

После включения нас встречает такая ламповая, но по мнению некоторых «васянская» тема в стиле Windows 7. В те годы темы в стиле десктопных операционных систем были очень популярны: почти под каждую платформу обязательно были темы в стиле XP, Vista и 7'ки, а также Ubuntu и Debian :)

Как я уже говорил ранее, у телефонов Motorola была сложная UI-подсистема, которая называлась Synergy. Она практически вся построена на стейтмашинах и абстракциях, из-за чего слабенькому ARM7TDMI порой тяжело справляться с обработкой и отрисовкой интерфейса. Однако мощность Synergy позволяла реализовывать довольно сложные и комплексные интерфейсы, и главное меню — один из примеров. Его можно было кастомизировать до неузнаваемости: добавить эльфы, патчи, ярлыки к различным приложениям и многое другое.

Несмотря на довольно мощный родной плеер в E398, энтузиасты взяли и написали ещё несколько дополнительных. В прошивке DAR присутствует три кастомных плеера на любой вкус: с темами, специальными опциями и другими полезностями. Кроме того, благодаря патчу появлялась возможность воспроизведения MP3-треков с битрейтом аж в 320кбит/с. А уж как играл E398 с патчами... да, пожалуй до такого качества отнюдь не каждый современный смартфон дотягивает. Из тех, что были реально в разы лучше могу вспомнить только ZTE Axon 7:

Также теперь в E398 появился полноценный файловый менеджер с доступом ко всем «дискам» телефона. Через него мы можем не только на лету редактировать коэффициент усиления динамиков и делать всяческие твики, но и запускать те самые эльфы...

Какие возможности давали эльфы? Да практически любые! Сетевые сервисы, клиенты мессенеджеров и почты, игры и даже банальные утилиты — всё это писалось абсолютно бесплатно энтузиастами, которые хотели чуточку расширить функционал своего телефона. Один из эльфов, к примеру, позволял зажать обе софт-клавиши и озвучить время голосом!

Один из самых полезных эльфов позволяет разогнать или наоборот затормозить ядро ARM7TDMI. Конечно с частотами лучше не баловаться, иначе есть риск зависания, однако любые Neptune LTE спокойно гонятся на 12МГц, то есть потенциальный прирост производительности может составлять около 23%. И он действительно чувствуется!

А сейчас телефоны Motorola становятся ещё и объектом интереса среди демосценеров. Например EXL сюда портировал эмулятор Денди, Дум и 3D-движок с GBA, а также ковыряет перспективы использования GPU Imageon. И пусть далеко не все оценили пост с его стараниями по портированию разных демок на E398, мы то знаем что он делает крутые и интересные вещи. Настоящий балдежник!

❯ Заключение

Вот так и получилось, что целых 22 года назад, компания Motorola выпустила пожалуй одну из лучших своих моделей телефонов. И несмотря на все косяки и недостатки, E398 стал действительно народным аппаратом. Настолько народным, что нашлись энтузиасты, которые отреверсили прошивку и хакнули телефон настолько, чтобы превратить его почти в полноценный смартфон...

А что вы думаете о E398? Пишите своё мнение в комментариях!

А если вам интересна тематика ремонта, моддинга и программирования для гаджетов прошлых лет — подписывайтесь на мой Telegram-канал «Клуб фанатов балдежа», куда я выкладываю бэкстейджи статей, ссылки на новые статьи и видео, а также иногда выкладываю полезные посты и щитпостю. А ролики (не всегда дублирующие статьи) можно найти на моём YouTube канале.

Если вам понравилась статья и вы хотите меня поддержать, у меня есть Boosty, а также виджет на Пикабу ниже. А ещё мне можно отправить какое-нибудь интересное железо: устройства на WinCE/WinMobile, китайские кнопочники, китайские подделки на iPhone/Samsung из начала 2010-х, ретро-ПК железо - всё это я очень люблю :) Всем огромное спасибо!

Статья подготовлена при материальной и корректорской поддержке @Timeweb.Cloud. У TimeWeb Cloud есть блог компании на Пикабу, поэтому реклама совершенно легальная :)

Друзья! А вы помните, какими были мобильные игры в 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, дабы не пропускать новые статьи каждую неделю!