Добрейшего времени суток, уважаемые ретрограды.
Когда-нибудь похожий терминал будет показывать логотип RobCo.
Продолжаем серию наших пикабу-передач про вторую жизнь старого терминала. Зачем?... Потому что вещи 90х обладают сладким флером ностальгии. Во второй части я обещал рассказать про физическую часть переходника(я, наконец, заказал плату, но пока не спаял).
Вид сзади. Нас интересует порт справа - DB15.
Как я уже рассказывал в предыдущей статье - в данных терминалах нет никаких средств связи, кроме порта(и, видимо, приёмо-передатчика) Twinax (LPT не в счет). Этот магический протокол работает таким образом, что терминал это всегда исключительно slave (в 90е еще можно было так называть), а "головная" часть находится на стороне майнфрейма. Забегая вперед - именно этот майнфреймм мы и будем эмулировать.
Вот такой шкафчик пришлось бы поставить дома, чтобы вернуть работоспособность терминалу без новых технологий. И всё это было слабее смартфона, через который вы, вероятно, читаете эту статью.
Перво-наперво, информацию о таких старых девайсах можно поискать в библиотеке IBM. Однако определенное время назад там произошел сбой, а бекапы, как мы знаем, для слабаков - часть старой документации была утеряна. Тем не менее, для пытливых умов рекомендую сайт bitsavers.
Документации по терминалу - кот наплакал. Но на самом деле всю работу за меня сделал некий inbolmie с форума deskthority - отличный форум для любителей старого железа и не только. Он собрал данные по однотипным терминалам и установил, что поскольку они работают по протоколу twinax, значит есть определенная унификация и ВСЕ терминалы, поддерживающие данный протокол будут работать через конвертер. На всякий случай оставлю ссылку на первоисточник.
Как получился этот терминал.
Документацию в 90х писали не то, что сейчас - тогда подразумевалось, что пользователь с паяльником может полностью восстановить не рабочее устройство. В описании терминала 5250 было указание на модуль работы с протоколом twinax и ссылка на процессов DP8344. Проц старый, но нас интересует не он(мы же не на сайте oldje (извините)), а описание принципа работы и характеристики:
Проц старый и понимает только ассемблер. Последний раз я асму держал в руках 15 лет назад и возвращаться к ней не очень хочется. После изучения доступной на битсейвере инфы, можно прийти к выводу, что:
Не надо изобретать свою плату, можно использовать схему 25-ти летней давности, повторив её - компоненты должны стоить копейки(о, как я ошибался).
нужен микроконтроллер, который будет конвертить из твинакса в "нормальный" вид
Конвертер конвертером, но нужен "заменитель майнфрейма", который и будет конечной точкой подключения терминала.
В исходной статье автор отказался от использования Raspbery Pi в качестве мозга конвертора, потому что порты GPIO работают куда медленнее 2Мгц и не вытянут семплинг, а еще там будет линукс, который чтобы заставить работать напрямую с портами(чтобы повысить быстродействие)-то еще развлечение. Следующим вариантом был FPGA, но для людей без опыта работа с данной микросхемой вообще не очевидна. Может быть, второе устройство я сделаю как раз на FPGA - оно бы решило все проблемы с быстродействием. В общем, автор статьи на дескторити решил взять Teensy 4.0 600Мгц, но данная микруха в 2025м в Москве(с доставкой) стоит порядка 4к (напомню, весь терминал 11к) и игрища с ней в мои финансовые планы не входят. По этому я выбрал китайский аналог AT32F403ACGU7 - похожая по характеристикам(медленнее) плата с процом частотой 240Мгц и стоимостью 280р на Али. Зачем нам такая частота для протокола и скоростей 90х? Как я уже говорил, twinax (да окончит Бог-Машина его циклы) работает на 2Мгц, это значит, что по теореме Котелькова мы должны считывать (дискредитировать, или как там) сигнал с частотой минимум 4Мгц. Однако, микроконтроллер не может на каждый такт выполнять команду, одна команда занимает несколько тактов, а нам, я предвижу, понадобится не одна команда для считывания сигнала. В общем, пол-палец-потолок было установлено, что 240Мгц частоты должно хватить впритирку для считывания сигнала от терминала.
Так же в исходной статье, аффтар предлагает конвертер втыкать через USB в современный комп с линуксом, где будет крутиться скрипт, отсылающий шелл на USB.
Мы же с вами схему немного изменим - конвертер будет подключаться не по USB, а по UART (есть в моём контроллере) и не к PC, а к Orange Pi, где тоже есть UART. Таким образом мы оставим терминал "мобильным" - просто к нему прибавится небольшая коробочка. На Оранж Пи я уже поставил Убунту, а это значит, что можно будет через SSH\cli (напомню, терминал ТЕКСТОВЫЙ, никакого графония) подключаться куда угодно. Плюс, я же хочу сделать подобие терминала RobCo из Falllout 4, а для кастомизации баша есть просто тонна утилит.
Про благословленный Омниссией интерфейс twinax можно почитать тут. Всё равно лучше википедии никто не расскажет:
The data transmission is half-duplex, balanced transmission, at 1 Mbit/s, on a single shielded, 110 Ω twisted pair. [...] Twinax is a bus topology that requires termination to function properly. Most Twinax T-connectors have an automatic termination feature. [...]
Signals are sent differentially over the wires at 1 Mbit/s (1 μs/bit ± 2%), Manchester coded, with preemphasis.[...] to provide preemphasis, for the first 250 ns (1/4 bit time) after a signal is driven low, the negative signal line is driven to −1.6 V. [...]
The two wires are denoted A and B. To encode a 0 bit, A>B for the first half of the bit time, and A<B for the second half. A 1 bit is the opposite. Thus, each signal line is driven low for either 500 or 1000 ns at a time, of which the first 250 ns is emphasized.
This is a picture of the teoric waveforms from the DP8344 datasheet.
"Манчестерский" код в протоколе Twinax
Как вы можете видеть, достаточно хитрожопое кодирование - нет "современного" логического уровня(самый нижний график), "единица" кодируется переходом от единицы на ноль в середине бита, а "ноль" - с нуля на единицу, плюс второй провод двух проводного кабеля твинакс дает тот же сигнал но с отставанием на 250 наносекунд (график В относительно графика А). Именно для считывания этого сигнала нам и нужен такой быстрый процессор.
Вообще микроконтроллер должен справиться играючи с задачей кодирования в "манчестерский" код (физическая среда передачи Ethernet, между прочим), нам всего-лишь нужна обвязка.
Из пиндосских не очень секретных материалов получаем данную схему.
Одна SN75110A и одна SN75112 нужны для генерации форм сигнала на линках А и В (между прочим, терминал "лупит" на 152м своим сигналом).
Одна LM361 - аналоговый компаратор - для восстановления манчестерского сигнала путем вычитания канала А из В и вывода результата с цифровым уровнем 3В.
Пара Резисторов 54.9Ом для терминации сигнала.
Несколько И, НЕТ, XOR микрух для логического склеивания.
Дальнейшими деталями сигнала грузить вас не буду, если хотите - читайте исходную статью.
Вот такую принципиальную схему я составил в итоге:
Сначала моя схема, потом исходная.
Отличий особо не заметно, верно? Схему я переделывал в EasyEDA - китайском каде, очень рекомендую. Ну тут понятно, я не менял элементы, если совпадал форм фактор, но микрухи 30ти летней давности в условиях санкций стоят как чугунный мост, по этому где мог, я постарался сделать замену. (опишу в следующей статье)
Сначала исходная схема, потом моя.
Для удешевления пришлось заменить ряд элементов и изменить их форм фактор - вместо DIP14 изначально, поставить SOP14 - как я буду это паять, я пока не представляю. Но... Элементы закуплены, плата в производстве, как только попадет в мои потные ручки - дам знать.
Статья была написала на клавиатуре 8bitdo C64 - если хотите сравнение с IBBM Model M, 8BitDo model M и 8BitDo C64 - черканите в комменты, пожалуйста - мне бы такая статья пригодилась до того, как я всё это купил, а вам - не знаю еще.
UPD:
Теорема, конечно же, Котельникова. Но мне чаще попадалась под английским именем.
А вот ошибка в дискретизации - неудачная попытка пошутить. Спасибо вам за внимательность!
