Серия «Старое железо»

Телетайп, телепринтер (teletype, TTY) — стартстопный приемо‑передающий телеграфный аппарат с клавиатурой, аналогичной пишущей машинке. В отличие от обычного телеграфа, где сообщение передается посимвольно, с помощью точек и тире, этот аппарат позволяет передавать текстовое сообщение, просто набирая его на клавиатуре. Также аппарат может принимать сообщение, печатая его на бумаге. Девайс широко применялся в качестве терминальных устройств вычислительной техники на заре ее становления. Благодаря этому факту эта технология оставила много артефактов в истории IT, многие из которых сохранились и до настоящего времени. Это различные компьютерные терминалы, терминалы tty в Linux, некоторые команды терминала и даже известный многим электронщикам и программистам интерфейс UART.

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

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

Код Бодо — это синхронный пятибитный двоичный код. А также собирательное название всех пятибитных двоичных кодов, используемых для передачи информации по телеграфу. Оригинальный код Бодо был стандартизован международным стандартом ITA1, модифицированный код Бодо‑Мюррея стандартизован стандартом ITA2. В отличие от оригинального кода Бодо, этот код — асинхронный или в терминологии тех лет — старт‑стопный. На основе стандарта ITA2 было разработано множество региональных стандартов телетайпной связи для каждой страны, которые, как правило, были обратно совместимы со стандартом ITA2. В США это стандарт US‑TTY, в СССР — стандарт МТК-2 (Международный Телеграфный Код № 2).

МТК-2 содержит 86 символов (из них различных — 85): 26 букв латинского алфавита, 31 букву русского алфавита (Ё и Ъ не используются), 10 цифр, 11 орфографических, пунктуационных и математических знаков, а также 8 управляющих символов (в том числе пробел). Символы, имеющие графическое (печатное) представление на телеграфной ленте (в том числе управляющие символы «Кто там?» и «Звонок»), разбиты на три регистра (группы символов) — латинского алфавита, русского алфавита и цифр/знаков, а остальные (непечатаемые) символы являются общими для всех регистров. Переключение регистров осуществляется с помощью соответствующих управляющих символов.

Принятый в МТК-2 вариант фонетического соответствия букв латинского и русского алфавитов был отражён в раскладке клавиатуры трёхрегистровых русскоязычных телетайпов, работающих в данном коде: в ней совмещены русская раскладка ЙЦУКЕН и производная от неё латинская фонетическая раскладка JCUKEN. Впоследствии данную раскладку унаследовали средства советской вычислительной техники, из‑за чего компьютерные кодировки символов КОИ-7 и КОИ-8 используют то же соответствие алфавитов, что и МТК-2, а ДКОИ — обусловленный им неалфавитный порядок следования русских букв в кодовой таблице.

Код Бодо передается в линию последовательно, асинхронно. Для обозначения начала посылки символа используется стартовый бит, затем передаются пять информационных бит и посылка завершается передачей стопового бита. Никакая модуляция не используется. Наличие тока в цепи обозначает лог. 1, а отсутствие тока — лог. 0. Аналогичным образом работает интерфейс UART, за исключением того, что в посылке может быть не пять бит, а более (обычно 8), и стоповых бита может быть не один, а более.

Схема соединения двух телетайпных аппаратов почти один‑в-один повторяет схему соединения двух телефонных аппаратов.

Только вместо микрофона — нормально замкнутый контакт (контакты) передатчика телетайпа, вместо телефона — электромагнит приемника и вместо аналогового звукового сигнала передаются импульсы тока. Да, как и в телефонии, сигнал передается током, а не напряжением, благодаря чему работа аппаратов не зависит от длины линии. В нормальном, неактивном состоянии все контакты замкнуты, все электромагниты притянуты, по цепи течет ток (примерно 40 мА). Если один аппарат начинает посылку, размыкая и замыкая контакт, то передаваемый символ проходит как через свой приемник, так и через приемник другого абонента. Оба приемника печатают одинаковый текст. Аналогично, если символ посылает второй абонент, то он также печатается как у отправителя, так и у получателя. Если оба аппарата начнут передачу одновременно, то в линии будет мешанина и оба аппарата напечатают какой то ошибочный символ. Оператор за передающим аппаратом это увидит и перезапустит передачу. Чтобы исключить такие ситуации, в тексте сообщения используются сигналы для маркировки начала и конца передачи. Например, сеанс связи обычно начинался с посылки команды «Кто там?». Некоторые модели телетайпов имели систему автоматического распознавания этой команды и выдачи в ответ в линию заранее запрограммированной последовательности символов, обозначающей абонента. Отправитель получал это сообщение, убеждался в том, что его скоммутировали верно и начинал передачу основного послания. Также в телетайпе широко применялись международные трехбуквенные Q‑коды, которые знакомы многим радиолюбителям.

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

Поскольку телефонные и телетайпные сигналы довольно похожи, на телефонных сетях была развернута телеграфная коммутируемая сеть «Телекс», которая во многих местах работает и до сих пор. Сигнализация (вызов абонента, набор номера) в этой сети происходит почти аналогично телефонной сети.

Это была общая информация, а теперь рассмотрим как же это все реализовано в железе. Причем, в железе — в прямом смысле этого слова. Попавший мне в руки аппарат — телетайп Т-63, 1983 года выпуска, производства фирмы RFT из города Карл‑Маркс‑Штадт (сейчас Хемниц), ГДР.

Аппарат в неисправном состоянии, долго хранился в сыром подвале, но благодаря обилию смазки и толстому слою налипшей грязи был практически не тронут ржавчиной. Его необходимо разобрать, отмыть, заново смазать и попробовать запустить.

Устройство состоит из передающей части, которая включает в себя клавиатуру и передатчик, приемной части, состоящей из приемника и печатающего устройства. Обе части приводятся во вращение электродвигателем. Также дополнительно аппарат комплектуется реперфоратором — устройством, параллельно кодирующим печатаемый текст на перфоленту (на фото ниже — в левой части).

Перфолента используется для предварительной подготовки передаваемых данных. Так как, обычно, канал связи весьма загружен, передавать сообщение, медленно набирая его на клавиатуре — это нерациональное использование времени канала. Поэтому послание предварительно, не торопясь, набивают на перфоленте, а потом уже эту перфоленту прогоняют через передатчик на максимально возможной скорости. Также, предварительная подготовка сообщения на перфоленте позволяет отправить одно и то же сообщение разным абонентам.

По правде сказать, я не удержался и попытался запустить аппарат в таком состоянии, предварительно обильно пролив маслом все трущиеся места (ведь все равно его потом отмывать). Предварительно была обнаружена неисправность двигателя, а конкретно его центробежного регулятора скорости вращения. Между щетками и кольцами регулятора не было контакта, слышалось искрение и даже шел небольшой дымок. Регулятор я пока заблокировал, зашунтировав его перемычкой, а скорость вращения регулировал изменяя напряжение питания с помощью стенда. Конечно, скорость вращения была далека от номинала и изменялась в широком диапазоне в зависимости от текущей механической нагрузки на двигатель, но при работе аппарата самого на себя это не имеет значения, поскольку и приемный и передающий узел приводятся во вращение от одного и того же вала и потому между собой они всегда синхронны. Далее для работы приемного узла необходимо через него пропустить ток примерно 40 мА. Это я осуществил с помощью лабораторного БП, подав напряжение порядка 12 В.

Далее обнаружилась полная неработоспособность передающего узла. Все контакты были очень сильно окислены и вообще не замыкались. Их чистка мелкозернистой наждачкой не помогла, надежного контакта по прежнему не было. Поэтому и начнем восстановление с этого узла.

Что удобно, в этом телетайпе все блоки, даже несмотря на их механическую связь, сделаны отдельными, относительно легкосъемными устройствами. Чтобы снять передатчик достаточно открутить три винта и сдвинуть вправо приводной вал. Рассмотрим его устройство.

Его основой являются 6 контактных пар, на которые воздействуют толкатели, приводимые в движение кулачковым механизмом. Почему контактов шесть? Пять из них формируют код Бодо, а шестой — стартовый и стоповый импульсы. Все шесть контактов включены параллельно. В стартовой позиции все контакты разомкнуты, кроме шестого — он замыкает цепь. Вал с кулачками заблокирован. Вращение на блок передается через муфту повышенного трения. Трение обеспечивается смоченными маслом фетровыми фрикционами. При нажатии на любую клавишу через спусковой механизм кулачковый вал освобождается и делает один оборот, после чего снова останавливается.

За время одного оборота первым делом размыкается шестой контакт и формирует стартовый бит. Затем кулачками нажимается первый контакт, потом второй, третий и т. д. — формируется 5-битовая посылка. В конце шестой контакт снова замыкается — это стоповый бит. Привод от кулачков к контактам осуществляется через коромысла.

А коромысла управляются снизу пятью подвижными планками с упорами. При нажатии кнопки эти планки сдвигаются в одну из 32 комбинаций. Если упор не стоит под коромыслом, то, когда коромысло попадает в выемку кулачка, оно «проваливается» и контакт замыкается, формируется, допустим, лог. 1. Если под коромыслом оказывается упор, то «провала» не происходит и контакт остается в разомкнутом состоянии и формируется лог. 0. После завершения цикла все планки сдвигаются в исходное состояние и аппарат готов принять очередной символ.

Вот таким нехитрым способом, без всякой электроники, формируется код МТК-2.

В верхней части передатчика виден барабан с металлическими шипами. Это, так называемый, комбинаторный валик.

Именно в нем зашифровано сообщение, которое выдает аппарат в ответ на команду «Кто там?». На нем можно закодировать порядка 20 символов. Кодирование одноразовое и производится путем отламывания ненужных шипов. Там где шип торчит, он упирается в коромысло и не дает замкнуть контакт, формируется лог. 0. Там где шип отсутствует, контакт замыкается и в линию уходит лог. 1. После того как аппарат будет починен, можно будет его запустить и прочитать это сообщение. Таким образом, можно выяснить, какой организации принадлежал ранее этот телетайп.

Кроме окисленных контактных площадок были обнаружены окислы между самим контактом и луженой контактной пластинкой, к которой уже припаивались провода. После того как я эти места также зачистил, контактная пара стала работать идеально. Эта операция была проделана для всех 6 контактных пар.

Что еще очень радует в древней технике так это то, что все можно разобрать до мельчайших деталей, а затем снова собрать. Все собрано на разъемных винтовых соединениях. Я без труда открутил планку с контактами, сами контакты от планки и разобрал эти контакты на мельчайшие детали.

После сборки передающего узла также пришлось отрегулировать зазор между контактами у контактных пар. Для этого у каждого контакта предусмотрены 2 винта — регулировочный и стопорный. Для регулировки необходимо ослабить стопорный винт и регулировочным винтом выставить необходимый зазор. Слишком маленький зазор может приводить к ошибочной передаче лог. 1 (замкнутое состояние). Слишком большой зазор приводит к ложному появлению коротких всплесков лог. 0 между отдельными единичными битами. Зазор регулируется при передаче комбинации 11 111 (команда переключения на латинский шрифт). При регулировке можно вручную вращать ротор двигателя и визуально следить за контактами. Необходимо выставить такой зазор, чтобы при переходе передатчика от одного разряда к другому, первый контакт еще не разомкнулся, а второй уже замкнулся, чтобы было небольшое перекрытие между ними. После регулировки и проверки необходимо затянуть все фиксирующие винты.

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

Также легко извлекается и весь узел клавиатуры целиком. Для этого достаточно открутить всего четыре винта. Он также был отмыт и смазан и, кроме того, были обратно выгнуты погнутые клавиши. Этот узел достаточно простой.

Кроме управления подвижными планками, о которых говорилось выше, в нем есть еще функция блокировки кнопок. В режимах «РУС», «ЛАТ» и «ЦИФ» соответственно высвобождаются только те клавиши, которые можно нажимать в этих режимах, остальные блокируются. Например, в режиме «ЦИФ» нажимаются только клавиши с цифрами, символами и некоторыми редко используемыми русскими буквами (которые не поместились в режиме «РУС»).

Собрав все назад можно убедиться что узел передатчика работает! Сначала я его проверил осциллографом, подключив контакты к источнику питания через нагрузочный резистор 220 Ом. Осциллограмма для буквы А имеет следующий вид (на длительность импульсов и всей посылки пока внимание не обращать, частота вращения двигателя не соответствует номиналу):

Осциллограмма для буквы «В»:

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

Приемник — следующий на очереди на отмывку. Если у передатчика для формирования кода Бодо было целых 5 контактов, то у приемника всего один электромагнит (на фото ниже — наверху, в центре), но зато с пятью якорями.

Якоря по очереди высвобождаются кулачковым механизмом.

Если в это время в катушке есть ток (передается лог. 1), то соответствующий якорь (92) остается притянутым. Если в этот момент тока нет, то он отпадает и блокирует деталь 87.

Заблокированная деталь 87 управляет тем, в какую сторону будет сдвинута одна из пяти ламелей с прорезями с помощью коромысла 1622. В результате, после приема символа все ламели также встают в одну из 32 позиций.

Ламели своими прорезями управляют печатающей частью, выбирая ту или иную литеру. Например, как на фото ниже.

Печатающая часть до отмывки.

Помимо управления литерами, печатающая часть еще исполняет команды «возврат каретки» и «перевод строки». Чтобы каретка с жутким грохотом не врезалась при возврате в начальную позицию, в аппарате применен пневматический тормоз. Тормоз регулируемый, управляя натяжением пружины клапана можно настроить желаемую скорость замедления. Команда «Перевод строки» просто проматывает бумагу на одну строку. Аппарат рассчитан на работу с бумагой в виде рулона. Отлично подходит обычная (не термо‑) бумага для факсов. Сбоку находится чашка звонка. Звонок раздается за 10 символов до самого крайнего положения каретки, а также при приеме буквы «Ю», она же команда «Звонок».

Также при получении команд «ЛАТ», «РУС» и «ЦИФ» происходит смещение каретки в вертикальном направлении в одну из трех позиций. В самом верхнем положении каретки печатаются латинские буквы, в самом нижнем — русские. В среднем — цифры.

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

Написано при поддержке Timeweb Cloud.

Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.

Автор текста: MechNIX

Здравствуйте, уважаемые читатели!

В этой статье я хочу рассказать об одной интересной компьютерной мыши, выпущенной отечественным производителем в далёком 1991 году. Помимо уникального дизайна, мышь содержит в себе ряд электронных компонентов, которые мы увидим. Также расскажу о проблеме, которая сгубила этого «грызуна», но я всё-таки не теряю надежды его воскресить. Будут детальные фото составляющих компонентов с описанием внутренней начинки этого интересного устройства, а в роликах вы увидите вскрытие «капсулы времени».

Сразу оговорюсь об использованном в заголовке названии данной мыши.

Официальное название — «Устройство ввода НВ 03.049.003». Выпущенное в 1991 году промышленным объединением «Комета», данный манипулятор иногда называют по наименованию производителя — «Комета», а еще в силу округлой формы — «Колобком». Подчеркну, что это неофициальные, «народно-обиходные» названия, и в паспорте устройства этих упоминаний нет. Но мне нравится название «Колобок»; думаю, в современном мире производитель вполне сам бы мог дать такое яркое название своему продукту. С другой стороны, зачем всё сворачивать к игровой форме? Строгое «УВ НВ 03.049.003» отражает серьёзное время. Вот прилагаемый изготовителем паспорт, я приведу его полностью.

По результатам чтения паспорта мы видим, что мышь подключается посредством интерфейса RS-232C, то есть в стандартный COM-порт.

Итак, начнем с внешнего вида, постепенно добираясь до внутреннего устройства.

Распаковка «мыши»:

Разборка «мыши»:

Помимо самого корпуса и согласно паспорту устройства, присутствуют два разъема — DIN5 (слева) и db9 (справа):

DB9 крупным планом — это интерфейсный разъем, подключаемый в порт RS-232:

DIN-5 вставляется в материнскую плату в разрыв клавиатуры AT, обеспечивая питание 5В, потому что, как мы увидим дальше, питание через RS-232 на «мышь» не подаётся.

Интерфейсный разъём в разборе, к нему подходят всего три провода, выглядит так:

Номинал резистора можно увидеть на экране мультиметра, чуть менее 1 кОм:

Теперь самый главный вопрос: зачем я разобрал «мышь» и вообще полез туда? Как вы, наверное, догадались, первоначальное подключение к компьютеру и переборка пары десятков мышиных драйверов (не шучу) ни к чему не привели — «мышь» не работала.

Цель данной статьи — найти единоМЫШленников, которые могут помочь. В чём конкретно, расскажу по мере повествования.

Разобранная «мышь» выглядит так:

Итак, рассмотрим составляющие элементы.

Микросхема КР1816ВЕ39 — это однокристальная 8-разрядная микро-ЭВМ, не содержащая ПЗУ.

Само ПЗУ (EPROM) КР573РФ5, организация памяти 16 Кбит (2К x 8). Кварцевое окошко для УФ-стирания заклеено толстой черной изоляцией толщиной 0,5мм.

Микросхема К555ИР22 — это восьмиразрядный регистр хранения информации, тактируемый импульсом. Логика работы приведена по ссылке.

Микросхема К561ЛН2 — это шесть логических элементов НЕ с буферным выходом.

Микросхема К561ТЛ1 содержат 4 элемента 2И-НЕ с триггерами Шмитта на входах.

Плюс ко всему мы видим кварцевый резонатор, три микровыключателя, несколько постоянных и 4 подстроечных резистора. А так же две КМ-ки.

Печатная плата держится на пластиковом основании при помощи маленьких саморезов.

Маленькие «ролики-штанги». Как можно видеть, в соединяющей несущей высверлены отверстия, сквозь которые при вращении роликов происходит циклический засвет оптопары.

Оборотная сторона печатной платы, содержащей оптопары (в красных кружочках). Как мы видим, ножки элементов оптопар, «одеты» во фторопластовые трубочки (изолирующие кембрики).

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

Как я уже говорил, нерабочая «мышь» не давала мне покоя. Начал я с измерения питания на выводах микросхем. Напряжение поступало, коротких замыканий обнаружено не было. Корпуса микросхем чуть заметно грелись — совсем немного, ощущал пальцами. Что делать, я не знал. Поиски принципиальной схемы, к сожалению, не увенчались успехом, поэтому я был бы рад помощи с этим. Но пока схемы нет, я решил выпаять ПЗУ. И здесь, как мне кажется, началась вторая существенная проблема.

Выпаять микросхему, как оказалось, не сложно, но и не просто. Паяльный фен не использовал, каким припоем было запаяно ПЗУ — я не знал. Вот процедура извлечения:

Сплав «Розе» имеет более низкую, чем у оловянно-свинцового припоя, температуру плавления. По технологии он наносится на выпаиваемые ножки микросхем с целью разбавления припоя и проникновения в отверстия печатной платы. Существующий припой был удалён при помощи оловоотсоса, и нанесён сплав «Розе».

Прошу строго не судить, но в определённый момент всё выглядело так:

ПЗУ слегка встало «на дыбы»:

И с другой стороны:

Результат:

После демонтажа ПЗУ и приведения платы в порядок, вот такой вид. Дорожки, не отслоились, металлизация отверстий не нарушена:

Что мы имеем:

Для чего все это? Конечно сделать дамп при помощи программатора:

Читаем:

И вот какой у меня получился дамп:

ПЗУ чиста, как после полного стирания УФ-лампой. Дамп улетучился, утёк — никакой микропрограммы. ПЗУ как новое. Всегда сохраняйте дампы своих ретро-гаджетов! Без них в один прекрасный момент ваш девайс может превратиться в бездушную железку.

Всё. На этом я понял, что нужно искать рабочую «мышь-донора» либо дамп для загрузки в ПЗУ. Собственно, поиск принципиальной схемы и донора и является целью написания данной статьи.

Чтобы больше не возиться с пайкой платы, на место ПЗУ я установил «кроватку».

Но еще не всё...

Возвращаясь к названию «Колобок», хочется выразить своё двоякое мнение. С одной стороны, не хочется нести некорректную информацию в ноосферу знаний. А с другой стороны, что вы скажете на нижеизложенный факт?

В загрузочном образе-сборке советской операционной системы «Альфа-ДОС», являющейся клоном MS-DOS 3.2, содержится драйвер мыши КОЛОБОК.КНД. Его можно увидеть вверху списка.

Запустив данный драйвер, мы видим следующее:

Оно и понятно: в COM-порт не вставлен разъём заведомо неисправной мыши.

Но и это ещё не всё. Я нашёл второй экземпляр драйвера «Колобка». Он называется «GMAUS.COM». Ему безразлично, подключена мышь в порт или нет. Без лишних вопросов он загружается резидентом в оперативную память, и при повторном запуске, проверяя наличие уже запущенной копии, «Колобок» отвечает: «программа уже готова».

Размер файлов немного отличается. Мы увидели, что существуют как минимум две модификации драйвера «КОЛОБКА».

Резюмируя, «Колобок» жив в программном коде. Файл в образе «Альфа-ДОС» датируется 1 августа 1988 г., а мой экземпляр мыши — декабрём 1991 года. В каком году начато серийное производство данных мышей, найти информацию не удалось. Под какую мышку написан драйвер «КОЛОБОК.КНД», можно только предполагать.

Итак, «Колобок» всё же был. Но катиться ли ему по столу дальше — решать вам, уважаемые читатели. Дело — за принципиальной схемой, дампом ПЗУ и накопленными вами знаниями и опытом.

Мой «Колобок» пока не готов... Если сможете помочь, пишите советы в комментариях.

Спасибо за уделённое время! :)

Написано при поддержке Timeweb Cloud.

Автор текста: MechNIX

Иногда полезно выбраться из привычной системы координат. Эта мысль посетила меня при взгляде на «Robotron 1715M». Не знаю, насколько привлекателен внешний дизайн этого компьютера, но в своеобразности взаимодействия с ним точно есть свой шарм.

❯ Аппаратная составляющая

Надо сказать, компьютер выполнен преимущественно из металла. Сам системный блок, клавиатура, монитор — всё металлическое. По весу очень тяжёлый; я попытался поднять системный блок со стоящим сверху монитором и чуть не сорвал спину. Вспомнился «Гроботрон» — видимо, повеяло прошлым.

Техническое описание компьютера — доступно здесь.

Наш экземпляр имеет «на борту»:

• Центральный процессор UA 880D (аналог Zilog Z80);

• Оперативную память объемом 256Кб (32 чипа в корпусе DIP);

• Два дисковода 5'' (К5601), 80 дорожек, 800К;

• Работает под операционной системой SCP 3.0, являющейся клоном CP/M.

Глянем составляющие:

Открутив три винтика, поднимаем крышку системного блока и видим, что треть пространства занимает блок питания (слева):

Смотрим на дисководы, расположенные сверху (К5601):

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

Модель и производитель:

Шасси дисководов держатся на двух удобных винтах с насечками для пальцев — снимаются очень легко:

Вот мы и добрались до плат. Их всего две:

И основная плата, которая содержит центральный процессор UA880D, работающий на частоте 4 МГц:

И поле оперативной памяти, объемом 256К (8Кб X 32):

ПЗУ производства СССР:

Надо отметить, что при подавляющем большинстве комплектующих ГДР, попадаются компоненты СССР:

Есть и Корея:

Чип зафиксирован клейкой лентой, предполагаю, от сползания из панельки. Отдирать не стал. Никакой деструкции с ретро:

Центральный процессор. В данном случае фиксирующая чёрная плёнка почти исчезла — можно разглядеть номинал. Выглядит «поюзанно». Плёнка будто сползла от температуры, что ли? Руками так не сдирают — она деформировалась и, похоже, стекла. Есть предположения?

Вообще, не совсем понятно назначение наклееных пленок, заклеек. Подскажите, для чего?

Тоненькие проводники, навитые на стержни. Любопытно, как навивали.

RFT-разъемы:

В завершение внешнего осмотра — интерфейсы.

Мы видим разъёмы для подключения дисплея MDA, принтера, внешнего floppy-дисковода и окно во внешний мир — протокол V.24. Благодаря ему мы и сможем почувствовать себя операторами, подключёнными к майнфреймам Всемирной паутины. А вот чем планировалось заменить заглушку под потенциальный разъём GRAF DISPLAY — интересно было бы найти.

❯ Дисковая подсистема

Так как жёсткий диск в принципе отсутствует, мы будем пользоваться двумя имеющимися дисководами. С одного загружается операционная система, на другом — дискета с данными. Удобно? Да. И дискового пространства больше — есть, где развернуться.

Профилактика — сначала почистим магнитные головки дисководов.

С профилактикой механики завершили, переходим к «софтовым мытарствам».

❯ Дела софтовые

Начнём с самого сложного (для меня) — с работы с дискетами. «Чего сложного, — скажете вы, — вставил дискету и работай». Но нет. Посмотрим-поглядим.

Прежде чем использовать дискету, её необходимо соответствующим образом записать. Отдельная песня — это работа с файловой системой SCP 3.0 (CP/M) для Robotron. Перепробовав тонну маленьких утилит под MS-DOS для форматирования, редактирования и записи образов, я так толком и не добился цели. Далее описан проверенный, простой и рабочий вариант для OS Linux, но чтобы его осознать и осуществить, пришлось просидеть несколько вечеров. Как оказалось, всё укладывается в несколько команд. Возможно, вам пригодится, да и мне — чтобы не забыть.

Дискеты можно и нужно использовать двойной плотности (DD). Вспомнили такие? 2S/2D означает «двухсторонние, двойной плотности».

Цель весьма простая — записать (дополнить) нужные файлы в готовые образы дискет и эти самые образы, а также записать на физические носители (дискеты). В итоге на помощь пришли пакеты cpmtools & fdutils для Linux.

После установки этих пакетов, необходимо отредактировать файл, находящийся по следующему пути: /etc/cpmtools/diskdefs. Файл описывает специфические парамеры, необходимые для работы дисковой подсистемы.

Далее все стало проще. Нам нужно изменить настройки контроллера дисковода. Делается при помощи setfdprm (из пакета fdutils). Запускаем команду со следующими параметрами:

После применения подготовительных параметров, форматируем (размечаем) дискету командой #fdformat /dev/fd0

Потом нас интересуют две команды: команда «#cpmls -f 17153 test.ima» выводит содержимое образа test.ima, а команда «#cpmcp -f 17153 test.ima tlc.com 0:», добавляет в образ файл tlc.com. Также существует команда «cpmrm», позволяющая удалять файлы из образа.

Следующей командой записываем свой модифицированный образ на дискету. Test.ima и scp30.cpm — это посекторные образы дискет.

Всего 3 команды, подытожим на живом примере:

Записанную таким образом дискету можно загружать в Robotron. Информация собиралась по крупинкам, моя благодарность этим источникам (вот и вот).

Результирующее видео:

❯ «Инжалид дежице»

Если вы увлекаетесь ретро-компьютерами, то вам наверняка встречалось сочетание «инжалид дежице». Мне, как и многим, смешно такое видеть; более того, это словосочетание утекло в мемы. Хочу чуть пояснить его на примере нашего «Роботрона».

Не удержусь — приведу уместную картинку, иллюстрирующую хитросплетение кодировок.

В описываемом компьютере используется древняя кодировка КОИ-7, не вплетённая в венок вышеприведённой картинки, а точнее — два её варианта: Н1 и Н2. В одном случае латинские буквы заменены на подходящие кириллические, а в другом заменены только строчные латинские буквы.

Вот пример для наглядности. Преднамеренное обращение к дисководу без дискеты порождает такое сообщение:

А после нажатия этой «волшебной» кнопки:

Мы видим:

Главное — результат достигнут, и смысл понятен в обоих случаях, правда? Такой вот своеобразный фонетический транслит.

Завершая, поясню: легендарное «инжалид дежице» означает Invalid device — дословно «неисправное устройство».

Здесь полное описание кодировки КОИ-7, а здесь объемлющее рассмотрение.

❯ Игры

Как правило, при взгляде на монитор «Роботрона» вспоминается Fallout. Наш сегодняшний «Фоллаут» будет состоять из игральных карт, мышей, машинок в виде цифр — а также текста.

Игра «Казино». Графического режима нет, но, на мой взгляд, изображения карт сделаны старательно.

Смотрим в динамике. Играть не умею, не обессудьте. На видео видно, как загружается операционная система и взаимодействие с ней в части запуска игры.

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

Гонимся за мышами!

Еще одна аркадная игра — гонки с названием «Ралли»:

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

Результат:

Игровой процесс:

«Тетрис»! О, эта игра не нуждается в представлении. Здесь она «на коне», потому что хронологически близка к первоисточнику. Алексей Леонидович Пажитнов написал её в 1984 году для компьютера «Электроника-60». Она живёт и на «Роботроне».

А теперь — мистификация. За правду в следующем абзаце не ручаюсь, но оцените идею. Повторюсь: в компьютере «Robotron 1715М» отсутствует динамик и, как следствие, звук. Нет звука в системном блоке, зато он есть в принтере.

Впечатляет реализация мифической игры «Диверсия» («DIWERSIQ»), в которой задействован звук «колокольчика» принтера «Robotron» — Bell. Как вам такое?

К сожалению, игра считается утерянной. И если её найти, придётся доставать и соответствующий принтер — уж больно оригинальную идею реализовал автор. Сам я этой игры не видел. Если встречали, а тем более — если она у вас есть на дискете, на полке, в чулане, — вы знаете, кому предложить копию.

Всех игр для «CP/M» не опишешь. Есть ещё «Горилла» (воображение рисует «Кинг-Конга» на небоскрёбах) и множество других произведений для погружения в «ту эпоху игр».

Не обязательно иметь настоящий, «железный» «Роботрон» — существует эмулятор. Кому нужно, можно найти в Сети; если лень — могу поделиться, пишите.

❯ Внешний мир

Упомянутый выше протокол V.24 используется в реализации стандарта RS232. Для нас это означает, что мы можем использовать последовательное соединение через COM-порт.

Покопавшись в документации, нашел следующую «распиновку» разъема «Роботрона».

Далее, самым непростым делом было найти ответную розетку:

Но всё позади и мы видим нуль-модемный кабель для использования COM-порта любого современного компьютера:

«Железо» без «софта» мертво. С пайкой аппаратной части разобрались, а что мы имеем из программ для SCP3? В этой части — скудненько. Сначала удалось найти телекоммуникационную программу TLC. Вроде бы то, что нужно.

Развернув бурную деятельность, в части вызванивания исходящих данных из «Роботрона», я имел вот такую картину:

Данные передавались, но не те, которые я ожидал. Программа TLC не пропускала символы ASCII с кодом выше 127. Изменение количества бит с 8 до 7 тоже не принесло результата. Иными словами, я видел «квакозяблы» вместо осмысленных символов. Терминальную программу с поддержкой КОИ-7 мне найти не удалось. Если есть на примете — подскажите.

Написано при поддержке Timeweb Cloud.

Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.

Приветствую всех!

Пожалуй, самой желанной для меня железкой на транспортную тему был контроллер машиниста от какого-нибудь поезда. Но, как это часто бывает, достать такой экземпляр не так уж и просто.

И вот наконец в мои руки попал не просто какой-то контроллер, а очень примечательный экземпляр — от «концептуальной» электрички ЭМ2И, коих в наши дни уже не осталось.

Итак, в сегодняшней статье поговорим о том, как устроен такой контроллер и как его подключить. Традиционно будет много интересного.

❯ Суть такова

Так получилось, что ко мне в руки попал контроллер от старого электропоезда ЭМ2И. И, само собой, напрашивалось единственное верное решение — подключить его к Trainz или «Метрострою».

Удивительно, что при наличии огромного количества железнодорожных симуляторов нет практически никакой периферии для них. Если вспомнить, сколько всякой амуниции выпускается для фанатов авиации, то окажется, что для желающих покататься на поезде у себя дома по сути нет ничего.

Безусловно, кое-что всё же существует. Есть такая штука как Raildriver, которая даже нативно поддерживается в Trainz, однако в России оказалось реальнее достать настоящий контроллер, нежели её.

Немного про электропоезда ЭМ2И

Прежде чем начать разбираться с подключением, поговорим о том, что это вообще была за электричка.

ЭМ2И являются детищем более старых проектов — ЭМ1 и ЭМ2. Все эти поезда — глубокие модернизации куда более старых ЭР2. Серия была предназначена для эксплуатации на линии в Домодедово в качестве экспрессов.

Электропоезд обладал целым рядом нововведений — новые сцепные устройства, полупантографы, электронная система управления. Выпускались они на Московском локомотиворемонтном заводе, а запчасти для них поставляло некое ЗАО «Спецремонт».

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

Увы, с самого начала история этих электричек пошла не в их пользу — уже на испытаниях выяснилось, что многие характеристики не соответствовали заявленным, а в конструкции имелось немало фатальных недостатков. Эксплуатировались необычные поезда совсем недолго, в первой половине нулевых, а большую часть своего существования они стояли в депо или на базах запаса и тихонечко гнили. Проект вышел крайне неоднозначным: стоили машины очень дорого (практически как новые ЭД4М), имели небольшой срок службы (ведь ходовая часть осталась от старых ЭРок), а также были крайне ненадёжными и неудобными в ремонте. В итоге от их использования довольно быстро отказались, а в 2019-2020 годах все машины (точнее, то, что от них осталось за долгие годы стояния на открытом воздухе и постепенного разграбления вандалами) были порезаны на металлолом.

Впрочем, многие (как и я) до сих пор жалеют, что не успели прокатиться на этом неудачном, но всё же весьма интересном МВПС.

Обзор оборудования

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

А вот и подопытный экземпляр. На нём две ручки — реверс и непосредственно управление. Также имеется тумблер.

Позиции.

Вид снизу. Видно сердце контроллера — кулачки. В нынешних электронных вагонах применяются бесконтактные контроллеры машиниста (БКМы), где вместо кулачков и контактных групп используются датчики (оптические или магнитные). Чуть позже я расскажу и про этот тип контроллеров, ну а пока что будем разбираться с нашим.

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

Разъём для связи девайса с внешним миром — DB37F. Закреплён он на обычном куске фанерки.

Наклейка того самого «Спецремонта».

А вот механизм. Дискретное перемещение ручки обеспечивается за счёт детали сложной формы, в которую упирается подпружиненный ролик. Шестерни обмазаны густой липкой смазкой.

Вдалеке видно тот самый прижимной механизм.

Нужное усилие обеспечивается двумя мощными пружинами.

По бокам находятся толстые стальные пластины, в которые вкручиваются стойки и вставляются валы. Из-за их толщины (десять миллиметров) скромный по размерам контроллер имеет весьма внушительную массу — чуть больше семи килограммов.

Кулачки

Контроллер внутри очень похож на командоаппарат.

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

Вот для примера положение кулачков в разных позициях ручки.

Реверс

Начнём, наверное, с самого простого — с ручки реверса.

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

Вот положение этих двух деталей при нулевой позиции реверса.

А вот — когда включён реверс, а ручка повёрнута на ход или тормоз.

Распиновка

Чтобы разобраться с работой самого контроллера, пришлось выяснить распиновку, благо проблем с её определением не возникло. Она здесь оказалась вот такая:

1. Пятый кулачок (нормально разомкнутый контакт)

2. Четвёртый кулачок (нормально разомкнутый контакт)

3. Третий кулачок (нормально разомкнутый контакт)

4. Второй кулачок (нормально разомкнутый контакт)

5. Первый кулачок (нормально разомкнутый контакт)

6. Третий кулачок (нормально замкнутый контакт)

7. Второй кулачок (нормально замкнутый контакт)

8. Назад

9. Вперёд

10. Ничего

11. Вперёд

12. Назад

13. Второй кулачок (нормально замкнутый контакт)

14. Третий кулачок (нормально замкнутый контакт)

15. Первый кулачок (нормально разомкнутый контакт)

16. Второй кулачок (нормально разомкнутый контакт)

17. Третий кулачок (нормально разомкнутый контакт)

18. Четвёртый кулачок (нормально разомкнутый контакт)

19. Пятый кулачок (нормально разомкнутый контакт)

20. Ничего

21. Ничего

22. Ничего

23. Ничего

24. Ничего

25. Ничего

26. Ничего

27. Ничего

28. ЗАП/ОТП

29. ЗАП/ОТП

30. Ничего

31. Ничего

32. Ничего

33. Ничего

34. Ничего

35. Ничего

36. Ничего

37. Ничего

Далее берём мультиметр и выясняем, какие контакты в какой позиции замкнуты.

Далее объединяем всё в одну таблицу:

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

Подключение к ПК

Для того, чтобы связать контроллер с компьютером, понадобится всего-ничего — плата на самом дешёвом МК с поддержкой USB HID в лице Raspberry Pico, вилка DB37 и немного проводков...

> Продолжение в источнике материала на Хабре. Увы, все фото не влезли (их действительно много), а именно в них вся суть и самое вкусное. Так же там элементы кода и прошивка :)

• Написано специально для Timeweb Cloud и читателей Пикабу. Подписывайтесь на наш блог, чтобы не пропустить новые интересные материалы.

• Также подписывайтесь на наш телеграмм-канал — только здесь, технично, информативно и с юмором об IT, технике и электронике. Будет интересно.

• Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать наши проекты.

Многие помнят линейку телефонов Siemens 65-75 серии, которые были в ходу около 20 лет назад. Мы попробуем провести необычный эксперимент на их основе, для чего напишем небольшую управляющую библиотеку на C, а также изменим код одной из встроенных в ОС Linux утилит. Подробнее в статье.

❯ 1. Аппаратная часть

В серии телефонов «Siemens 75» существовали такие модели, как C75, ME75, CX75 и прочие. Они различались между собой дизайном корпуса и некоторым другим функционалом. Но их основные элементы были, во многом, схожи. Например, дисплей разрешением 132x176. Для работы с данным проектом в коробке с различным электронным мусором были обнаружены останки подобного телефона. Состояние изделия за 20 с лишним лет очень плохое, надписи стёрлись, но я предполагаю, что это был экземпляр телефона C75 – BenQ, позднего выпуска. Родной процессор телефона давно уже умер — какое-то время назад удавалось оживить его, прогрев плату паяльным феном, но теперь осталась лишь безжизненная плата и оболочка. Поэтому я решил перехватить информацию на уровне дисплея.

Нас интересует, в первую очередь, этот самый дисплей. Поэтому, для начала, разберём устройство:

Поскольку любая наука стоит «на плечах гигантов», я не буду повторять материал о видах дисплеев в данном телефоне. Ознакомиться с ним вы можете самостоятельно, это описал ещё в 2013 году Кизим Игорь, в своей статье.

У меня уже был некоторый опыт работы с данным дисплеем. Используя библиотеку, взятую из статьи Игоря, я подключал данный дисплей к микроконтроллеру ATmega8. Однако, это было более 5 лет назад, поэтому, для начала, я решил проверить, а работает ли вообще данный дисплей. Для чего собрал схему Игоря. Её ключевые особенности: установлен стабилитрон по питанию дисплея (5V -> 2.9V), установлены резисторы для понижения уровней логики (5V -> 3.3V). Однако, нам необходимо ещё одно напряжение – 12V, для питания диодной ленты подсветки. Поскольку я не хотел городить дополнительный инвертор, я расковырял подсветку и заменил диоды на те, которые могут работать напрямую от 5V, подсоединив их не последовательно, а параллельно. Таким образом я избавился от лишнего провода питания, хотя и качество подсветки несколько пострадало.

Теперь я имел 2 провода питания (+5V, GND), и 5 сигнальных проводов с уровнем логики 3.3V.

Однако, контроллера ATmega8 под рукой не оказалось, но был китайский клон Arduino Uno на ATmega328. Я попытался поискать библиотеку Arduino под этот дисплей, и нашёл такую. Но она была заточена под ESP8266. Хотя идею замены SPI в функции Send_to_lcd с программного на аппаратный я намотал на ус:

В итоге я взял оригинальную библиотеку Игоря (Igoryosha), и портировал её под Uno, просто заменив в текстовом редакторе функции присваивания (напр. LCD_CLK=0) на ардуиновские digitalWrite(LCD_CLK, LOW). Библиотека запустилась без особых проблем.

Так как в ней используется программная имитация SPI, выводы GPIO можно назначить произвольно (кроме тех, что заняты RX TX). Библиотеку под Arduino Uno для данного дисплея в итоге я оставил у себя на github, в ветке main.

Результат запуска программы и скорость работы такого SPI можно увидеть наглядно на видео:

Теперь можно подсобрать телефон для удобства работы. Я вытащил динамик, чтобы вывести провода через отверстие.

Проверено: дисплей работоспособен, а это означает, что наша задумка в конечном итоге получится.

❯ 2. Подключаем Orange Pi GPIO

Как можно было увидеть в предыдущем фрагменте, скорость отрисовки картинки просто черепашья. Оно и неудивительно: контроллер работает всего лишь на 16 МГц, ещё и использует программный SPI для вывода картинки. Ситуацию нужно исправлять, взяв более мощный и производительный контроллер. Тут я натыкаюсь на статью хабровчанина Hoshi.

В ней он данный дисплей подключает к Raspberry Pi, и использует его как «монитор». Поскольку мы стоим на плечах гигантов, было решено проследовать его примеру, и не изобретать ещё какие-либо методики. Но Raspberry Pi у меня не оказалось, нашёлся только Orange Pi PC.

Поэтому запустить код Hoshi без переделки у меня бы не вышло: в своей статье он оперирует GPIO через библиотеки чипсета bcm2835. Так как данного чипсета на моей плате нет, и библиотеку подключить не выйдет. Я начал поиски способа, как подключить GPIO на моём чипсете h3. Выяснилось, что для этого нужна библиотека wiringPi (на текущий момент уже не поддерживается официальными авторами). Однако, просто установить её через apt-get оказалось мало: устанавливался оригинал под Raspberry. Спустя некоторое время была найдена модификация этой библиотеки от zhaolei. Я собрал её через build (ветка h3), и именно она оказалась рабочей для моей платы. После выполнения build библиотека установилась в систему, и стало возможным вызвать её из требуемого места (например, проверить пины с помощью sudo gpio readall).

Назначение выводов GPIO для «апельсина» назначается через define по аналогии с Arduino:

Также следует отметить следующий момент: в схеме Igoryosha для AVR использовался логический уровень +5В, а на Orange Pi разъем GPIO сразу оперирует уровнями +3.3В. Поэтому резисторные делители я убрал. В итоге получилась следующая конструкция:

Однако, у меня сходу не получалось завести аппаратный SPI. Поэтому для повторной проверки работоспособности дисплея я взял, опять же, библиотеку Игоря из-под AVR, портировав её теперь и под wiringPi. К счастью, особых замен не понадобилось, только поменять в коде LOW и HIGH на 0 и 1 соответственно. Даже функции delay в wiringPi аналогичны ардуиновским. Также на данном этапе библиотека лишилась практически всех графических функций отрисовки примитивов, кроме отрисовки, непосредственно, одного кадра из буфера.
После чего я собрал программу через gcc (gcc –o example example.c –lwiringPi), и запустил из терминала.

Результат можно увидеть на видео:

Однако разницы, по сравнению с Arduino, практически нет. Отрисовка стала шустрее, но лишь немножко. Оно и неудивительно: чаще всего вызывается метод передачи по SPI (Send_to_lcd), а так как он у нас всё ещё программный, прироста в скорости мы не видим, сам GPIO работает достаточно медленно, по скорости сопоставим с обычным Arduino. Поэтому нам нужно исправлять ситуацию, задействовав аппаратный SPI.

❯ 3. Подключаем аппаратный SPI

Для замены программного SPI на апаратный можно, также, задействовать библиотеку wiringPi, а именно, из wiringPiSPI.h использовать функции wiringPiSPISetup и wiringPiSPIDataRW. Функции эти несколько хитрые. Но перед тем, как их использовать, нужно включить этот самый SPI. Информации о том, как это сделать конкретно на Orange Pi PC также в интернете нет, но удалось найти направление, в котором нужно искать. Немного погуглив, я выяснил, что spi включается правкой файла /boot/armbianEnv.txt (актуально для моей версии системы Armbian_23.11.1_Orangepipc_jammy_current_6.1.63_xfce_desktop.img).

В него нужно добавить следующие строки:

После чего сделать sudo reboot, и у нас в /dev/ появляется spidev0.0. Проверить это можно, выполнив команду ls /dev | grep spi. Если spidev0.0 появился, дальше библиотека wiringPiSPI подхватит его. Теперь контакты дисплея CS, CLK, DATA нужно подключить к пинам SPI0, как это сделано у Hoshi. Распиновка (40-pin) полностью соответствует Raspberry Pi. Пины RS и RESET оставляем на попечении обычного GPIO.

Однако, просто заменив SPI на аппаратный, я заметил, что FPS отрисовки практически не поменялся. Проблема заключалась в том, что если отправлять по одному байту, то с каждой посылкой SPI будет заново открываться и закрываться, а эта процедура отнимает очень много времени. Поэтому было решено отправлять данные пачками максимально возможной длины.

Возникла следующая проблема: буферизация пакетов SPI. На данном устройстве мы можем отправить только 4 килобайта данных за одну посылку. Наша страница же занимает порядка 44 Кб: 132*176*2, так как используется 16-битная цветность. В качестве решения можно было либо увеличить буфер SPI, что возможно, однако, мне не хотелось прибегать к данной методике. Поэтому я просто в своём коде раздробил страницу на 11 пачек:

И используя memcpy, копировал перед отправкой каждую пачку в буфер. К слову, это необходимо ещё и потому, что буфер побайтово очищается в процессе передачи, заменяя выходные данные на входные с буфера RX (MOSI pin).

Также библиотека позволяет регулировать скорость: от 500 КГц до предела в 32 МГц. Делается это в момент инициализации: int fd = wiringPiSPISetup(0, 32000000); мы выставляем канал 0, и скорость в 32 МГц.

После вышеописанных процедур мне удалось получить скорость кадров в 60 FPS. Я не уверен, способен ли дисплей отрисовать данные с такой скоростью, но таймер рапортовал именно так. Можно увидеть это на видеозаписи:

На первой половинке видео можно увидеть кусочек области дисплея, который передаётся за одну отправку (4096 байт), это примерно одна десятая всей экранной области. Скорость шины выставлена в 500 КГц. На второй половинке отправка всех 11 областей, и скорость шины в 32 МГц. То есть, скорость передачи примерно порядка 20 Мбит/сек. В данном случае, я считаю, достигнут потолок пропускной способности всей нашей сборки.

❯ 4. Выводим статичный bmp кадр

Следующее, что сделал Hoshi в своей статье – вывел статичную картинку, получив проблемы с цветностью. Поскольку я иду по его стопам, я попробовал вывести картинку из буфера, используя частично его код, поменяв только сдвиг (offset, так как мой заголовок занял другое количество байт). Однако, сначала я получил такую картинку, как показана на левой части изображения, и, лишь потом, такую, как на правой:

Я взял такую же картинку, как у Hoshi, и получил примерно такой же результат. Подводный камень заключался в следующем:

1. Два байта нужно поменять местами, этот момент был в коде Hoshi. Либо же добавить/убрать один лишний байт в начале пакета, чтобы вызвать сдвиг всего массива.

2. Я сохранил исходную картинку через Adobe Photoshop в формат BMP 16-bit. Однако, как выяснилось после просмотра в HEX-редакторе, белый цвет у меня получился не FF FF, а FF 7F, вследствие чего он отображался, как бирюзовый, и остальные цвета также имели искажения:

Произошло это из-за того, что редактор сохранил BMP файл в режиме X1R5G5B5 (с альфа-каналом), а у нас в дисплее используется R5G6B5, то есть, зелёный цвет занимает на один бит больше. Поэтому, при скармливании картинки дисплею, мало того, что один из старших битов пропадает, так ещё и происходит бинарный сдвиг одного цветового канала на единицу, из-за чего вся палитра оказывается искажена. После сохранения картинки в нужном режиме значения белого заменились на FF FF, потери одного бита данных больше не было, и она отрисовалась с нормальной цветностью.

На этом построение библиотеки для работы с дисплеем было закончено, и началось самое интересное – попытка вывести на него живой видеопоток.

❯ 5. Пишем ПО для захвата экрана

Далее вышеупомянутый автор для рендеринга использует интерполяцию из фрейм-буфера ОС Linux /dev/fb0. Попытка запустить его код не привела ни к чему хорошему: в моём случае фреймбуфер отображается как чёрная сетка из-за несоответствия данных, да и мне не нужно было проводить интерполяцию картинки всего рабочего стола, а нужна была конкретная область экрана.

Слева: отрисовка из /dev/fb0. Справа: отрисовка из скриншота.

Так как моя GUI в Armbian работает на графической оболочке XFCE, у меня возникла идея выдрать требуемые пиксели непосредственно через неё. Для этого используются средства gdk и x11. Добавление всех необходимых библиотек сильно усложнило бы программу, поэтому мне пришлось прийти к костыльному решению проблемы.

Я решил копнуть в сторону встроенной в ОС утилиты xfce4-screenshooter. Данная утилита позволяет снять скриншот, в том числе, через командную строку. Однако, функции сохранения заданной области в ней нет, либо требуется задавать каждый раз область мышкой, что было мне неудобно. Поэтому я сделал форк кода данной утилиты. И добавил в опции командной строки, помимо FULLSCREEN, WINDOW и REGION ещё и аргумент FIXED, который сохранял в файл конкретно прописанную в коде область экрана.

Для удобства разработки пришлось поставить xubuntu на виртуальную машину с x86, после чего изменить исходный код, а затем собрать его же, но под armbian непосредственно на своём Orange Pi. Сборка утилиты осуществляется помощью xdt-autogen: сначала ./autogen.sh, далее установить библиотеки по требованию (через apt-install) затем с помощью make, и make install для замены установленного в систему скриншоттера на изменённый вариант. После этого готовый скриншот нужного размера стало можно выводить в файл с помощью одной лишь команды терминала – для определения файлового пути, формата и прочего используется оригинальный код скриншоттера.

Однако, данное решение имеет и недостаток: программа-скриншоттер работает, вероятно, таким образом, что сначала делает скриншот всего root-окна (рабочего стола), затем обрезает его до требуемого размера. При этом, на какой-то момент, отрисовка даже приостанавливается. Вся процедура съемки занимает порядочное количество времени: на десктопе xubuntu она осуществлялась примерно за 50-100 миллисекунд. На Orange Pi она же стала занимать порядка 100-400 миллисекунд. Видеозахват – в целом тяжелая процедура для ЦПУ. Поэтому уменьшение разрешения рабочего стола помогло, но незначительно. В идеале нужно выдирать изображение через низкоуровневый код непосредственно из экранной памяти, а не из пользовательской среды через функции gdk. Более того, в самом коде скриншоттера написано, что рекомендуемая задержка между скриншотами должна быть не менее 200 мс, то есть, это уже ограничивает нас до 5 FPS. В случае, если нужно просто проверить консольный вывод, этого достаточно, а вот для видеопотока оказалось маловато.

Прим. авт.: через некоторое время после написания статьи, мне удалось решить данную проблему, используя вместо скриншоттера ПО jsmpeg-vnc. С ним я получил 50 FPS и выше, плюс имеются встроенные функции обрезки кадра до нужного размера.

Данное ПО передаёт MPEG-поток через WebSocket протокол (выполняя трансляцию видеосигнала), позволяет закодировать только нужную область, чтобы не передавать весь рабочий стол. Далее кадр можно расшифровать и передать непосредственно в контроллер, минуя костыль в виде отображения его на экране и снятия скриншота. Если это будет интересно, можно показать подробнее в следующей статье.

Также, поскольку сохранение в bmp происходит через встроенные средства gdk, мне не удалось заставить программу сохранять в 16-битный формат. Она сохраняла в 24-битный формат, поэтому для преобразования цветовой палитры мне пришлось написать фрагмент кода на бинарных сдвигах:

Изначально содержимое нашего скриншота копируется в массив байтов (uint8_t) в порядке очередности. Для конвертации цвета 24bit -> 16 bit (ещё и с перевёрнутым порядком байтов) использованы сдвиги: мы сравниваем первый байт красного с пятью единицами, далее сравниваем второй байт зелёного с тремя единицами и сдвигаем результат в самое начало, далее сравниваем следующие разряды байта зелёного и сдвигаем в самый конец, далее сравниваем синий и сдвигаем его в середину. Таким образом, из цветности КККККККК ЗЗЗЗЗЗЗЗ ССССССС мы привели палитру к цветности ЗЗЗССССС КККККЗЗЗЗ, которую и принимает наш дисплей. Для отладки я использовал цветные картинки, после чего смотрел, корректно ли отображается цвет согласно своему описанию, или же цветовой канал требуется сдвинуть ещё на какое-то количество ячеек.

После чего я в цикле запустил скриншоттер через вызов терминала, а далее отрендерил картинку на экран. Это можно увидеть на видео:

Конечно, данный пункт программы нуждается в доработке – ссылки на заголовочные файлы библиотек gdk и x11 следует внести в общий файл программы, в котором происходит работа с дисплеем чтобы избежать костыля в виде сохранения картинки в кэш на жестком диске. Возможно, это несколько улучшит производительность. А для идеальной работы требуется переписать это всё на уровне ядра ос, чтобы превратить самодельную библиотеку в драйвер для устройства. Но на текущий момент ход программы получился такой:

• Через терминал вызывается скриншоттер, который сохраняет кадр в cache.bmp;

• Файл cache.bmp открывается, после чего отправляется его содержимое на дисплей.

Причём, основная потеря скорости идёт на этапе снятия скриншота, а не записи/чтения его с диска. Для увеличения FPS выше 5 необходимо заменить xfce4 скриншоттер на какое-то другое ПО. Тем не менее, мы движемся дальше.

❯ 6. Эмуляция сотового телефона

Эмулятор телефона CX75 был написан лет 20 назад, и входил в официальный пакет программ для разработки java-приложений через WTK/JDK 2.0. Он пролежал у меня на жестком диске лет 15, после чего я запустил его для данной работы. Если кому-то интересно также запустить его на своём компьютере, делюсь файлами.

Для работы требуется JDK 6u45 и Windows XP. Насколько я помню, даже при запуске на Windows 7 эмулятор вылетал, на Win 10, тем более, работоспособность я не проверял. Поэтому запускать я его буду через виртуальную машину с WinXP.

Эмулятор полностью реализует функционал прошивки телефона 75-й серии, в том числе, можно устанавливать java-игры, подключать веб-камеру для съемки фото, и так далее. Единственное, вряд ли будет работать интернет, по причине того, что WAP технологии уже не получится использовать.

Вот так эмулятор выглядит в системном окне. Управлять можно с клавиатуры (джойстик – стрелки и enter, клавиши – цифры или тачпад), либо нажатием на виртуальные кнопки.

Выдаёт он картинку чётко размера 132x176, поэтому интерполяция не потребуется. Теперь нужно прокинуть картинку из виртуальной машины в Linux машину. Можно было использовать wine, но я не уверен, будет ли эмулятор адекватно работать на нём. Поэтому он запущен в XP. Для передачи картинки, опять же, ничего нового изобретать я не буду, использую TightVNC.

На Windows мы устанавливаем сервер, на armbian’е устанавливаем клиент через apt-get xtightvncviewer.

После чего запускаем клиент-сервер, и выставляем на экране требуемую зону отображения. FPS в данном случае также примерно равен 5 кадрам, поэтому дисплей будет рендерить с точно такой же скоростью.

И вот момент, ради которого всё затевалось: помещаем эмулятор телефона в экранную область на самом телефоне

Видео:

Таким образом, наш видеопоток проходит через следующие уровни:

• Эмулятор CX75 (x86 C-программа, но порт ARM-совместимой прошивки);

• Windows XP (виртуальная машина);

• Windows 10 (через виртуализацию, но можно пропустить, выведя в VNC напрямую с XP);

• Armbian xfce4 gui (через VNC);

• Изображение cache.bmp (через xfce4-screenshooter);

• Дисплей C75 (через wiringPi + wiringPiSPI).

Для эмуляции же клавиатуры достаточно просто припаять контактные площадки к контроллеру от USB-клавиатуры в соответствии со схемой их разводки:

Делать этого сейчас я не буду по причине того, что это несколько монотонное занятие, и вся задача заключается лишь в правильном сопоставлении таблиц кнопок и таблиц на контроллере от USB клавиатуры. После чего клавиатура подключается к виртуальной машине, и можно испытать полное погружение в эмулятор.

❯ 7. Заключение

Результат проекта:

В ходе работы были изучены особенности работы с GPIO, SPI, GTK3, VNC, преобразованием цветности и некоторым другим функционалом компьютерных и микроконтроллерных систем.

Готовые файлы проекта под wiringPi.

Спасибо за внимание.

• Написано специально для Timeweb Cloud и читателей Пикабу. Подписывайтесь на наш блог, чтобы не пропустить новые интересные материалы.

• Также подписывайтесь на наш телеграмм-канал — только здесь, технично, информативно и с юмором об IT, технике и электронике. Будет интересно.

• Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать наши проекты.

• Автор: MaFrance351

Многие из нас всё ещё помнят такой стандарт связи как AMPS. В лучшие времена он, как и другой аналоговый стандарт NMT-450, был достаточно популярен на просторах России. И, возможно, у кого-то из нас даже был такой телефон.

Хотя сети общего пользования прекратили работу уже давным-давно, при помощи некоторого оборудования и софта всё ещё возможно дать старым телефонам возможность вновь зазвонить.
Итак, в сегодняшней статье разберёмся, как запустить сотовую сеть стандарта AMPS. Узнаем, с какими сложностями придётся столкнуться и как заставить всё это работать. Традиционно будет много интересного.

❯ Суть такова

Как и многих других любителей старой электроники, древние телефоны не обошли меня стороной. Хотя основным моим увлечением по этой части остаётся компьютерное железо, да и из мобильных устройств мне больше нравятся КПК, смартфоны и коммуникаторы (без привязки к стандарту связи и оператору), такие древние трубки у меня всё же имелись. И, разумеется, мне всегда хотелось их запустить. И вот, спустя столько лет, мне наконец-то удалось приобрести полноценный SDR, так что теперь у меня есть возможность увидеть всё это в работе. А раз так — самое время поведать об этом миру.

❯ Немного истории

Сети стандарта AMPS принадлежали к первому поколению мобильных сетей. Появившись в начале восьмидесятых, они достаточно быстро получили распространение в Америке (где вообще стали первыми сотовыми сетями), а позже и в других странах мира. Немало легендарных устройств работали в этом стандарте, например, первый коммерчески доступный мобильный телефон Motorola DynaTAC или один из первых смартфонов IBM Simon. И даже первый звонок по сотовому телефону был совершён именно в сети этого стандарта.

В России эти сети появились в 1994 году и были развёрнуты компанией «Вымпелком» (он же «Билайн»). Как удалось найти, в них использовалось оборудование Ericsson, телефоны предлагались преимущественно этой же фирмы.

К концу нулевых годов AMPS стал сдавать позиции и был вытеснен более совершенными GSM и D-AMPS (впрочем, имеющего мало общего с «оригинальным» AMPS). Последние сети этого стандарта были отключены в 2008-2010 годах.

❯ Как работает AMPS

И перед началом экспериментов разберёмся, как же были устроены данные сети.
По принципу работы AMPS очень близка к своему предшественнику IMTS (Improved Mobile Telephone Service). Это типичная аналоговая сотовая сеть с частотным разделением каналов. Всего их 416 — 395 голосовых и и 21 управляющий. Каналы эти назначались автоматически, в зависимости от занятости и уровня сигнала.

В отличие от регионов NMT, тут используются так называемые System ID, кодирующие сети операторов. Сети делятся на два типа — System A (нечётный ID) и System B (чётный ID), для каждой из них выделены свои каналы.

❯ Что нужно для запуска

Итак, определимся с оборудованием. Для создания нашей сети нам понадобится примерно следующее:

1. Компьютер с ОС Linux. Машина должна быть достаточно мощной, Raspberry Pi не подойдёт. Также обязателен хотя бы один свободный порт USB 3.0. Использовать ВМ я настоятельно не рекомендую, чуть позже я покажу, почему.

2. Полнодуплексный SDR, совместимый с GNU Radio. В качестве него подойдут, например, LimeSDR, USRP или BladeRF.

3. Антенны, рассчитанные на частоту в районе восьмисот мегагерц или антенная нагрузка (что ещё более предпочтительно)

4. Собственно, сам телефон. Как нетрудно догадаться, аппарат должен включаться и пытаться ловить сеть. Антенна также должна быть на месте.

Вся сложность заключается именно во втором пункте. Дело в том, что полнодуплексный SDR на момент написания поста стоит весьма недёшево ввиду наличия в его составе «жирной» ПЛИС и трансивера.

❯ Обзор оборудования

Ну что же, самое время взглянуть на железо.

Это самый важный из всех компонентов — USRP B200-mini, он же full-duplex SDR. Железка по-настоящему крутая, для экспериментов с сотовыми сетями она просто идеальна. Единственное — цена такой штуки весьма впечатляет.

Теперь очередь телефонов.
Это Ericsson R300LX. У него интересная судьба: в своё время, когда отключали аналоговые сотовые сети, эти телефоны продавали очень дёшево, и я купил его всего за десять рублей в привокзальной палатке. В годы начальной школы он был моей любимой игрушкой. Аккумулятор был потёкший, и я его сразу выкинул, так что запускать аппарат будем от ЛБП. Благо ещё в те далёкие годы я припаял два проводка. Позже я раздобыл ещё один такой телефон, его и буду использовать в рамках данного поста.

А это Ericsson T60D. Аппарат куда более поздний, нежели предыдущий. У него также была версия T60C стандарта CDMA.

Аккумулятор у него тоже дохлый, но подключается он через разъём, а не подпружиненные контакты, так что я просто откусил вздувшуюся банку и припаял взамен другую батарею (она от отслужившего своё аккумулятора Lego NXT. Постоянно использовать её, конечно, не выйдет, но для тестов сгодится).

Самая интересная, на мой взгляд, особенность этого телефона — ЭЛИ-подсветка. Если его разобрать, на плате можно увидеть характерную плёночку, светящуюся при подаче на неё переменного напряжения высокой частоты. Аналогичная технология использовалась в телефоне Motorola RARZ V3.

Ericsson LX588. Увы, у обоих аппаратов сломаны и утеряны антенны, так что в данных экспериментах они участвовать не будут, хоть они и включаются и пытаются работать.

Nokia 8260. Это самый поздний аналоговый аппарат, что у меня есть, если бы не отсутствие слота под SIM, его было бы сложно отличить от обычной GSM-трубки.

Среди прочих аппаратов есть и те, которые заслуживают более подробного описания. Вот, к примеру, Motorola MicroTAC, как по мне, один из самых крутых аппаратов того времени в плане дизайна (наряду со StarTAC от той же Motorola). Их было выпущено много модификаций, в мои руки попала MicroTAC Ultra Lite.

Обратная сторона. Под батареей находится краткая инструкция со списком основных действий.
Что примечательно, средний контакт аккумулятора хоть и есть, но не задействован. Он используется не для контроля состояния аккумулятора, а для активации режима Test mode.

Никелевый аккумулятор, разумеется, давно сдохший. Без этой штуки телефон теряет весь свой шарм, перестаёт приятно оттягивать руку и, если бы не светодиодный дисплей, он бы напоминал типичный древний аппарат от Ericsson.

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

А вот так на ней лежит аппарат.

Внутренности. В некоторых моделях стоял ещё и микроконтроллер PIC, но у меня его нет.

Девайс в работе. Даже по нынешним меркам светодиодные матричные индикаторы очень классно смотрятся и навевают мысли о старых авиаприборах.

Ещё одной интересной особенностью является наличие у него зарезервированных функций меню.

А вот и легендарный StarTAC. Вообще, я не очень люблю раскладушки, но этот девайс (наряду с КПК Sony) мне безумно нравится.

Он же в сложенном виде. Увы, аккумулятор от него давно утрачен. Кстати, это единственная известная мне раскладушка, где батарея установлена в верхней части.

❯ Ставим софт

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

Вообще, кое-что про работу с софтом, что мы будем сейчас использовать, я уже рассказывал в посте про NMT-450, так что настоятельно рекомендую вначале прочитать его. Хотя стандарты и оборудование сильно отличаются, по части софта многие аспекты полностью идентичны.
Как и в случае с NMT, я буду использовать Osmocom Analog. В отличие от другой реализации AMPS для GNU Radio, gr-amps, этот софт намного более прост в установке и запуске.
Итак, для начала необходимо установить ПО для управления SDR (UHD или LimeSuite). Выбор его зависит от вашей железки, так что подробно описывать это не вижу смысла.

Далее нужно установить библиотеку SoapySDR:

sudo apt install libsoapysdr-dev
sudo apt install soapysdr-tools

Это официальный вариант от разработчиков Osmocom Analog. Я встречал информацию, что нужно использовать только конкретную версию библиотеки, иначе будут проблемы с запуском, но на момент написания статьи, похоже, это было исправлено, так как у меня всё запустилось нормально.

Если же у вас нет желания разбираться с библиотеками и прочими зависимостями, то я рекомендую запускать всё на Dragon OS. Это известный в узких кругах дистрибутив Lubuntu, этакий идеологический аналог Kali Linux, только если последний ориентирован на хакеров, Dragon OS предназначена для работы с SDR и радио. Там уже установлены все необходимые программы, так что проблем у вас быть точно не должно. На всякий случай я оставлю ссылку на ту версию, что я использовал, в конце статьи. Точно также я выложу уже скомпилированный софт, который будет достаточно только установить и запустить.

Теперь необходимо собрать Osmocom Analog. Делается это очень просто:

git clone git://git.osmocom.org/osmocom-analog
cd osmocom-analog
autoreconf -if
./configure
make clean
make sudo
make install

После сборки у вас должна будет появиться папка osmocom-analog, где в папках в разделе src будут лежать нужные нам программы для запуска сетей. Вообще, этот софт можно использовать и с аналоговым трансивером (по сути всё абсолютно аналогично тому, что я описывал в посте про NMT), но найти SDR оказалось проще, чем приёмопередатчик на такие частоты.

Кстати, существует ещё и вот такой проект. Как по мне, это одна из самых крутых реализаций такой сети, а подробное описание собранного девайса потянет на отдельную статью. Но об этом всём как-нибудь в другой раз. Кстати, именно автор данного девайса сильно помог проекту Osmocom-Analog в реализации сети AMPS.

❯ Запускаем сеть

Ну что же, пробуем? Втыкаем SDR в компьютер, включаем наш телефон.

Запускаем наш софт:

amps --sdr-uhd -k 334 -k 320 --samplerate 512000

При первом запуске после перезагрузки (а также если была нажата кнопка RESET на SDR или он был отключён от компьютера) программа выдаст ошибку обращения к SDR. Это норма, через несколько секунд в SDR должна будет загрузиться конфигурация, и всё заработает. Если не работает — надо разбираться с драйверами SDR.

Остаётся только положить телефон рядом с антеннами и ждать чуда.

И, если всё было сделано правильно, телефон поймает сеть и скажет, что мы в роуминге (так как код оператора отличается от того, что прошит в него).

При этом в окне посыпятся логи. Здесь же можно увидеть номер — в моём случае это 3512761234., Присвоенный номер наводит на мысли о наследии старых сотовых операторов — когда-то давно мобильные номера выдавались просто с кодом города, а не оператора (что, кстати, отражено в моём нике: 351 — код города Челябинска).

Всё, можно пробовать звонить.

❯ Итак, оно не работает

Если телефон сразу нашёл сеть и подключился к ней — поздравляю. Всё успешно запущено, теперь можно пробовать звонить.

Но, как оказалось, всё не так просто, как может показаться.

Если сеть не запускается, следует попробовать поменять samplerate на более большой. Завышать его, правда, тоже не стоит, так как ресурсов это будет тратить больше, а особого результата не будет. Значение это должно быть таким, чтобы обеспечить работу всех созданных каналов.

Если же появляются строки вроде «SDR underrun», скорее всего, не хватает пропускной способности порта. Причин для этого много, либо SDR воткнут в «медленный» USB 2.0 вместо USB 3.0, либо компьютер слишком слаб, чтобы держать столько каналов. К слову говоря, это одна из причин, почему не стоит запускать софт на виртуальной машине. У меня нет отдельного мощного ПК с линуксом на борту, но было достаточно записать Dragon OS на флешку и загрузиться с неё, чтобы сообщения об ошибках пропали.

Запустив сеть, надо включить телефон и ждать, пока он не увидит сеть. Процесс этот не слишком быстрый, использовавшийся как основной для экспериментов Ericsson T60D перед нахождением сигнала тупил где-то минут десять. Если всё равно не находит — пробуем выбрать сеть вручную.

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

Также причина отсутствия сети может крыться в антеннах. В своих опытах я использовал таковые из комплекта от другого SDR, HackRF (эти же антенны я пробовал подключать к рациям в опытах с NMT). Попытки использовать антенны от рации или от другого телефона не увенчались успехом, трубки либо в упор не видели сеть, либо ловили, но звонок не шёл. Кстати, упомянутый Ericsson T60D в этом плане показал себя лучше всех, что даже было для меня удивительным, так как больше всего надежд возлагалось на R300LX.

❯ Звоним

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

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

Чтобы получить возможность принимать звонки, необходимо использовать звуковую карту, аналогично тому, как это было показано в статье про NMT.

Для звонка на телефон необходимо узнать его номер. Увидеть его можно в логах регистрации или при звонке. Далее необходимо набрать его (если с этого телефона уже осуществлялся звонок, то номер будет вписан автоматически) и жмякнуть на клавиатуре «d».

❯ Про каналы и Test mode

Для правильной работы сети важно выбрать правильные номера каналов. Если они совпадают с теми, что записаны в телефон, то находить сеть он будет практически моментально (MicroTAC, на котором удалось зайти в сервисное меню, делал это за несколько секунд), иначе же ему придётся сканировать весь эфир, что занимает достаточно длительное время.

У меня есть телефон Motorola MicroTAC, на котором ставить данные опыты проще простого. Не нужно кодов, секретных комбинаций кнопочек, каких-то внешних причиндалов, подключаемых к аппарату. Достаточно только соединить средний контакт аккумуляторного разъёма с землёй. Если батарея вашего телефона перепакована, то достаточно всунуть в отверстие комочек фольги (средний контакт батареи через диод соединён с минусом), если же телефон питается от ЛБП, то нужно подкинуть земляной провод к этому контакту. Далее необходимо включить телефон, и он перейдёт в тестовый режим, после этого соединение можно размыкать. Вообще, для опытов с AMPS советую разжиться телефоном именно такой модели (StarTAC, MicroTAC, TeleTAC), ввиду огромного числа функций, могущих помочь при наладке сети.

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

Разумеется, помимо просмотра и настройки каналов в данном режиме можно делать много интересного. Есть такой текстовик как Motorola Bible. Тогдашние гуру фрикинга сотовых телефонов скажут, что всё написанное там — полная чушь. Не буду ручаться за это, но кое-что интересное оттуда таки можно почерпнуть. А именно — номера команд и способы входа в Test mode для целого модельного ряда аналоговых телефонов Motorola. В частности, в этом режиме можно осуществлять настройку передатчика, просмотр серийного номера (ESN), программирование кода абонента (NAM) и многое другое. Описание приведено для двухстрочных моделей, но на моём многие команды тоже завелись...

Продолжение в источнике материала. Увы, все фото не влезли, а именно в них вся суть и самое вкусное. :)