У @w23 (он же provod), которого вы наверняка знаете, давно была неплохая серия статей про написание демок для Linux, где он описывал все эти подводные камни там, почитайте на досуге если интересно, начало здесь: Создание 1k/4k intro для Linux, часть 1.
Спасибо за интересную статью. Кстати, можете посоветовать какой-нибудь удобный и функциональный HEX-редактор? В различных инструментах реверс-инжиниринга типа IDA Pro зачастую встроенные HEX-редакторы достаточно простенькие и различные полезные и часто используемые операции над бинарными файлами по типу: сохранить выделенный кусок в отдельный файл, добить файл определённым байтом до нужного размера и прочие подобные делаются в них несколько топорно и неудобно.
Там не Linux, к сожалению, а Qualcomm'овская платформа, скорее всего AMSS + REX OS, приправленная шкуркой Siemens, ну и поддержка запуска BREW-приложения должна быть.
Siemens SXG75 телефон действительно классный, даже и без Linux'а.
Перепрошивка Motorola Milestone довольно тривиальна и может быть выполнена не только в Windows через RSD Lite, но и в Linux с помощью утилиты sbf_flash. Недавно кто-то на форуме где обсуждают устройства Motorola как раз писал об успешной прошивке Milestone этой утилитой. Где-то тут: https://forum.motofan.ru/index.php?s=&showtopic=175745&view=findpost&p=1796157, последняя официальная прошивка для Milestone как раз с Android 2.2.1 и относительно чистым Android'ом.
P.S. Автору статьи возможно будет интересен метод разгона CPU на его железке, хотя и не знаю зачем он там ему нужен, он тоже работает через подгрузку кастомного модуля ядра, вот исходники и пару интересных страничек в Wiki посвящённых Kernel Hacking на схожем SoC:
Интересно, для 176x220 (16-bit на пиксель) и для 128x160 (тоже 16-bit на пиксель) какие значения будут? Вообще ваши расчёты внушают некоторый оптимизм, потому что я могу выделить по сути 1400 КБ, хотя у меня там ещё аллоцирование частями насколько я помню, этот момент тоже нужно будет проработать.
Да вот тоже есть парочка старых мобильных телефонов с возможностью запускать собственный исполняемый код, но RAM там всего ~1.5 MB, поэтому интересны облегчённые порты.
При 4 мегабайтах RAM на дешевых моделях - запустить игру вместе с ОС из прошивки - невозможно, только если сделать режим, когда прошивка выгружается (и функции сотовой связи работать не будут), а после выхода из игры загружается снова. При 8 мегабайтах памяти хватит, это чип SC6531H (совместимый с E).
Спасибо за ответ, а вы не в курсе, есть ли в природе какие-нибудь версии и порты DOOM, где подобные ограничения сняты и игра вмещается в 1-2 МБ RAM?
Было бы здорово, если бы вы перечислили технические характеристики упомянутых вами SOC'ов, интересует частота CPU и количество RAM.
Такой ещё вопрос, есть ли теоретическая возможность запустить подобный порт DOOM'а не в режиме bootloader'а, а в режиме самой прошивки? По типу того, как это было сделано в старых телефонах Sony Ericsson и Siemens посредством Elf'ов и специальных патчей. Подозреваю что всё может упереться в количество RAM.
использованы исходники ванильной версии Doom от id Software
Были ли использованы какие-либо оптимизации ванильных исходников для их работы на этих устройствах? Или мощности этих SOC для DOOM'а хватает с лихвой?
Артём, спасибо вам большое за интересную статью, видеоролик и вообще ваше творчество, которое вдохновляет!
Я вот вспомнил, что тоже когда-то давно интересовался EL-индикаторами, когда обнаружил что в подсветке клавиатуры некоторых старых мобильных телефонов используется именно эта технология вместо всем привычных светодиодов. Видимо подобное решение было распространено у тех производителей мобильных телефонов которые хотели, чтобы подсветка была равномерной и красиво выглядела в темноте.
Когда разбирал Motorola V150 для ремонта я обнаружил, что если притронуться пальцем к одному металлическому выводу, получишь весьма ощутимый удар током. Стало интересно откуда там берётся высокое напряжение, оказалось оно идёт на гибкую розовую пластину, которую я изначально посчитал просто подложкой клавиатуры. При включении телефона розовая пластина начинала светить довольно ярким молочно-белым светом. Пластинка напоминала собой что-то вроде самоклеющейся наклейки-стикера. Интересно, какой там люминофор и технология изготовления были задействованы?
А питалось оно, если я правильно помню по сервис-мануалам, от ~220 V переменки какой-то высокой частоты, помнится была ещё миниатюрная катушка выполненная в SMD там какая-то, видимо высоковольтный трансформатор или дроссель.
Даже вот фотографии нашёл 15-летней давности с какого-то телефона и схемы из сервис-мануала, извиняюсь за их качество.
А ещё светло-голубая EL подсветка клавиатуры была в Motorola RAZR V3 и огромной куче его модификаций, а также в слизанной с RAZR раскладушке BenQ-Siemens EF81. Тоже выполненная на гибкой подложке.
Что интересно, при различных повреждениях телефона, например, в результате падения, высокое напряжение могло попасть на металлические части корпуса телефона. А обе эти раскладушки были high-end класса и их корпуса были почти полностью выполнены из анодированного алюминия, соотвественно при включении подсветки клавиатуры человека могло ощутимо ударить током, особенно при ответе на вызов раскрытием раскладушки прямо в щёку. Когда были актуальны эти мобильные телефоны на различных форумах иногда встречались темы вида "упал телефон, теперь бьётся током", да и сам я сталкивался с подобным на EF81.
Ещё из типичных неполадок применяемых EL-подсветок в телефонах был высокочастотный писк этого самого преобразующего трансформатора, который в некоторых случаях повреждения катушки был вполне различим для человеческих и зверинных ушей. Помнится где-то видел забавный видеоролик, когда при включении подсветки клавиатуры на RAZR V3 кошка лежащая на диване убегала подальше от этого телефона.
Кстати, покрашенный красный прямоугольник на EL-пластинах RAZR V3 и EF81 на фотографиях выше использовался для обозначения красной трубки, поскольку эта белая пластина светилась красивым бледно-голубым светом. А вот для зелёной трубки такого закрашенного прямоугольника не делали, видимо потому что плёночный светофильтр внутри самой кнопки в случае преобразования голубого цвета в зелёный вполне справлялся со своей работой.
Вот такой информацией решил поделиться, может она будет кому-нибудь интересна.
Интересно, хватит ли столь скромных технических характеристик устройства по части памяти для реализации этих самых Elf-программок, которые были на Siemens, Sony Ericsson и Motorola? Этим как раз можно было бы "оживить" пункт Funbox, забив его не nop'ами, а ELF-loader'ом, который бы читал список Elf'ов откуда-нибудь из директории Elfs на карте памяти. Как раз и название подходящее. Жаль только всё это займёт куда больше времени чем просто патчинг, а благодарная аудитория будет совсем небольшой. Всё-таки сегодня не середина нулевых. P.S. кому интересно, материал по теме:
Серверная подсветка — простейший пример библиотеки, которая недоступна для определённой платформы, но доступна на других нескольких. Поэтому для демонстрационного примера и был выбран именно этот тип библиотек.
С тем же успехом можно рассматривать какую-нибудь полезную научную батарейку, написанную на Python или R, что-нибудь из ML и т. д. Тут просто сложнее найти пример полезного для нескольких языков сразу и отсутствующего в Java, а мне именно что хотелось попробовать совместить всё вместе и посмотреть, что получится :)
Поэтому я несколько не понимаю выпады в сторону аргументации. Увольте, но в споре о том чьё болото лучше и где батареек больше, я учавствовать и не хотел. Лишь поинтересовался ситуацией с подобной задачей в мире C# и .NET и удивлён, что мой вопрос восприняли несколько странно. Это же просто инструменты, не так ли? Если С# и .NET будет в какой-то позиции использовать выгоднее, сам с удовольствием выберу его.
А для C# имеются библиотеки серверной подсветки синтаксиса для самых разных языков программирования? То бишь аналоги Highlight.js, Rouge или Pygments? Насколько я могу судить, ситуация там точно такая же, как и в случае с языками JVM-стека, когда имеются полузаброшенные порты Pygments, охватывающие лишь самую малую часть необходимого:
Нет, это не перевод. Компилятор при отсутствии объявления ругается следующим образом:
malloc.c:153:1: error: static declaration of ‘morecore’ follows non-static declaration
malloc.c:124:5: note: previous implicit declaration of ‘morecore’ was here
124 | morecore(bucket);
| ^~~~~~~~
Я не слишком вникал в эту проблему, но кажется отсутствие явного объявления статической функции является частным случаем расхождения сигнатуры. Возможно привёл не слишком удачную ссылку на Stack Overflow.
Теперь осталось подменить музыку в лифте на эту (:
У @w23 (он же provod), которого вы наверняка знаете, давно была неплохая серия статей про написание демок для Linux, где он описывал все эти подводные камни там, почитайте на досуге если интересно, начало здесь: Создание 1k/4k intro для Linux, часть 1.
Отличная статья, спасибо, прочитал с удовольствием! Как вижу с творчеством Řrřola вы уже знакомы.
В своё время меня очень сильно впечатлила 32-байтная демка Dírojed от этого разработчика.
Выглядит очень эффектно, а если оставить её на экране подольше, то можно узреть как зарождается жизнь :D
Спасибо за интересную статью. Кстати, можете посоветовать какой-нибудь удобный и функциональный HEX-редактор? В различных инструментах реверс-инжиниринга типа IDA Pro зачастую встроенные HEX-редакторы достаточно простенькие и различные полезные и часто используемые операции над бинарными файлами по типу: сохранить выделенный кусок в отдельный файл, добить файл определённым байтом до нужного размера и прочие подобные делаются в них несколько топорно и неудобно.
Там не Linux, к сожалению, а Qualcomm'овская платформа, скорее всего AMSS + REX OS, приправленная шкуркой Siemens, ну и поддержка запуска BREW-приложения должна быть.
Siemens SXG75 телефон действительно классный, даже и без Linux'а.
Перепрошивка Motorola Milestone довольно тривиальна и может быть выполнена не только в Windows через RSD Lite, но и в Linux с помощью утилиты
sbf_flash. Недавно кто-то на форуме где обсуждают устройства Motorola как раз писал об успешной прошивке Milestone этой утилитой. Где-то тут: https://forum.motofan.ru/index.php?s=&showtopic=175745&view=findpost&p=1796157, последняя официальная прошивка для Milestone как раз с Android 2.2.1 и относительно чистым Android'ом.P.S. Автору статьи возможно будет интересен метод разгона CPU на его железке, хотя и не знаю зачем он там ему нужен, он тоже работает через подгрузку кастомного модуля ядра, вот исходники и пару интересных страничек в Wiki посвящённых Kernel Hacking на схожем SoC:
https://code.google.com/archive/p/milestone-overclock/downloads
https://code.google.com/archive/p/milestone-overclock/wikis
Интересно, для 176x220 (16-bit на пиксель) и для 128x160 (тоже 16-bit на пиксель) какие значения будут? Вообще ваши расчёты внушают некоторый оптимизм, потому что я могу выделить по сути 1400 КБ, хотя у меня там ещё аллоцирование частями насколько я помню, этот момент тоже нужно будет проработать.
В общем, спасибо за информацию.
Спасибо, посмотрел, но к сожалению ничего там не нашёл по поводу оптимизации по потреблению памяти.
Да вот тоже есть парочка старых мобильных телефонов с возможностью запускать собственный исполняемый код, но RAM там всего ~1.5 MB, поэтому интересны облегчённые порты.
Спасибо за ответ, а вы не в курсе, есть ли в природе какие-нибудь версии и порты DOOM, где подобные ограничения сняты и игра вмещается в 1-2 МБ RAM?
Было бы здорово, если бы вы перечислили технические характеристики упомянутых вами SOC'ов, интересует частота CPU и количество RAM.
Такой ещё вопрос, есть ли теоретическая возможность запустить подобный порт DOOM'а не в режиме bootloader'а, а в режиме самой прошивки? По типу того, как это было сделано в старых телефонах Sony Ericsson и Siemens посредством Elf'ов и специальных патчей. Подозреваю что всё может упереться в количество RAM.
Были ли использованы какие-либо оптимизации ванильных исходников для их работы на этих устройствах? Или мощности этих SOC для DOOM'а хватает с лихвой?
А поделитесь пожалуйста своим набором тестовых md-файликов, которые вы прогоняете на различных парсерах.
Артём, спасибо вам большое за интересную статью, видеоролик и вообще ваше творчество, которое вдохновляет!
Я вот вспомнил, что тоже когда-то давно интересовался EL-индикаторами, когда обнаружил что в подсветке клавиатуры некоторых старых мобильных телефонов используется именно эта технология вместо всем привычных светодиодов. Видимо подобное решение было распространено у тех производителей мобильных телефонов которые хотели, чтобы подсветка была равномерной и красиво выглядела в темноте.
Когда разбирал Motorola V150 для ремонта я обнаружил, что если притронуться пальцем к одному металлическому выводу, получишь весьма ощутимый удар током. Стало интересно откуда там берётся высокое напряжение, оказалось оно идёт на гибкую розовую пластину, которую я изначально посчитал просто подложкой клавиатуры. При включении телефона розовая пластина начинала светить довольно ярким молочно-белым светом. Пластинка напоминала собой что-то вроде самоклеющейся наклейки-стикера. Интересно, какой там люминофор и технология изготовления были задействованы?
А питалось оно, если я правильно помню по сервис-мануалам, от ~220 V переменки какой-то высокой частоты, помнится была ещё миниатюрная катушка выполненная в SMD там какая-то, видимо высоковольтный трансформатор или дроссель.
Даже вот фотографии нашёл 15-летней давности с какого-то телефона и схемы из сервис-мануала, извиняюсь за их качество.
А ещё светло-голубая EL подсветка клавиатуры была в Motorola RAZR V3 и огромной куче его модификаций, а также в слизанной с RAZR раскладушке BenQ-Siemens EF81. Тоже выполненная на гибкой подложке.
Что интересно, при различных повреждениях телефона, например, в результате падения, высокое напряжение могло попасть на металлические части корпуса телефона. А обе эти раскладушки были high-end класса и их корпуса были почти полностью выполнены из анодированного алюминия, соотвественно при включении подсветки клавиатуры человека могло ощутимо ударить током, особенно при ответе на вызов раскрытием раскладушки прямо в щёку. Когда были актуальны эти мобильные телефоны на различных форумах иногда встречались темы вида "упал телефон, теперь бьётся током", да и сам я сталкивался с подобным на EF81.
Ещё из типичных неполадок применяемых EL-подсветок в телефонах был высокочастотный писк этого самого преобразующего трансформатора, который в некоторых случаях повреждения катушки был вполне различим для человеческих и зверинных ушей. Помнится где-то видел забавный видеоролик, когда при включении подсветки клавиатуры на RAZR V3 кошка лежащая на диване убегала подальше от этого телефона.
Кстати, покрашенный красный прямоугольник на EL-пластинах RAZR V3 и EF81 на фотографиях выше использовался для обозначения красной трубки, поскольку эта белая пластина светилась красивым бледно-голубым светом. А вот для зелёной трубки такого закрашенного прямоугольника не делали, видимо потому что плёночный светофильтр внутри самой кнопки в случае преобразования голубого цвета в зелёный вполне справлялся со своей работой.
Вот такой информацией решил поделиться, может она будет кому-нибудь интересна.
Интересно, хватит ли столь скромных технических характеристик устройства по части памяти для реализации этих самых Elf-программок, которые были на Siemens, Sony Ericsson и Motorola? Этим как раз можно было бы "оживить" пункт Funbox, забив его не
nop'ами, а ELF-loader'ом, который бы читал список Elf'ов откуда-нибудь из директории Elfs на карте памяти. Как раз и название подходящее. Жаль только всё это займёт куда больше времени чем просто патчинг, а благодарная аудитория будет совсем небольшой. Всё-таки сегодня не середина нулевых. P.S. кому интересно, материал по теме:Спасибо вам за интересную статью.
Существует такой вот проект https://github.com/sh286/LuaTruffle, но что-то он выглядит заброшенным.
Серверная подсветка — простейший пример библиотеки, которая недоступна для определённой платформы, но доступна на других нескольких. Поэтому для демонстрационного примера и был выбран именно этот тип библиотек.
С тем же успехом можно рассматривать какую-нибудь полезную научную батарейку, написанную на Python или R, что-нибудь из ML и т. д. Тут просто сложнее найти пример полезного для нескольких языков сразу и отсутствующего в Java, а мне именно что хотелось попробовать совместить всё вместе и посмотреть, что получится :)
Поэтому я несколько не понимаю выпады в сторону аргументации. Увольте, но в споре о том чьё болото лучше и где батареек больше, я учавствовать и не хотел. Лишь поинтересовался ситуацией с подобной задачей в мире C# и .NET и удивлён, что мой вопрос восприняли несколько странно. Это же просто инструменты, не так ли? Если С# и .NET будет в какой-то позиции использовать выгоднее, сам с удовольствием выберу его.
А для C# имеются библиотеки серверной подсветки синтаксиса для самых разных языков программирования? То бишь аналоги Highlight.js, Rouge или Pygments? Насколько я могу судить, ситуация там точно такая же, как и в случае с языками JVM-стека, когда имеются полузаброшенные порты Pygments, охватывающие лишь самую малую часть необходимого:
https://github.com/akatakritos/PygmentSharp/tree/develop/src/PygmentSharp/PygmentSharp.Core/Lexing
Подход с использованием IronRuby, IronPython и каким-нибудь IronJS наверняка имеет точно такие же недостатки, которые я описал в этой статье.
Благодарю за детальное исследование! Спасибо, что прояснили ситуацию и ответили на мои вопросы.
С наступающим Новым Годом!
Нет, это не перевод. Компилятор при отсутствии объявления ругается следующим образом:
Я не слишком вникал в эту проблему, но кажется отсутствие явного объявления статической функции является частным случаем расхождения сигнатуры. Возможно привёл не слишком удачную ссылку на Stack Overflow.
В любом случае, спасибо за замечание!
Подскажите, а параметризованные команды поддерживаются?
Что-то вроде
/send <chat_id> <text_message>и подобное.