Именно Вы, читатели, помогаете с подготовкой новых статей - все деньги отправляются на покупку девайсов для будущих статей и оборудования! Спасибо всем, кто помогает - и морально, и материально!
Друзья! Заметил что за последние полгода, очень сильно просели показатели по чтению и лайкам на своих статьях. С учетом того, что я постоянный автор и материал выходит раз в неделю-две, интересно узнать, почему так происходит. Порой большие, подробные и иллюстрированные длиннопосты (или лонгриды - кому как удобнее) едва сотню лайков набирают, а "просто обзорные" статьи и под 1-2к плюсов набрать. Почему так по вашему мнению?
Дисклеймер: игра была написана как простенькая, но познавательная демка именно для PowerVR MBX и именно для Axim X51v. Именно поэтому здесь нет нормального Update-таймера, расчёта дельты времени, а игра прибита к константным временным отрезкам и величинам скорости!
Итак, как же игры подобного планы работают «под капотом»? По факту, обычно мы с вами никуда не едем: фоновые модели ландшафта и дороги просто скроллятся и телепортируются друг за другом, когда одна из частей уходят за экран, что создаёт эффект бесконечной дороги. И эта техника используется во многих играх! Что же касается машинок, от которых мы должны лавировать, то это не мы едем на них, это они едут на нас! По итогу создаётся эффект будто мы с вами куда-то едем и уворачиваемся от машинок, хотя на деле это не так!
Начинаем с реализации базовой вещи в архитектуре любой современной игры, а именно системы игровых объектов. В нашей игре нет необходимости в реализации сложного графа сцены с комплексной компонентной системой, или, например, ECS. Хватит классического линейного списка игровых объектов (который использовался, например, в Half-Life), по которому объект World проходится каждый кадр, вызывая необходимые функции для обновления состояния объекта и его отрисовки:
public abstractclass Entity { public Transform Transform;
foreach (Entity ent in entityRemovalList) Entities.Remove(ent);
entityRemovalList.Clear(); }
publicvoid Draw() { sky.Draw();
renderer.Draw();
foreach (Entity ent in Entities) ent.Draw(); }
Самым первым нашим объектом будет машинка игрока, которой можно будет управлять! Модельки я взял лоуполи со скетчфаба, вот ссылка на ВАЗ 21099 и VW Golf Mk2. Спасибо авторам моделей за их работу!
Наследуемся от Entity и реализуем абстрактные методы с логикой объекта. Здесь мы получаем состояние аппаратных кнопок влево и вправо, в зависимости от них вычисляем направление поворота машинки и, собственно, поворачиваем машинку путём сложения с координатой X вычисленного направления, помноженного на «скорость» поворота машинки. Для лучшего визуального эффекта, мы также плавно поворачиваем машинку эффектом а-ля EaseIn/EaseOut:
Теперь нам нужно, чтобы машинка где-то «ездила». Для этого мы моделируем в блендере примитивный кусок дороги с элементами ландшафта:
А затем реализуем примитивный рендерер фона, который будет скроллить два одинаковых seamless-куска уровня и как я уже говорил ранее, просто телепортировать их друг за другом, создавая эффект бесконечности.
public SectorRenderer() { road = Model.FromFile("road.mdl"); roadMaterial.Diffuse = Texture2D.FromFile("road.tex");
Где terrain.mdl — окружающий ландшафт, а road.mdl — собственно, сам меш дороги. Получаем вот такой эффект:
Артефакты на видео — следствие проблем с точностью float у MBX Lite в процессе клиппинга геометрии при ближней плоскости отсечения в 0.1f. Меняем на 1.0f и всё снова работает нормально :) Чуть изменяем проекцию, переместив камеру выше и наклонив на 45 градусов и игра уже похожа на Traffic Racer!
Переходим к реализации машин трафика. Модельки их машин будут загружаться при старте игры:
publicstaticvoid Preload() { PreloadedCars = new Model[1]; PreloadedMaterials = new Material[1];
LoadTrafficModel(0, "traffic1"); }
А сама их логика предельно проста. При спавне, машинка выбирает себе полосу, по которой будет ехать и рандомный множитель скорости, который вносит разнообразие в игру:
Переходим к обработке столкновений. Помним, что мы на этапе конвертации моделей посчитали Axis Aligned Bounding Box для каждой модели? В качестве алгоритма мы будем использовать классический AABB — или Rect vs rect:
public bool Intersects(BoundingBox box) { return (X < box.X + box.X2 && Y < box.Y + box.Y2 && Z < box.Z + box.Z2 && box.X < X + X2 && box.Y < Y + Y2 && box.Z < Z + Z2); }
Теперь для проверки столкновения между ними, нам надо посчитать абсолютный Bounding Box для каждого игрового объекта:
Затем итерируемся по списку всех игровых объектов в сцене, и если у нас есть машинка трафика, то проверяем на столкновение с машинкой игрока. Если столкнулись, то помечаем машинку игрока как разбитую и предлагаем игроку рестартнуть игру.
foreach (Entity ent in Game.Current.World.Entities) { if (ent is TrafficCar) { if (Player.Bounds.Intersects(((TrafficCar)ent).Bounds)) { // TODO: Damage logic Player.IsDestroyed = true; } } }
Уже что-то немного похожее на игру. Добавим конечное препятствие — необходимость рестарта при столкновении с другой машинкой и для демки пока-что хватит.
if (Game.Current.world.Player.IsDestroyed) { int measure = Engine.Current.Graphics.MeasureString(RestartString); Engine.Current.Graphics.DrawString("Press Return to restart", Engine.Current.Graphics.ViewWidth / 2 - (measure / 2), Engine.Current.Graphics.ViewHeight / 2, StatsColor); } }
Вот что у нас получилось:
Правда, что на МКАДе каждый вечер такое? Я просто не с МСК :)
❯ Заключение
Вот такой у нас получился материал про PowerVR MBX! С выходом iPhone, этот GPU дал толчок для появления красивых мобильных игр с уровнем графики, близким к полноценным домашним консолям… жаль, что золотая эра интересных, самодостаточных и бездонатных мобильных игр и закончилась во времена iPhone 5 :(
В остальном же, надеюсь материал был достаточно интересен и познавателен для всех моих читателей, даже тех, кто никогда не программировал игры! Был у вас Dell Axim X51v? Пишите в комментариях!
Исходный код демки и бинарники можно найти на моём гитхабе.
Материал написан при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud , чтобы не пропускать новые статьи каждую неделю! А ещё у меня есть своя телега, куда я публикую бэкстейдж статей и вовремя публикую ссылки на новый материал!
Понравился материал?
А ещё я собираю деньги на проект с уже настоящим, физическим ТАЗом и его электронным дооснащением бортовым компьютером "по самому дешману" своими руками! Уже собрано 50.000 рублей из планируемых 70.000 на машину, из них 45.000 моих личных сбережений и 5.000 рублей - помощь читателей, за что вам большое спасибо :)
Пожалуй, многие из вас помнят, какими были мобильные игры до и после выхода первого iPhone. В начале 2000-х годов, ещё до появления яблочного смартфона, игры для телефонов в основном были весьма интересными, но тем не менее, достаточно простенькими с точки зрения графики и реализации в целом. После запуска AppStore в 2008 году, на iPhone начали выходить самые разные красочные, невиданные раннее по уровню детализации и проработке 2D и 3D игры. Но появление таких игр — отнюдь не заслуга Apple, а относительной малоизвестной компании PowerVR (подразделение Imagination Tech), которая смогла разработать на базе видеочипа Dreamcast и внедрить один из первых действительно массовых мобильных 3D-ускорителей, имя которому — PowerVR MBX! Сейчас мы с вами привыкли, что почти любой дешевый смартфон может отрисовывать графику уровня PS3 в 1080p, а то и выше, но когда-то даже уровень PS2 был роскошью… Сегодня мы с вами: узнаем предысторию появления аппаратно-ускоренной 3D-графики на телефонах, рассмотрим такую фирменную фишку PowerVR, как тайловый рендеринг, а в практической части статьи нам поможет легендарный КПК Dell Axim X51v с MBX на борту, под который мы напишем 3D-игру «про жигули» с нуля! Интересно? Тогда добро пожаловать под кат!
❯ Мобильная 3D-графика. Начало
Пожалуй, 3D-графика на мобильных устройствах начала развиваться ещё с самого начала 2000-х годов. К тому моменту, как мобильные телефоны научились запускать сторонние Java-приложения, практически сразу же появился прибыльный рынок мобильных игр. Ещё до появления поддержки jar-приложений, люди ставили рекорды в «Змейке» на телефонах Nokia, таскали ящики в «Строителе» на Siemens и играли в другие предустановленные игры на девайсах других брендов, поэтому было очевидно, что игры на мобильных телефонах рано или поздно смогут занять немалую часть сегмента портативных игровых устройств.
Именно появление J2ME дало тот самый толчок для развития мобильного гейминга. Производители телефонов активно развивали и дорабатывали мобильную платформу, добавляя в неё различные API-расширения — например, активацию приложений через СМС и доступ в WAP-интернет. Сама платформа J2ME была достаточно простой для изучения и имела низкий порог вхождения не только для людей, имевших какой-то опыт программирования, но даже для совсем новичков, которые никогда не писали код и тем более игр! Благодаря этому, появились сотни игр, многие из которых до сих пор помнят и любят: это и легендарный «мячик» Bounce, и «зайчик с морковками» Bobby Carrot, и весьма крутой Gish, а также множество различных платформеров по известным фильмам и «большим» играм!
В 2003 году появился Nokia N-Gage — первый массовый телефон, ориентированный именно на мобильный гейминг, который поддерживал не только Java-игры, но и собственные Symbian-игры с достаточно крутой 3D-графикой! Примерно в том же 2003 году, для платформы Java вышло сразу два API-расширения, которые добавляли поддержку симпатичной 3D-графики даже в самые простенькие и бюджетные телефоны: Mobile 3D Graphics (M3G, была почти везде) и Mascot Capsule (эта платформа была только на Sony Ericsson и Motorola). Именно благодаря этим API, мы с вами увидели такие легендарные игры, как V-Rally, Galaxy on Fire, Deep3D и многие другие! Но тем не менее, эти API были относительно медленными из-за программной растеризации на процессоре без отдельного 3D-ускорителя и весьма ограниченными в функционале. Ближайший пример по функционалу — уровень софтрендера первой кваки на первом Pentium! Кстати, про 3D на мобильных телефонах я писал отдельную статью, там в практической части мы пишем 3D-бродилку для Sony Ericsson!
Но помимо кнопочных телефонов, существовал сегмент High-end мультимедийных устройств, которые предоставляли гораздо больший функционал и производительность за немалые деньги. И речь, конечно же, о КПК! Девайсы, работавшие на базе шустрых процессоров Intel PXA и Samsung S3C с Windows Mobile на борту были заметно более перспективными для игр… но как-то не задалось из-за отсутствия нормальных каналов для распространения. Но тем не менее, Intel (иронично, но один из самых больших производителей ARM-чипсетов для КПК в те годы), которая уже занималась развитием десктопной графики GMA и PowerVR активно работали в этой сфере и результатом стало появление видеоускорителя 2700G, который представлял из себя не только 3D GPU PowerVR MBX Lite, но и аппаратный декодер видео, позволявший смотреть видео в высоком качестве! MBX Lite позволял запустить даже Quake 3 в 640x480 (!), пусть и в 10-15 FPS… Ещё за 5 лет до этого, далеко не все десктопные видеокарты могли выдать больше 30 FPS в 800x600!
Конечно в 2004 году уже вышел PSP, выставивший новую планку уровня 3D-графики для портативного гейминга, однако для смартфонов и КПК, уровень графики, разрешение и производительность 3D-игр на MBX Lite был просто немыслимым! Одним из самых легендарных и популярных устройств с 2700G, которое вы можете приобрести достаточно дешево и сейчас, был КПК Dell Axim X51v, флагманская модель с VGA-дисплеем тех лет. Но нельзя сказать, что только PowerVR работала в этом направлении. Параллельно NVidia выпустили GoForce, крайне редко попадающийся в «полноценном» виде (NVidia предлагала дешевле лицензировать только видео-декодер с отключением 3D-части, как это было в Toshiba Portege G900) и ATI Imageon, который чаще всего можно встретить в виде Adreno на ранних Android-чипсетах Qualcomm (Adreno — анаграмма Radeon :)).
Тем не менее, решение PowerVR было действительно массовым: компания не предлагала отдельный чип (что обычно было дороже), как конкуренты, а лицензировала другим компаниям уже готовые IP-ядра, которые производители чипов могли синтезировать и использовать в своих собственных чипсетах, или, сопроцессорах, как в случае с 2700G. Благодаря этому, MBX появился в чипсете TI OMAP 2430, использовавшийся в легендарных Nokia N93i и Nokia N95, Samsung INNOV8, Asus Lamborghini, Nokia E90 и некоторых других. Кроме того, PowerVR MBX использовался в процессоре Samsung S5L8900, судя по всему, разработанный для iPhone 2G и 3G! Благодаря этому, его можно считать одним из первых массовых 3D GPU в телефонах!
Одна из игр для iPhone 2G и N95 — Assasins Creed
И Asphalt 5!
Весьма симпатично, согласитесь?
❯ Под капотом
Но MBX, конечно же, не появился «из ниоткуда» и был основан на более ранних разработках компании Imagination Tech, а именно GPU из полноценной домашней консоли SEGA Dreamcast — PowerVR CLX2, который в свою очередь был основан на ранних десктопных GPU PowerVR из середины-конца 90-х годов. Основная фишка PowerVR была в использовании так называемой техники отложного тайлового рендеринга (TBDR), которая, в отличии от классической растеризации и сортировки с помощью Z-буфера (или ручной сортировки треугольников) всех примитивов «в лоб» (методика, используемая в PSP, PS2 и большинстве видеокарт 2000-х годов), сначала ждёт от программы списка всех рисуемых треугольников в кадре, разбивает весь экран на тайлы (небольшие прямоугольные области), которые содержат в себе информацию о пересекающихся треугольниках, а затем процессом, несколько схожим с рейтрейсингом, определяет, какой из пикселей треугольника ближе всего находится к камере наблюдателя. Таким образом, мы избавляемся от необходимости сортировки геометрии с помощью Z-буфера (который сам по себе занимает достаточно много, по меркам тех лет, памяти и страдает от проблем точности и Z-fighting'а), а также такой метод позволяет реализовать более дешевый альфа-блендинг без ручной сортировки полупрозрачных примитивов и имеет ещё одну приятную фишку — «бесплатный» Occlusion Query, который можно использовать для реализации продвинутых техник отсечения невидимой глазу геометрии.
Производительность PowerVR MBX была весьма достойной для своих лет: при частоте работы в 200МГц, видеочип обеспечивал филлрейт в 100Мп, обрабатывал до 1млн треугольников в секунду. Нативным графическим API MBX был OpenGL ES 1.1 — специальная урезанная версия OpenGL для встраиваемых устройств, из которой выбросили все ненужное и которая заточена не только под floating-point, но и под fixed-point арифметику. В остальном, особо никаких отличий для программиста по сравнению с обычными GPU не было, можно было без проблем портировать уже существующие приложения для десктопого OpenGL для мобильные девайсы, чем и пользовались энтузиасты при портировании Quake 3 на Nokia E90, КПК и другие девайсы. Также, PowerVR MBX поддерживал D3DM — графический API Windows Mobile, о котором мы поговорим позднее.
Однако PowerVR MBX был GPU с фиксированным конвейером (FFP), а не программируемым, как принято в современных 3D-ускорителях. Что-же такое программируемый и фиксированный конвейер? Давайте разберемся:
Фиксированный конвейер: для того, чтобы задать визуальную составляющую рисуемой геометрии, программист оперирует набором заранее определенных при проектировании видеочипа параметров, которые позволяют управлять внешним видом растеризуемых примитивов. Например, для реализации света, программист задает параметры каждого из 8 источников света влияющих на рисуемый объект. Если программисту необходимо наложить несколько текстур за один проход (например, для реализации плавных переходов текстур на ландшафте или нанесения карты отражений на модель), он оперировал комбайнерами, которые позволяли задавать для каждого сэмплера параметры наложения. Такой подход использовался на десктопных GPU эпохи до GeForce 3 (т. е. примерно до 2000 года), до PS3 на Sony PlayStation (Xbox сразу вышел с GeForce 3) и до PSP включительно на портативках. Очевидно, что такой подход сильно ограничивает программиста в том, как будет выглядеть его игра на той или иной видеокарте.
Программируемый конвейер: в программируемом подходе, для управления визуальной составляющей программист пишет небольшие программы для видеокарты, называемые шейдерами. Всего есть два базовых (в современных GPU их больше) этапа программируемого конвейера: первый из них — вершинный шейдер, отвечающий за трансформацию геометрии (перевод из мировой системы координат в экранную) и, например, анимацию. Трансформированные вершины отправляются в следующий этап конвейера — растеризацию, где выполняется уже пиксельный шейдер, который определяет цвет пикселя (или более корректно — фрагмента в терминологии 3D графики) — т.е например, окрас объекта в определенной цвет, текстуру (или несколько текстур), рассчитывает попиксельное освещение, накладывает тени и т. д. Кроме того, такой подход позволяет реализовать сложные техники типа Ambient Occlusion, SSR, а также пост-эффекты (например блюр/блум, правда эти два можно «сэмулировать» и на FFP при определенной сноровке).
К 2007 году, Khronos выпустили спецификацию второй версии OpenGL ES, которая добавляла в мобильные устройства поддержку программируемого конвейера и шейдеров. Таким образом, мобильные GPU всё ближе приближались к уровню консолей и могли выдавать вполне годную графику, близкую к консолям. Даже была когда-то такая консоль, как Zeebo, которая работала на базе смартфонного чипсета Qualcomm с графикой ATI Imageon (!). PowerVR уже в 2009 выпустила серию SGX, которая также использовалась в iPhone, iPad, многих Android-смартфонах и планшетах, а также PS Vita!
Modern Combat 3 на iPad
Но статья с пересказом фишек PowerVR MBX была бы не особо интересной без практической части с написанием 3D-игры под этот GPU с нуля! Поэтому предлагаю посмотреть на нашего сегодняшнего гостя, легендарный флагманский КПК Dell Axim X51v из далекого 2005 года! Для тех лет, это настоящий «жир»:
Его мне подарил мой читатель Сергей с Хабра, за что ему огромное спасибо! Девайс был в полной комплектации, даже с флэшкой и усиленной АКБ, которая до сих пор неплохо держит заряд, однако у него не работал тачскрин. Если вам интересен только процесс программирования игры, а не аппаратного ремонта, то листайте ниже сразу до следующего абзаца :)
❯ Практическая часть: ремонтируем КПК
По факту, девайс полностью работал, однако в некоторые моменты времени не откликался на кнопки и тачскрин, и по всем симптомам это напоминало дребезг кнопок. При этом тачскрин сам по себе реагировал нормально во всех местах, что, фактически, исключало вероятность его поломки (хотя резистивные тач-панели сами по себе не особо надежные, в отличии от емкостных тачскринов). Дело было вот в чём: во многих КПК тех лет был отдельный аппаратный переключатель блокировки клавиатуры и тачскрина, который можно было использовать при просмотре фильмов. Однако на моем девайсе он был слишком разболтанным…
Разбирается КПК несложно: выкручиваем 4 винта и снимаем переднюю часть корпуса. На всякий случай я прочистил грязь между тачем и верхней частью корпуса — она тоже бывает влияет на ложные нажатия и чувствительность тачскрина:
А вот и виновник наших проблем: рычажок переключателя был отломан, но все еще находится в положении «разблокирован». Даже если в выжать в упор — он все равно не работал. Ну что ж, фен в руки, сдуваем переключатель и ставим вот такую перемычку (на фото флюс ещё не отмыт):
Включаем девайс и смотрим — теперь всё работает! Вот такой простой и быстрый ремонт Axim'а. КПК мне сразу очень понравился, я и ранее знал о его легендарности, но теперь узнал и о том, что он очень круто спроектирован и собран! Кстати, есть смысл сразу сдуть концевой выключатель, который прижимает задняя крышка и заменить на перемычку. GPU не очень хорошо работает на кастомных прошивок, на которую прошиты многие Axim X51v. Поэтому есть смысл прошить сток: качаем прошивку (Файл отката), закидываем на SD-карту и ребутим девайс нажатием клавиш Wi-Fi + включение + Reset. После этого, девайс пойдет прошиваться.
Теперь девайс чистый, как с завода! Можно приступить к написанию небольшой демки-игрушки, которая сможет продемонстрировать нам перспективы нашего КПК в 3D!
❯ Практическая часть: подготовка
Изначально, в практической части статьи должна была участвовать не менее легендарная Nokia N95. Однако вот незадача: несмотря на то, что под Symbian сохранился SDK (который работает нормально только под Windows XP), на устройствах с системой старше 9.x необходимо взламывать installserver, дабы иметь возможность ставить хоумбрю программы (к которым относится и наша игра) и отладчик TRK.
И хотя свой девайс я пропатчил, дебаггер нормально поднять мне так и не удалось. Я смог проинициализировать контекст GLES, запилить примитивный рендерер с загрузкой ассетов из памяти устройства но потом решил перевести проект на WinMobile… Проблем с разработкой под Symbian много: если приложение крашится — то оно просто закрывается, без сообщений и логов. Добавьте к этому то, что в Symbian вообще нет исключений и не всегда можно записать ошибки в лог и отладка превращается в ужас. Ситуацию исправляет Qt, который работает на N95, но в котором нет поддержки GLES (по крайней мере, в виде обычного QOpenGL, хотя возможность юзать API системы из Qt есть и дебаггер там работает нормально, так что не всё потеряно). Если вы когда-то что-то пилили под Symbian, особенно в Carbide — пишите свой опыт в комментариях, интересно почитать :)
WinMobile не менее интересен тем, что в нём поддерживается сразу два графических API: классический OpenGLES в профиле Common Lite (только fixed-point арифметика) и мобильная версия Direct3D — D3DM.dll, которая предоставляет API очень похожее на DX9, но без поддержки шейдеров. Что не менее приятно — есть официальные биндинги от Microsoft к D3DM в .NET Compact Framework, что позволяет легко писать 3D-игры под WM на C#/VB.NET. Поскольку WinMobile — достаточно открытая для пользователя система, хватит лишь накатить VS2005/2008 на машину с WinXP/WinVista/Win7/Win8 и сразу начать разрабатывать под неё приложения, никаких проблем с отладкой и запуском приложений тут нет. На Win10/Win11 совместимость с WM5 поломали :(
Создаём приложение для смарт-устройств, выбираем в качестве целевой платформы WM5-устройство (эмулятор будет слишком медленным для наших целей, он даже для 2D-игр не подойдет) и, наконец-то, приступаем к написанию игры!
Что же за игра у нас будет? Я решил сделать эдакое 3D-переосмысление популярного в прошлом бесконечного раннера из «тетриса», где мы едем на машинке F1 и обгоняем другие машины, стараясь в них не врезаться. Основной целью является набрать как можно больше очков. Подобные игры достаточно популярны на мобильных девайсах и сейчас: вспомнить хотя-бы Highway Traffic, однако мой вариант будет весьма колоритным: ведь в моей демке мы будем кататься на ТАЗе 21099 и уворачиваться от гнилых «вторых гольфов». Ну а почему бы и нет, я просто очень люблю старые гнилые жигули и это не первый мой проект про машины этого производителя :)
❯ Практическая часть: «движок»
Как и у настоящей машины, у каждой игры должен быть собственный движок! Однако в случае конкретно нашей игры, это скорее небольшой фреймворк, который предоставляет ровно тот функционал, который нужен игре без каких либо излишеств. Необходимо изначально распланировать требования для будущего фреймворка, дабы написание игры не скатилось в процесс, известный в узких кругах как «движкописание» :)
Рендерер: с графической точки зрения, фреймворк должен реализовывать весьма небольшой функционал. Загружать геометрию и текстуры из файлов в специально-подготовленном формате, реализовывать концепцию камеры, отрисовывать статическую геометрию, а также спрайты и текст, реализовывать примитивную систему материалов, которая позволяет наносить на геометрию текстуры, красить их в определенный цвет и управлять повершинным освещением, а также наносить на геометрию отражения с помощью специально подготовленных enviornment-текстур. Кроме того, рендерер должен уметь рисовать симпатичное анимированное небо в виде полусферы.
Звук: воспроизведение wav-звуков и музыки из файлов. Да и всё пожалуй — что ещё нужно от звуковой подсистемы? :) Стерео ведь нет, поэтому и 3D-звук не нужен.
Ввод: обработка нажатий на тачскрин и аппаратные кнопки устройства, маппинг кейкодов в виртуальный «геймпад». GUI-подсистему тоже частично можно отнести именно сюда!
Физика: AABB и Sphere vs Sphere столкновения. Никакого полноценного солвера тут и не нужно :)
Начинаем, пожалуй, с реализации рендерера. Сначала нам необходимо создать окно и контекст D3DM. Процесс практически идентичен D3D8 и D3D9: передаём информацию о нужном адаптере (видеочипе) и заполняем структуру PresentationParameters, однако есть важные нюансы: аппаратный FSAA лучше всего отключить (MultisampleQuality), а также передавайте точный размер окна, в которое собираетесь рендерить изображение, иначе система начнёт софтварно (!) скейлить рендертаргет до размера окна каждый кадр, что, как сами понимаете, крайне медленно.
Из форматов Depth-Stencil форматов поддерживается D16, D24S8 и D32. Желательно использовать D16 (несмотря на тайловую архитектуру, насколько мне известно, в MBX все равно есть fallback до классического рендеринга при некоторых условиях). Практически на всех КПК и коммуникаторах использовался 16-битный цвет, т.е RGB565, но можно указать Unknown — тогда GAPI подцепит тот формат пикселя, что используется в остальной системе.
Переходим сразу же к рисованию геометрии! Для начала рендеринга, нам необходимо подготовить состояние контекста: посчитать и установить матрицы вида (т. е. камеры) и проекции для трансформации геометрии, задать рендерстейты (список состояний, например нужно ли рисовать модельку с освещением, или нет), очистить экран и Z-буфер и установить параметры фильтрации текстур. Перспективная коррекция текстур — достаточно тяжелая операция и использовать её стоит лишь при необходимости:
public void EndScene() { device.EndScene(); device.Present();
System.Threading.Thread.Sleep(16); }
Чтобы какую-то модельку нарисовать, нам нужно сначала её загрузить! Для возможности напрямую прочитать треугольники из файла и сразу записать их в вершинный буфер, я написал небольшой конвертер из формата SMD (GoldSrc) в собственный, очень простой и легковесный формат, который состоит из позиции вершины и её текстурных координат:
foreach (SmdTriangle triangle in mesh.Triangles) { for (int i = 0; i < 3; i++) { writer.Write(FloatToFixedPoint(triangle.Verts[i].Position.X)); writer.Write(FloatToFixedPoint(triangle.Verts[i].Position.Y)); writer.Write(FloatToFixedPoint(triangle.Verts[i].Position.Z));
Обратите внимание, PowerVR MBX оперирует fixed-point арифметикой! D3DM, конечно, может автоматически преобразовывать float-координаты вершин в числа с фиксированной точкой, вот только реализовано это криво и косо: драйвер будет конвертировать все вершины в fixed-point каждый вызов отрисовки, вместо того, чтобы один раз преобразовать их после Unlock'а вершинного буфера. Теперь представьте, насколько это тормозно для хоть сколь-либо комплексной модели :)
При этом загрузчик модели при таком подходе будет очень простым и будет работать шустро даже на таком слабеньком железе:
public Model(string debugName, Stream strm) { BinaryReader reader = new BinaryReader(strm);
int hdr = reader.ReadInt32(); int numVerts = reader.ReadInt32(); int vertSize = 20;
Переходим к текстурам. Грузить напрямую png/jpg на КПК слишком долго, поэтому их я тоже перегоняю в собственный примитивный формат, который состоит из описания ширины/высоты, а также формата текстуры и собственно, самих пикселей. На данный момент поддерживаются только RGB565 текстуры — с ними MBX работает лучше всего:
public sealedclass TextureConverter { publicconstint Header = 0x1234;
Загрузчик тоже получился примитивным и шустрым донельзя, пусть и без какой либо компрессии. PowerVR MBX поддерживает собственный формат компрессии — PVRTC:
BinaryReader reader = new BinaryReader(strm);
int hdr = reader.ReadInt32(); int fmt = reader.ReadInt32();
Handle = new Texture(Engine.Current.Graphics.device, Width, Height, 1, Usage.Lockable, Format.R5G6B5, Pool.VideoMemory);
int pitch; GraphicsStream gs = Handle.LockRectangle(0, LockFlags.None, out pitch); gs.Write(data, 0, data.Length); Handle.UnlockRectangle(0);
strm.Close();
Переходим, наконец, к фактическому рисованию модели! Для этого мы строим мировую матрицу для трансформации нашей модели, а также задаем вершинный буфер для, собственно, вершинного конвейера и посылаем видеочипу команду отрисовки. ZBufferWriteEnable нужен для отрисовки геометрии без записи в Z-буфер, что можно использовать, например, для реализации скайбоксов:
public void DrawModel(Model model, Transform transform, Material material) { Matrix matrix = Matrix.RotationY(transform.Rotation.Y * MathUtils.DegToRad) * Matrix.Translation(transform.Position); device.SetTransform(TransformType.World, matrix);
void Start() { model = Model.FromFile("model.mdl");
mat = new Material(); mat.Diffuse = Texture2D.FromFile("test.tex"); }
void Update() { t = new Transform(); t.Position.Z = 150; t.Rotation.Y += 0.1f;
graphics.DrawModel(model, t, mat); }
Результат: у нас есть крутящийся кубик или любая другая произвольная 3D-модель!
Переходим к обработке ввода. Тут ничего сложного нет, ловим события KeyUp/KeyDown формы и назначаем виртуальным кнопкам их состояние.
public Input(Form parentForm) { keyState = newbool[(int)GamepadKey.Count];
parentForm.KeyPreview = true;
parentForm.KeyDown += new KeyEventHandler(OnKeyDown); parentForm.KeyUp += new KeyEventHandler(OnKeyUp); }
private GamepadKey ResolveKeyCode(Keys key) { GamepadKey k = GamepadKey.Count;
switch (key) { case Keys.Left: k = GamepadKey.Left; break; case Keys.Right: k = GamepadKey.Right; break; case Keys.Up: k = GamepadKey.Up; break; case Keys.Down: k = GamepadKey.Down; break; case Keys.Return: k = GamepadKey.OK; break; }
Теперь мы сможем управлять нашей машинкой в игре (которой пока ещё нет). Самая-самая основа для реализации игры подобного плана у нас есть, пора переходить к геймплею!
Вот я собираюсь брать ТАЗ для проекта и старта одной из будущих рубрик. Вариантов два: либо сейчас взять подгнившую девятку за 70 тыщ рублей (я на Кубани, тут они ещё +- живенькие), либо взять кредит на 110к и взять чет более-менее живое. Есесно сразу после проекта машину сливать я не собираюсь - хотелось бы поездить. Поскольку я молод и неопытен, можете проконсультировать насчет кредитов чутка? У меня не оч большой "белый" доход, мне 22 года и у меня неполное среднее.
Я так понимаю, с такими вводными мне хер че дадут? Планировал взять 110к + свои 60к и взять более-менее живой девятосик. Читатель говорит, что тебе необязательно могут дать 110к и начнут торговаться типа "а давай мы тебе 50 тыщ и не на 8 месяцев, а на 8 лет". И хотелось бы понять, один известный "кредитный маркетплейс" пишет мол цена кредита может достигать 40%. Это типа серьезно, берешь 110к и отдаешь 150?) А смысл тогда?
Пожалуй, немалая часть моих читателей так или иначе интересуется DIY-тематикой. И в различных самодельных девайсах порой есть необходимость вывести какую-либо информацию на дисплей, будь это текст, графики или даже какая-то анимация! Для разных задач существуют самые разные дисплеи и в сегодняшнем материале я хотел бы систематизировать и собрать подробнейший гайд об использовании дисплеев с нерабочих мобильных телефонов: какие бывают протоколы и шины данных, как читать схемы устройств и определять контроллеры дисплеев, какие дисплеи стандартизированы, а какие придётся реверсить самому и как быть с подсветкой. В практической части статьи мы подключим дисплей используя протокол MIPI DBI к RP2040 с использованием DMA. Интересно? Тогда добро пожаловать в статью!
❯ Виды дисплеев и их протоколы
Пожалуй, ЖК-дисплеи с самого момента их появления стали основным инструментом для вывода информации и взаимодействия с пользователями. Первые ЖК-панели были монохромными и требовали отдельный драйвер, который занимался выводом изображения на экран и формированием необходимых для его работы напряжений.
Сейчас же всё гораздо проще и каждый любитель DIY-электроники может и сам подключить дисплейчик к своему проекту и использовать в необходимых ему целях. Ведь не зря написаны десятки библиотек по типу AdaFruit LCD, которые упрощают задачу программисту и дают ему возможность оперировать готовыми и простыми операциями по типу «вывести линию» или «отрисовать изображение». Однако, готовые библиотеки — это, конечно, здорово, но они не всегда дают понимание о том, как работают такие дисплеи на программном и аппаратном уровне. И первая часть статьи как раз и будет посвящена этому.
Всего в мире дисплейных матриц существует несколько общепринятых аппаратных протоколов. Некоторые из них можно легко использовать в собственных проектов с микроконтроллерами, с другими придется повозиться:
Параллельная шина 8080 — одна из самых простых и понятных шин данных, как в теории, так и на практике. Суть её очень простая: на каждый бит отводится по одной сигнальной линии, плюс две дополнительные линии для сообщения статуса передачи: RD означает запрос чтения, а WR — запрос на запись. Большинство дисплеев использует девятый, неявный бит D/C, который сообщает контроллеру, задаём ли мы номер команды, или уже пишем аргументы для этой команды. Что самое приятное — шина по сути стандартизирована и во многих дисплеях команды на старт записи в видеопамять, а также получение ID-контроллера идентичны. Шина бывает 8-битной и 16-битной (её состояние задаётся битами IM0..IM2 и используется не только для подключения дисплеев, но и микросхем параллельной флэш-памяти, ОЗУ и т. д. Такие шины используются в дисплеях с разрешением до 480x320.
SPI — шина, которая наверняка знакома большинству моих читателей. Достаточно простая — у нас есть две сигнальные линии с входным (MISO) и выходным (MOSI) битом, плюс сигнал тактирования, который согласовывает передачу данных. Таким образом, шина получается полнодуплексной. Фактически, каждый байт передаётся по одному биту через одну сигнальную линию, что, по сравнению с 8080, заставляет повышать тактовую частоту контроллера SPI, но при этом занимает гораздо меньше пинов самого МК или процессора. В программном плане, большинство дисплеев представленных в различных интернет-магазинах полностью совместимы с дисплеями 8080, ведь SPI — просто один из режимов работы. Единственный нюанс — из SPI дисплея не всегда можно вычитать ID-контроллера и вообще что-либо читать из регистров дисплея.
I2C — относительно редко используемая шина для дисплеев из-за её невысокой производительности, однако, тем не менее, очень подходящая для МК (благодаря использованию только двух сигнальных линий — SDA для данных и SCL для тактирования. Даже чипселект здесь программный благодаря тому, что каждое устройство имеет собственный адрес!), однако её можно найти в дисплеях некоторых телефонов из самого начала 2000-х годов.
TTL/параллельный RGB — тут, в общем-то, меня упрекали пару раз из-за того, что я продолжаю называть её TTL, но так сложилось исторически — даже в даташитах эту шину называют именно так. С логической точки зрения она очень простая: у нас есть 16/24 сигнальные линии, где 5 (или 8) бит используются для красного и синего канала и 6 (или опять же 8) бит используются для зеленого цвета (т. е. в 16-битном цвете у нас RGB565, а в 24-битном — RGB888). К ним идут сигналы HSYNC для горизонтальной синхронизации и VSYNC для вертикальной. Вообще, необязательно использовать все сигнальные линии предоставляемые дисплеем — можно использовать, например, RGB332 и использовать всего 8 сигнальных линий. Однако для отображения картинки, необходимо строго соблюдать тайминги синхронизации, иначе дисплей будет просто показывать белый цвет. Помимо цифрового варианта, бывает также аналоговый, очень похожий на телевизионный RGB или VGA. Такие дисплеи обычно используются для матриц до 1024x768 включительно.
MIPI DSI — протокол, используемый для дисплеев высокого разрешения — от 480x800 и выше, его можно встретить в большинстве современных смартфонов и планшетов. Кроме того, такие дисплеи используют относительно мало пинов — по два на каждый канал LVDS (обычно в смартфоне около двух-четырех каналов) + две сигнальные линии на тактирование. Звучит всё хорошо? Как-бы не так: протокол дифференциальный и на каждый канал (т. е. логический бит) приходится по две сигнальные линии — одна с положительная, а вторая отрицательная. Затем одна вычитается из другой и получается окончательный сигнал, а сделано это для уменьшения помех от передачи данных по нескольким линиям с очень высокой тактовой частотой без увеличения битности шины.
LVDS/eDP — Протоколы, используемые в матрицах ноутбуков, телевизоров и иногда планшетов. На физическом уровне близки к DSI, на программном — если честно, не знаю, но наслышан о некой стандартизации и высоком уровне совместимости. Даже «неродные» ноутбучные матрицы вполне «заводятся», максимум после перепрошивки родной EEPROM, даже если дисплей другого разрешения!
В списке выше, мы рассмотрели несколько популярных аппаратных шин для дисплеев. В данной статье, мы разберемся в программных особенностях таких дисплеев и узнаем, где взять по дисплею одного из следующих типов: SPI, I2C, а также 8080.
❯ Виды дисплеев и их протоколы
Пожалуй, писать статью, где были бы только готовые примеры без объяснения принципов работы «под капотом» было бы плохим тоном. Поэтому предлагаю немного разобраться в системе команд для самых распространенных контроллеров дисплеев в наше время.
У рассматриваемых нами дисплеев есть собственная видеопамять, благодаря чему нет необходимости соблюдать тайминги, а также общий набор команд (или аппаратных регистров), которые мы можем записывать и тем самым менять поведение дисплея. Если мы просто подадим питание на дисплей и попытаемся что-то вывести — у нас ничего не выйдет, поскольку при каждом аппаратном RESET'е, состояние большинства регистров, кроме SleepOn и PowerOn не определено и может содержать в себе любой «мусор». Для корректной работы дисплея, нам необходимо послать определенный набор команд, называемый инициализацией, который установит настройки драйвера дисплея, такие как контраст, параметры цветности, направление развертки изображения из VRAM и т. д. Пожалуй, стоит сразу отметить, что некоторые люди называют регистры дисплея командами — это означает одно и тоже!
Пример инициализации. На самом деле, не все люди делают такую простыню из вывозов функций чтения/записи регистров дисплея, поскольку это кушает драгоценный ROM. На AVR, например, команды инициализации можно хранить в ROM и читать из PROGMEM.
Если дисплей инициализирован неправильно, то мы можем наблюдать некорректную развертку, артефакты на дисплее и полосы: если вы когда-нибудь прошивали смартфоны прошивками других ревизий, то могли замечать подобный эффект сами.
Набор команд для контроллеров дисплеев частично стандартизирован спецификацией MIPI DBI, которая описывает и закрепляет некоторые конкретные адреса регистров, общие для всех контроллеров дисплея. К ним относится, например, установка «окна» для записи (0x2B и 0x2A), sleepout (0x11) и некоторые другие. Проприетарными командами остаются настройки питания, развертки, контраста и самого драйвера дисплея. Ну и всяческие LUT, а также палитровые режимы (если они есть) тоже проприетарные.
Пример одной из таких стандартизированных команд:
Почти во всех дисплеях есть разделение отправляемых байтов на команду (или выборка номера регистра для чтения/записи) и на данные. Как обработать текущий байт определяет отдельный пин (или бит, в зависимости от конфигурации дисплея), называемый D/C (Data/Command), иногда также можно встретить названиеRS. Обычно, при записи команды, D/C должен быть на низком уровне, при записи данных, соответственно, на высоком. Суть простая: записываем номер команды (или регистра) при низком D/C, а затем дописываем необходимые аргументы (или конфигурацию регистра) при высоком уровне D/C. Примерно так:
Касательно сброса, то в дисплеях обычно существуют два вида этого процесса: аппаратный сброс через соответствующий пин и программный с помощью специальной команды. Пин RESET никогда нельзя оставлять в «воздухе» (т. е. не подключенным) в надежде что «да состояние пинов МК после ресета известно, мусора на шине явно не будет». Мусора может и не будет, а вот дисплей упадет в вечный ресет, поскольку ожидает перехода сигнала RESET в высокий уровень. Тоже самое касается и пина CS, отвечающий за выбор устройства на шине. Если вам не нужен CS и у вас висит только одно устройство на шине — просто притяните его к массе. Некоторые контроллеры (например, ILI9325) адекватно реагируют на CS «в воздухе», некоторые — нет. Только после того, как RESET оказался на высоком уровне, дисплей начнёт принимать команды:
Переходим конкретно в выводу данных. Для начала вывода изображения на дисплей, нам необходимо выполнить команду 0x2C, которая переведет контроллер дисплея в режим записи данных в видеопамять. После этого, нам остаётся лишь установить высокий уровень на пине D/C и просто слать непрерывный поток пикселей. Контроллер дисплея сам инкрементирует координаты на дисплее и после того, как координаты выйдут за границы нужной области, дисплей сам их переведет в изначальные. Таким образом, достаточно лишь один раз проинициализировать дисплей и просто гонять в него данные, например, с помощью DMA.
Всё просто и понятно :)
❯ Дисплеи с шиной 8080
Пожалуй, подобные дисплеи найти проще всего, поскольку они использовались в большинстве кнопочных телефонов из нулевых. Такие экранчики можно встретить во многих моделях Nokia, Samsung, LG, Fly, Sony Ericsson и большинстве китайских телефонов. С поиском распиновки и разводкой таких дисплеев всё относительно просто и одновременно сложно: на некоторые модели телефонов (например, почти на все Nokia) можно свободно найти схему в гугле и узнать распиновку коннектора дисплея… однако этот коннектор сначала надо сдуть и развести на breakout-плате, или под микроскопом вывести перемычки. В некоторых случаях (например, Siemens S-серии), дисплей просто прижимался к контактам на плате, а сами контакты имели более чем паябельный шаг.
Из схемы на Nokia N70. Этот дисплей применялся во многих Symbian-смартфонах Nokia тех лет: N-Gage/N-Gage QD, N70, N72, 6600 и некоторых других.
Но особо удобными можно считать дисплеи с паябельными шлейфами с большим шагом пинов — такие можно встретить в некоторых телефонах Samsung и большинстве китайских телефонов. Пытливый читатель спросит «так это ж китаец, где ты на него схему будешь искать?». И вот тут, китайские производители нас приятно порадуют, поскольку за редким исключением, такие дисплеи имеют стандартизированную распиновку: лично мне известны матрицы 37 Pin, 39 Pin и 44 Pin. Как найти для них распиновку? Пишем на «алике» или «таобао» 37 pin lcd tft и смотрим: в описании продавец частенько прилагает распиновку (правда учтите, что 37 pin не имеет пинов IM для настройки ширины шины, а 16-битный интерфейс может быть слишком прожорилвый по числу пинов):
В случае с китайцами, иногда можно найти и схему (нажимайте на зеленую стрелку) на устройство: например, почти на все модели Fly схемы лежат в свободном доступе, где почти всегда можно найти распиновку дисплея. Иногда производитель даже выводит тестпоинты на все сигнальные линии и дисплей с тачскрином можно использовать, не выпаивая его с платы!
Распиновка на Fly IQ239. На нижней части изображения, вы можете увидеть, что такие, безусловно, здоровенные дисплеи можно купить за копейки и сейчас :)
Но задумывались ли вы когда-нибудь, откуда на тачскринах в дисплеях с «али» взялись кнопки «домой», «сообщения», «телефон»? Это ведь те самые дисплеи, которые использовались в «ноклах», просто припаянные к удобной плате! :) Кроме того, на китайские дисплеи без проблем можно найти даташит: обычно они используют контроллеры от ST или ILI, в зависимости от разрешения дисплея.
Концептуально, аппаратная реализация протокола одновременно простая и понятна любому: программа устанавливает состояние каждого бита передаваемого байта на сигнальных линиях D0..D7 (либо D00..D15, если шина у нас 16-битная), а затем просто «дёргает» линию RD (Read или чтение), либо WR (Write или запись) по переходу из низкого уровня в высокий, благодаря чему контроллер дисплея понимает, что байт (или слово в случае 16-битного интерфейса) можно «забирать» с шины. По переходу из высокого уровня в низкий, контроллер снова переходит в режим ожидания следующего байта с шины.
Где взять такие дисплейчики? Да почти везде! Но лучше всего брать дисплеи с китайчиков, которые можно развести на вот таких breakout-платах, которые можно заказать на алике за пару сотен рублей.
Обратите внимание на то, как по свински припаивают подсветку на некоторых дисплеях. И это завод! Лучше сразу прозвоните прежде чем подавать питание. Я, вот, забыл, понадеялся на производителя и по итогу сжёг подсветку :(
Другой вопрос, где искать на них информацию? Помимо схем, можно просто поискать на алике «37 pin lcd tft», «39 pin tft lcd», «24 pin tft lcd» и т. п. Обычно продавцы сами выкладывают распиновку и даже прикладывают ID контроллера дисплея. Поскольку иногда различия в распиновках всё же попадаются, обращайте внимание на то, куда у вас идут дорожки от подсветки и от резистивного тачскрина (если есть), а также вызванивайте все пины с массой — это поможет подобрать правильную распиновку без логического анализатора. Вот, например, дисплейчик из китайской нерабочей реплики Nokia 130 с здоровым 2.4" дисплеем… казалось бы, вообще не понятно что за дисплей, однако воспользовавшись смекалкой, мы находим его распиновку!
❯ SPI-дисплеи
SPI-дисплеи в телефонах встречались относительно редко. В основном, подобные дисплейчики можно было найти в моделях начала 2000х годов: сименсах, моторолах, ранних сонериках T-серии и Nokia на S40. Иногда SPI-дисплеи можно встретить в современных кнопочных телефонах — обычно они имеют шлейф с менее чем 15 пинами, как некоторые модели Fly. Обычно контроллер дисплея поддерживал сразу несколько аппаратных шин, а производитель телефона ещё на этапе установки шлейфа к контроллеру дисплея замыкал необходимые IM-пины выбирая необходимую шину, поэтому программный протокол фактически идентичен дисплеям с шиной 8080.
Несомненным плюсом SPI-дисплеев можно назвать малое число пинов для работы с матрицей: достаточно всего два (плюс сигнал D/C, если дисплей не 9-битный), если повесить RESET на VIO, либо три (четыре), если хотите управлять аппаратным RESET вручную. Но есть и, в некоторой степени, минусы: например, не все микроконтроллеры умеют работать в 9-битном режиме и возможно последний бит придётся досылать «ногодрыгом» (что ломает любую возможность реализации DMA).
Многие дисплеи с этим интерфейсом задокументированы ещё в начале 2000х годов на известных форумах и сайтах, таких как VRTP, Радиокот и easyelectronics, поэтому проблем с их подключением не возникнет даже у новичка. Даже такой крутой и уважаемый дядька, как @DIHALT, когда-то писал полезный материал об использовании FSMC в STM32.
Достать их новыми можно и сейчас: различные магазины запчастей для телефонов бывают продают их по 20-30-40 рублей… Я недавно себе целую коробочку накупил, в том числе и просто для ремонта смартфонов для будущих статей :)
❯ I2C-дисплеи
Дисплеи с такой шиной — настоящая редкость и обычно попадались в телефонах самого начала нулевых годов с низким разрешением дисплея. Из известных мне — Ericsson'ы и ранние Sony Ericsson T-серии, ODM Motorola (головастики например) и… пожалуй всё. Казалось бы, разве I2C может быть полезен для работы с дисплеями, где требуется активный вывод графики? Ведь он совсем медленный! Однако, даже он может пригодится для некоторых проектов, а в большинстве МК частенько попадается аппаратный TWI.
Кроме того, I2C дисплейчики удобно отлаживать: благодаря тому, что периферийное устройство должно отрапортовать ACK (состояние успешности получения байта) мастер-устройству, можно сразу определить обрыв линий до дисплея. Но какой-то конкретной информации по ним я не смогу написать — они все совсем разные :( Правда, полезным линком поделюсь, ребята с форума VRTP собрали хорошую таблицу с различными контроллерами дисплеев, где бывают и i2c!
❯ Подсветка
Отдельного радела стоит тема подсветки дисплеев. По первой может показаться, что тут всё просто: современным дисплеями достаточно 5В, а на старых можно замерить напряжение бустера на живом девайсе и смастерить свой DC-DC повышающий преобразователь, или взять, например, уже готовый драйвер, как известный в определенных кругах LTYN. На самом деле и тут есть свои нюансы.
Итак, каким образом реализована подсветка в том или ином устройстве? Обычно её реализация заключается в последовательном соединении двух и более светодиодов, которые формируют небольшую ленту под рассеивающей плёнкой. На современных китайских дисплейчиках, для работы в полную яркость достаточно всего лишь 5В источника питания + токоограничивающего резистора. Но что самое приятное, подсветка в таких дисплеях способна работать и при 3.3В, пусть менее ярко, но всё равно вполне читабельно.
Если вы делаете портативное маломощное устройство, работающее от одного Li-Ion аккумулятора, то достаточно лишь пустить 3.3В с линейного стабилизатора, который формирует напряжение VSYS для микроконтроллера. Таким образом, у вас будет стабильная подсветка среднего уровня яркости. В качестве альтернативного «бомж» варианта, когда нет возможности собрать нормальный драйвер подсветки, можно попробовать подключить светодиоды напрямую к АКБ, но при разряде дисплей будет потихоньку «тухнуть». Ещё один «бомж» вариант — разобрать дисплейный модуль, порезать дорожки на ленте и соединить пару светодиодов параллельно, выведя их через отверстие, откуда выходит шлейф дисплея, однако в таком случае, потребление подсветки заметно увеличится.
Правильным выходом будет взять с того-же телефона бустер подсветки с индуктивностью и иной необходимой обвязкой, и собрать бустер самому. Особой популярностью когда-то пользовались вышеупомянутые LTYN из телефонов Samsung (это маркировка известного драйвера LT1937). Уровнем подсветки на подобных бустерах телефоны управляют с помощью встроенного ШИМ-контроллера, чем можете воспользоваться и вы :)
❯ Запускаем дисплейчик на практике
В первой части статьи, я постарался ввести вас в курс дела и кратко рассказать о том, как работают такие дисплейчики «под капотом». Как видите — с теоретической точки зрения, ничего сложного нет: пересылаем данные на дисплей, да вовремя дёргаем пин D/C. Но какого же это на практике?
К сожалению, у меня на руках не нашлось подходящего дисплейчика от мобильного телефона (я ведь брал новые по уценке, не все заработали нормально), поэтому в качестве примера работы мы возьмём фактически такой же «китайский» дисплей с алика. Но будьте уверены — с большинством дисплеев, принцип работы будет идентичен (если мы говорим о дисплеях 2005г.в и моложе).
В качестве МК, мы возьмём мой любимый RP2040, который, по моему мнению, незаслуженно обделен вниманием. Время от времени я делаю всякие прикольные девайсы на базе этого МК, поэтому крайне рекомендую его всем моим читателям :)
Давайте же перейдем к практической части статьи! Обычно при создании проекта, я просто клонирую с гита RPi сэмплы с уже готовыми файлами CMake, беру hello world, конфигурирую CMakeLists.txt и пишу свою программу. На малинке пока что нет такого удобного способа создания проекта, как idf.py create-project :) Само собой, для удобства отладки я всегда включаю встроенную в чипсет эмуляцию UART через USB.
if (TARGET tinyusb_device) add_executable(hello_usb main.cpp )
# pull in common dependencies target_link_libraries(hello_usb pico_stdlib hardware_spi)
# create map/bin/hex/uf2 file etc. pico_add_extra_outputs(hello_usb)
# add url via pico_set_program_url example_auto_set_url(hello_usb) elseif(PICO_ON_DEVICE) message(WARNING "not building hello_usb because TinyUSB submodule is not initialized in the SDK") endif()
И инициализирую USB-стек и биндинги stdout к нему:
stdio_init_all(); sleep_ms(1000);
Задержка здесь важна, иначе девайс отказывается определятся в системе. Переходим, собственно, к разводке дисплея. Для работы нам достаточно лишь питания, подсветки, общей массы и четырёх сигнальных линий: MOSI, CLK, DC, RESET. На CS я обычно ставлю перемычку с массой, т. к обычно не вешаю что-то ещё на одну шину с дисплеем.
Переходим к инициализации дисплея. Наш экранчик работает на базе контроллера ST7735R и имеет разрешение 128x160. Сначала, назначаем функции для пинов и дёргаем RESET:
Весьма негусто скажете вы? Ну, с минорными изменениями, здесь заработает дисплейчик любого разрешения, даже 480x320! Переходим к фактической инициализации:
Прошиваем наш МК и смотрим что получилось. Видим шум на экране? Значит дисплей инициализирован верно!
После инициализации дисплея, мы можем выводить на него данные! Дабы дать возможность процессору заниматься другими делами во время передачи картинки на дисплей, мы настроим один из DMA-каналов. DMA-контроллер занимается пересылкой данных из ОЗУ в другой участок ОЗУ (аппаратный memcpy) или периферию. Как раз для второго случая, т. е. пересылки данных в контроллер SPI, мы и будем использовать DMA!
Аллокейтим фреймбуфер, куда мы будем выводить нашу картинку и настраивает DMA-канал:
Переходим к выводу изображения на дисплей. Для того, чтобы просто установить цвет пикселя в любых координатах экрана, достаточно лишь посчитать смещение от начала указателя на фреймбуфер к определенным координатам экрана. Формула очень простая и понятная: ширина дисплея * Y-координата + x координата и результат предыдущих операций помноженный на число байт в одном пикселе.
__inline void pixelAt(short x, short y, short color) { if(x < 0 || y < 0 || x >= LCM_WIDTH || y >= LCM_HEIGHT) return;
В функции есть валидация границ дисплея. Если уверены, что не зайдете за границы дисплея — можете убрать проверку, будет шустрее.
Теперь для вывода картинки, нам достаточно лишь скопировать изначальное изображение в наш фреймбуфер и попросить DMA-канал вывести изображение на дисплей. Для прозрачных картинок без альфа-канала (т. е. с цветовым ключом), функция будет выглядеть так:
Можно сделать чуть комплекснее, добавив альфа-блендинг и аффинные трансформации (возможность поворота и скейла картинок), но пока-что такой задачи не стоит. Ну что, всё очень просто и понятно? :) Пример прошивки можно найти на моём GitHub!
Производительность такого способ на RP2040 можно увидеть вот в этом видосе (на Пикабу не смог залить из-за ограничения на число медиа-элементов). Обратите внимание, что подход предложенный выше больше подходит именно для динамического вывода изображения без dirty-регионов. Он подойдет для игровых консолей, камер, анимаций или устройств с выводом динамической информации по типу осциллографов. Если вам нужно обновлять картинку реже, например, если вы делаете умные часы с плеером, то нет необходимости занимать довольно большой объем ОЗУ фреймбуфером, ведь вы можете писать напрямую в видеопамять. Тут уже решать в зависимости от конкретной ситуации именно вам :)
❯ Заключение
Вот мы с вами и систематизировали информацию о том, как использовать дисплеи с мобильных телефонов в своих проектах. Надеюсь, информация была достаточно полезной для вас! Однако, у меня к вам просьба: пожалуйста, не «дербаньте» рабочие девайсы «на запчасти» :( Это будет не очень гуманно по отношению к нашему «технобалдежу», где мы наоборот стараемся найти применение стареньким девайсам :)
Был ли для вас материал полезен? Пишите в комментариях.
Полезный материал?
Какие дисплейчики подключали?
❯ Важное объявление для читателей касательно будущей рубрики
Друзья! Я, как и многие мои читатели, помимо программирования и железа обожаю тачки! Особенно те тачки, где что-то нужно доделывать самому… и речь, конечно-же, о ТАЗах! Я долго думал, но всё же решился: сейчас я коплю на будущий интересный проект, связанный с ультрабюджетным электронным дооснащением автомобиля, который старше меня в полтора раза — скорее всего, речь пойдет о ВАЗ 2108/2109/21099, причём не исключено что карбюраторной! В планах довольно крутой проект, заключающийся в следующем: мы спроектируем очень дешевый бортовой компьютер (т.е панель) для управления автомобилем на базе дешевого Б/У планшета за пару сотен рублей. Планшет будет связан с управляющим МК через UART (о подобной коммуникации через хардварные протоколы я уже писал целых две статьи: сам себе Linux смартфон, превращаем планшет с нерабочим тачскрином в игровую консоль), и с планшета мы сможем не только управлять основными системами машины (стеклоподъемники, центральный замок и соленоид багажника), но и собирать и пытаться примерно посчитать некоторую информацию о расходе, километраже и стабильности работы двигателя на карбюраторной(!) машине без электронных систем с завода!
Если вдруг двигатель машины будет живенький и заводиться с полтычка, то может и удаленный прогрев постараюсь реализовать :)
В наши задачи будет входить не только проектирование аппаратной части такого оснащения, но и разработка симпатичного интерфейса для самой панели, дабы было не хуже чем в BMW :D Всеми схемами, исходным кодом и инструкциями я буду делится с вами в каждой статье и, как обычно, расскажу обо всех деталях реализации во всех подробностях! У меня уже есть некоторые идеи и наработки. Собственно, почему-б и не попробовать? Будет новая рубрика в блоге: апгрейд автомобилей глазами электронщика и прожженного программера.
Фото не моё, из интернета
Если вам нравятся мои статьи, вас интересует развитие такой рубрики и у вас есть желание и возможность — можете помочь проекту копеечкой с помощью формы доната ниже. Пикабу позволяет остаться анонимным и донатить даже без регистрации. Сейчас у меня есть 40 тысяч рублей личных накоплений, на покупку самой машины планирую выделить 70-80 тысяч рублей (я живу в Краснодарском крае, так что здесь ещё есть шансы найти что-то +- живое за такие деньги), так что остаётся собрать около 30-35 тысяч рублей. За каждую копейку я готов отчитаться (по факту покупки машины я сделаю пост с фотографиями авто, ДКП, а также оглашу фронт будущих работ и сразу начну заниматься проектом).
Друзья! А вы помните такие мобильные телефоны, как Siemens? Когда-то у всемирно известного консорциума, занимающегося выпуском различного силового оборудования и поездов, было собственное мобильное подразделение, которое успешно конкурировало в конце 90х и начале 2000х. Многие мои читатели «постарше» наверняка вспомнят, а то и сами владели такими легендарными моделями, как Siemens SL45, ME45, C55, C65, S65, S75! Но немногие знают, что в своё время эти девайсы были сродни полноценным Symbian-смартфонам Nokia, или даже современным Android-девайсам с разблокированным загрузчиком: энтузиасты быстро смогли разобраться в алгоритме генерации ключей для загрузчика и начать делать патчи, которые фактически превращали «тормозной» телефон в почти настоящий смартфон с полноценной многозадачностью! Недавно мне подарили целых три телефона Siemens, которые носят статус культовых: Siemens C65, Siemens C75 и Siemens S75! Два девайса из трёх были в замечательном состоянии, но имели некоторые проблемы в аппаратной части. В сегодняшнем ностальгическом материале, мы с вами: вспомним о том, какие телефоны делали Siemens в своё время и на каких аппаратных платформах они работали, продиагностируем, проведем аппаратный ремонт и составим список самых частых болячек устройств на платформе S-Gold, рассчитаем ключи для загрузчика, пропатчим, накатим эльфпак и посмотрим, какой же была моддинг-сцена телефонов в нулевых! Интересно? Тогда бегом разворачивать статью!
❯ Эх, Siemens, Siemens...
Пожалуй, ни одно видео или статья с ностальгией по мобильным телефонам из нулевых не обходится без упоминания телефонов от компании Siemens. Немецкие девайсы были инновационными и прорывными во многих аспектах. Например, инженеры Siemens стали первопроходцами, добавив возможность прослушивания MP3 на телефоне, поддержку карт памяти MMC (предок MicroSD, полностью совместимый с ним на программном уровне) и установки полноценных Java-приложений в легендарный SL45, вышедший аж в 2000 году. Нельзя также не упомянуть первый телефон с цветным дисплеем и предусмотрительность инженеров Siemens с точки зрения разъёма для аксессуаров — вряд ли вы видели ещё один телефон с возможностью «горячей» установки внешней камеры прямо в порт для синхронизации!
Но особый статус телефоны Siemens получили на территории СНГ — их девайсы одновременно обожали и злостно ругали. И ведь было за что их любить: у Siemens был особый подход к дизайну телефонов с чётким разделением целевой аудитории устройства, не похожий ни на Nokia, ни на Sony Ericsson, а прошивка в этих девайсах хоть и была достаточно тормознутой и местами не совсем логичной, но тем не менее, её визуальная часть была сделана с явной любовью художников к делу. Каждый девайс по своему отличался от своих собратьев. Вот, вспомните молодежного маскота Siemens, пацанёнка в очках:
Критика в основном заключалась в очень сырых и тормозных первых версиях прошивок (однако компания активно выпускала обновления и пользователь мог спокойно перепрошить телефон в домашних условиях без похода в СЦ), слишком сильном урезании C-серии (например, в С75 невозможно было установить флэшку, а встроенной памяти было мало для мультимедийного телефона) и отсутствии поддержки MP3 на поздних устройствах. Но тем не менее, «сименсам» всё равно было что предложить простым пользователям в мультимедийном плане. А со временем, потянулись и энтузиасты…
Телефоны Siemens были построены на двух аппаратных платформах разработки родственной компании Infineon (ранее эта компания была полупроводниковым подразделением Siemens и занималась разработкой микропроцессоров): первая платформа называлась E-Gold и состояла из микропроцессора с архитектурой C166, работающего на частоте от ~13МГц (SL45) до ~52МГц (S55), GSM-радиотракта и контроллера питания Dialog (на некоторых телефонах использовался Twigo, по каким-то причинам несовместимый с «диалогом»). Её мы могли встретить во множестве устройств A-серии (бюджетники), S и C серии до 6x, а также некоторых устройствах серии SL. Второй платформой была легендарная и многообещающая S-Gold, которая использовалась в устройствах 65'ой и 75'ой серии. Эта платформа была построена на базе ядра ARM926EJ-S, работающего на частоте ~104-208МГц (с возможность разгона), GSM-радиотракта с поддержкой GPRS и EDGE, а также всё того-же контроллера питания Dialog. В своё время устройства на базе S-Gold получили небывалый интерес среди энтузиастов, которые относительно быстро разобрались в алгоритме расчёта ключей для загрузчика и получили возможность применять специальные врезки ресурсов или кода в оригинальную прошивку устройства, называемые патчами. В сегодняшнем материале мы рассмотрим устройства именно на платформе S-Gold!
Со временем, патчи стали неотъемлемой частью «прошаренного» сообщества Siemens, которое в основном тусовалось на форуме siemens-club. Десятки людей активно ковыряли различные версии прошивок под разные девайсы, добавляя новый функционал или меняли визуальную составляющую устройства: какие-то патчи просто «перекрашивали» индикаторы, или, например, меняли шрифт устройства, другие отключали надоедливую кнопку выхода в интернет (которая сжирала огромные денюжки для среднестатистического школяра или студента тех лет), добавляли возможность альтернативного управления, переназначая вечно ломучий джойстик C65 на кнопки клавиатуры, а то и добавляли довольно точную A-GPS навигацию по карте вышек оператора (!) и поддержку нескольких (!!) E-Sim (!!!) в 2004-2005 году!
Пожалуй, многие читатели отнесутся со скепсисом к E-Sim в 2005 году. Но такая возможность была, хоть и не совсем в современном и удобном виде.
Дело в том, что у каждой SIM-карты, помимо публично доступного для телефона идентификатора IMSI, существует ещё идентификатор Ki, который возможно расшифровать только используя алгоритмы БС оператора. Однако в те годы, алгоритмы криптографии в «симках» были проще и с помощью специального софта была возможность «сбрутить» (взломать методом перебора) Ki за несколько часов. Патч, предположительно, работал довольно просто: он подменял Ki и IMSI на те, которые уже были предварительно посчитаны и заставлял baseband часть прошивки заново искать сеть. По итогу мы работали уже с другой SIM-картой :)
Не стоит забывать о различных патчах, связанных с Java-машиной: были ускорители Java-приложений, расширители хипа и тому подобное, позволяющие играть в Java-игры с большим комфортом.
Высшей точкой развития моддинг-сцены на телефонах Siemens стало появление эльфлоадера и эльфпака — возможности запуска нативных программ, написанных на C с полноценной многозадачностью и возможность переключаться между несколькими приложениями! Фактически, это превращало простой мультимедийный телефон в смартфон, который мог выполнять довольно широкий круг задач! Чего уж говорить, одними из самых популярных эльфов были клиенты электронной почты, аськи, плееры с поддержкой mp3 (они, кстати, с дикими хаками — поскольку PCM-часть сименсов толком не отреверсили, эльф просто налету конвертировал mp3 в wav (т. е. тот же PCM) и скармливал в родной плеер :)). Такая свобода действий позволяла, например, портировать на телефон эмулятор NES или SEGA и играть в них на долгих и скучных парах. Для владельцев обычных кнопочников (но не смартфонов на WM2003 for Smartphones) это было шиком и роскошью.
Стоит упомянуть также проект моего друга, с которым мы довольно давно знакомы — @Azq2, который вообще умудрился портировать на него Linux, причём полноценный, а не ucLinux (который не требует MMU и в целом попроще своего десктопного аналога).
Со временем подтянулись и фанаты других производителей мобильных телефонов — Motorola и Sony Ericsson. Сначала появились «моторы» — на мотофане с большим трудом смогли справиться с RSA-подписью и шифрованием прошивок (об этом может подробнее рассказать один из активных админов мотофана — @EXL. По его словам, не обошлось без утечек дебаг-инфы прошивки), но всё же нашли тестпоинт, изучили утекшую информацию и написали свой эльфлоадер, который работает на E398, E1, Razr V3/V3i и некоторых других аппаратах. Сонерики подтянулись позже всех, а вот на Nokia S40 почему-то никто особо и не пытался ничего сделать. Возможно дело в RPL-сертификатах и жёсткой политике Nokia относительно модов, а может в том, что моддерам хватало Symbian — ведь кастомные прошивки выходят даже сейчас!
Недавно мне подарили сразу двух красавцев в очень хорошем состоянии — Siemens C65 от известного блогера Maddy MURK и Siemens C75 от моего читателя из Краснодара. А ещё мой читатель @kostett, задарил CX75 в идеальном состоянии, S75 под реставрацию и S68, за что вам всем огромное спасибо!
И C65 и C75 имели определенные аппаратные проблемы — оба девайса не включались и не подавали никаких признаков жизни. Ну что ж, берём в зубы сервис-мануал, схему и идём диагностировать наших красавцев, плавно переходя в практическую часть нашей статьи!
❯ Диагностика
Начнём мы с вами с C75. Визуально девайс был в очень хорошем состоянии, если бы не бич 75-ой серии — крайне хрупкие корпуса. Крепления фронтальных панелек рассыпались прямо на глазах, так что на этапе фотографирования пришлось немного, эээ, выкручиваться :) К сожалению, к моменту написания статьи я так и не нашёл новый (пусть и китайский) корпус на C75 по нормальной цене, зато нашел на S-ки!
Итак, при установке аккумулятора, девайс не реагируетy ни на кнопку включения, ни на зарядное устройство. В первую очередь, нам нужно определить характер неисправности: исправны ли контроллер питания, процессор и флэш-память.
Очевидно что одно без другого работать не может, однако здесь важна поступательность действий: если за кнопку включения и формирование напряжений для остальных модулей отвечает КП, то и начинать нужно с него. Смотрим, присутствует ли на кнопке включения напряжение, близкое к вольтажу часов реального времени (~2.8В).
В нашем случае, питальники были на месте и при замыкании KB_ON_OFF на землю, КП кратковременно поднимал напряжения на процессоре и затем обратно отключался. Смотрим внимательно сервис-мануал и находим Power On Sequence. После старта контроллера питания, процессор должен вычитать из флэш-памяти стартовый код прошивки, проинициализировать ОЗУ и после этого регулярно отправлять «пинг» контроллеру питания, сигнализируя о том, что телефон работает. Если связь с флэш-памятью, ОЗУ или КП утеряна, то модуль WatchDog в КП просто выключит устройство.
Цитата из схемы на A60 на платформе E-Gold, но ASIC'и концептуально очень похожи.
Кроме того, процессор тактируется от 26МГц кварца, идущего с SDR-передатчика. Если он пострадал в следствии воды или падения — телефон также не включится. Проверить наличие старта процессора можно с помощью x65PapuaUtils. Если девайс хотя бы как-то отвечает на нажатие красной кнопки и что-то показывает в логе «папуаса» — значит передатчик, скорее всего, жив. Но для этого, конечно же, нужен дата-кабель.
Самое время глянуть, что у нас под металлическими экранами! Вскрываем их и видим… вот это:
Явные следы попадания влаги, процессор был весь ужарен и во флюсе… кто-то ещё в нулевых пытался его ремонтировать. Берём в зубы строительный фен и сдуваем процессор:
Процессор снялся за 10-15 секунд без нижнего подогрева, что говорит нам о том, что прошлый мастер пытался посадить процессор «на пузо» (т. е. не нанося новые шары припоя) и у него явно не получилось. После этого на девайс забили и отложили в долгий ящик… чтобы спустя 18 лет он попал ко мне! Специально для ремонта этого «симака» я нашёл и купил новый BGA-трафарет, отреболил процессор и поставил обратно:
Помимо перекатки процессора, поскольку девайс «купался», помимо поврежденных шаров процессора помер и фильтр на USB, отвечающий за дата-кабель. Его можно заменить на перемычки, но для этого нужен адекватный микроскоп, которого у меня пока нет. Я пробовал махнуть с 65 серии — не работает.
Тот самый крошечный фильтр на примере C65. Находится в BGA-корпусе, его легко посадить «на пузо».
Подсобрал девайс и… Он включился! Правда, работал только под небольшим изгибом — присмотревшись, я обнаружил следы флюса около флэш-памяти производства Intel, которую тоже сажали на пузо, да ещё и криво. После прогрева, девайс поработал какое-то время и через пару дней отвалился — как раз к моменту подготовки статьи, а у меня как назло не было нужного универсального трафарета :( Поэтому C75 выбывает из сегодняшней статьи, окруженным, но не сломленным :) Трафареты заказаны — ждём, оживляем и я сделаю отдельный пост о его судьбе.
Давайте перейдем ко второму красавцу — Siemens C65. Как я уже говорил ранее, его мне подарил известный блогер Maddy MURK, у которого частенько выходят обзорные ламповые видео о ретро-мобилках. Заслал он мне сразу несколько девайсов под восстановление, одним из которых и был этот C65!
Изначально, у девайса был битый дисплей — это не проблема, у меня такие есть :) Очевидно, что это следствие падения и как это часто бывало на 65'ых/75'ых, заменой дисплея всё не закончилось. Всё дело в том, что в те годы отвал процов и диалогов был типовой болячкой на телефонах Siemens. После перехода на более низкий техпроцесс производства плат (шары уменьшились в размерах, а следовательно и сами контактные площадки), пятачки стали хрупкими и в лучшем случае дело заканчивалось отвалом с необходимостью прогрева или перекатки. А в худшем — пятаки под процессором срывало и приходилось их восстанавливать, тянув перемычки!
К сожалению, конструктивно некоторые Сименсы были не очень продуманы: блок клавиатуры был внешним и пружинился к коннектору на плате, создавая при каждом нажатии нагрузку на плату. Добавить к этому то, что иногда телефоны закручивались фиг пойми какими винтами (после мастерских и т. д.), перекашивая плату, и результат был печальным — спустя пару лет активных нажатий на клавиатуру, девайс переставал включаться…
И причина этому проста — из-за того, что плата подвергается регулярным деформациям (хоть и несерьезным) — со временем может либо оборвать дороги, либо просто отвалиться процессор/флэш/ОЗУ с необходимостью дальнейшей перекатки. Именно поэтому живых CX65 осталось относительно немного.
Девайс определялся в «папуасе», но не мог зайти в сервисный режим из-за ошибки связи с ОЗУ. Тут уже всё стало очевидно и я приготовил фен… ремонт оказался абсолютно таким же, как и в случае с C75! Правда, если вы хотите попробовать оживить свой симак и перекатывать BGA не умеете, то можете просто погреть и покачать процессор с хорошим флюсом, есть шанс, что девайс оживет и ещё порадует вас или, по крайней-мере, позволит скинуть фото на другое устройство.
Обратите внимание на выделенную надпись. Boot not loaded как раз означает то, что телефон ответил на нажатие буткея, но девайс не смог полностью проинициализировать загрузчик.
Дисплей я взял в одном из сименсов, которые купил по 70 рублей «на запчасти».
Включаем девайс и тут тоже всё работает :)
Девайс определяется в папуасе и полностью проходит тест дисплея, кнопок и звука, что означает его полную работоспособность! Подытоживая аппаратный ремонт, рассказываю о некоторых типовых болячках телефонов Siemens:
Телефон едва слышимо пикает при попытке включения: это называется пикофф (отключение телефона с вылетевшим исключением) из-за переполнения раздела с пользовательскими данными. Увы и ах, но его придётся форматировать (хотя перед этим можно посчитать ключи и снять дамп, а потом попытаться поискать фотки в условном binwalk'е). Решается очень легко при наличии дата-кабеля: подключаем телефон к ПК с Windows XP (подойдет и виртуалка), заходим в «папуас», жмём «Service Mode» и кратковременно нажимаем красную кнопку. После того, как девайс зашёл в сервис-мод, форматируем User-раздел в соотвествующей вкладке. Всё, девайс загрузится как новый!
Телефон не стартует, VRTC нет, питаний на тест-поинтах вообще никаких нет: начните с осмотра Dialog, на месте ли обвязка, не калится ли он, приходит ли на него VBat, какое потребление при нажатии на кнопку питания и есть ли реакция на подключение ЗУ. При необходимости перекатать или заменить. Аккумулятор тоже стоит проверить.
Телефон не стартует, но определяется в папуасе: проверьте процессор. При необходимости перекатайте и, если умеете, восстановите пятаки. Вполне возможно, что девайс когда-то прошивали и окирпичили — прошейте последнюю доступную сервисную прошивку (через Winswup). В крайнем случае можно посчитать буткей и залить фуллфлэш с чужого девайса.
Телефон не стартует, напряжения есть и никак не определяется: вполне может быть что и фильтр USB-поврежден, из-за чего папуас не видит телефон. Опять же, катаем проц, если не помогло — то ОЗУ и КП. Стоит глянуть на наличие 26МГц кварца с передатчика.
Телефон пикает и отключается в процессе работы: если есть дата-кабель, то x65PapuaUtils покажет причину пикоффа и ExitString, что поможет понять из-за чего ошибка. Но в основном это следствие кривой прошивки: шьем последнюю официальную и наслаждаемся!
❯ Прошиваем и патчим
Давайте сначала я просвещу вас в терминологию в мире моддинга сименсов:
Патч — хак оригинальной прошивки, который прошивается в флэш-память по определенному адресу. Обычно патчи подменяют графику, реакцию системы на какие либо события (например поиск сети или пропуск проверки SIM-карты) или добавляют новые функции.
Эльфлоадер — загрузчик нативных ELF-программ.
XTask — диспетчер задач, позволяющий переключаться между программами.
Эльфпак — сборка из эльфлоадера и необходимых патчей для его работы.
SWILIB, библиотека функций — Специальная таблица функций, предназначенная для того, чтобы эльфы и патчи могли работать на разных версиях прошивок.
Пришло время пропатчить наши сименсы и посмотреть, на что они способны теперь! Я собрал все необходимые файлы, в том числе папуас, флэшер и патчер, а также прошивки для C65 и SL65 и необходимые патчи в один архив, дабы вам не пришлось ничего искать самим! К сожалению, к моменту подготовки статьи, я так и не смог найти фильтр на C75, да ещё и флэша отвалилась :( Поэтому моддить мы будем только C65 и S75! И в этом нам снова поможет x65PapuaUtils. Для применения патчей нам необходимо разблокировать загрузчик путем расчёта Boot-ключе, которые генерируются на основе связки ESN + Hash. Для устройств 65 серии с низкой версией прошивки, x65PapuaUtils может сам всё сделать одной кнопкой, но для устройств 75 серии придется устанавливать отдельный мидлет и смотреть бут-ключи там.
Мидлет, позволяющий узнать ESN, эксплуатировал интересную уязвимость Java-машины, связанную с реализацией deflate. Благодаря тому, что разработчики оставили ошибку с переполнением, мидлет выходил за границы указателя и инжектил собственный шеллкод, который позволял читать и писать всё адресное пространство устройства :)
После разлочки загрузчика, сгенерируйте VKD-файл в папуасе и ставьте софт одного из самых крутых дядек в моддинг-сцене сименсов: V_KLay от ValeraVi! Это довольно крутая программа, которая оперирует собственным «языком» патчей: каждый патч предполагает указатель на адрес в флэш-памяти, старое значение (для валидации) и новое. По итогу, каждый патч — это просто текстовый файл, в том числе и эльфлоадер!
Пример патча. ValeraVi даже какое-то подобие препроцессора сделал с #if'ами — что вообще улёт :)
Но ставить патчи пока рано, на C65 в чистом виде не было нормального эльфпака, хотя патчей было достаточно. Обычно его перепрошивали в SL65, где была более шустрая Java-машина (вроде даже с поддержкой M3G) и возможность снимать видео! В остальном, девайс был почти аналогичен C65. Сначала телефон нужно «переименовать» в SL65 с помощью утилиты x65Flasher, а затем прошить WinSwup'ом с отключенными галочками проверок.
Девайс откажется стартовать, вылетая с пикоффом (при этом телефон будет жаловаться на Invalid HW). Для обхода этого ограничения, нам необходимо поставить специальный патч на обход проверки железа телефона и адаптации C65 к SL65. Делается это просто: загружаем патч по отдельности, выбираем C65 (Password boot) и подключаем выключенный телефон к ПК. Когда программа начнет искать телефон — кратковременно нажимаем красную кнопочку и программа начнет патчить девайс!
Делать дамп флэши необязательно, достаточно просто нажать пробел (дамп затянется на час-полтора).
После применения патчей, девайс стартует и работает как будто это SL65! Давайте же теперь присмотрим себе прикольные плюшки в базе патчей и накатим что-нить интересное. Например, я поставил «ускоритель Java», «замена значков на C75», «открыть все диски» и «работа без SIM-карты».
Увы, я несколько ночей бился с эльфпаком и заставить работать у меня его не вышло: на C65 эльфпак слишком старый и удален из базы патчей, а на SL65 он банально нерабочий — в комментариях тоже были жалобы на то, что программы банально не работают :(
Накатили эльфпак? Отлично, теперь наш телефон пропатчен, посмотрим как это работало в случае C65, а заодно узнаем, какую информацию он хранит в себе уже почти 20 лет!
❯ Знакомимся с девайсом поближе
Друзья! Эту часть статьи я решил оформить в виде серии относительно небольших видосов, дабы вы могли лучше прочувствовать дух того времени. Для занятых читателей, или просто тех, кто не хочет смотреть видео, я хотел сделать отдельный подраздел, где были бы только скриншоты - но увы, ограничение Pikabu на 25 медиа-элементов в одном посте дают о себе знать :(
Включив девайс, нас встречает такой знакомый звук щелчка включения света и пацаненок в очках на фоне! После установки патча на работу без SIM, девайс сразу грузится в систему и работает стабильно, без каких либо проблем. Эффекты от патчей есть сразу. Разблокируются два скрытых диска с кэшем системы и конфигами, что позволяет чистить их без форматирования устройства, немного меняется верхний статусбар, а Java-машина и StackAttack в ней работают заметно шустрее!
Но самая главная кладезь информации в «симаках» — это, конечно же, раздел файлов! Телефоном пользовалась маленькая девочка лет десяти и здесь, спустя практически 20 лет, сохранилась часть её жизни! На телефоне остались фотографии родственников, а также мультимедийные файлы, которыми она обменивалась со своими друзьями и возможно одноклассниками! На девайсе есть просто куча различных картиночек и гифок, популярные в рунете тех лет. Котики, гифки с девушками, машины — всё, чем делились пацаны класса попадало сюда! Не менее важной была и фонотека каждого телефона! Некоторые MIDI-мелодии на большинстве девайсов и сейчас можно встретить!
Что особенно забавно, девочка, видимо, очень хотела себе Sony Ericsson, так что на телефоне есть заставка с лого «сонерика» и фирменным рингтоном! А может, это отголоски тех лет, когда сонерики считались самыми крутыми и некоторые пытались стилизовать под них свои телефоны? Ведь в начале 2010-х такой тренд тоже был, но с кастомными прошивками в стиле iOS для Android смартфонов!
Осторожно, на фото ниже ламповые бобины, а из-за названия файла начинает играть миди в голове! Кто тут не узнает evropa.mid? На телефоне были самые разные треки, начиная с midi-версий ранних треков Eminem, заканчивая гимном СССР и, конечно же, саундтреками фильмов «Бумер» и сериала «Бригада»!
Но вы ведь, вероятно, ждёте эльфов, дабы узнать что они могли привносить новенького в телефон?
❯ А эльфы? Эльфы где!?
Ну как я мог написать статью про Siemens'ы без эльфов! Как я уже говорил выше, на C65 (который стал SL65) эльфлоадер поставить мне не удалось. Однако, на более популярные модели Siemens, эльфлоадер легко установить и он работает без проблем, разве что перед этим придется прошиться на самую свежую прошивку для вашего девайса!
Изучать эльфы мы будем с вами на примере Siemens S75, который подарил мне читатель! На телефон были установлены патчи для работы без SIM, библиотека функций а также эльфпак. Но для работы эльфов, необходимо закинуть на нулевой диск (т. е. в память) папку ZBin с некоторыми полезными программами типа того же XTask'а. Если у вас нет подходящей флэшки, то это можно сделать через Bluetooth, ИК-порт или дата-кабелем с помощью Mobile Phone Manager (осторожно, он забагованный до жути!).
Ну, а на видео ниже предлагаю вам ознакомиться с тем, что же привносили эльфы в мир телефонов Siemens!
❯ Заключение
И вот, казалось бы, мобильные телефоны Siemens серьёзно сдали позиции в 2004 году и совсем погибли после покупки компанией Benq. Но какая же ирония случилась ближе к концу 2000 годов, когда Nokia на платформе S40 начала использовать… чипсеты Infineon X-Gold, те самые продолжатели сименсовких S-Gold'ов! До этого Nokia использовала собственный процессор UPP (вроде бы, разработанный в сотрудничестве с STMicroelectronics). Помимо Nokia, X-Gold использовали Apple и некоторые другие производители (LG), а старую платформу E-Gold можно было встретить в некоторых бюджетных телефона, по типу Мегафон Минифон. То есть в весьма своеобразной форме, учитывая родственные связи Infineon и Siemens, «сименсы» как бы вернулись обратно на рынок телефонов, только уже в качестве «сердца» телефонов других брендов!
Вот такой была моддинг-сцена эльфов в нулевых годах! Лёгким движением руки, сименсы превращались из обычных кнопочников в почти аналоги современных смартфонов! Казалось бы, прошло практически 20 лет, многие форумы упомянутые в первом разделе статьи уже не существуют, а тот же мотофан стал прибежищем коллекционеров и немногих владельцев «моторов» в наше время. Но как бы не так! Спустя много лет, интерес к кнопочникам снова пробудился у многих участников сообщества того же сименс клаба. Мы чудом обнаруживаем, что база патчей для Siemens, которую ведет Илья kibab всё ещё работает, EXL с мотофана продолжает портировать всякие ништяки на моторы, Azq2 всё ещё пилит эльфы, патчи, а также полноценный аппаратный эмулятор процессора SGold, который способен запустить родную прошивку! У любителей моддинга мобилок из нулевых есть собственный TG-канал siepatch, где обсуждают моддинг под симаки, моторы — всё подряд! Но чатик формально приватный и по инвайтам. Если действительно хотите попасть туда — пишите мне в тг @monobogdan, скину инвайт.
P. S.: Друзья! Время от времени я пишу пост о поиске различных китайских девайсов (подделок, реплик, закосов на айфоны, самсунги, сони, HTC и т. п.) для будущих статей. Однако очень часто читатели пишут «где ж ты был месяц назад, мешок таких выбросил!», поэтому я решил в заключение каждой статьи вставлять объявление о поиске девайсов для контента. Есть желание что-то выкинуть или отправить в чермет? Даже нерабочую «невключайку» или полурабочую? А может, у этих девайсов есть шанс на более интересное существование! Смотрите в соответствующем посте, что я делаю с китайскими подделками на айфоны, самсунги, макбуки и айпады! Да и чего уж там говорить: эта статья уже сама по себе весьма наглядный пример! Найти меня можно в комментариях тут, на Пикабу, и в тг @monobogdan
Понравился материал?
Был у вас Siemens?
Я тут Galaxy S8 прикупил за 800 рублей. Большая часть фотографий в статье сделана именно на него. Норм качество?
Понравилась статья и хотите поддержать меня, дабы новые статьи выходили чаще? Ниже есть формочка с донатами. Всем большое спасибо!
А вам как наши сегодняшние герои? Понравились? Если вдруг интересно, то у меня есть канал в Телеге, куда я публикую бэкстейдж со статей, всякие мысли и советы касательно ремонта и программирования под различные девайсы, а также вовремя публикую ссылки на свои новые статьи. 1-2 поста в день, никакого мусора!
Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю!
Есть у кого ATF Box с SDC-модулем? Нужно помочь с подготовкой одной из будущих статей. В материале не забуду упомянуть вас, само собой :) Нужно записать sdc на microsd, а затем снять с её дамп с помощью Win32DiskImager и скинуть мне. Если кто-то хочет помочь - пишите в комменты или @monobogdan в тг! Спасибо :)
