Я очень надеюсь, что не довёл ещё @bodyawmдо белого каления постоянными упоминаниями — но мимо этого я пройти, конечно, не мог. Как вы все помните, я сам что‑то пытался изобразить на тему «кастомизируемого телефона‑звонилки». Я давно обещал выложить свои наработки, но даже просто вспомнить, на чём я там сломался N лет назад — уже труд немалый, и если бы не активность единомышленника в этом направлении, которая меня стронула, сподвигла и стриггерила — стронуться, наверное, так бы и не смог. Особенно учитывая тот прискорбный факт, что я открываю свои собственные записки на эту тему и не понимаю там ни слова — положите на могилку Элджернона, что на заднем дворе, хотя бы пару цветочков... ну и да, конечно, его мнение по поводу этой «истории одного фейла» особо интересно, и просто как специалиста, и как человека, покушавшегося что-то эдакое разработать.

Итак, в силу смутно мной запомненных соображений я выбрал в качестве процессора TMS320C5517. Почему не гарвард типа АтМеги, как у великого предшественника? Постоянная перепрошивка процу не особо полезна, и хочется всё‑таки возможность грузить код в оперативку. Тем более, что речь идёт о телефоне, а это означает поминутную подгрузку одного‑другого‑третьего приложения по сто раз на дню. Почему именно этот сигнальник и почему вообще сигнальник? Дёшево, сердито, зачатки SIMD (некоторые операции выполняются не просто за такт, а дуплет за такт), ну а что ещё надо для быстрого софтового рендерера в олдскульном стиле? Опять же, 256К «срамы», можно использовать как кэш, а можно и вовсе туда затолкать с ногами всё «узкое место» кода. «Драмы» можно делать до восьми метров, минус то, что срама с флэшкой из адресного пространства выжрали. Оно как бы и так уже неплохо, во всяком случае, пинать какодемонов более чем хватит, но сразу наводит на мысли о маппере, позволяющем расширить это адресное пространство (грех не расширить!) Ну, и периферия там возводит девайс практически в ранг SoC, в котором есть всё и сразу. Ну, кроме драмы и радиомодуля, который, как мы помним, должен общаться с симкой через GPIO нашего камня, дабы реализовать тёщаанекдотнадзор, дабы пресечь или хотя бы зафиксировать в логах мошенничество со стороны опсосов. Ну, и тут вроде бы, если память не врёт, было в комментариях несколько идей промежуточного уровня параноидальности, достойных гражданского применения.

Поскольку безумие нашей эпохи набирает обороты — я заранее прошу прощения за то хабрапреступление, на которое я сейчас пойду. Я позволю себе прицепить собранные мной ПДФки прямо в статью, в виде «изображения». На случай санкций, блокировок, налёта мышей‑байкеров с Марса и прочих вариантов, из‑за которых у кого‑то может быть возможность прочитать Хабр в целом и статью в особенности, но не будет возможности почитать ПДФки на комплектующие (с некоторыми контрами вообще парадокс, они сами не под санкциями, покупай‑не‑хочу, а вот сайт вместе со всеми ПДФками забанил не только непосредственно ойтишнегов в наших галилеях, но и все выходные узлы всяких торов‑ш2з‑впнов). Движок Хабра не позволил, в камментах что-нибудь придумаю. Потом. Или нет.

Дальше начинается ирония судьбы, потому что моя память отказывается выдавать информацию про память. Разрозненные заметки говорят, что первые 320 «килек» адресного пространства тупо теряются «в тени» встроенной срамы (256 обычной и 64 двухканальной, причём двухканальная наверняка сожрётся под всякие там видеобуферы и ещё должны останемся), и что в какой‑то момент мне стало жалко терять треть метра (из всего восьми) и я решил записаться на чемпионат мира по крохоборству: путём внешнего зануления каким‑нибудь маппером переводить чип в режим «младшая половина замаплена во всё адресное пространство дважды». Эти же заметки упоминают, что «есть чипы с большей драмой, но у них всё плохо со внутренней срамой и периферией». С одной стороны, наверное, тогда так и было. С другой стороны, ситуация могла измениться, лет прошло изрядно. С третьей — для двухсотмегагерцового ядра «кнопочной звонилки» доступ к памяти через маппер и восьмиметровые окна — ничего зазорного в любом случае. Девайс в любом случае подразумевает олдскульное программирование, которое мы все так любим — а там это совершенно нормально и в целом скорее развлекает, чем усложняет и мешает.

Судя по тем же заметкам, я так и не определился с тем, сколько можно сделать рамы в целом, если использовать какой‑нибудь нарочито простой маппер уровня «1 пин GPIO и микруха элементарной логики», причём не выходя за рамки одного‑двух корпусов драмы как таковой. Кроме возможности задавать непосредственно старшие биты, медленно и неспешно переключая адресные пространства, упоминались размышлизмы насчёт ручного переключения банков и, что мне кажется особо угарной затеей и по сей день — зануления пары младших бит адреса с тем, чтобы доступ к остальным трём адресам шёл исключительно методом «задай адрес начала и сделай burst read/write». Вообще чувствуется, что в схемотехнике оперативки я «плавал» уже тогда, раз не определился с границами возможного — а сейчас в голове и вовсе осталась только болезненно звенящая пустота. Отдельная вишенка на торте — я так и не знаю, умеет ли вообще выбранный «техасец» делать burst read/write (а он должен не просто уметь, а гарантированно делать в случае определённых вариантов доступа к памяти и гарантированно не делать в случае других вариантов доступа к ней).

В любом случае, восьми метров для наших игрищ хватит даже самих по себе.

Кое‑как перевалив через эти два абзаца сплошного позорища, я понемногу перехожу к более родной для меня теме — софту для этой ретро‑оргии. Девайс в общем и целом не предполагается для какого‑то прямо очень уж широкого круга — хотя круг айтишников в наше время сложно назвать узким. В то же время, это не чисто гиковская машинка, которую надо программировать на асме каждому юзеру лично — она скорее как 486-я с ДОСом и «нортоном», к которой она по характеристикам, собственно, довольно‑таки близка. А это значит, что софт всё‑таки будет писаться самыми разными людьми с самым разным радиусом кривизны рук, активно обмениваться и тэ дэ и тэ пэ. А это означает вечную проблему тех же ДОСовских персоналок — то есть всякоразный вирусняк.

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

Нативный бинарный код, по сути, расширяет операционку до более‑менее юзабельного уровня. Хотя бы файловый менеджер типа того же «нортона»! Не говоря уже о библиотеках для всяких там MP3. В отличие от — всё это неизбежно должно обновляться довольно часто, ну и никуда нам не деться от того, чтобы класть его на внешнюю флэшку, аппаратно от записи уже не защищённую. А вот код на Си (который мы можем как интерпретировать встроенной в нашу мини‑ОС picoC‑машинкой, так и JiT‑компилировать) — это может быть примерно что угодно, вытворяющее примерно что в голову взбредёт. И, чтобы не создавать риски случайного открытия прав доступа к чему не надо — я пошёл на грязный хак, который заодно, кстати, открывает возможность использовать ФС без разграничения прав доступа (хотя бы FAT32, почему бы и не FAT32, в конце концов — просто и удобно, и если правильно записывать вторую копию FAT после записи данных, то можно сделать даже некое подобие CoW). Суть этого грязного хака в том, что всякое юзерское приложение может работать только с директорией, из которой запущен исполнимый файл (и её поддиректориями, конечно). А если надо, скажем, дать мессенджеру доступ к фотографиям, но не ко всем, а только к расшаренным — мы дополняем всё это дело самыми обычными симлинками (предчувствую, что «симлинк на рут» станет таким же мемом среди юзефонщиков, как стал format c: среди досовиков или rm ‑rf / у линуксоидов). Как это должно работать? Посмотрим на примере: допустим, приложение «Камера» лежит в a:\Camera (не, ну правда, почему бы не использовать для смонтированных файловых систем старую ДОСовскую нотацию a:, b: и так далее? Извлекаемая флэшка в разъёме, конечно, «а»). Ему, естественно, доступен файл самого себя, возможно — какие‑то библиотеки, ну и поддиректория a:\Camera\Photos, в которую оно кладёт фотографии. Приложение «Галерея», лежащее в a:\Viewer, имеет в a:\Viewer симлинк на a:\Camera\Photos и может показывать и даже редактировать эти фотографии, но ничего не может сделать даже с файлами приложения «Камера», не говоря уже об остальных. А вот у какого‑нибудь там мессенджера есть только симлинк на a:\Camera\Photos\Shared, в который можно сохранить фотографию, явно это указав — и она будет доступна для «Галереи» и для мессенджера, но доступа к остальным фотографиям мессенджер уже не получит. Достаточно наглядная и очевидная настройка, не создающая у хотя бы минимально пряморукого пользователя типичных рисков, связанных с правами доступа. Собственно, в системном файловом менеджере уже всё видно — кому чего дозволено и кому чего не дозволено.

Вопросы «а как наследуются права доступа, если одно приложение вызвало другое приложение „на правах библиотеки“, а ему нужны файлы из собственной директории просто для работы самого себя» (да и вообще, подходит ли эта схема для урегулирования таких вызовов), «а как урегулировать доступ приложения к системным API, особенно таким чреватым злоупотреблениями, как звонки, СМС и гео», ну и подобные — я оставляю читателям для самостоятельного погружения в мысли. Задумаетесь над «затравкой» — придумаете ещё миллион способов усовершенствовать этот подход, как в этой части, так и в каких‑то ещё.

«Батники», кстати, в этой системе я делать особого смысла не вижу. Наличие PicoC позволяет их тоже свести к чистому Си — ну и зачем плодить лишние сущности, если «батник» и приложение уже не отличаются вообще ничем? Вопрос разве что с командной строкой в консоли, да и то уже не совсем понятно, нужна ли там консоль как таковая. Наверное, в идеале нужна просто потому, чтобы не разрушать общую целостность ретро‑девайса — если вместо a:\Viewer\View ‑convert GIF *.jpg | a:\Mail\Send Template.dat ‑attach CON будет запуск строго через гуй (а для описанного действия вообще потребуется свой сишный файл писать) — весь шарм девайса мгновенно улетучивается, а если и командную строку сделать на Си — ну, тут вы меня убьёте и я даже не берусь вас за это осуждать, потому что это уже не просто абсурд, это эзотерика. Даже простой запуск приложения потребует набрать изрядную пачку сишных команд (начиная с объявления переменных и аллокациии памяти под строчки), короче, чуть ли не кусок операционки каждый раз с нуля писать прямо в командной строке. Сходить с ума надо весело, а не так вот уныло. Но вся эта разумная аргументация разбивается о голос скепсиса внутри меня — «окстись, речь идёт о КНОПОЧНОЙ звонилке, а не QWERTY‑смартфоне! Какая, на фиг, консоль и командная строка, с какого девайса в неё вбивать ввод, с ABC DEF GHI?» И, слушая этот голос, я таки соглашаюсь — раз уж писать сишные «не‑батники» на каком‑то более удобном девайсе с более удобной клавиатурой, то автоматически в топку отправляется и тёпло‑ламповая командная строка, и все связанные с ней обработки синтаксиса, а раз их не требуется для неё — соответственно, делать их ради одних только «настоящих батников» смысла тоже нет. В сухом остатке имеем таки просто PicoC, без скромного очарования командной строки и каких‑либо шелл‑скриптов.

Кстати, об устройствах ввода. Чего уж греха таить, монобогдановскую концепцию в плане игр я вполне разделяю и поэтому девайс, в моём представлении, должен иметь не только экранчик 640×480 и 14 кнопочек. На задней стенке, под указательными пальцами, я предполагаю размещение двух «крестовино‑дисков», которые позволяют нажимать на край диска (4 варианта нажатия одного замыкателя и ещё 4 — диагональные, по два сразу), в центр (нажатие всех замыкателей плюс‑минус одновременно) и, самое главное, вертеть эти «блины» с достаточной точностью, чтобы в шутерах наводиться не хуже, чем с мышки! Ну, и курки до кучи, хотя бы под большие пальцы. Но эти можно совместить с основной клавиатурой «звёздочка‑ноль‑решётка‑вызов‑отбой». Минус — вместо правой крестовины традиционно принято делать отдельные кнопки, которые нажимаются не только «любая одна или две смежные», но и вообще как угодно, поэтому в эмуляторах сие может быть препятствием. Но, с другой стороны, назначив в настройках функцию каких‑либо из кнопок этим самым куркам, наверняка можно будет это обойти.

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

С выводом традиционно всё весьма интересно и весьма непросто. Любая прослойка сожрёт недопустимо много быстродействия, поэтому придётся использовать DOS‑подобный подход. Но совсем ограничивать вариации на тему экрана не хочется (в UzeBox это не проблема, потому что экран один — TV‑Out), значит, придётся более‑менее вырабатывать какие‑то API, которые могут хотя бы указать приложению, как именно ему класть данные в видеопамять (нет, предусматривать в каждой игрушке все мыслимые и немыслимые разрешения и глубины цветности не нужно, процессор‑то у нас как раз всегда одинаковый, поэтому просто берём и генерируем по месту. А если руки кривые — генерируем код на Си и отдаём на растерзание системному JiT). Я вообще бы с удовольствием слинковал эту статью с (надеюсь!) будущей статьёй «Как я в плацкарте со скуки сделал очки дополненной реальности из того, что было в карманах», поскольку там пойдёт речь об ультра‑минималистичных очках (из обычных очков и двух проекторов типа «карандаш за ухом»), вполне соответствующих уровню UzePhone. Но, увы, пока я не смог получить из своей хари достаточно качественные иллюстрации в нужных проекциях, чтобы на них можно было изобразить ход лучей, который требуется получить для попадания в фокус, для получения более‑менее приличного размера изображения на сетчатке, ну и как это изображение будет козявить в зависимости от реакции зрачка на освещённость и как с этим жить (а вы думали, система, которую можно собрать в плацкарте из содержимого карманов, будет по параметрам равна очкам за стопиццот рублей, в которых применили все доступные технологии микроэлектроники? Да они бы были размером с ламповый телевизор, прикрученный к носу саморезами). Всё это упорно не желает упихиваться на фотки моего глаза в очках, даже я сам, зная и так, о чём там речь, не могу в этом месиве разобрать ничего — короче, «мы работаем над этим».

Ну и, раз я уж затронул схемотехнику, попробую всё‑таки проработать свой «6502-й на новый лад». Который был бы приспособлен к работе напрямую с драмой так же, как 6502-й был приспособлен к сраме. Аналогичные страницы (каждая равна строке драмы), прибитые гвоздями к определённым местам страницы команды precharge, RAS, CAS, чтобы вовремя подгрузилась следующая, возможность на усмотрение программиста выполнить их произвольно, несколько приёмных регистров, в которые эти данные (и команды!) по выбору льются, простейшие SIMD‑операции сразу над целыми регистрами (то есть над целой огромной строкой драмы), обычные операции (которые могут быть более сложными)... Принцип я уже изложил (и не в первый раз), мне интересны конкретные числа, чтобы всё это было реалистично не только в виде эмулятора, но и в виде потенциально существующего кристалла, который было бы реально развести и не захлебнуться в дорожках, идущих от операционников драмы к защёлкам регистров, например (если что, операционники там тоже функционируют как защёлки, так что стоит и их добавить в вариации операндов SIMD, не вынося в отдельную сущность).