А можно рассмотреть старые компы типа XT?
Эмулятор для них есть в проекте "мурмулятор".
Там же схемы эмуляции различных приставок, компьютеров типа "Радио-86РК" и "ZX-Spectrum".
Надеюсь скоро можно будет эмулировать i286 и i386 - и, возможно, даже получится запустить OS/2 Warp 4.0 Merlin или что-то подобное для офисной работы...
Меня часто спрашивают, почему я не наносек.
Я маргинал, который знает исключительно вершки-корешки и не умеет ни код нормальный писать, ни что то доводить до конца. Я не закончил три пту в своем городе из за того, что просто отбитый маргинал. Поэтому мне не светит ни госка, ни частная контора, ни даже работа на галере - у меня нет скиллов, а умело продавать себя я не умею и у меня не хватает хватки.
Так что фигня это все, мой максимум - второсортные развлекательные статейки, чисто как бульварное чтиво, только про IT. Почти как нейромусор.
Осторожно: Статья написана максимально простым языком. Так что если вы гик, но не умеете программировать - вам всё равно будет интересно!
Недавно я наткнулся на DIY-игровую консоль за 1.500 рублей - Waveshare GamePi13. Когда гаджет приехал ко мне, я запустил примеры игр от производителя... и оторопел от 5 FPS в Pong - это ж как плохо нужно код писать!
Не желая мириться с этим, я открыл схему устройства, даташит на RP2040 и принялся писать свой собственный BIOS. Если вам интересно узнать, как работают DIY-консоли «изнутри», можно ли запускать внешние программы на микроконтроллерах из RAM, как реализованы различные подсистемы BIOS, а в конце даже написать «Змейку» - добро пожаловать под кат!
❯ Предисловие
Иногда китайские производители выпускают на рынок дешевые гаджеты с ориентиром исключительно на гиков. Чего-уж говорить, с какой-нибудь R36s чего только не сделали: и кастомные прошивки, и порты игр с ПК, и даже достаточно сложные аппаратные модификации. Однако в тусовке DIY'щиков обычно всё куда хардкорнее...
«Андерграундные» консоли выходят чуть ли не каждый день, но лишь единицы из них становятся хоть сколь либо популярными и попадают на массовый конвейер. От «больших» консолей их отличает простая схемотехника, использование распространенных и дешевых микроконтроллеров общего назначения и полная свобода творчества — что хочешь, то и твори! По характеристикам они чаще всего близки к оригинальному GameBoy или GameBoy Advance, а покупают их инженеры, демосценеры и ретро-энтузиасты, которые не только играют во что-то готовое, но и пишут небольшие игрушки сами!
Самые известные консоли такого формата — это нашумевший Playdate и чуть менее известный Arduboy. Обе консоли сильно ограничены в характеристиках и это подстегивает интерес гиков к постоянной оптимизации кода и попыткам впихнуть «невпихуемое». Выделился даже российский «Микрон», представив свою DIY-консоль «для хардкорных ардуинщиков» — некий MikBoy на базе своего же МИК32 «Амур»!
Я уверен что Микроновцы будут читать эту статью... Если вдруг всё получится и MikBoy пойдёт в серию — то напишите мне пожалуйста сообщение :)
Подобным «ардуинщиком» являюсь и я. Ещё со школьных лет меня нереально тянет к микроконтроллерам и Embedded-электронике в целом. О консоли собственной разработки я мечтаю с 14 лет, при этом мне не просто хочется собрать прототип и «забить», но и запустить мелкосерийное ручное производство и продавать устройства подписчикам! К своим 24-годам я сделал два прототипа и развел три платы, но все эти проекты так или иначе откладывались в долгий ящик...
Один из ранних-ранних прототипов, предназначенный для обкатки драйвера дисплея.
И вот, 25 сентября мне стукнуло 24 годика. Уже взрослый мальчик получил в качестве подарка донат от постоянного читателя и пошёл изучать маркетплейсы в поисках интересного железа. По ключевым словам «tft lcd diy» был найден «ESP32 Bitcoin Miner V2» (выгодный девкит с 2.8" и ESP32-S2), девкит ESP32 с 4.3" дисплеем и емкостным тачскрином, а также некий Waveshare GamePi13, о котором мы сегодня с вами и поговорим!
Отдельное спасибо хотелось бы сказать тем самым подписчикам. Без вашей поддержки этой статьи бы не было!
Waveshare — знаменитый в кругах энтузиастов SBC производитель. В основном компания занимается дисплеями, модулями расширения и одноплатными компьютерами.
В тот же день я заказал устройство, и уже через 3 недели трепетного ожидания, GamePi13 оказался у меня на столе. На первый взгляд консоль показалась очень маленькой: её 1.3" дисплей был даже меньше, чем у Nokia 6230i, а кнопки оказались расположены непривычно близко друг к другу. Ко всему прочему, у консоли не было предусмотрено вообще никакого корпуса: ни «болванки» от производителя, ни STL-файлов для печати. Что-ж, это только придаёт брутальности нашему устройству!
Оба устройства помещаются в одну ладошку... А ведь когда-то 6230i казался реально большим!
Как вы уже могли заметить, консоль состоит из двух независимых модулей: платы разработки Waveshare RP2040-PiZero и «бутербродного» геймпада с дисплеем, который подключается к гребёнке основной платы. В этом и кроется главный секрет устройства: геймпад изначально рассчитан именно для «одноплатников» Raspberry Pi, но поскольку Waveshare также выпускает плату RP2040 с Pi-совместимой гребёнкой, они решили заодно адаптировать его и для PiZero.
❯ Что внутри?
Хоть PiZero и похожа на референсную плату в лице Raspberry Pi Pico, у неё есть несколько серьёзных отличий:
Во первых, на плате установлена SPI-флэшка объёмом аж в 16МБ. Это максимальный объём, который поддерживает XIP-контроллер в RP2040. В RPi Pico же используется флэш-память объёмом всего в 2МБ.
Далее внимание привлекает использование менее эффективного ULDO RT9193 вместо полноценного DC-DC преобразователя в оригинальном Pico. Сам микроконтроллер сможет работать при разрядке аккумулятора ниже 3.6В, а вот периферия — под вопросом. Иными словами, мы не сможем использовать «все соки» из аккумулятора и нам придётся реализовывать отсечку по напряжению.
На плате распаяна микросхема-чарджер литий-ионных аккумуляторов ETA6096 с током зарядки аж в 1А. Если захотите использовать аккумулятор меньшей емкости — стоит подобрать резистор ISET большего номинала, иначе есть риск перегрева.
Из разъёмов распаян HDMI (да, я тоже в шоке), слот для MicroSD (под него отдали весь SPI0) и два Type-C: один для аппаратного USB-контроллера в RP2040, второй для USB через PIO. В общем, пытались угодить всем.
Плата с геймпадом не менее интересная. С фронтальной стороны у нас расположилось 10 кнопок и 1.3" IPS-дисплей с разрешением 240x240, использующий контроллер ST7789. Вообще, для такой диагонали разрешение дисплея крайне избыточно: оно не только съедает драгоценные килобайты оперативной памяти для фреймбуфера, но и значительно грузит DMA-контроллер и всю шину SPI. Я бы на месте инженеров установил бы сюда «золотой стандарт» — недорогой 1.8" 128x160. Все кнопки подключены к отдельным пинам без сдвигового регистра и занимают значительную часть доступных GPIO.
Я бы сделал лучше!
С обратной стороны расположился небольшой динамик, усилитель, построенный на базе NS8002, 3.5мм джек для подключения наушников, а также токоограничивающий резистор подсветки и обвязка для дисплея. Подсветка подключена напрямую к VSYS и рассчитана на питание от 3.3В, так что никакой регулировки яркости и продвинутых режимов сна!
Производитель платы — компания SpotPear.
Ну что-ж, собираем наш бутерброд обратно, подключаем Type-C и смотрим на одну из представленных демо-игр — Тетрис!
Нет, это не пережатая гифка, игра действительно идёт буквально в 1 FPS и с мерцанием — и это на микроконтроллере с ядром Cortex-M0+ на частоте аж в 150МГц! Я напомню, что N-Gage с процессором TI OMAP на более старом ядре ARM926EJ-S с частотой 104МГц умудрялся тянуть первый Tomb Raider с полностью программным рендерингом в 25 FPS!!!
Далее я решил открыть официальный вики Waveshare и изучить информацию о консоли, где нашел несколько примеров игр для неё, одной из которых был Pong. Какое же было моё разочарование, когда я узнал, что обе игры написаны полностью на Python: игровая логика, маршалинг данных, работа с «железом» — всё это было на интерпретируемом языке и более того, написано плохо и крайне неэффективно!
class hardware():
def init():
spi0=SPI(1,baudrate=900000000, phase=0, polarity=0,
sck=Pin(game_kit.lcd_sck, Pin.OUT),
mosi=Pin(game_kit.lcd_sda, Pin.OUT))
display = st7789.ST7789(spi0, 240, 240,
reset=Pin(game_kit.lcd_rst, Pin.OUT),
dc=Pin(game_kit.lcd_dc, Pin.OUT),cs=Pin(game_kit.lcd_cs, Pin.OUT),
xstart=0, ystart=0, rotation=0)
# 初始界面，提示游戏开始
display.fill(st7789.BLACK)
display.text(font2, "Pong!", 90, 90)
display.text(font2, "Let's go!", 60, 140)
time.sleep(1)
hardware.display = display
class pong():
def __init__(self):
# bgm
self.bgm = p_music(p_music.song2, tempo=1, duty=500, pins=[
Pin(game_kit.buzzer, Pin.OUT)])
# 控制音乐暂停和播放的键start
self.key_start = button(game_kit.key_start, self.key_start_callback)
# led
self.led = Pin(game_kit.led_sta, Pin.OUT)
Ни о каком подобии SDK или библиотеки для абстрагирования работы с железом даже речи не шло, практически всё, кроме номеров пинов, было захардкожено прямо в коде игры. О хорошей архитектуре тоже речи не идёт: один класс на всю логику с глобальными переменными... В общем, сэмплы писал либо новичок, либо прожженный эмбеддер :)
Драйвер дисплея даже не пытается использовать DMA, из-за чего даже Понг, состоящий из трёх прямоугольников умудряется тормозить.
def blit_buffer(self, buffer, x, y, width, height):
"""
Copy buffer to display at the given location.
Args:
buffer (bytes): Data to copy to display
x (int): Top left corner x coordinate
Y (int): Top left corner y coordinate
width (int): Width
height (int): Height
"""
self.set_window(x, y, x + width - 1, y + height - 1)
self.write(None, buffer)
Звуковая подсистема, состоящая из одноканальной тональной пищалки на аппаратном ШИМ-контроллере, тоже была со своими «приколами». Например «тишина» — это 0, то есть магнит всегда прижат к нижней части, хотя должно быть PWM_MAX / 2.
Под впечатлением от такого кода, я решил попробовать написать SDK для этой консоли сам. Однако моё видение идеальной DIY-консоли сильно отличалось от того-же Arduboy или Playdate!
❯ Архитектура
При проработке архитектуры будущего «BIOS», я сразу же поставил для себя несколько чётких задач:
Во первых, BIOS должен быть достаточно абстрактным для того, чтобы скрывать от игры детали реализации конкретного «железа». Иными словами, игра оперирует не DMA-контроллерами, FPU-сопроцессором и SPI, а набором простых и понятных подсистем: графика, ввод, звук, хранилище. Кроме того, это позволяет легко портировать игры для такого BIOS'а на другие платформы: можно без проблем реализовать симулятор (не эмулятор!) консоли на ПК или портировать её на ESP32 с минимальными изменениями.
Во вторых, мы ставим производительность в основной приоритет при разработке устройства. В конце-концов это же позорище, что простейшая игра тормозит и мерцает на мощном микроконтроллере, но при этом тетрисы с трёхмерной графикой вполне шустро работали на телефонах Sony Ericsson 2005 года. Именно поэтому для написания игр используются не скриптовые языки по типу Lua или JS, а самый обычный «C с классами».
В третьих, сам BIOS должен быть легко портируем между разными платами (у SpotPear есть вторая похожая плата — уже с 1.5" и стиком) и даже аппаратными платформами. Этот проект может стать основной прошивкой для консоли уже моей разработки и иметь вот такую «кроссплатформу» было бы отнюдь не лишним!
Руководствуясь критериями выше, я решил писать BIOS на C++ (на деле C с классами) с активным использованием интерфейсов и VMT. Это позволяет не только удобно структурировать модули и повышает читаемость кода игры, но и избавляет от необходимости вручную составлять таблицу системных вызовов к API. Тем не менее, в таком подходе есть один серьёзный нюанс: когда у подсистем появляются новые методы или добавляются перегрузки к прошлым, их необходимо по порядку добавлять в конец интерфейса, иначе VMT ломается.
vtable for CTest:
.word 0
.word typeinfo for CTest
.word CTest::Test()
.word CTest::Abc()
vtable for ITest:
.word 0
.word typeinfo for ITest
.word __cxa_pure_virtual
.word __cxa_pure_virtual
В своё время Microsoft решила эту проблему в COM с помощью QueryInterface и миллиона вариаций этих самых интерфейсов: IDirectSound8, IDirectDraw7 и т.д, но мы можем не изобретать велосипед, а просто предоставлять «старым» играм такие же «старые» версии VMT.
Основным объектом в BIOS'е является CSystem, который содержит в себе ссылки на другие подсистемы консоли, а также на информацию о текущей аппаратной платформе:
/// @brief Primary system service, supplied to both games and system modules.
class ISystem
{
public:
virtual CSystemInfo* GetSystemInfo() = 0;
virtual void* Alloc(uint32_t size) = 0;
virtual void Free(void* ptr) = 0;
virtual IGraphicsService* GetGraphicsService() = 0;
virtual IInputService* GetInputService() = 0;
virtual IDebugService* GetDebugService() = 0;
};
Несмотря на кажущуюся «динамическую» натуру системы, никаких IID я переизобретать не стал. BIOS должен реализовывать ровно тот минимальный функционал системы, который нужен. Экземпляр CSystem создаётся так называемым «портом» на конкретную плату, который должен заполнить структуру с указателями на реализации подсистем — прямо как machine-файлы в Linux! И RAII не нарушили, и полный контроль без костылей сохранили — ляпота!
void InitializePlatform()
{
CommManager = new CCommunicationManager();
CDebugService* dbgSvc = new CDebugService();
/* Print some userful debug information */
CJEDECFlashID* flashId = FlashManager.GetFlashID();
dbgSvc->Print("Initializing platform");
dbgSvc->Print("Flash memory manufacturer: 0x%x, capacity: %dKb", flashId->Manufacturer, flashId->Capacity / 1024);
dbgSvc->Print("CID: %d", FlashManager.GetCID());
dbgSvc->Print("First available: %d", FlashManager.GetFirstUserSector());
/* Service initialization */
InputService = new CInputService(dbgSvc);
GraphicsService = new CGraphicsService(dbgSvc);
/* Platform description info */
PlatformInfo.DebugService = dbgSvc;
PlatformInfo.GraphicsService = GraphicsService;
PlatformInfo.InputService = InputService;
System = new CSystem(&PlatformInfo);
}
int main() {
InitializePlatform();
while (true) {
/* Tick all platform-depend services here */
CommManager->Tick();
PowerStateManager.Tick();
InputService->Tick();
System->Tick();
}
}
В целом, базовая архитектура примитивная и понятная. Перейдем же к деталям реализации конкретных модулей.
❯ Графика
Первая подсистема, которую я реализовал — была графической. Концептуально она разделена на два отдельных модуля: драйвер дисплея, который позволяет получить его параметры и в будущем управлять его состоянием, а также модуль для рисования на поверхностях. Прямо как в DirectDraw:
struct CFrameBufferInfo
{
uint16_t Width;
uint16_t Height;
CColor* Pointer;
uint32_t Size;
};
class IDrawingSurface : public ISystemService
{
public:
virtual void Clear(CColor color) = 0;
virtual void DrawBitmap(CBitmap* bitmap, int x, int y) = 0;
virtual void DrawBitmapEx(CBitmap* bitmap, int x, int y, CSpriteInfo* spriteInfo) = 0;
virtual void DrawRect(CColor color, int x, int y, int width, int height) = 0;
virtual void FillRect(CColor color, int x, int y, int width, int height) = 0;
virtual void DrawLine(CColor color, int x1, int y1, int x2, int y2) = 0;
virtual void DrawString(CColor color, int x, int y, CAnsiChar* str) = 0;
};
class IGraphicsService : public ISystemService
{
public:
virtual void SetPowerState(bool isPowerEnabled) = 0;
virtual void SetBacklightState(bool isBacklightEnabled) = 0;
/* Maybe some controller-related functions in future? Like BIAS and HW rotation? */
virtual CFrameBufferInfo* GetFrameBufferInfo() = 0;
virtual IDrawingSurface* GetDrawingSurface() = 0;
virtual void Flush() = 0;
};
Сам драйвер дисплея классический: в его задачи входит инициализация контроллера, выделение памяти под фреймбуфер и регулярное обновление изображения на матрице. Поскольку в таких устройствах используются стандартные MIPI DBI экраны с набором команд DCS, часть кода инициализации и работы с дисплеем стало возможным унифицировать:
/* Perform hardware reset */
gpio_put(PIN_LCD_RST, 0);
sleep_ms(DISPLAY_INIT_SLEEP_TIME);
gpio_put(PIN_LCD_RST, 1);
sleep_ms(DISPLAY_INIT_SLEEP_TIME); /* Wait for display controller to complete initialization */
Reset(); /* Perform software reset to maintain default register state */
SendCommand(cmdSLPOUT, 0, 0); /* Disable sleep mode */
SendCommand(cmdCOLMOD, 0x05); /* Set color format and decoding*/
SendCommand(cmdINVON, 0, 0); /* Disable inversion */
SendCommand(cmdNORON, 0, 0); /* Enable normal mode */
SendCommand(cmdMADCTL, cmdMADCTL_RGB); /* Set pixel size */
uint8_t windowSize[] = { 0 >> 8, 0, DISPLAY_WIDTH >> 8, DISPLAY_WIDTH }; /* Set display window (note this is not safe for displays with sides not equal in size) */
SendCommand(cmdCASET, windowSize, 4);
SendCommand(cmdRASET, windowSize, 4);
SetPowerState(true); /* Enable display */
Вероятно читатель может спросить: «зачем выделять целых 115КБ под фреймбуфер, если можно использовать команды CASET/RASET и рисовать отдельные спрайты прямо в память дисплея?». Дело в том, что в таком случае скорость отрисовки будет падать обратно пропорционально размеру и числу рисуемых изображений. Если мы попытаемся нарисовать параллакс-фон, состоящий из трёх картинок с размерами 240x240, то нашим узким местом станет не только цена обращения к XIP-кэшу, но и производительность SPI-контроллера (который напрямую тактируется от системного PLL) и мы получим те самые 1-2 FPS. Кроме того мы потеряем возможность использования DMA и нам придётся ждать каждой транзакции на экран: это проблема многих «самодельных» консолей, которую, впрочем, можно решить обратившись к опыту предков — а именно PPU.
В своём проекте я решил активно задействовать DMA-контроллер для отправки фреймбуфера на дисплей. Концепция простая: мы указываем ему переслать фреймбуфер, начинаем подготавливать следующий кадр и если транзакция ещё не завершена - то дожидаемся её окончания, дабы картинка оставалась целостной. Однако если обновление логики следующего кадра завершается быстрее, чем DMA-контроллер успевает отправить сканлайны - мы можем получить эффект тиринга.
/* Setup DMA for SPI */
dmaChannel = dma_claim_unused_channel(true);
dmaConfig = dma_channel_get_default_config(dmaChannel);
channel_config_set_transfer_data_size(&dmaConfig, DMA_SIZE_8);
channel_config_set_dreq(&dmaConfig, spi_get_dreq(spi1, true));
channel_config_set_read_increment(&dmaConfig, true);
channel_config_set_write_increment(&dmaConfig, false);
...
if(!dma_channel_is_busy(dmaChannel))
{
uint8_t cmdByte = cmdRAMWR;
gpio_put(PIN_LCD_CS, 0);
gpio_put(PIN_LCD_DC, 0);
spi_write_blocking(spi1, &cmdByte, 1);
gpio_put(PIN_LCD_DC, 1);
dma_channel_configure(dmaChannel, &dmaConfig, &spi_get_hw(spi1)->dr, frameBufferInfo.Pointer, frameBufferInfo.Size, true);
}
Далее переходим к фактической отрисовке изображений. На данный момент поддерживается только один формат пикселей — RGB565, поскольку нет особого смысла использовать 8-битную палитру для изображений 32x32 (но есть смысл использовать 4х-битную, как на NES). Процесс рисования называется блиттингом и поскольку реализация полноценного альфа-блендинга слишком дорогая для реалтайм графики на микроконтроллерах, для описания прозрачности используется техника колоркеев.
Взято с pinterest
ColorKey — это как ChromaKey, но для описания прозрачного цвета используется только базовый цвет, а не цвет + порог допустимых цветов. Помните как в играх 90-х были картинки с розовым фоном цвета Magenta? Вот это оно самое :)
for(int i = 0; i < min(y + bitmap->Height, frameBufferInfo->Height) - y; i++)
{
CColor* bitmapScanline = &bitmap->Pointer[i * bitmap->Width];
CColor* scanline = &frameBufferInfo->Pointer[(y + i) * frameBufferInfo->Width + x];
for(int j = 0; j < min(x + bitmap->Width, frameBufferInfo->Width) - x; j++)
{
uint16_t sample = *bitmapScanline;
if(sample != bitmap->ColorKey)
*scanline = sample;
scanline++;
bitmapScanline++;
}
}
Рисование текста реализовано знакомым для Embedded-инженеров способом: шрифты описываются в формате 8x8, где 8 битов каждого байта обозначают наличие или отсутствие пикселя в текущей позиции. Такие шрифты не только занимают очень мало места, но их также очень легко и быстро рисовать, а также масштабировать под различные разрешения экранов. На данный момент я задумываюсь — стоит ли добавлять в консоль поддержку полноценного UTF-16, если учесть что основной таргет на русскоязычную аудиторию, где и CP866 хватает с головой?
Какой же дисплей чёткий...
❯ Ввод
Далее мы плавно переходим к реализации драйвера ввода. Как я уже говорил выше, все кнопки подключены к своим отдельным GPIO без использования сдвигового регистра или I/O Expander'а, что с одной стороны и хорошо (некоторые китайские производители реализовывают консоли с кнопками, основанными на матричном (!!!) принципе), а с другой — отъедает большинство GPIO у RP2040. Свободными пинами мы могли бы выполнять множество полезной работы: получать уровень заряда аккумулятора у Fuel Gauge, управлять уровнем подсветки с помощью ШИМ-контроллера и ключа, или, в конце-концов, сделать порт для подключения периферии... но нет так нет.
Сам по себе драйвер ввода до жути примитивный: он позволяет получить состояние отдельных кнопок, осей (как Input.GetAxis в Unity) и проверить, нажата ли хоть какая-то кнопка:
class IInputService : public ISystemService
{
public:
virtual EKeyState GetKeyState(EKeyCode keyCode) = 0;
virtual int GetAxis(EInputAxis axis) = 0;
virtual bool IsAnyKeyPressed() = 0;
};
Для удобства и портабельности BIOS'а между платами, кнопки геймпада маппятся к соответствующим GPIO в отдельной таблице трансляции, которая также содержит состояния этих самых кнопок:
// Should be layouted in order of EKeyCode enum
CButtonState ButtonMapping[] = {
{
PIN_KEY_LEFT
},
{
PIN_KEY_RIGHT
},
{
PIN_KEY_UP
},
{
PIN_KEY_DOWN
},
{
PIN_KEY_A
},
{
PIN_KEY_B
},
{
PIN_KEY_X
},
{
PIN_KEY_Y
},
{
PIN_KEY_LEFT_TRIGGER
},
{
PIN_KEY_RIGHT_TRIGGER
}
};
Дело в том, что в нашем проекте недостаточно иметь лишь одно булево: нажата-ли кнопка или нет, для компенсации дребезга кнопок у нас также реализуется задержка перед следующей проверкой и дополнительное состояние для удобства реализации меню — «только что отпущена».
void CInputService::Tick()
{
timeStamp = get_absolute_time();
for(int i = 0; i < ButtonMappingCount; i++)
{
CButtonState* buttonState = &ButtonMapping[i];
bool gpioState = !gpio_get(buttonState->GPIO); // Buttons are pull-up to high when not pressed
// Check if there was elapsed enough time
if(timeStamp > buttonState->LastStateChange)
{
if(buttonState->State == EKeyState::ksReleased)
buttonState->State = EKeyState::ksIdle;
if(buttonState->State == EKeyState::ksIdle && gpioState)
buttonState->State = EKeyState::ksPressed;
if(buttonState->State == EKeyState::ksPressed && !gpioState)
buttonState->State = EKeyState::ksReleased;
buttonState->LastStateChange = timeStamp + KEY_DEBOUNCE_THRESHOLD;
}
}
}
Таким образом, мы получаем куда более удобную подсистему ввода, чем условная битовая маска с обозначением каждой кнопки и ручной обработкой её состояний в игре...
EKeyState CInputService::GetKeyState(EKeyCode keyCode)
{
uint32_t code = (uint32_t)keyCode;
if(keyCode >= ButtonMappingCount)
return EKeyState::ksIdle; /* Maybe we should throw an exception? */
return ButtonMapping[code].State;
}
int CInputService::GetAxis(EInputAxis axis)
{
EKeyCode a = EKeyCode::keyLeft;
EKeyCode b = EKeyCode::keyRight;
if(axis == EInputAxis::inputAxisVertical)
{
a = EKeyCode::keyUp;
b = EKeyCode::keyDown;
}
return GetKeyState(a) == EKeyState::ksPressed ? -1 : (GetKeyState(b) == EKeyState::ksPressed ? 1 : 0);
}
А вот и результат:
❯ Запуск программ
Вот мы и подошли к, возможно, самой интересной подсистеме в нашем BIOS'е. Думаю многие читатели так или иначе интересовались тем, как же компилятор и линкер превращают исходный код и объектный файлы в пригодные для выполнения программы и библиотеки. Вопрос запуска нативных программ на микроконтроллерах интересовал и меня — я даже написал целых три статьи об этом: в первой мы поговорили о ESP32 и Xtensa, а во второй реализовали BinLoader путём реверс-инжиниринга и хакинга кнопочного телефона, а в третьей сделали полу-универсальный ElfLoader для нескольких моделей телефонов на разных платформах.
Но начнём мы с простого. Каждая программа делится на три основных секции:
.text — содержит в себе машинный код функций и так называемые Literal pools. Может быть как в ROM, так и в RAM. На системах, где есть возможность выполнять код и в ROM, и в RAM, есть отдельная секция - .iram.
.data — содержит инициализированные переменные, которые обычно попадают в оперативную память. Для статических констант есть отдельная секция, называемая .rodata.
.bss — содержит в себе не-инициализированные переменные, обычно это нули. В исполняемый файл секция .bss напрямую не записывается, остаётся лишь информация о том, каков её размер, а саму секцию затем выделит динамический линкер.
Куда попадут части программы определяет специальная утилита — линкер, которая на основе специального скрипта «раскладывает» данные по нужным секциям. Благодаря этому скрипту, мы можем, например, перенести часть функций в оперативную память для более быстрого исполнения или добавить в начало программы заголовок с описанием приложения.
В моём случае, я решил загружать игры в SRAM и дабы не реализовывать нормальный динамический линкер и релокации, решил выделить под игру фиксированный кусочек оперативной памяти объёмом в 128КБ. Для этого я отредактировал скрипт линкера Pico C SDK так, чтобы сразу после вектора прерываний шла наша программа:
. = ALIGN(4);
.ram_vector_table (NOLOAD): {
*(.ram_vector_table)
} > RAM
iram_program_reserve_size = 128K;
.iram_program (NOLOAD) : {
. = ALIGN(4);
PROVIDE(iram_program_origin = .);
. += iram_program_reserve_size;
} > RAM
.uninitialized_data (NOLOAD): {
. = ALIGN(4);
*(.uninitialized_data*)
} > RAM
Для компиляции программы также используется кастомный скрипт для линкера и особый Makefile, где после сборки программы мы копируем все её секции в выходной файл в «сыром» виде. Поскольку программа собирается под выполнение из конкретного адреса — пока речь идёт о переносимости только между одной аппаратной платформой. На RP2040, RP2350 и возможно STM32 такое «прокатит», но вот на других ARM-процессорах — большой вопрос!
OUTPUT_FORMAT("elf32-littlearm")
SECTIONS
{
. = 0x200000c0;
.program_info : {
*(.program_info*)
}
.text : {
*(.vtable*)
*(.text*)
*(.rodata*)
*(.data*)
*(.bss*)
}
/DISCARD/ : {
*(.ARM.*)
*(.comment*)
}
}
Каждое приложение, как и базовая система, предполагает использование ООП и поэтому представляет из себя реализацию класса IApplication. Для этого нам нужна некоторая runtime-поддержка: аллокатор, функция для создания экземпляра приложения, а также указатель на ISystem. Именно поэтому каждая программа должна экспортировать специальный заголовок, где содержится указатель на функцию-инициализатор:
#define PROGRAM_HEADER 0x1337
#define PROGRAM_INFO(name, clazz) int test; CAllocator* __Allocator; IApplication* __createInstance(CAllocator* allocator, ISystem* systemPtr) { __Allocator = allocator; return new clazz(systemPtr); } \
CProgramInfo __program_info __attribute__ ((section(".program_info"))) = { PROGRAM_HEADER, BIOS_VERSION, name, &__createInstance };
struct CProgramInfo
{
uint32_t Header;
uint32_t BIOSVersion;
CAnsiChar Name[32];
CreateApplicationInstanceFunction CreateApplicationInstance;
};
...
PROGRAM_INFO("Blink", CBlinkApplication)
Таким образом, для выполнения нашей программы и вызова её обработчиков событий нам достаточно лишь загрузить файл по адресу 0x200000c0 и создать экземпляр IApplication. Всё очень просто и понятно!
CAllocator allocator;
allocator.Alloc = malloc;
allocator.Free = free;
IApplication* app = ((CProgramInfo*)ptr)->CreateApplicationInstance(&allocator, System);
Но "моргалка" ведь слишком просто, согласитесь? Поэтому мы с вами напишем ремейк классической игры Змейка, которая работает в настоящие 60 FPS!
❯ Заключение
Вот таким нехитрым образом я понемногу реализовываю свою мечту детства: «андерграунд" консоль собственной разработки. Конечно здесь ещё много чего нужно доделывать перед тем, как начинать разводить свою плату, но начало ведь положено! В контексте GamePi13, я считаю что моя реализация SDK для консоли всё таки немного лучше, чем то, что предлагает производитель «из коробки».
Я понимаю что мой не совсем трушный эмбеддерский подход может вызвать разные ощущения у читателей: так что приглашаю всех заинтересованных в комментарии, обсудим с вами «сломанный Branch-prediction из-за виртуалов», «UB из-за того, что порядок указателей на реализации в VMT может отличаться» и «какого фига игры у тебя оказались в SRAM, а высокопроизводительный код на Flash, если у XIP кэш всего в 16КБ!».
А если вам интересна тематика ремонта, моддинга и программирования для гаджетов прошлых лет — подписывайтесь на мой Telegram-канал «Клуб фанатов балдежа», куда я выкладываю бэкстейджи статей, ссылки на новые статьи и видео, а также иногда выкладываю полезные посты и щитпостю. А ролики (не всегда дублирующие статьи) можно найти на моём YouTube канале.
Если вам понравилась статья...
И у вас появилось желание что-то мне задонатить (например прикольный гаджет) - пишите мне в телегу или в комментариях :) Без вашей помощи статьи бы не выходили! А ещё у меня есть Boosty.
Помните мою статью про самую дешевую игровую консоль - Sup, и о её самой главной тайне?
Так вот, я написал вендору чипсетов и спустя неделю мне ответили! Производитель аппаратных клонов Денди не только жив, но и до сих пор занимается доработкой чипов и их кристаллы действительно всё ещё производятся специально для таких консолей.
Судя по голосованию на всех платформах, многие гики потенциально заинтересованы в подобном SoC для использования в качестве экзотического микроконтроллера с продвинутыми графическими и аудиовозможностями.
В письме мне ответили, что возможно компания хотела бы выйти на рынок DIY-щиков, но необходимо проанализировать спрос рынка... так что, всех DIY'щиков приглашаю голосовать ниже, но сначала приведу ТТХ чипсета:
Ядро: 6502-совместимое, частота 5 мегагерц, теоретически можно разогнать ещё выше. Также присутствуют расширения АЛУ для возможности умножения и деления 16-32х битных чисел.
Оперативная память: 8 для процессора и 4 для PPU
Постоянная память: Шина 8080 для подключения NOR и ROM-памяти, а также нативная поддержка SPI-флэшек.
Графика: PPU NES с расширенной палитрой, поддержка вывода изображения через TV-Out (тюльпаны) и на ЖК-дисплеи от телефонов.
Периферия: SPI, I2C, UART, АЦП, 56 GPIO. Данные на основе даташитов для более старых моделей, возможно сейчас ещё что-то добавилось.
И ориентировочный формат:
Наверняка многие читатели слышали о самой дешевой консоли на маркетплейсах — «Sup». На первый взгляд, это устройство — чудо чудное: цветной дисплей приличного разрешения, целых 500 игр в комплекте, аккумулятор и даже дополнительный геймпад, и всё это за какие-то 400 рублей в розницу.
Обычный человек просто подумает мол «очередной масс-маркет по типу Тетриса» и пройдет мимо. Однако моя гиковская душа очень хотела узнать, в чём же заключается тайна самой дешевой консоли на Озоне и я решил заглянуть «под капот»… Поверьте, внутри гораздо интереснее, чем кажется на первый взгляд!
Консоль Sup заполонила виртуальные полки магазинов примерно в 2019 году и сразу же стала мегахитом. Полноценная ретро-консоль с кучей встроенных игр всего за 300–400 рублей явно метила в конкуренты «Тетрису» по массовости, однако в технологическом плане была куда более продвинутой, чем её предшественник из 90-х. Несмотря на то, что сейчас Sup, вероятно, одна из самых продаваемых ретро-консолей, её богатая история тоже тянется с тех самых 90-х годов…
Как известно, основные игры в Sup — это различная классика времен NES, разбавленная играми «собственной» китайской разработки по типу портов Angry Birds и хаков уже существующих игр. С учетом того, что самопальные игры зачастую более «цветастые», чем родные с NES, у многих складывается впечатление, что это самый обычный эмулятор, а особо пытливые умы при разборке находили микросхему флэш-памяти и все вопросы касательно реализации у них отпадали. Но первое впечатление порой очень обманчивое, ведь Sup — аппаратный клон NES! Но давайте по порядку.
История разработки клонов Famicom (далее по тексту — «Фамиклонов») берёт своё начало примерно в 1990–1991 году. В те годы, микроэлектронная промышленность Тайваня развивалась семимильными шагами: в стране активно выпускались x86-компьютеры, ноутбуки в разных конфигурациях, различная оргтехника и всё это по относительно доступной цене. Помимо устройств на готовой компонентной базе, в Тайване также разрабатывались и производились микросхемы — как клоны существующих чипов, так и собственные разработки. Самыми крупными производителями были UMC и Holtek.
Завод UMC в Тайване
Holtek в основном производил ASIC'и для конкретных задач (к примеру контроллеры PS/2 и USB-клавиатур), а также очень недорогие 4х-битные микроконтроллеры с масочной ROM-памятью, которые использовались в устройствах по типу органайзеров и наручных часов. Однако венцом творения гаджетов на базе МК от Holtek можно считать культовую консоль нашего детства — ведь HT-943E5 использовался в том самом Brick Game!
Фото от @Azya
UMC же в те годы занималась клонами оригинальной японской консоли. В её R&D центрах были разработаны клоны центрального процессора Ricoh RP2A03 на ядре 6502, а затем и PPU («видеокарта», предок современных GPU) 2C02G, что позволило выпускать «фамиклоны», которые довольно сильно были похожи на оригинальную консоль. Это были те самые «трушные» многочиповые «Денди», за которыми гоняются коллекционеры!
Сводный братик NES, собранный на почти стандартной компонентной базе
Однако как я уже сказал выше, полупроводниковая промышленность Тайваня тогда очень быстро развивалась и ближе к середине 90-х годов, UMC освоила настолько малый техпроцесс, что умудрилась засунуть вообще весь NES в один-единственный чип UM6578F, который называется системой на кристалле (SoC). Только представьте себе: процессор, звуковой чип, видеочип, память — и всё это в небольшом кристалле, который стоит относительно недорого... Это настоящее технологическое чудо!
Одна из первых известных систем на кристалле — UM6578F, которая также производилась и другими компаниями (по лицензии?)
Но UMC и на этом решили не останавливаться. UM6578F был не просто клоном оригинального Famciom, это был серьёзный апгрейд оригинальной аппаратной платформы. Например, добавилась поддержка 16-цветного режима для спрайтов, полноценного 8-битного PCM-звука (к примеру, почти вся MP3-музыка кодирует 16-битный PCM-поток) помимо классических генераторов волн, а также расширен объём оперативной и видеопамяти до целых 10КБ — это в ПЯТЬ раз больше, чем на оригинальной консоли! Причины такого апгрейда просты: во-первых, в те годы власти Китая ввели заградительные пошлины на импорт электроники, поэтому домашние x86-компьютеры были доступны отнюдь не всем. Им на замену пришли относительно доступные компьютеры по типу «Сюбора», которые совмещали в себе как клавиатуру и набор обучающего софта вместе с интерпретатором BASIC'а, так и игровую консоль. А во-вторых — небольшие китайские компании выпускали свои собственные коммерческие игры без лицензии от Nintendo и расширенные возможности новых фамиклонов могли значительно увеличить комплексность выпускаемых игр.
Относительно современный «Сюбор-ноутбук» — примерно 2001 год
Время шло, наступил 2001 год, клоны SEGA и Famicom не теряли своей актуальности и продолжали взращивать второе поколение — детей 90-х, а в городе Чжубэй появляется компания VRT Technology, которая занимается разработкой и проектированием фамиклонов. Но в отличие от конкурентов, VRT в плане апгрейдов оригинальной платформы пошла ещё дальше и превратила NES в нечто вроде очень продвинутого микроконтроллера: их чипы научились выводить изображение не только на телевизор, но и на ЖК-дисплеи, был серьёзно доработан АЛУ — появилась возможность аппаратного умножения и ДЕЛЕНИЯ (чего не было даже в ARM) 16-битных чисел, ядро 6502 было разогнано с 1 МГц до целых 5, объём ОЗУ увеличен с 2 КБ до 8 для основного процессора и 4 для PPU, а также были добавлены контроллеры SPI, UART, АЦП и GPIO.
В одной из ревизий чипа даже есть возможность работы с SPI-флэшками!
Ко всему прочему, VRT умудрилась сделать некое подобие MMU с шиной OneBUS, благодаря чему стало возможным хранить игры на самой обычной параллельной ROM или NOR-памяти, без необходимости установки отдельного памяти чипа для PPU. Компания даже выпустила отдельный SDK для своих консолей с компилятором C, статическими библиотеками для общения с периферией и специальным эмулятором. Но вот нюанс — все чипы этого производителя поставлялись без корпуса, а приобрести их в свободной продаже нельзя, поэтому определить точную маркировку сложно...
Скриншот из документации на плату для разработчиков. Как видно, даже здесь процессор поставляется в виде System on Module
Но казалось бы... прошло столько лет, NES давным-давно неактуальна и VRT наверняка сменила профиль или вообще закрылась, а её чипы можно найти только в старых клонах и в Sup наверняка используется что-то другое... Если бы не одно но: судя по документам, бескорпусные чипы поставляются в блистере и имеют определенный срок годности. Дело в том, что они не припаиваются к плате, а приклеиваются «пузом» к текстолиту, затем их пины привариваются к дорожкам, а далее они покрываются компаундом для защиты от внешних факторов. У самих кристаллов срока годности нет, однако у клея — около 3х-4х месяцев, после чего кристаллы можно выбрасывать (в случае чипов VRT конечно, не думаю что там оптовая цена превышает 3-4 рубля за штучку), так как вряд-ли кто-то будет выделять целую линию для нанесения нового клеевого слоя на копеечные кристаллы...
Та самая каелька
В начале года я рассказывал об ещё одном китайском чуде инженерной мысли — относительно новом телефоне Kechaoda с встроенным аппаратным клоном NES, где использовался точно такой-же чип от VRT, только с поддержкой SPI-флэшек и дисплеев с шиной 8080. Учитывая огромные объёмы производства Sup и подобных ей консолей, можно сделать вывод что VRT всё ещё существует, заказывает производство новых партий и возможно даже продолжает дорабатывать свои клоны NES... Спустя 40 лет после выхода оригинальной консоли!
А далее по традиции блога я предлагаю разобрать Sup и посмотреть, что же у него находится под капотом. Уверяю вас, мой экземпляр в какой-то степени уникален!
Консоль разбирается очень просто: необходимо вытащить аккумулятор и выкрутить 6 винтиков с обратной части устройства, после чего крышка отходит без каких либо защелок. Внутри нас встречает толстенная однослойная плата, которая, к слову, довольно грамотно разведена инженерами. В наши дни, для серийных ЭВМ это большая редкость, но здесь авторы решили максимально сэкономить, местами используя большие резисторы-нулевики в качестве перемычек.
С правой верхней стороны расположен блок, отвечающий за питание консоли и зарядку аккумулятора. Здесь всё стандартно для таких простых устройств: защитный диод на VBat, линейный регулятор на 3.3В в корпусе SOT-23 под маркировкой 662K, а также парочка ключей, вероятно составляющие часть схемы чарджера. Схема зарядки аккумулятора здесь, судя по всему, настоящая и его основная логика расположилась в кристалле под компаундом.
Опытные читатели уже могли заметить уникальность моей ревизии: вместо чипа памяти в BGA-корпусе поверх SoM, здесь используется самая обычная NOR-флэшка в корпусе TSOP58 объёмом в 16МБ. Это значит, что теоретически я могу её сдуть, слить дамп с помощью программатора и попытаться подсунуть в него свои игры... Если вам был был бы интересен контент такого формата — дайте знать в комментариях!
Чуть ниже флэши расположилось сердце устройства — неизвестный кристалл, который с вероятностью 99% разработан VRT. Дело в том, что безвредно декапсулировать такие чипы нельзя, они с большой вероятностью трескаются, так что конкретную модель чипа мы возможно сможем узнать только изучив дамп. Левее процессора расположился кварц на 20МГц, который тактирует остальную периферию.
В качестве дисплея здесь используется безымянная матрица разрешением примерно в 240x320 с параллельным интерфейсом MIPI DBI (8080). Иными словами, здесь используется такой-же дисплей, как в классических кнопочных телефонах и DIY-самоделках. Я не пробовал подключать этот дисплей к микроконтроллер, но уверен, что если посидеть пару дней с лог. анализатором, то можно без проблем найти все сигнальные линии параллельной шины по стандартизированным командам DBI :)
Также вы могли заметить MicroUSB-разъём с верхней части устройства, который используется для зарядки. Однако здесь используются и три дополнительные сигнальные линии — D+, D- и ID, однако служат они для подключения второго геймпада, а не к ПК. Фактически это не USB, а сигнальные линии оригинального геймпада NES — Latch, Data и Clock.. такое вот нецелевое, но практичное использование разъема!
И... это всё! Да, вот такая простейшая, но при этом достаточно продуманная схемотехника и конструктив. Несмотря на дешевизну, убить этот гаджет в аппаратном плане очень сложно, его самое слабое место — это дисплей.
После включения консоли нас встречает меню выбора языка в многоигровке. Список игр довольно обширный и ограничивается не только классикой, зачастую под непонятными названиями, но и самопальными китайскими играми. Однако здесь есть одна важная особенность: поскольку клоны VRT реализуют шину OneBus, они поддерживают только маппер MMC3, что здорово снижает число поддерживаемых игр.
В большинстве игр копирайты намеренно подрезаны, скорее всего чтобы можно было без проблем продавать консоли на маркетплейсах. Поскольку это аппаратный клон, здесь нет инпутлага и всё работает точь в точь как на оригинальной консоли, в том числе и игры для других регионов. Например ром Super Mario Bros. здесь почему-то от другого региона, из-за чего работает слишком быстро.
Звук у консоли в целом неплохой, однако у части Sup'ов не работает треугольный канал APU, из-за чего звуки и музыка в некоторых играх искажены. С чем это связано - доподлинно неизвестно, но думаю вы и сами понимаете, что контроль качества у таких чипов наверняка минимальный!
Поскольку у консоли нет Fuel Gauge (микросхемы для определения уровня заряда аккумулятора, обычно она сложнее чем просто АЦП-вольтметр) как класса, при разрядке АКБ сначала начинает тухнуть подсветка, затем утихать звук, а в произвольные моменты времени консоль может просто зависнуть (сохранений тут нет). Забавно то, что подсветка подключена напрямую к VBat (плюсу аккумулятора) и её яркость плавно снижается, обратно пропорционально заряду аккумулятора, однако такое решение "в лоб" также прямо пропорционально напряжению АКБ увеличивает потребление. Если у вас меткий глаз - сможете определить уровень заряда по тусклости :)
В процессе работы консоль потребляет аж 200мА при самом высоком уровне звука на среднем заряде аккумулятора, 170мА при 10% громкости и будет потреблять ещё меньше, если снизить подсветку дисплея путем установки линейного регулятора с выходным напряжением в 3.3В (потребление снизится до ~130мА, добавив минимум час игры от АКБ). Само процессорное ядро довольно экономичное, так что я до сих пор не понимаю, почему его не выпустили как конкурента атмеги с продвинутыми графическими и звуковыми возможностями. Родной аккумулятор хоть и имеет размеры BL-4C, на практике имеет емкость в 300-400мАч максимум, поэтому есть смысл поискать оригинальный аккумулятор от Nokia: с ним консоль сможет проработать 5-6 часов без подзарядки.
Минимальное напряжение, при котором консоль работает стабильно - 2.6В, практически без подсветки. Учитывая дропаут на линейном регуляторе, фактически процессор способен работать и на 2.4В, а возможно и ещё ниже!
В заключении мне хотелось бы сказать, что Sup — это по факту шедевр инженерной и технологической мысли. Судите сами: полноценная ЭВМ с цветным дисплеем, звуком, памятью, большим количеством игр и даже аккумулятором, и всё это буквально за 5$. Большинство читателей наверняка посчитает это устройство одноразовым мусором, однако для меня, как для прожженного гика, это маленькое портативное чудо!
Надеюсь, вам было интересно узнать тайну Sup'а. О том, что в руках у вас не эмулятор, а настоящий аппаратный клон, только очень сильно прокачанный наверняка известно не всем...
Если вам понравилась статья и вы хотите помочь мне финансово, можно воспользоваться формой доната выше. Донаты идут на контент - оборудование и всякие DIY-гаджеты. А ещё мне можно подарить какой-нибудь прикольный гаджет, о котором выйдет статья. Доставку я оплачу :)
А если вам интересна тематика ремонта, моддинга и программирования для гаджетов прошлых лет — подписывайтесь на мой Telegram-канал «Клуб фанатов балдежа», куда я выкладываю бэкстейджи статей, ссылки на новые статьи и видео, а также иногда выкладываю полезные посты и щитпостю. А ролики (не всегда дублирующие статьи) можно найти на моём YouTube канале.
Очень важно! Разыскиваются девайсы для будущих статей!
Друзья! Для подготовки статей с разработкой самопальных игрушек под необычные устройства, объявляется розыск телефонов и консолей! В 2000-х годах, китайцы часто делали дешевые телефоны с игровым уклоном — обычно у них было подобие геймпада (джойстика) или хотя бы две кнопки с верхней части устройства, выполняющие функцию A/B, а также предустановлены эмуляторы NES/Sega. Фишка в том, что на таких телефонах можно выполнять нативный код и портировать на них новые эмуляторы, чем я и хочу заняться и написать об этом подробную статью и записать видео! Если у вас есть телефон подобного формата и вы готовы его задонатить или продать, пожалуйста напишите мне в Telegram (@monobogdan) или в комментарии. Также интересуют смартфоны-консоли на Android (на рынке РФ точно была Func Much-01), там будет контент чуточку другого формата :)
Кроме того, я ищу подделки на брендовые смартфоны 2009-2015 года выпуска. Многие из них работают на весьма интересном железе и об их моддинге я бы мог сделать интересный контент. Особо разыскиваются подделки Apple iPhone и HTC (по типу HD2 и Touch Diamond 2) на Windows Mobile и Android, а также Samsung Galaxy. Также представляют моддерский интерес первые смартфоны Xiaomi из серии Mi, Meizu (ещё на Exynos) и телефоны Motorola на Linux (например, EM30, RAZR V8, ROKR Z6, ROKR E2, ROKR E6, ZINE ZN5, о которых я хотел бы подготовить отдельные статью и видео, поскольку они работали на очень мощных для своих лет процессорах, поддавались серьезному моддингу и были способны запустить даже Quake.
Большое спасибо читателям и зрителям за подгоны, без вас контент бы не выходил!
Закрыл свой очередной маленький гештальт:)
Своей "dendy" у меня небыло в пользовании уже больше 25 лет. Недавно попался лот со всяким ретрохламом и среди него была она - Symba's со встроенными играми, примерно 2013 год.
Не "оригинал" конечно, но поковыряться в железе и вспомнить детство - самое то.
Состояние - убит, но не сломлен:)
Как итог - отмыты приставка и джойстики. Замененил шлейфы и провода, напечатал недостающие детали.
Получился нормальный настольный экземпляр, иногда вспомнить детство. :)
Но когда я сел поиграть, пришло осознание - что не моё это, сега лучше 🤣
Мой ТГ
Осторожно: эта статья точно будет интересной, ведь в ней мы смоделируем, спроектируем и запрограммируем своё видение N-Gage 2! Я очень старался сделать статью интересной даже для тех читателей, кто не разбирается в теме 3D-печати и программирования микроконтроллеров :)
Я очень люблю ретро-игры и игровые консоли. Иногда я люблю позалипать в какую-нибудь классику с NES, Sega Mega Drive или, например, PSP. Однако особое место в моём сердечке занимает игровой телефон Nokia N-Gage, который, к сожалению, не получил продолжения, как и его более современный собрат — Sony Ericsson Xperia Play. Недавно я пересматривал свою коллекцию девайсов и обнаружил на полочке Galaxy S4 Mini. И тут я подумал: а что если...
Думаю многие мои давние читатели заметили, что примерно четверть статей в моем блоге так или иначе касается вопроса игр и портативного гейминга. За почти три года существования блога, мы с вами успели не только поностальгировать и потыкать игровые гаджеты, но и отремонтировать часть из них, узнать как разрабатывались и работали «под капотом» игры и даже попытались спроектировать свою собственную игровую консоль!
Почти два года назад в моей голове уже возникала идея сделать «портативку» из полурабочего гаджета. В то время я хотел рассказать читателям о том, что многие старые девайсы можно использовать в качестве одноплатных компьютеров и HMI-панелей благодаря наличию пятачков с шиной UART на плате, с которой можно легко взаимодействовать в Android-приложениях! В качестве реального примера использования я взял планшет с нерабочим тачскрином, подключил через UART геймпад, разработанный на базе RP2040 и написал программу, которая читает UART и инжектит состояние кнопок напрямую в драйвер ввода:
Именно для того чтобы закончить этот проект я приобрел себе Ender3 V2
С тех пор прошло много времени, в моей коллекции появились некоторые серийные игровые-смартфоны и даже прототипы никогда не выходивших устройств. Однако по своей натуре я прожженный гик, у меня постоянно чешутся руки что-то запрограммировать и собрать самому.
Недавно я осматривал свою коллекцию гаджетов и на полочке с смартфонами Samsung обнаружил легендарный Galaxy S4 Mini, который мне когда-то дарил один из читателей. У смартфона отсутствовала задняя крышка, средняя часть корпуса была немного ободрана, однако несмотря на почтенный возраст в 12 лет, смартфон продолжал нормально работать и даже AMOLED-матрица у него ничуть не выгорела!
И тут в моей голове что-то щёлкнуло: я вспомнил что S4 Mini — смартфон с довольно неплохим железом для эмуляторов и очень крутым даже по современным меркам AMOLED дисплеем. На моей памяти, в мире не выходило ни одного серийного игрового телефона в монолитном корпусе с OLED-матрицей, а тут ещё рядом лежал оригинальный N-Gage, который я недавно купил в утиле и восстановил после воды. Я взвесил все за и против, прикинул схему и конструктив будущего устройства и принялся мастерить...
Всё начинается с кубика...
Перед тем как начать работу, нам необходимо определится с тем что нам нужно будет сделать для реализации такого гаджета на практике:
В первую очередь, нам необходимо продумать как геймпад будет общаться с нашим устройством. За исключением моего хака с UART'ом, у нас есть два варианта: первый — микроконтроллер выполняет роль USB-HID устройства (прикидываясь клавиатурой) и подключается к OTG-хосту гаджета. Среди плюсов этого подхода можно выделить низкую задержку, однако минусов гораздо больше. Например, далеко не все старые устройства поддерживают OTG и могут быть проблемы с реализацией одновременной работы USB-хоста и зарядки (зависит от реализации OTG в каждом конкретном устройстве). А второй вариант — это Bluetooth-HID, который работает почти с любыми Android устройствами, однако потребляет чуть больше энергии и может иметь небольшой инпут-лаг.
После расследования выяснилось, что у S4 Mini OTG нет, а значит остается лишь один вариант — Bluetooth. Среди дешевых микроконтроллеров с BT выделяется лишь ESP32, который стоит буквально три пачки доширака. Его мы с вами и выберем.
Далее нам необходимо придумать внешний вид устройства. Изначально мне хотелось, чтобы гаджет по форм-фактору и эргономике напоминал оригинальный N-Gage. Но поскольку мне не хотелось делать слишком длинную «колбасу» и бюджета по свободному пространству в корпусе откровенно не хватало, пришлось пойти на некоторые ухищрения — например, расположить блок кнопок вертикально.
Теперь самое сложное — смоделировать более-менее адекватный корпус и подогнать детали так, чтобы их хоть как-то можно было состыковать и закрепить. Я в 3D-печати новичок, а в вопросах проектирования корпусов — вообще неотесанный селюк, поэтому мне оставалось лишь смоделировать в блендере выпуклый меш, импортировать в TinkerCad и затем CSG'шками вырезать в нём дырки отверстия.
И самое легкое — написать прошивку для микроконтроллера и спаять всё вместе, дабы наши кнопочки не просто прикольно щелкали, но и на практике работали в системе!
Звучит как приключение на 5 минут. Но вот как на практике? Давайте посмотрим!
В первую очередь я сел моделировать корпус устройства и прикидывать его размеры. В TinkerCad'е CSG'шками сделать корпус по референсу проблематично (по крайней мере для меня), поэтому я решил смоделировать основу в блендере. Я взял рендеры N-Gage с фронтальной части, установил камеру в ортографическую проекцию и принялся повторять контур корпуса оригинального телефона. После этого я создал грани на одной половинке корпуса, продублировал все вершины и отзеркалил их с другой стороны. Таким образом, корпус получился одинаковым (кривым) с обеих сторон.
Далее я убрал лишние рёбра посередине и вытянул корпус по оси Z с помощью инструмента Extrude. Теперь это напоминает поделку семикласника на уроке обращения с рубанком:
Внимательные читатели могли заметить косяк, который из-за затенения я не замечал вплоть до первой печати
Дальше я использовал инструмент Inset faces, дабы создать новые грани на плоскости и вытянуть из них фронтальную часть корпуса. Таким образом, мы получаем ровные и мягкие стенки, которые затем можно смягчить ещё больше с помощью модификатора Bevel:
Однако сейчас геометрия нашего корпуса полая, внутри неё ничего нет. Чтобы добавить внутренние стенки, мы воспользуемся модификатором Boolean (CSG) в блендере: дублируем геометрию нашего корпуса, немного уменьшаем её по оси X и Y (чем меньше дубль, тем толще будут стенки), и затем сдвигаем немного вниз, а затем на основном объекте корпуса добавляем модификатор Boolean, устанавливаем режим Difference, ставим дубль в качестве второго объекта и жмём Apply. Теперь у нашего корпуса внутри отнюдь не пустота!
Далее экспортируем модель в STL, импортируем её в TinkerCad и берём линейку в зубы. Пора замерять габариты нашего устройства и размер дисплея.
Поскольку S4 Mini уж очень скругленный, я аппроксимировал его размеры до прямоугольника (ни слово про мыло!). Над этим прямоугольником я расположил прямоугольник размером с дисплей, который и вырежет нам пространство для этого самого дисплея:
На этом подготовка болванки корпуса закончена, переходим к реализации геймпада.
Изначально я решил распаять все кнопки геймпада на двух макетных платах — первая с «стрелками» будет установлена слева, вторая с кнопками действий — справа. Поскольку место в корпусе сильно ограничено, текстолит я решил распилить: для этого я сделал насечки канцелярским ножом и затем руками отломал ненужные части.
В качестве кнопок я решил использовать обычные DIP-микрики, поскольку в моем городе не было ни плоских SMD-кнопок, ни тем более мягких мембранных. А ещё они прикольно щёлкают. Я, как пользователь механической клавиатуры, гарантирую это!
Ошметки текстолита можно счистить надфилем или просто подровнять канцелярским ножом
Для реализации обработки кнопок есть несколько подходов:
«В лоб»: самый простой и самый подходящий для геймпадов. На один входной GPIO микроконтроллера вешается подтягивающий резистор и кнопка, которая коммутирует массу. Главный плюс такого подхода — возможность зажимать сколько угодно кнопок одновременно, а если ножек на микроконтроллере не хватает, то всегда можно использовать сдвиговый регистр!
На резисторах: требует наличия ADC в микроконтроллере. Принцип работы заключается в том, что на выходе каждой кнопки установлен резистор определенного номинала. В прошивке микроконтроллера опытным путем задается диапазон значений ADC, который соответствует нажатой кнопке. Такой подход иногда используется в планшетах для обработки кнопок по типу включения, громкости и т.п.
Матричный: используется в клавиатурах, в том числе и в телефонах. Позволяет реализовать 16-кнопочную клавиатуру всего с 8-ю сигнальными линиями, однако с таким подходом нельзя нажимать сразу несколько кнопок кнопок в одной «линии» одновременно. Этим и страдали некоторые китайские игровые консоли, на которых нельзя было одновременно зажать вверх и влево или A и B!
Поскольку у нас всего 10 кнопок, мы выберем первый подход. Для этого мы подведем общую массу к нашей макетке, от которой пустим перемычки (дорожки) к каждой кнопке, а с другой стороны подпаяем провода, которые пойдут на входы в наш микроконтроллер.
После этого я наконец-то напечатал первую примерочную болванку, в которой всё помещалось идеально! Время от раздумий до первой болванки — ~5-6 часов:
Если с моделированием корпуса у меня проблем не возникло, то стыковка деталей — вопрос совершенно другой, особенно для человека без опыта проектирования корпусов. В какой-то момент времени я даже впал в депрессию и сломал парочку болванок, хотя планировал их оставить в коллекции на память. Что-ж, будет памятью о моей вспыльчивости:
Сначала я решил сделать толкатели кнопок. Для «стрелок» я решил сделать классическую крестовину в духе GBA, а кнопки действий решил сделать цилиндрическими. Здесь в целом ничего сложного: подгоняем размеры толкателей к размерам кнопок, делаем у них небольшую выемку снизу, которая будет «шляпкой» для самих кнопок, а также добавляем «юбку» по бокам как ограничитель, дабы они не выпадали из корпуса:
А она ей как раз!
С крестовиной всё чуточку сложнее: сначала я сделал монолитную в стиле GameBoy, однако из-за того что расстояние между кнопками относительно маленькое, при нажатии на стрелку иногда нажималась и вторая кнопка. Поэтому я решил её разделить на несколько частей, оставив характерный рельеф посередине для лучшей тактильности. Я печатал много разных вариантов: подгонял зазоры для уменьшения люфта и добавлял тактильные выемки, однако остановился на классическом варианте. Далее встал вопрос как закрепить плату с геймпадом с обратной части корпуса. Я долго думал и прикидывал варианты: хотел и саморезы вкручивать, и гайки вплавлять, но потом придумал что самым лучшим и надежным решением будут салазки приклеенные на дихлорэтан, которые при желании можно снять не ломая корпус, но которые будут хорошо выдерживать постоянное усилие со стороны игрока!
Мне кажется что это невероятный говнокод и костыль от мира инженеров. Напишите своё мнение на этот счёт в комментариях.
Когда зазоры были подогнаны, я принялся моделировать заднюю крышку. Дабы она не выбивалась из общего стиля, я сделал её из фронтальной части корпуса: продублировал, отменил все CSG-операции характерные для основного корпуса и обрезал стенки одним большим кубиком.
Нарезаем модель в слайсере и печатаем! Как по мне, получилось очень даже стильно. Да, кто-то скажет, мол, видно, что это колхоз, не Industrial-grade, но как по мне для самоделки вполне на уровне!
На этом разработка корпуса наконец-то закончена!
Теперь, когда корпус нашего устройства готов и элементы в нём более-менее стыкуются, можно перейти к написанию прошивки. Как я уже говорил ранее, в качестве микроконтроллера я решил выбрать ESP32 благодаря копеечной цене и наличию неплохого BT-стека:
В качестве основы я взял официальный сэмпл BT HID-устройства с гитхаба Espressif. Собрав прошивку и протестировав что всё работает нормально, я принялся адаптировать её под свои задачи. Сначала я написал код для опроса кнопок: устанавливаем GPIO в режим входа с подтяжкой к высокому уровню, затем по запросу итерируемся по массиву с GPIO и заносим состояние кнопок в отдельный массив:
uint8_t input_gpio_mapping[] = {
INPUT_GPIO_LEFT,
INPUT_GPIO_RIGHT,
INPUT_GPIO_UP,
INPUT_GPIO_DOWN,
INPUT_GPIO_A,
INPUT_GPIO_B,
INPUT_GPIO_C,
INPUT_GPIO_D,
INPUT_GPIO_E,
INPUT_GPIO_F
};
uint8_t input_key_states[INPUT_KEYS_COUNT];
void input_initialize_hw()
{
for(int i = 0; i < INPUT_KEYS_COUNT; i++)
{
gpio_reset_pin(input_gpio_mapping[i]);
gpio_set_direction(input_gpio_mapping[i], GPIO_MODE_INPUT);
gpio_set_pull_mode(input_gpio_mapping[i], GPIO_PULLUP_ONLY);
}
}
void input_update_key_state()
{
for(int i = 0; i < INPUT_KEYS_COUNT; i++)
input_key_states[i] = !gpio_get_level(input_gpio_mapping[i]); // TODO: Implement timestamp-based debouncing
}
У любых механических кнопок есть особенность, которая называется дребезг. Случается она в момент когда мы отпускаем кнопку, но при этом размыкатель ещё не полностью поднялся в крайнее верхнее положение. Бороться с этим можно по разному, самый простой способ — программный, когда мы обновляем состояние кнопки только когда прошло определенное время (измеряемое в миллисекундах) с момента прошлого апдейта.
Все HID-устройства описываются специальным дескриптором, однако формат пакетов с репортами о состоянии устройства у них очень сильно отличается: мышки передают ускорение по осям X и Y, а также состояние кнопок, клавиатуры передают до 8-нажатых клавиш одновременно (наследие PS/2), а у геймпадов целый ворох стандартов (DirectInput, XInput... чего только нет. Кстати именно поэтому внешние геймпады обычно имеют несколько режимов). Алгоритм отправки репортов очень прост: 60 раз в секунду проверяем состояние кнопок, если какие-то нажаты — заполняем буфер с нажатыми клавишами и затем отправляем репорт хост-устройству.
// Internal input keycode mapping to HID
int hid_key_mapping[] = {
HID_KEY_DOWN_ARROW,
HID_KEY_LEFT_ARROW,
HID_KEY_UP_ARROW,
HID_KEY_RIGHT_ARROW,
HID_KEY_Z,
HID_KEY_LEFT_GUI,
HID_KEY_V,
HID_KEY_ENTER,
HID_KEY_C,
HID_KEY_X
};
uint8_t hid_report[8];
vTaskDelay(1000 / portTICK_PERIOD_MS);
while(1) {
input_update_key_state();
vTaskDelay((1000 / 60) / portTICK_PERIOD_MS);
if (sec_conn) {
int hid_report_offs = 0;
memset(&hid_report, 0, sizeof(hid_report));
// Not more than 8 keys pressed at once
for(int i = 0; i < INPUT_KEYS_COUNT; i++)
{
if(hid_report_offs == 8)
break;
if(input_key_states[i])
{
hid_report[hid_report_offs] = hid_key_mapping[i];
hid_report_offs++;
}
}
esp_hidd_send_keyboard_value(hid_conn_id, 0, &hid_report, hid_report_offs);
}
}
Вуаля! Всё работает идеально!
Мы уже почти дошли до финала, осталось лишь чуть-чуть доработать прошивку смартфона! Для этого, его сначала необходимо рутировать: ставим CWM через Odin и устанавливаем SuperSU!
Поскольку кнопку включения я не предусмотрел в корпусе, было решено реализовать автостарт устройства от зарядки — прямо как на айфоне! Большинство смартфонов при отображении анимации зарядки на самом деле загружают ядро Linux и запускают специальную программу. Если эту программу подменить на перезагрузку в обычный режим — мы получим автостарт устройства!
На смартфонах Samsung за это отвечает бинарник /system/bin/lpm или же /system/bin/playlpm. Изначально я хотел сделать жёсткую ссылку на программу reboot, которая не работала пока не были запущены какие-то Samsung'овские службы. Затем я узнал что есть возможность напрямую направить ядру запрос о перезагрузке устройства с помощью sysrq.
Далее был написан простенький скрипт:
#!/system/bin/sh
echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger
Который тоже не работал. И я понял что lpm нужно подменять другой самопальной программой. Так была написана и собрана с помощью NDK вот такая мелкая утилита, с которой уже всё заработало:
int main(int argc, char** argv)
{
system("echo 1 > /proc/sys/kernel/sysrq");
system("echo b > /proc/sysrq-trigger");
}
Далее необходимо было решить вопрос с виртуальными кнопками: поскольку в корпусе консоли виден только дисплей смартфона без кнопки Home, нам нужен был способ как-то управлять системой. Для этого было достаточно лишь пропатчить build.prop и добавить qemu.hw.mainkeys=0. В S4 Mini программные кнопки работают немного кривовато (только в портретной ориентации - т.е в нашем случае в режиме смартфона), но в целом пойдет. Я ещё немного поигрался в build.prop ради фана и добавил упоминания N-Gage :)
Далее необходимо было решить вопрос с зарядкой. Как я уже говорил выше, было решено использовать Type-C. Я заказал разъём на плате, разобрал смартфон и кинул перемычки с цепи питания и сигнальных линий на разъем.
У Samsung'ов в те годы были не совсем стандартные разъемы с кучей пластика и к VBus'у аккуратно подпаяться немного проблематично
Теперь нужно решить задачу запитывания микроконтроллера. ESP32 в режиме BLE кушает целые 130мА (что очень много, телефоны нулевых кушали меньше с учетом параллельно работающего GSM-тракта!) в режиме активной передачи данных. Поскольку на самой плате с ESP32 используется LDO AMS1117 с высоким dropout-напряжением в 1.2В, для использования с обычным литий-ионным аккумулятором необходимо было использовать ULDO с дропаутом в ~0.3В...
...но зачем, если контроллер питания смартфона — буквально и есть многоканальный DC-DC преобразователь, который выдаёт сразу несколько различных напряжений:
0.8В-1.2В - VCore, это шина питания ядер процессора. Именно на ней работает вся или почти вся внутренняя логика системы на кристалле.
1.2V-1.8V VRef - обычно это референсное напряжение для работы процессора с внешней логикой. Впрочем, с таким напряжением может быть и одна из шин питания для каких-то модулей (например камеры), это зависит от платформы.
3.3V - Ну, здесь всё очевидно. 3.3В — одно из самых распространенных напряжений в микроэлектронике и может использоваться в широком спектре модулей. Например оно может использоваться для запитки модуля камеры, различных датчиков, контроллера тачскрина, усилителя и т.п. Именно эта шина питания в идеале нам и нужна.
Однако 3v3 уровни могут быть и логическими. Крайне не рекомендую вешать нагрузку аж в целых 130мАч на какую-нибудь цифровую линию, есть неиллюзорный риск спалить процессор или контролер питания. Лучше всего брать эту шину питания с здоровых decoupling-конденсаторов, однако имейте ввиду что шина может быть нагружена другими устройствами и вы со своей нагрузкой в сотню миллиампер можете увести КП в защиту!
В случае с S4 Mini у меня был сервис-мануал с схемой, где я принялся искать нужное напряжение. Изначально у меня была возможность взять 3.3В с питания eMMC, однако по ходу изучения схемы я заметил ещё одну подходящую шину питания — 3P0 (т.е 3В ровно), которая питает Wi-Fi, ИК-порт и тачскрин.
Я решил заглянуть в даташит на микроконтроллер и убедился, что он умеет работать в том числе и при 3В на входе, однако это пороговое напряжение при котором может работать чип. Если питание нестабильное и проседает, то МК либо зависнет, либо упадет в ресет. Однако я был уверен что на выходе DC-DC с КП смартфона точно должно быть всё нормальным. Я быстренько вывел перемычку и запитал МК буквально «в воздухе», проверил что всё работает стабильно, а затем припаял несколько жилок с LVDS-кабеля и закрепил УФ-маской.
Ну что ж, пришло время собрать всё воедино! Не без помощи дихлоэретана салазки были установлены, платы геймпада вставлены, все питания припаяны, а резьба в задней крышке была нарезана.
На МК ничего не слиплось — просто на момент фотографии мне всё ещё не пришёл флюкс-офф)
И вот, наконец-то моё детище собрано! Давайте же посмотрим что я там насобирал!
Одним из основных критериев будущего игрового смартфона была конечно-же возможность сохранить функционал телефона. Иными словами, мне очень хотелось чтобы девайс повторял концепцию N-Gage и действительно в себе совмещал возможность звонить и удобно играть в игры!
В целом, я считаю что у меня это вполне получилось. Помимо функций самой звонилки, Android 4.4 всё ещё вполне может порадовать владельца базовым серфингом сети (большинство сайтов не откроется... ну нам и опеннета хватит!) и мессенджерами - здесь пока ещё работают и Telegram, и ВК в лице в Kate Mobile. Однако есть определенный нюанс... я взял GT-I9190 - т.е односимочную 3G-версию S4 Mini. А как известно, 3G в России уже практически не используется, поэтому вне Wi-Fi придется ограничится EDGE :)
Вчера я сделал анонс статьи на Пикабу и несколько читателей задали резонный вопрос: это же буквально смартфон 2013 года, он же, на первый взгляд, ничего не умеет в современных реалиях. Однако спешу вас заверить что под капотом всё не так уж и плохо! 400'ого Snapdragon'а хватает для большинства мобильных игр тех лет, не говоря уже об эмуляторах. При этом в отличии от старших 600'ых снапов (тогда 800'ый ещё не вышел), он не слишком сильно греется и более лоялен к и без того не самому объёмному аккумулятору!
Однако про опыт использования смартфонов прошлых лет в современных реалиях я уже не раз рассказывал в других своих статьях, поэтому предлагаю перейти к тесту игр. И начнем мы с вами с эмулятора NES.
Когда запускаешь любимый Super Mario Bros на офигенной AMOLED-матрице, то сразу понимаешь что весь проект был затеян точно не зря. После отключения линейного фильтра и растягивания картинки на весь экран, то диву даешься какие тут сочные цвета - не как на ЭЛТ-телевизоре, но тоже очень годно! Эмулятор работает очень шустро!
Ещё раз ноапомню что справа не рамка, а забагованные софт-кнопки. А вот сверху - рукопопие :)
Давайте же перейдем к чему-то ещё более пестрому и "графонистому" - а именно к Sega Mega Drive с оригинальным Соником! Здесь игра точно также летает, звук не хрипит, а картинка выглядят максимально приятной. Когда-то AMOLED-матрицы Samsung ругали за PenTile и немного не естественную цветовую схему... но в эмуляторах она как-будто какой-то шарм придает.
Далее предлагаю опробовать DOS'овскую классику - Wolfenstein 3D. Помимо "вольфа", я хотел добавить в тесты также и Quake... но порты попались кривые и не запускались. Очевидно что игра, которая шла даже на 286'ом, будет отлично летать на S4 Mini:
Ну и нативные игрушки здесь тоже работают неплохо. В какие-нибудь аркады типа Angry Brids, Fruit Ninja или Asphalt можно поиграть с большим удовольствием!
Вот такой незамысловатый и полезный девайс у нас с вами сегодня получился. Вы можете собрать такой и сами, схему, код прошивки и исходные файлы моделей я выкладываю на своём Github. Корпус можно "пощупать" в TinkerCad.
Сама разработка заняла всего 7 дней, большая часть времени ушла на подгонку деталей. Да, эту неделю я определенно точно почти не спал и даже один раз попсиховал. Однако все время разработки мне было дико весело и интересно. Ну, а что ещё пареньку в 23 года то нужно, кроме как писать код, копаться в девайсах и ТАЗах!?
Жду ваше мнение о моей самоделке в комментариях! А если вам интересна тематика ремонта, моддинга и программирования для гаджетов прошлых лет, подписывайтесь на мой Telegram-канал «Клуб фанатов балдежа», куда я публикую бэкстейджи статей, иногда полезные посты ну и немножечко щитпоста! Если вам интересны мои видео той же тематики — предлагаю подписаться на мой YouTube-канал.
Важно
Друзья! Для подготовки статей с разработкой самопальных игрушек под необычные устройства, объявляется розыск телефонов и консолей! В 2000-х годах, китайцы часто делали дешевые телефоны с игровым уклоном — обычно у них было подобие геймпада (джойстика) или хотя бы две кнопки с верхней части устройства, выполняющие функцию A/B, а также предустановлены эмуляторы NES/Sega. Фишка в том, что на таких телефонах можно выполнять нативный код и портировать на них новые эмуляторы, чем я и хочу заняться и написать об этом подробную статью и записать видео! Если у вас есть телефон подобного формата и вы готовы его задонатить или продать, пожалуйста напишите мне в Telegram (@monobogdan) или в комментарии. Также интересуют смартфоны-консоли на Android (на рынке РФ точно была Func Much-01), там будет контент чуточку другого формата :)
А также я ищу старые (2010-2014) подделки на брендовые смартфоны Samsung, Apple и т. п. Они зачастую работают на весьма интересных чипсетах и поддаются хорошему моддингу, парочку статей уже вышло, но у меня ещё есть идеи по их моддингу! Также может у кого-то остались самые первые смартфоны Xiaomi (серии Mi), Meizu (ещё на Exynos) или телефоны Motorola на Linux (например, EM30, RAZR V8, ROKR Z6, ROKR E2, ROKR E5, ZINE ZN5 и т.п, о них я хотел бы подготовить специальную статью и видео т. к. на самом деле они работали на очень мощных для своих лет процессорах, поддавались серьезному моддингу и были способны запустить даже Quake!). Всем большое спасибо за донаты!
Осторожно: В статье простым и понятным языком описана диагностика и ремонт редкого ретро-гаджета со всей гиковской любовью. Возможны неконтроллируемые приступы ностальгии!
Недавно мне удалось купить в Китае легендарный игровой смартфон, о котором наверняка слышали многие Хабровчане, а именно — Nokia N-Gage Classic. Однако полностью рабочий экземпляр в хорошем состоянии сейчас ценится как коллекционный девайс и стоит не менее 10.000 рублей. Но у меня таких денег не было... да и простых путей я тоже не ищу, поэтому я приобрел себе телефон не из рук ценителя, а напрямую из металлоприёмки после воды и работы другого мастера. В конечном счете, мне удалось практически полностью восстановить телефон и в сегодняшней статьей я расскажу вам о: диагностике некоторых аппаратных неисправностей классических телефонов Nokia, принципе работы матричной клавиатуры, ремонте телефона на практике с подробными изображениями и в заключительной части мы посмотрим с вами, во что можно было на нём поиграть!
Так уж получилось, что почти все январские статьи у нас посвящены телефонам-игровым консолям. Мы с вами не только вкратце рассмотрели предысторию появления мобильного гейминга и игровых телефонов в целом, но и успели на практике пощупать два необычных телефона с функциями консоли: современный кнопочный телефон с встроенным аппаратным клоном денди и редчайший прототип Android-смартфона для геймеров.
Телефон с двумя процессорами!
Однако, думаю многие читатели ждали статью о серийном и относительно массовом игровом смартфоне, который вышел в далёком 2003 году. И да, речь сегодня пойдет об оригинальном Nokia N-Gage, который в наше время получил постфикс «Classic». Но начнём с предыстории.
В 2002 году, рынок портативных игровых консолей переживал свои лучшие годы. Самой популярной «портативкой» на рынке была свежая GameBoy Advance от Nintendo, которая отличалась неплохой, по меркам хэндхэлда, производительностью, хорошим цветным дисплеем с высоким разрешением и обильной библиотекой игр. Ещё в 2001 году, компания Nokia выпустила свой первый смартфон — Nokia 7650, на операционной системе Symbian, которая была прямым наследником ОС EPOC с карманных компьютеров Psion.
Смартфон помог привезти в Россию из Сербии подписчик AlexSteam!
Аппаратная платформа смартфона называлась WD2 и состояла из ARMv5 процессора TI OMAP 310, работающего на частоте ~104-126МГц, от 8 до 16 мегабайт оперативной памяти типа SDRAM, а также около 16 мегабайт постоянной памяти и бейсбенд-процессора (иными словами — модема) от обычного S40-телефона. В Nokia смекнули, что в сравнении с GBA, такие характеристики были как минимум достойными для портативной консоли и на базе смартфонной платформы вполне можно сделать игровой девайс!
В одном устройстве необходимо было объединить две концепции — телефона и игровой консоли, поэтому компания решила использовать весьма необычный форм-фактор, который назывался «Тако» и подразумевал горизонтальное расположение аппаратных кнопок. Причём первый телефон с таким дизайном, Nokia 5510, имел QWERTY-клавиатуру! Уже в 2002 году, Nokia анонсировала N-Gage, который должен был перевернуть рынок портативных игровых консолей.
В начале 2003 года, вышла Nokia 3300, представляющая из себя телефон в формате «гаги», но при этом ориентированный на мультимедийные возможности и работающий на платформе S40. И хотя производитель не позиционировал его как игровой, это был один из первых цветных телефонов с поддержкой Java-приложений и на нём можно было играть в самые первые мобильные игры. Ну а раз есть игры — то чем не игровой? :)
7 октября 2003 года, мир наконец-то увидел N-Gage: смартфон, на который Nokia возлагала большие надежды... Однако телефон получил лишь умеренный успех на рынке из-за ряда инженерных особенностей устройства. Например, говорить предлагалось повернув телефон торцом к уху, а для смены игры необходимо было вытащить аккумулятор, достать прошлую MMC-флэшку, установить новую, снова установить аккумулятор и включить телефон — и весь процесс занимал около полутора минут, во время которого вы были не в сети! Помимо этого, у телефона был странно реализован драйвер MMC-флэшек: плеер мог эксклюзивно заблокировать карту памяти и если «аська» была установлена на MMC-карту, вы не могли параллельно общаться и слушать музыку!
Игры для N-Gage распространялись на картриджах в виде MMC-флэшек с какой-никакой защитой от копирования. Развитие WAP-сайтов и мобильного интернета в целом было отнюдь не на руку Nokia в этом случае, поскольку игры очень быстро сдампили с картриджей, пропатчили и выложили в интернет — совершенно бесплатно, пользователю оставалось лишь скопировать игру на свою карту памяти. В те годы, на Symbian можно было ставить всё что угодно, никаких сертфикатов и трюков с переводом даты на телефоне не было!
В 2004 году, Nokia выпустила второе поколение N-Gage, которое называлось QD и имело как улучшения, так и упрощения. Из улучшений можно выделить разговорный динамик, перенесенный на фронтальную часть устройства, хороший дисплей с гораздо более яркой подсветкой и возможность замены картриджей без перезагрузки, а из упрощений — зачем-то убрали разъём для синхронизации с ПК и уменьшили габариты телефона — лично мне с моими большими руками на Classic'е играть удобнее!
На фото кудишка. Заказывал подписчику Андрею, благодаря которому вы читаете сегодняшнюю статью. Вот бы поколупать нерабочую :))
Конечно и мне хотелось обзавестись своим собственным N-Gage Classic. Однако, как я уже сказал в вводной части статьи, цены на них очень сильно кусаются: классическая версия редкая и выпускалась не очень большим тиражом, из-за чего ценники на вторичке в России достигают 15 тысяч рублей за рабочее устройство в хорошем состоянии и 10 тысяч рублей за девайс с небольшими недостатками. У меня таких денег нет, но зато я обожаю ремонтировать и пытаться дать новую жизнь различным ретро-устройствам, поэтому я решился на рисковый шаг - купить смартфон из утиля в Китае!
Смартфон продавался на онлайн-барахолке Goofish, аналоге нашего Avito. Продавец писал о том, что у смартфона не работает подсветка и возможно есть какие-то другие недостатки. Ну, подсветка это несложно на первый взгляд, поэтому я решил рискнуть и заказал его себе. Купить устройство и доставить его на склад в Китае помог мой подписчик Роман, а привезти в мой город - Ейск, помог сервис самостоятельных покупок YouCanBuy, за что вам большое спасибо!
При получении, я проверил смартфон: он включился, но требовал SIM-карту. Подсветка хоть и работала — но только в момент включения устройства до фактической загрузки ОС. Ну что ж, давайте перейдем к процессу дриставрации!
Поскольку телефон я купил из утиля, за годы лежания в неизвестных условиях, он очень сильно покрылся пылью и грязью, а все прижимные модули телефона, по типу разъёма зарядки, были в серьезной коррозии. Поэтому в первую очередь, смартфон необходимо было хорошенько отмыть!
Я разобрал телефон и пошёл тщательно отмывать каждый корпусной элемент устройства с зубной щёткой и шампунем. Особо тщательно я вымывал труднодоступные места в фронтальной панели и силиконовой резинке клавиатуры — там скопилось ну просто неприличное количество грязи.
Промежуточное фото
После принятия душа, все корпусные элементы были предварительно высушены феном при температуре в 100 градусов с средним потоком, а затем отправлены окончательно досыхать на стол.
Теперь самое время посмотреть на саму плату устройства. Когда я вставил SIM, включил смартфон и начал проверять кнопки — я обнаружил, что «меню», «музыка» и «левая софт-клавиша» не функционируют: При детальном осмотре платы обнаружилось, что мембранный слой с кнопками уже когда-то отклеивался... и я увидел как кто-то криво залудил контакты кнопки «меню» в надежде её починить. С виду, эта часть платы точно топилась и возможно мастер, обнаружив следы коррозии на контактах, решил попробовать отремонтировать её вот таким путём.
Я уверен, что опытные мастера, которые читают эту статью, уже поняли в чём здесь проблема
Само собой это не дело. Я перезалудил контакты и снял лишний припой оплеткой, однако это, очевидно, не помогло.
Если мы обратимся к схеме устройства, то увидим что клавиатура выполнена по матричному принципу — простыми словами, процессор выдаёт высокий уровень на GPIO каждой колонки матрицы, при этом напряжение с колонки идёт на первый вывод каждой кнопки, а второй вывод присоединён к соответствующему столбцу в процессоре. По итогу получаем очень простую схему: процессор выдаёт VIO-напряжение на каждый ряд кнопок и если какая-то из них нажата, то получает это же напряжение на одной из своих ножек. Итого делаем вывод что один из row или column-сигналов банально не доходит до кнопки!
Для уменьшения помех от радиотракта на сигнальных линиях, в смартфонах Nokia использовались т.н EMIF-фильтры в BGA-корпусах, ещё их называют «стекляшки». Фильтры ставятся на линии клавиатуры и на дисплей, однако сами стекляшки очень хрупкие и практически гарантированно выходят из строя при попадании в воду и иногда при падении. Поэтому если у вашей Нокии белый дисплей, но при этом есть звуки и все кнопки работают, либо же часть кнопок не работает при общей работоспособности устройства — скорее всего, вышел из строя один или два EMIF-фильтра.
Однако если фильтр вышел из строя — не беда, его можно заменить перемычками. Для этого сам фильтр необходимо снять: добавляем флюс под «пузо» фильтра и греем его паяльником сверху. Если не получается — можно добавить немного припоя, главное не пытайтесь снять его насильно — иначе есть риск сорвать пятачки! После этого, необходимо сделать перемычки на всех I и O пинах площадки под чип. Где они находятся, можно узнать в даташите на фильтр, в моем случае это верхние два пятака и нижние два пятака.
Не ругайте за хвосты на перемычках! Я выполнял работу без микроскопа и у меня не было лезвий, дабы аккуратно срезать хвостики. Срезать мычку «в расчкачку» я не стал — высокий риск сорвать пятак.
Это помогло лишь частично — у меня наконец-то заработала кнопка музыки. Тут я уже взял в руки мультиметр и начал прозванивать где у нас обрываются дорожки с кнопок. До выхода фильтров все прозванивалось замечательно, при этом я обнаружил тестпоинты всех колонок и столбцов кнопок... кроме одного. И тут мне стало всё очевидно: поскольку от кнопки меню идёт общий сигнал ROW0 с левым-софткеем — у нас банально отгнили две дорожки на кнопке меню! Сигнал COL я взял с тест-поинта, а ROW0 я нашёл, счистив маску с ближайшей кнопки дорожки сверху и установив между ними перемычку. Теперь всё наконец-то заработало!
За кадром я пообрезал хвосты и поставил перемычки потоньше (с изначально тонкими на фото ничего не было бы видно), но УФ-маску наносить пока не стал. Был бы у меня микроскоп — сделал бы вообще идеально, но и так вполне неплохо :) Однако остался вопрос с дисплеем, из-за пребывания во влажной среде клей под поляризационной пленкой вспух, поэтому у нас останутся перманентные артефакты на дисплее. Пришло время собрать смартфон и посмотреть что же у нас получилось! Поковырявшись в меню, я обнаружил программу nLights для управления подсветкой устройства... прошлый хозяин зачем-то выкрутил подсветку клавиатуры и дисплея в ноль — в этом и была причина её «неработоспособности».
На этом наш процесс дриставрации завершен. Аппарат собран, выглядит вполне неплохо и что самое главное — полностью работает! Весь ремонт занял у меня часа 2 от силы вместе с диагностикой. Давайте же посмотрим, на что смартфон способен в 2024 году!
You look lonely...
После включения смартфона, нас встречает ламповый и любимый интерфейс Symbian 6.1! Телефонные функции доступны и сейчас, в России 2G ещё не отключили, поэтому при желании можно пользоваться телефоном по прямому назначению.
В отличии от QD, у Classic был весьма широкий мультимедийный функционал — он из коробки поддерживал mp3 и wav, FM-радио, а также имел поддержку стерео-звука. Качество звука для тех лет было вполне неплохим — представляю, какой мечтой было заполучить такой телефон в момент выхода и сидеть с пацанами «у падика», слушая музычку и поигрывая по очереди в Asphalt 2!
После установки MMC-флэшки с приложениями и играми, смартфон раскрывался в полную силу. Помимо нативных sis-приложений, N-Gage поддерживал также и Java-приложения, что ещё больше расширяло библиотеку софта и игр. Лет 10 назад можно было даже Хабр почитать, пока работала Opera Mini 5. Однако MIDP 1.0 потерял свою актуальность уже к 2006 году.
Но мы ведь пришли с вами за играми! Давайте посмотрим, что-же умел N-Gage на практике: вместо статичных скриншотов, я приложил видео с таймкодом начала теста игр. На Пикабу разрешено прикеплять всего-лишь 25 медиаэлементов (т.е в сумме 25 фото или видео), поэтому часть статьи пришлось обрезать - тут уж все вопросы к команде Пикабу. Ниже также есть плеер ВК - для тех, кому лень включать впн.
А вот и ВК:
Вот такая ретроспективная статья о легендарном игровом смартфоне у нас с вами получилась. Удалось ли мне вдохнуть новую жизнь в смартфон, который побывал в утиле, на котором по сути в своё время поставили крест и почти отправили в переработку? Пишите своё мнение в комментариях!
Друзья! Если вам интересен мой контент, то будет здорово если вы подпишитесь на мой канал на YouTube или паблик ВК. Сами понимаете, для видеоблогеров в РФ сейчас время сложное, на ютубе охваты сильно упали, а в ВК нет никаких механизмов для продвижения контентмейкеров-новичков — так что приходится искать зрителей среди читателей :) Также если вам интересна тематика ремонта, моддинга и программирования для гаджетов прошлых лет, подписывайтесь на мой Telegram-канал, куда я публикую бэстейджи статей и видео, ссылки на новый контент и немножко щитпоста!
Очень важно! Разыскиваются девайсы для будущих статей!
Друзья! Для подготовки статей с разработкой самопальных игрушек под необычные устройства, объявляется розыск телефонов и консолей! В 2000-х годах, китайцы часто делали дешевые телефоны с игровым уклоном — обычно у них было подобие геймпада (джойстика) или хотя бы две кнопки с верхней части устройства, выполняющие функцию A/B, а также предустановлены эмуляторы NES/Sega. Фишка в том, что на таких телефонах можно выполнять нативный код и портировать на них новые эмуляторы, чем я и хочу заняться и написать об этом подробную статью и записать видео! Если у вас есть телефон подобного формата и вы готовы его задонатить или продать, пожалуйста напишите мне в Telegram (@monobogdan) или в комментарии. Также интересуют смартфоны-консоли на Android (на рынке РФ точно была Func Much-01), там будет контент чуточку другого формата :)
