Siemens

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

Недавно я задался вопросом: а возможно ли написать для ARM нативную программу, которая будет бесшовно работать сразу на 4-х операционных системах без необходимости перекомпиляции для разных платформ и ABI. Мне очень хотелось реализовать возможность писать кроссплатформенные эльфы для мобильных телефонов из нулевых и попытаться портировать на них эмуляторы ретро-консолей. Погрузившись в документацию на исполняемые форматы, я пришёл к выводу, что да - это возможно и смог реализовать такую программу на практике без читерства по типу VM! Всех гиков приглашаю под кат!

❯ Зачем и почему?

Давным-давно, в далёком 2001 году, мир увидел легендарный японский телефон - Sony CMD-J70. Ещё до создания совместного подразделения с Ericsson, Sony выпускала достаточно занимательные девайсы, которые привлекали внимание не только рядовых пользователей, но и моддеров всех мастей. Уже через пару лет после выхода, в программном плане телефон копали все кому не лень: кто-то менял графику, кто-то писал патчи, а со временем написали даже бинлоадер (PRGLoader) - загрузчик внешних "экзешников", позволявший запускать на телефоне произвольный софт, написанный на ассемблере!

Сейчас сложно себе представить, но в те годы это был нереальный отвал башки: на большинстве телефонов были доступны разве что Java/Mophun-приложения, которые обладали ограниченным функционалом и уж тем более не позволяли лезть в дебри прошивки телефона, а здесь были программы которые буквально позволяли делать с телефоном всё что захочешь: светомузыку из подсветки, кастомные игры, обои на главный экран... всё это было доступно только на куда более дорогих смартфонах с Symbian и Windows Mobile на борту!

Недавно мы с вами вспоминали о легендарном Siemens M55 и узнали, что у него находится под капотом. Несмотря на диковинную архитектуру Infineon C166, даже под этот телефон делались патчи и была написана как минимум одна кастомная игра. Но рассвет моддинг-сцены Siemens произошёл с выходом платформы S-Gold на базе стандартного ядра ARM926EJ-S, когда в ~2004 году энтузиасты полностью взломали алгоритм генерации BootKEY для загрузчика, а затем в 2006 году реализовали полноценный эльфлоадер, который позволял загружать программы написанные на C и скомпилированные самым обычным компилятором ADS. В отличии от бинлоадера для CMD-J70, "эльфятник" позволял угонять функции RTOS для создания потоков и привносил в бюджетные телефоны полноценную вытесняющую многозадачность с настоящим диспетчером задач и возможностью запуска несколько программ одновременно:

Энтузиасты раскапывали прошивку в дизассемблере, изучали её и пытались понять как работают разные её подсистемы. Результатом стало появление нативного клиента почты с предком пуш-уведомлений, аськи (NatICQ), порты самых разных эмуляторов ретро-консолей и даже полная программная поддержка MP3 в тех телефонах, где её отродясь не было! И представьте себе, почти все эти программы можно было свернуть и продолжить работу в браузере или, например, Card Explorer'е! Одним из эльфописателей был Хабровчанин @ilya_ZX

Но если вы думаете что одними телефонами Siemens энтузиасты были едины, то вы ошибаетесь - ведь круче были только "моторолки"! В 2004-году, недорогая Motorola E398 с двумя громкими динамиками, светомузыкой и поддержкой MicroSD-флэшек, стала настоящим бестселлером и привлекла к себе не меньше энтузиастов, чем Siemens. Ребята сплотились на форуме MotoFan, нашли уязвимость в загрузчике и хакнули верификацию RSA-подписи у прошивок, позволив не только модифицировать Seem'ы (что-то типа NVRAM), но и создавать для телефона кастомные прошивки - монстрпаки, которые прибавляли громкость и без того не самым тихим динамикам и в различных аспектах изменяли главное меню устройства. Со временем, @Andy51 и ещё несколько энтузиастов реализовали эльфлоадер (EP1) для E398, раскопали прошивку и написали много полезного софта, время от времени переключаясь на Linux-телефоны от Motorola...

Вероятно многие читатели подумают мол "было и было, мой айфон/сяоми может запускать любой произвольный софт и эти ухищрения давным-давно неактуальны...". Но как бы не так: про моторолки и сименсы не просто всё чаще вспоминают, у них есть до сих пор активное моддерское коммьюнити, которое продолжает пилить для них кастомный софт и далее колупать прошивку. Всё тот же @EXL портировал крутой софтрендер для E398 и в 2025 году наконец-то взломал C350, @Azq2 пилит аппаратный эмулятор Infineon S-Gold и многие другие делают свой вклад в моддинг сцену уже не таких мейнстримных, но отнюдь не устаревших устройств!

Однако порог вхождения для написания эльфов достаточно высокий: нет никакой отладки кроме printf, любая ошибка в приложении приводит к зависанию или ребуту телефона (на сименсах с характерным "пик"), а API напрямую импортируется из прошивки телефона и может быть достаточно комплексным - ни о каких кроссплатформенных эльфах и речи не идет. Поэтому в какой-то момент мне стало интересно: а возможно ли написать такой эльфлоадер, который за своим рантаймом будет прятать детали реализации работы с аппаратной начинкой телефона и при этом загружать один и тот же бинарник на всех поддерживаемых платформах без особых патчей и изменений? Принявшись за изучение ABI ARM и спецификации Elf, я начал дизассемблировать и изучать самые маленькие тестовые программы...

❯ Формат ELF, ABI ARM и тулчейн

Начнём с самого простого: что же такое эти самые эльфы? Elf - формат исполняемых файлов, широко применяемый как в мире Unix-систем, так и в embedded-устройствах. Самые распространенные тулчейны - GCC и clang/llvm, по умолчанию собирают программы именно в этом формате и по своей сути, это прямой аналог .exe (PE) файлов из Windows. Помимо кода, Elf также содержит в себе множество секций и различных данных, при этом разработчики формата старались сделать его настолько гибким, чтобы его можно было использовать на любых архитектурах: от x86, до risc-v.

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

.text - хранит в себе код программы и обычно записывается в память с флагами MMU R X (чтение и выполнение)

.data - преинициализированные данные, имеет флаги R W (чтение и запись). Например, заполненная структура в C:

int a[] = { 1, 2, 3 };

.bss - не инициализированные данные, иными словами глобальные переменные, которые при старте программы должны быть забиты нулями. Имеет те же флаги, что и .data.

.rodata - различные константы: строковые, const-преинициализированные массивы, а также структуры и т.п, имеет только флаг R и на системах с MMU попытка запись в эту секцию повлечет SIGSEGV.

За загрузку всех этих секций отвечает загрузчик Elf в ядре ОС. Однако это справедливо только для простых программ, которые загружаются в фиксированный адрес виртуальной памяти и которые не используют внешние библиотеки (.so, аналог в Windows - .dll). Поскольку адрес загрузки для всех библиотек предсказать невозможно, разработчики ABI придумали позиционно-независимый код (PIC и его производное - PIE), который может загружаться в любую область памяти и оттуда выполняться.

Реализация PIC может достигаться тремя разными способами:

• Первый способ заключается в использовании глобальной таблицы смещений (GOT) и релокаций. Релокации - специальные данные в Elf, которые позволяют переместить программу в другой адрес путём патчинга адресов в секции .got "на лету": иными словами, сам код (.text) остаётся позиционно-независимым (дабы библиотеку можно было загрузить один раз и использовать во множестве процессов) и обращается к GOT относительно PC, но в самом GOT (который представляет из себя массив void* addresses[]) указатели на остальные сегменты находятся так, будто программа загружается по смещению 0x0. Задача динамического линкера - посчитать абсолютный адрес для всех указателей в GOT: в простейшем случае, это got[address] += baseAddress.
  Релокации могут затрагивать сразу literal pools в обход GOT, если архитектура предусматривает их наличие.

• Релокацией занимается динамический линкер или интерпретатор в мире Unix (тот самый ld.so, что часто "not found" :) ), а самих релокаций есть много разных видов в зависимости от архитектуры процессора. В ARM чаще всего встречается R_ARM_REL32

• Второй способ заключается в том, что мы компилируем программу так, будто она должна загружаться по фиксированному адресу 0x0 - то есть без PIC, однако просим линкер (--emit-relocs) создать информацию о всех обращениях к памяти в виде всё тех же релокаций. Вместо R_ARM_REL32, линкер создаёт релокации R_ARM_ABS32, которые можно разрешить обычным сложением.
  С таким подходом количество релокаций кратно увеличивается, однако из-за отсутствия GOT немного повышается быстродействие программы (вместо трёх LDR для загрузки слова из памяти нужно всего два: из Literal pool в регистр и затем из фактической памяти).

Третий способ поддерживается не везде, но в ARM он является одним из самых распространенных в embedded-среде: код собирается с флагами /rwpi и /ropi полностью не зависит ни от GOT, ни имеет каких либо релокаций. Вместо этого, для адресации базового адреса программы он использует выделенный регистр R9, который загрузчик должен заполнить адресом, куда он загрузил программу (mov r9, textSectionBase). Такой подход теоретически чуточку быстрее, чем GOT, но медленнее второго подхода из-за необходимости добавлять сложение регистра с PC перед каждым фетчем из памяти.

Поскольку в телефонах MMU обычно не используется, эльфлоадеры загружают программы по тому адресу, что им выделяет системный аллокатор памяти и вынуждены использовать PIC. Чаще всего используются релокации (как минимум на Siemens и Motorola), на некоторых платформах используется второй подход с использованием регистра R9.

Для большей гибкости, я решил выбрать второй подход и построить свой эльфлоадер поверх уже существующих загрузчиков, обернув API прошивок в ряд собственных стандартизированных функций: работа с дисплеем, вводом, файлами, а также звуком. При этом эльфы должны собираться современным компилятором clang с поддержкой C99, чтобы была возможность легко портировать современные single-header программы по типу эмуляторов, да и в целом не писать код на манер Ansi C, когда переменную нигде нельзя объявить кроме начала блока.

Далее я сутками игрался с компиляторами и пытался заставить выдать их подходящий для моих целей код и по итогу написал скрипт для линкера, который для простоты загрузки файла объединяет все секции в один .text (таким образом остаётся всего один Program Header):

OUTPUT_FORMAT("elf32-littlearm")
SECTIONS
{
. = 0x0;
.text : {
*(.r9ptr)
*(.text*)
*(.data*)
*(.bss*)
*(.rodata*)
*(.functions)
}

.rel : {
*(.rel*)
}

/DISCARD/ : {
*(.ARM.*)
}

}

И следующий набор опций для компилятора, который устанавливает архитектуру и целевой процессор, ABI для FPU, включает генерацию релокаций и отключает выравнивание в линкере для выходного файла (иначе файлы забиты нулями и весят целых 64Кб:

Когда компилятор наконец-то начал выдавать корректный код, я принялся писать сам эльфлоадер. За качество кода и отсутствие нормальной структуры не ругайте - это эмбеддед, тут можно ;))

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

// Read and verify ELF header
Elf32_Ehdr* hdr = (Elf32_Ehdr*)data;

PRINT("Loading ELF...");
if(hdr->e_machine != EM_ARM)
{
PRINT("Not an EM_ARM executable");

return 0;
}

if(hdr->e_ident[EI_DATA] != PLATFORM_ELF_ENDIANESS)
{
PRINT("Endianess mismatch");

return 0; // Wrong endianess
}

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

ret = (ExecInfo*)ExecAlloc(sizeof(ExecInfo));

sections = (Elf32_Phdr*)(&data[hdr->e_phoff]);
sh = (Elf32_Shdr*)&data[hdr->e_shoff];
symSectionIndex = hdr->e_shstrndx;
codeSize = 0x0;

PRINT("Processing program headers");
// Process program headers and determine total size
for(i = 0; i < hdr->e_phnum; i++) {
Elf32_Phdr hdr = sections[i];

if(hdr.p_type == PT_LOAD) {
if(hdr.p_offset == 0x0)
continue;

codeSize += hdr.p_memsz;
}
}

PRINT("Allocating memory for .text");

textSection = (char*)ExecAlloc(codeSize);
textOffset = textSection;

ret->CodeSection = textSection;

if(!textSection)
{
free(ret);
PRINT("Failed to allocate .text section");

return 0;
}

Далее найти секцию с таблицей символов и с строками, где содержатся имена символов:

PRINT("Analyzing section table");
for(i = 0; i < hdr->e_shnum; i++)
{
Elf32_Shdr sec = sh[i];

if(sec.sh_type == SHT_STRTAB && i != hdr->e_shstrndx && strTable == 0)
{
strTable = &data[sec.sh_offset];
PRINT("Found string table");
}

if(sec.sh_type == SHT_SYMTAB)
{
PRINT("Found symbol table");
symbols = (Elf32_Sym*)&data[sec.sh_offset];
symNum = sec.sh_size / sizeof(Elf32_Sym);
}

if(sec.sh_type == SHT_REL && relocs == 0)
{
UtilPrint("Found relocations");
relocs = (Elf32_Rel*)&data[sec.sh_offset];
relNum = sec.sh_size / sizeof(Elf32_Rel);
}

if(sec.sh_type == SHT_RELA)
{
PRINT("Found unsupported relocation types");
return 0;
}
}

if(!strTable || !symbols)
{
free(ret);
PRINT(".strtab or .symtab not found");

return 0;
}

А затем найти функцию ElfMain, которая служит точкой входа и пропатчить таблицу импортированных функций! На этом, загрузка эльфа завершена - можно устанавливать регистр R9 и вызывать Main!

PRINT("Relocation fix-up");
for(i = 0; i < relNum; i++)
{
Elf32_Rel rel = relocs[i];
int sym = ELF32_R_SYM(rel.r_info);

switch(ELF32_R_TYPE(rel.r_info))
{
case R_ARM_ABS32:
*((unsigned int*)&textSection[rel.r_offset]) += (unsigned int)textSection;
break;
case R_ARM_JUMP24:
break;
case R_ARM_CALL:
break;
default:
PRINT("Unsupported relocation type");
}
}

PRINT("Patching import table");

// Analyze symbol table and patch all imported function pointers to real counterparts
for(i = 0; i < symNum; i++)
{
Elf32_Sym sym = symbols[i];
uint8_t* symName = &strTable[sym.st_name];

int symType = ELF32_ST_TYPE(sym.st_info);

if(symType == STT_OBJECT && strstr((const char*)symName, "SYS_"))
{
int funcNumber = ExecFindFunction(symName);

if(funcNumber == -1)
{
PRINT("Failed to import function: ");
UtilPrint((char*)symName);
PRINT("");

continue;
}

//drawDebug(FuncExportTable[funcNumber].Pointer == 0 ? "Not OK" : "OK");

*((unsigned int*)&textSection[sym.st_value]) = (unsigned int)FuncExportTable[funcNumber].Pointer;
}

if(symType == STT_FUNC && strstr((const char*)symName, "ElfMain"))
{
PRINT("ElfMain function is found");

ret->Main = (ExecMainFunction)&textSection[sym.st_value];
}

В Elf уже есть механизм импорта функций из сторонних библиотек, называется Platform Linkage Table. Для импорта функций прошивки, эльфлоадер Siemens использует SWI (сисколлы, что-то типа программных прерываний в x86 - int 10h и т.п.), Motorola же патчит thunk-функции на лету, которые сами вызывают настоящую функцию:

А я решил поступить несколько изящнее. В моем эльфятнике, функции импортируются с помощью специального макроса, который создаёт переменную-указатель на функцию, который изначально располагается в секции .functions. При этом с помощью ключевого слова asm, символу присваивается иное имя - с префиксом SYS_, которое означает то, что загрузчик эльфа должен пропатчить адреса функций на реальные (которые предварительно зарегистрированы в рантайме) в процессе загрузки программ и таким образом, избежать thunk-функций и позволить оптимизатору легко выкидывать указатели на неиспользуемые функции:

#ifndef LOADER
#define IMPORT(name, ret, ...) __attribute__ ((section(".functions"))) ret (* name )( __VA_ARGS__ ) asm( "SYS_" #name )
#define IMPORTNOARGS(name, ret) __attribute__ ((section(".functions"))) ret (* name )() asm( "SYS_" #name )
#else
#define IMPORT(name, ret, ...) ret name( __VA_ARGS__ )
#define IMPORTNOARGS(name, ret) ret name()
#endif

Что самое забавное, лучший способ отладить эльфлоадер - в QEMU с GDB под Linux. Однако я решил время не терять и отлаживал его сразу на смартфоне с Windows Mobile. А раз WM стал первой поддерживаемой платформой - на нем мы с вами и реализуем рантайм.

❯ Портируем на Windows Mobile (CE)

Поскольку всю жизнь я сижу в основном на Windows, а WinAPI в CE практически полностью копирует десктопную версию, никаких проблем с портированием рантайма не возникло. Единственный выбор который передо мной встал: стоит ли прокидывать stdlib из хост-системы в "эльфятник", или же воспользоваться реализацией newlib в clang/gcc. В процессе портирования на другие платформы выяснилось, что нормально libc реализован, по сути, только на Windows, во все остальных реализациях были лишь самые основные функции по типу malloc, free, memcpy, strcmp и т.п. Поэтому я решил не городить велосипеды и прокинул из хост-системы лишь аллокатор - т.е malloc и free:

// stdlib
IMPORT(elf_malloc, void*, int size);
IMPORT(elf_free, void, void* ptr);
/*IMPORT(elf_strcmp, int, char* str1, char* str2);
IMPORT(elf_strcpy, char*, char* dst, char* src);
IMPORT(elf_strlen, int, char* str);
IMPORT(elf_strstr, char*, char* string, char* substring);
IMPORTNOARGS(elf_rand, int);
IMPORT(elf_memcpy, void*, void* dst, const void* src, uint32_t length);
IMPORT(elf_memset, void*, void* dst, int what, uint32_t length);
IMPORT(elf_memmove, void*, void* dst, void* src, uint32_t length);*/

Далее я сразу решил, что платформозависимые функции для работы с дисплеем использовать не буду и из хост-системы мне нужен будет лишь указатель на фреймбуфер, а блиттинг, рисование текста и прочие операции я реализую сам. На первый взгляд может показаться что это единственное верное решение, однако на практике в некоторых телефонах (Motorola E398, Razr V3) активно использовались 2D GPU от ATI и Nvidia, которые рисуют (BitBLT) изображение значительно быстрее любой программной реализации.

Ниже представлена черновая реализация без преобразования пиксельформатов (поскольку на подавляющем числе телефонов использовался 565) и поддержки прозрачности через колоркей. Её можно оптимизировать до быстрого копирования по сканлайнам через memcpy:

for(i = 0; i < bitmap->Height; i++)
{
for(j = 0; j < bitmap->Width; j++)
{
LCD_PLOT_565(clamp(x + j, 0, lcd->Width), clamp(y + i, 0, lcd->Height), bmp[i * bitmap->Width + j]);
}
}

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

__inline int LcdDrawChar(LcdInfo* lcd, char chr, uint32_t x, uint32_t y, uint16_t color)
{
if(x >= 0 && y >= 0 && x + FONT_WIDTH < lcd->Width && y + FONT_HEIGHT < lcd->Height)
{
int i, j;
unsigned char* glyph = &embedded_font[chr * 8];

for(i = 0; i < FONT_HEIGHT; i++)
{
short* fb = &((short*)lcd->Pixels)[(y + i) * lcd->Width + x];

for(j = 0; j < FONT_WIDTH; j++)
{
if((*glyph >> (FONT_WIDTH - j)) & 0x1)
*fb = color;

fb++;
}

glyph++;
}

return true;
}

return false;
}

void LcdDrawString(LcdInfo* lcd, char* str, uint32_t x, uint32_t y, uint16_t color)
{
SWITCH_CONTEXT;
if(lcd && x >= 0 && y >= 0)
{
unsigned int i;

for(i = 0; i < strlen(str); i++)
{
if(!LcdDrawChar(lcd, str[i], x, y, color))
return; // Out of screen

x += FONT_WIDTH;
}
}
END_CONTEXT;
}

Отладив эльфлоадер, я написал небольшую тестовую программу для вывода картинки и текста:

#include <system.h>

int ElfMain(void* ptr)
{
LcdInfo* lcd = lcdInit();

lcdDrawBitmap(lcd, bitmap, 0, 0);
lcdDrawString(lcd, "Test", 0, 0, COLOR_BLUE)

return 100;
}

И получил следующий результат:

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

❯ Портируем на MRP/MRE

И имя этой платформе, вернее даже двумя платформам - MRP и WRE. Эти платформы использовались на бюджетных китайских телефонах с 2007 по 2016 год. Встретить их можно было везде: легендарная Nokla TV E71/E72, клоны 6700, бюджетные телефоны Fly/Explay/DEXP и даже в оригинальных телефонах Nokia на платформе S30+ (например 230)!

И хотя люди часто считали такие устройства бесполезными в плане установки сторонних приложений, многие ранние "нонейм"-телефоны поддерживали запуск нативных программ через небольшой костыль - установку специального "загрузчика" dsm_gm.mrp и ввод комбинации *#220807# в номеронабиратель. Конечно, знали об этом костыле единицы и в 2010 году MediaTek решила сделать свою платформу под названием MRE (MAUI Runtime Environment), приложения для которой можно было запускать прямо из проводника без установки! SDK для обеих платформ сейчас свободно лежит в сети.

Обе платформы, по сути, занимаются тем же самым, что и мой эльфятник - прокидывают нативные функции MMI (оболочка телефона) в приложения и для загрузки позиционно-независимых программ используют третий подход с регистром R9, который обязательно необходимо где-то хранить и восстанавливать. Изначально мой эльфятник использовал такой же подход, из-за чего я написал отдельный костыль для "свичнга" контекстов, причем восстановление R9 я делал в отдельной функции из-за бага ассемблера в ADS:

#define SWITCH_CONTEXT unsigned int staticBase; __asm { MOV staticBase, sb;
LDR r0, [sb];
MOV sb, r0 }

#define ELF_CONTEXT(ptr) unsigned int staticBase; void* elfStaticBase = ptr; __asm { MOV staticBase, sb; \
MOV r9, elfStaticBase }

#define END_CONTEXT RestoreSB(staticBase);

Но я не учел то, что MMI хоть и построены по event-based принципу, в них нельзя так просто взять и сделать while(true) {}, а необходимо использовать таймеры, что влечет за собой постоянные костыли с свичингом контекстов что по итогу только снижает производительность. По итогу я перешел на релокации и реализовал проброс таймеров.

Во всем остальном, MRP и MRE простые как табуретка, никаких проблем с пробросом ввода и графики не возникло:

LcdInfo* LcdInit()
{
LcdInfo* ret;
ret = (LcdInfo*)malloc(sizeof(LcdInfo));
ret->Width = screenInfo.width;
ret->Height = screenInfo.height;
ret->Pixels = (void*)w_getScreenBuffer();

return ret;
}

void LcdFree()
{

}

void LcdLock(LcdInfo* info)
{

}

void LcdFlush(LcdInfo* info)
{
mrc_refreshScreen(0, 0, 240, 320);
}

И вот, наша программа уже запускается на двух совершенно разных ОС без каких либо проблем!

❯ А если что-то посложнее Hello, world?

Наверняка у читателя возникнет вопрос мол "окей, твой эльфятник может и способен запускать простые программы, но как насчет чего-то посложнее?". И конечно-же, для тестов я решил портировать не абы что, а целый эмулятор NES! В конце-концов, одна из целей разработки такого эльфятника - возможность запускать Java-игр и эмуляторов на многих кнопочных телефонах из нулевых.

Какое то время назад, я обнаружил весьма шустрый эмулятор NES от неизвестного разработчика из Китая. Код был неважного качества, никаких копирайтов в нём не было. Но поскольку сам эмулятор был быстрый (быстрее, наверное, только vNesC, который является прямым source-портом Java-эмулятора vNes на C), я отвязал его от целевой платформы и превратил в небольшую библиотеку для легкого портирования на любые платформы путем вызова всего нескольких функций:

typedef struct {
uint16_t* FrameBuffer;
uint8_t* JoyState;
} emuContext;

emuContext* emuInitialize();
uint8_t emuLoadROM(void* rom, int length);
void emuReset();
void emuDoFrame();
void emuShutdown();

И, соответственно, базовый порт на наш эльфятник выглядит примерно так:

#include <string.h>

#define FUNC_PROTOTYPES
#include <system.h>

#include <nes.h>
#include "nes_rom.h"

emu_context* ctx;
LcdInfo* lcdInfo;

void EmuTick()
{
emuDoFrame();

LcdLock(lcdInfo);
short* pixels = (short*)lcdInfo->Pixels;

for(int i = 0; i < EMU_FRAMEBUFFER_HEIGHT; i++)
{
memcpy(&pixels[i * lcdInfo->Width], &ctx->FrameBuffer[i * EMU_FRAMEBUFFER_WIDTH], lcdInfo->Width * 2);
}

LcdFlush(lcdInfo);

}

void EmuSetupTimer()
{
TimerAttach(1, EmuTick); // As fast as possible
}

void EmuSetupRegularLoop()
{
while(true)
EmuTick(); // TODO: If elfloader port will be usable on Android, add FPS limit :)
}

int ElfMain(unsigned int* basePtr, void* test)
{
lcdInfo = LcdInit();

ctx = emuInitialize();
if(!emuLoadROM(nes_rom, sizeof(nes_rom)))
{
UtilPrint("Failed to load ROM");
return 100;
}

emuReset();

switch(GetMainLoopType())
{
case PLATFORM_LOOP_MMI_TIMER:
EmuSetupTimer();
break;
case PLATFORM_LOOP_REGULAR:
EmuSetupRegularLoop();
break;
}

return 100;
}

А вот и результат:

❯ Заключение

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

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

Очень важно! Разыскиваются девайсы для будущих статей!

Друзья! Если вам понравилась сегодняшняя статья про разработку эльфов, то спешу объявить: для подготовки будущих материалов с разработкой самопальных игрушек под необычные устройства, объявляется розыск телефонов и консолей! В 2000-х годах, китайцы часто делали дешевые телефоны с игровым уклоном — обычно у них было подобие геймпада (джойстика) или хотя бы две кнопки с верхней части устройства, выполняющие функцию A/B, а также предустановлены эмуляторы NES/Sega. Фишка в том, что на таких телефонах можно выполнять нативный код и портировать на них новые эмуляторы, чем я сейчас занимаюсь, а затем написать об этом подробную статью и записать видео! Если у вас есть телефон подобного формата и вы готовы его задонатить или продать, пожалуйста напишите мне в Telegram (@monobogdan) или в комментарии. Также интересуют смартфоны-консоли на Android (на рынке РФ точно была Func Much-01), там будет контент чуточку другого формата :)

А также я ищу старые (2010-2014) подделки на брендовые смартфоны Samsung, Apple и т. п. Они зачастую работают на весьма интересных чипсетах и поддаются хорошему моддингу, парочку статей уже вышло, но у меня ещё есть идеи по их моддингу! Также может у кого-то остались самые первые смартфоны Xiaomi (серии Mi), Meizu (ещё на Exynos) или телефоны на Linux (например Motorola EM30, RAZR V8, ROKR Z6, ROKR E2, ROKR E5, ZINE ZN5 и т. п., о них я хотел бы подготовить специальную статью и видео т. к. на самом деле они работали на очень мощных для своих лет процессорах, поддавались серьезному моддингу и были способны запустить даже Quake!). Всем большое спасибо за донаты!

Всем привет с вами ARTOMI44 Retro mobile сегодня будет про телефоны в детстве в 2000х

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

И даже никаких сертификатов ударопрочности/водостойкости у Nokia 3310 не было. И не нужно было — телефон оказался настолько прочным, что «продавал сам себя»! Да ещё и стоил недорого, поэтому Nokia продали свыше сотни миллионов таких трубок, а о надёжности этой модели легенды (и краш-тесты) ходят до сих пор.

Siemens ME45 (2001 год)

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

людей, что, впрочем, не мешало любителям апгрейдить (тогда ещё не без помощи программатора) «Мессер» прошивкой от более престижного Siemens S45.

Огромная записная книжка, диктофон с продолжительностью записи аж до трёх минут (чего вы смеётесь? Бывало и хуже), поддержка GPRS и ИК-порт для модемно-компьютерных нужд. Универсальное орудие любителей навороченных и при этом прочных телефонов. А ещё не стоит забывать об одном из первых телефонов MP3-плееров с поддержкой карты памяти — Siemens SL45!

Почему? Ну, например, потому, что это был один из первых на Земле мобильников с цветным экраном и «полным фаршем» по состоянию на 2002 год. Наличие Bluetooth, ИК-порта, поддержка MMS, возможность ваять свои, пусть и монофонические, мелодии. Компактный корпус и новаторский по тем временам джойстик вместо клавиш-стрелочек (потом пользователи Sony Ericsson этот джойстик проклянут, но это уж потом).

В общем, японо-шведы завоевали любовь народа очень удачным, толковым, с какой стороны ни посмотри, флагманом 2002 модельного года.

Сегодня о том, что мобильники Sony проектировались совместно с «каким-то там» Ericsson, почти никто и не вспомнит. А ведь именно благодаря совместному со шведами концерну знаменитый производитель «видаков и теликов» стал популярен на мобильном рынке. T68i стал одной из причин такого успеха

Samsung C100 (2003)

В далёком 2003 году Samsung была на мобильном рынке чем-то сродни нынешнему HTC — то есть, язык не повернётся сказать, что компания не умеет производить качественные телефоны, но «выстреливают» из них явно не все и не всегда.

Но Samsung сделал модель, которая «выстрелила» — сверхтонкая (сейчас будете смеяться — 17 мм), пафосная, крутая и относительно доступная трубка с индексом C100 превратила Samsung из «выскочки» в компанию с «полифонически-цветасто-экранным» имиджем.

Потому что да — дисплей на базе UFB-матрицы был ярче и круче, чем CSTN и TFT TN у конкурентов, а 40-голосная полифония пела просто на уровне «супер-люкс» в сравнении с тусклыми напевами в Nokia или Siemens. А ещё C100 был абсолютно «безглючным» и стабильным, что в моделях с навороченной мультимедиа-составляющей того времени было редкостью.

Motorola MPx200

Характеристики смартфонов-мото были неплохими, но не сногсшибательными — процессор ARM OMAP 710 с частотой 120 МГц и 32 Мбайт ОЗУ (для Windows — средняя величина), но даже при такой начинке MPx200 был гораздо ближе к нашему смартфонному настоящему, чем другие модели по такой же цене. Поэтому на старую Моторолу продолжали портировать новые версии Windows (почти как с нынешними ведроидами, да?) даже спустя годы после того, как производитель перестал поддерживать её новыми версиями ПО.

Siemens SX1 (2003 год)

Поймите правильно — мы даже и не пытаемся оспорить первенство и величие Nokia в производстве Symbian-смартфонов, но моделей с четырёхзначными индексами была тьма, и не понятно, почему «котлету» Nokia 6600 нужно отметить, а первопроходца, 7650, бюджетный 3650 или игровую N-Gage, нет. Случались у Nokia за «двухтысячные» и более яркие модели, а вот «сЫЧ» такой один — первый и последний Symbian-смартфон Siemens.

Потому что: «взрослая» по качеству и возможностям фотокамера, поддержка всех мыслимых аудиоформатов, быстрый и стабильный ИК-порт, очень крутая и производительная Java-машина, которая умела работать в фоне (очень пригождалось для того, чтобы держать там «аську») и сохранять данные во внутренней памяти (полезно для игр и Opera Mini). Отличная модель для повседневной эксплуатации, долговечность которой портил только чёртов, будь он проклят, джойстик (хорошо, больше не буду о нём вспоминать).

Потому что: «взрослая» по качеству и возможностям фотокамера, поддержка всех мыслимых аудиоформатов, быстрый и стабильный ИК-порт, очень крутая и производительная Java-машина, которая умела работать в фоне (очень пригождалось для того, чтобы держать там «аську») и сохранять данные во внутренней памяти (полезно для игр и Opera Mini). Отличная модель для повседневной эксплуатации, долговечность которой портил только чёртов, будь он проклят, джойстик (хорошо, больше не буду о нём вспоминать).

Siemens M65 (2004 год)

Знаете что? Я тоже душой болел и болею за «фаблет» того времени — Siemens CX65, но коль уж мы ограничены в количестве смартфонов для сегодняшней статьи, стоит упомянуть «танк» под индексом M65. Корпус с металлической рамой, устойчивый к ударам, попаданию воды и пыли, огромный и яркий по меркам 2004 года дисплей, громкий динамик, ИК-порт без ограничений на тип передаваемых файлов (а то бывали подлянки у этих ваших нокий и самсунгов…), возможность тюнинговать прошивку «эльфами» — исполняемыми файлами наподобие «ведроидного» Xposed, только лучше… Да много чего можно было сотворить с этим телефоном в программном плане. Кроме нормальной поддержки файлов MP3, разве что.

Motorola E398 (2004 год)

Motorola начала двухтысячных раздражала покупателей вечно «тормозным» меню и не очень-то стабильными прошивками, да и по качеству съёмки на первые в мобильниках камеры не блистала. Зато в Мото были «фишки», которые хваленые Nokia, Siemens и Sony Ericsson были неспособны предложить ни до, ни после выхода знаковых моделей «большой М».

Одной из таких была Motorola E398 — «бумбокс в кармане». Телефон с мощными стереодинамиками, который сотрясали корпус на максимальной громкости, доступной ценой и поддержкой новых карт памяти типа microSD.  Потом на основе E398 Apple даже решила создать «недоайфон» — ROKR E1 с поддержкой Apple iTunes, но это уже отдельная, грустная история.

Motorola RAZR V3 (2004 год)

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

Motorola RAZR V3

Даже сама Моторола не ожидала, что RAZR настолько «выстрелит» — разработчикам было не привыкать создавать эффектные модели с необычной внешностью. Но в случае с V3 создателям удалось упаковать все «вкусности»  современных моделей (два цветных дисплея, поддержку современных «фишек», от MMS до MP3 и GPRS) в приемлемую для большинства покупателей цену. Нет, RAZR не был дешёвым, но и не стоил на уровне витающих в облаках флагманов.

Вопреки дефициту памяти (10 Мбайт), медлительности, плохой автономности, короткому ходу клавиш мобильник стал хитом — настолько хитом, что со дня выхода V3 Моторола продолжала выпускать «рестайлинги» нашумевшего смартфона и производить телефоны-моноблоки SLVR, эксплуатируя один и тот же дизайн, пока «внезапно» эпоха смартфонов похоронила всю компанию почти на корню. О том, что произошло с Moto дальше

Nokia N70 (2005 год)

*пролистав список из всех Symbian-смартфонов*. А, бог с ними — предлагаю вспомнить добрым словом Nokia N70 — модель-олицетворение роскоши и достатка Symbian-смартфонов. Когда архаичные модели на базе Symbian 6.x окончательно ушли в прошлое, а разухабистая гвардия моделей на базе новой S60 3rd (а вы помните, как весело было взламывать сертификаты на ваших старых Симбианфонах?) ещё не появилась на свет, N70 была идеальным «бюргерским» смартфоном.

Наконец-то с «тоннами» оперативной памяти (старая проблема Symbian), хорошим звуком, мощным процессором, качественной камерой, практически без недостатков. Потом, когда Nokia стала плодить Symbian-модели в огромном количестве, на свет появились и «калькуляторного» дизайна E71, и смартфон-суперкамера N90, и «мобильный компьютер» Nokia N95 (и гвардия её подделок), но, пожалуй, именно начиная с N70 Симбиан-смартфоны обзавелись по-настоящему актуальным железом и с тех пор просто наращивали «мускулы» в избыточную сторону да улучшали качество дисплеев и камер.

Sony Ericsson M600i (2006 год)

Да-да, я решил вспомнить о «коммуникаторах с человеческим лицом» — сенсорных Symbian UIQ, которая самолично развивали Sony Ericsson. С академической точки зрения начать следовало бы с 2002 года и выхода SE P800, но если уж быть реалистами, то с самого своего появления P-серия была неистово дорогой, приложения от Symbian S60 нельзя было установить на менее массовые «сониэрики», а бизнес-аудитория давно и плотно использовала Windows-коммуникаторы, о которых в этой статье подробно рассказывать не хочется — утонем в их количестве и характерных особенностях.

Sony Ericsson M600i

Так вот — M600 стал первым мало-мальски «народным» коммуникатором под управлением Symbian UIQ. Без откидной крышки с клавиатурой, зато с клавишами «двойного назначения» при вводе текста, со смартфонной наружностью и фирменным колесиком JogDial (о-о-о, это старая история, которая пошла ещё со времён «чистокровных» мобильников Sony). Эту модель выбирали те, кому до чёртиков надоели смартфоны Nokia и не приглянулись редкие смартфоны Samsung — корейцы тогда хватались за всё подряд и выпускали хорошие модели, но все они были «пресными», «без души», и поэтому популярностью почти не пользовались.

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

Nokia 8800 (2005 год)

«Шестисотый мерседес» среди мобильных телефонов, главный антисмартфон и живое доказательство, что вызывать симпатию у энтузиастов и не разбирающихся в технике людей может одна и та же модель. Разумеется, до 8800 у Nokia было немало других имиджевых моделей (например, старая 8910), но только эта модель стала именем нарицательным, брендом в себе, так сказать.

В 2005 году символом качества был стальной корпус (не эти кастрюли, что в ваших китайфонах, а качественно другой корпус), автодоводчик для раскрытия корпуса и привычное сегодня «не царапающееся» стекло поверх дисплея. Аппаратная начинка — наполовину хорошая, наполовину смехотворная. Всего лишь 64 мегабайт (мегабайт!!!) встроенной памяти и тоскливая уже в те времена 0,3-мегапиксельная камера, зато супер-красивые рингтоны (их создавали по заказу в сотрудничестве с знаменитым японским композитором) и качественный дисплей с достойным для такой диагонали разрешением 208x208 пикселей.

Sony Ericsson K790i (2006 год)

Критиковать Sony за их своенравие спустя годы — беспроигрышное занятие. Но именно упрямство японской компании поспособствовало выпуску мобильников, в которых все функции были доведены до абсолюта. От топорного, но уже интересного функционально K700 компания перешла к супер-хиту K750i и его Walkman-клону W800i, а затем, пока Motorola упивалась дизайном своих RAZR, а Nokia штамповала «пресные» Symbian-смартфоны, Sony Ericsson выпустили «памятник» быстрым и качественным «просто мобильникам». А заодно и фотофлагман своего времени.

Sony достали из кармана привычный по фирменным фотоаппаратам-«мыльницам» бренд Cybershot, сделали тыловую панель мобильника похожей на ту, что в фотокамерах, не поскупились на качественный сенсор и довели быстродействие операционной системы и Java-приложений (да, J2ME уже понемногу «умирала», и всё же) до самого высокого уровня. Прибавим к этом традиционно качественный звук в Sony-телефонах, и получаем почти идеальный аппарат для тех, кому хватало одного быстрого мессенджера в фоне и не перегруженного хитроумной операционной системой мобильника для повседневного использования. Безусловно, от любви с первого взгляда всегда помогает второй взгляд, и попади сегодня к нам в руки K790i, он бы вряд ли впечатлил нас, как в момент своего дебюта, но сама идея качественного, быстрого, всесторонне развитого не-смартфона давно канула в Лету. И вы все знаете, кто в этом виноват…

На Хабре довольно часто публикуются статьи с ретроспективными обзорами на телефоны прошлых лет, где авторы рассказывают о том, как заполучили желаемый гаджет, показывают его фишки и даже дают послушать те самые рингтоны... Однако гикам такой ретроспективы уж точно будет мало и поэтому я решил попробовать начать вести новую рубрику, в которой мы с вами будем не только ностальгировать по легендарным моделям, но и досконально изучать их аппаратную часть. Интересно узнать, за что отвечает каждый чип в легендарном "Сименсе"? Тогда добро пожаловать под кат!

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

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

Начав свой путь в мобильном бизнесе ещё в 1985 году, Siemens успела внести свой след в историю как компания, которая в некоторых аспектах опережала время: первый телефон с цветным дисплеем (Siemens S10), с поддержкой Java (Siemens SL45) и с основным OLED-дисплеем (Benq-Siemens S88). Не менее интересен и тот факт, что Siemens сделала большинство аппаратных платформ для своих телефонов сама (вернее, её дочка Infineon)!

❯ Что внутри?

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

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

Как пример - дисплей, который здесь подходит еще от ~5 моделей A, S и C-серии. Во всей 55-ой линейке используется CSTN матрица разрешением 101x80, с не очень качественной цветопередачей... но для тех лет вполне нормально. В нашем случае, дисплей прижимается контактами к плате телефона. Решение практичное, но не без недостатков: многие сименсы спустя годы лежания в тумбочках при включении показывают белый экран из-за грязи и окислов, и их незаслуженно отправляют в помойку как "нерабочие". При этом количество самих пинов достаточно маленькое по сравнению с современными устройствами: всё потому что общение с дисплеем происходило через 2х-пиновую шину SPI (MOSI и CLK). Остальные пины - CS, масса, питание подсветки и самого контроллера дисплея.

Что примечательно - не все версии прошивки поддерживали дисплеи от других E-Gold'ов, иногда её приходилось обновлять с помощью дата-кабеля. Среди моих дисплеев от сименсов был один условно подходящий, но с ним телефон давал изображение на 500мс и уходил в "белый экран".

Однако самое интересное скрывается у нас под защитными экранами. Сразу под клавиатурой у нас находится процессор, оперативная память, флэш память и контроллер питания. Но с каждым - по порядку:

В качестве процессора используется система на кристалле Infineon PMB7850, которая состоит из:

• Микроконтроллера на архитектуре C166S собственной разработки Infineon, работающий на частоте 52МГц. В его задачи входит отрисовка изображения на дисплей, воспроизведение звуков (MIDI, WAV), обработка ввода и всего того, что вы видите на экране телефона.

• Вспомогательного DSP TeakLITE, который занимается задачами работы с GSM-сетью: декодирование и кодирование звука в формате AMR, работа с сигналами и даже декодер MP3 (к сожалению, на сименсах не использовался).

• Периферийные модули для общения с внешними устройствами - UART для общения с компьютером и ИК-порта, I2C для дисплея и контроллера питания, I2S для звука, а также модуль для работы с MMC-карточками (55-я серия теоретически поддерживала флэшки!)

• Контроллера Flash-памяти и ОЗУ, а также 2Мбит встроенной SRAM-памяти.

Снизу располагается чип PSRAM памяти объёмом 2МБ от компании AMD. Судя по всему, E-Gold не поддерживал DRAM из-за микроконтроллерной направленности и вынужден был использовать более дорогую псевдостатическую память. А чуть правее расположился чип флэш-памяти объёмом 16МБ - и его хватало для ОС, прошивки модема и даже пользовательских данных!

Правее процессора находится контроллер питания TWIGO, в задачи которого входит мониторинг состояния самого процессора (если процессор долго не посылает сигналы КП, Watchdog отключает устройство), обработка кнопки включения, формирование напряжений для всех чипов, зарядка аккумулятора, а также ЦАП и усилитель звука.

Снизу можно заметить пустую контактную площадку, которая предназначается для монтажа Bluetooth-модуля. Дело в том, что все телефоны 55-ой линейки по сути идентичны, различия лишь в так называемых "вариантах" судя по схеме.

С обратной стороны платы можно обнаружить радиочасть: трансивер, фронтэнд, усилитель сигнала, а слева - драйвер подсветки для дисплея. Снизу же расположился 12-пиновый разъем Lumberg и рядом стекляшка - EMIF-фильтр для защиты линий RS232 от помех и пробоя. Помимо зарядки и подключения к ПК, Lumberg также служил для подключения гарнитуры и аксессуаров. И один из самых известных аксессуаров - это, конечно, внешняя камера! Даже сейчас люди делают фотографии на неё!

И... на этом собственно всё! Вот такой простой конструктив был у данного телефона. При этом E-Gold'ы были достаточно надежными и стойко переносили падения об асфальт... чего не скажешь об устройствах 65'ой серии. Но об этом поговорим в другой статье, а сейчас перейдем к программной части.

❯ Программная часть

Когда во втором абзаце статьи я сказал о том, что телефоны Siemens были неоднозначными, я подразумевал именно их прошивку. Местами запутанная, нелогичная, относительно медленная... и при всём этом её можно назвать одновременно функциональной и обрезанной!

По слухам, UI-часть прошивки разрабатывал подрядчик из Польши и он же слил диагностический билд "прошивки" под Windows со всеми отладочными символами. Благодаря сливу, моддеры смогли разобраться в внутренней архитектуре оболочки и сделать свои собственные патчи, вносящие полезные и не очень изменения в телефон, а во времена x65 даже написать загрузчик отдельных нативных программы - эльфов.

И даже без патчей и эльфов, сименсы были достаточно функциональными. Многие модели имели возможность запуска Java-приложений, при этом Siemens сделал огромный вклад в развитие J2ME. Всё дело в том, что практически весь Siemens API в S55 (и M55/C55 соответственно) перекочевал в неизменном виде в спецификацию MIDP 2.0. Почти с самого начала, приложения для Siemens имели доступ к файловой системе устройства, а чуть позже смогли общаться с внешними аксессуарами через UART:

В MIDP 1.0 не было даже API для проигрывания звуков и отрисовки произвольных изображений, оно было крайне ограниченным, а множество фишек были Vendor specific (именно поэтому появлялись игры в версиях для Samsung, LG, Sony Ericsson, Nokia и т.п.).

Помимо этого, сименсы отличались "свободной" файловой системой и позволяли невозбранно подменять RMS в играх (сохранения), а также обмениваться мультимедией и jar-файлами через Bluetooth и ИК-порт. Пользователь мог использовать как приложение "Мои файлы", где всё упорядочено по типам файлов, так и "CardExplorer", где была полная свобода воли. А через мастер памяти можно было воспроизводить "неподдерживаемые" форматы по типу 3gp-видео:

И именно в этом был главный минус сименсовского ПО. Многие фичи по факту были реализованы, но на практике отключены в прошивке и до них можно было добраться только самыми нелогичными путями. Например, C65 не умел записывать видео в обычном режиме (при том что почти полный функциональный аналог в лице C72 - умел), но мог записать 3х-секундный ролик для MMS-сообщений. Были вопросы и к качеству звука - аудиостек устройства на первый взгляд не поддерживал звук с частотой дискретизации выше 16кГц (напомню что в GSM для звонков используется 11050Гц - вот и представьте себе качество звука), из-за чего даже MIDI-мелодии звучали "так себе", но после установки соответствующего патча на x65-серию, появлялась поддержка частоты дискретизации 44100Гц.

Одна из главных проблем, которая по итогу значительно повлияла на продажи телефонов Siemens - это отсутствие поддержки MP3 в поздних телефонах. На самом деле, MP3 появился ещё в SL45 в виде внешнего модуля, который представлял из себя обычный внешний плеер, управляемый с экрана телефона, однако далее ситуация была довольно странной. Ни один телефон на платформе E-Gold, кроме SL45, вообще не поддерживал MP3, а на S-Gold и NSG (x65 и выше) когда как. Где-то (CX75) поставили внешний чип MP3-декодера, где-то сделали программный декодер (E71/EL71), а где-то вообще ничего не сделали. При этом поддержки MP3 не имел даже флагманский S65, при том что у него был слот для MMC-карточек! Самое забавное то, что моддеры (одним из которых был @ilya_zx ) ближе к 2007 году реализовали полностью рабочий программный MP3-плеер даже на C65!

❯ Заключение

Вот такой интересный контент о легендарном "семене" у нас с вами получился. Как говорится, всё гениальное - просто, а платформа E-Gold - простая как табуретка, что и обеспечивало этим "сименсам" репутацию очень надежных устройств вплоть до появления 65-ой серии...

Почему до 65-ой? Если вам интересно узнать ответ, то жду вашего фидбека о новой рубрике в комментариях. Возможно я сделаю её постоянной и статьи в ней будут выходить как минимум раз в месяц!

А если вам интересна тематика ремонта, моддинга и программирования для гаджетов прошлых лет — подписывайтесь на мой 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!). Всем большое спасибо за донаты!

"Пожарник" - Siemens M55! Я сделал ролик с рассказом о том, что это за аппарат такой, что у него находится "под капотом" и на какой аппаратной платформе он построен, ну и ностальгически "потыкал"))

YouTube:

ВК (подтянется чуть позже, ещё на обработке):