Геймдев, про который мы забыли: как работали 2D-игры на кнопочных телефонах нулевых
Друзья! А вы помните, какими были мобильные игры в 2000-х годах? Помните, как разработчики умудрялись уместить целые миры в устройство с небольшим дисплеем, аппаратной клавиатурой, весьма слабым железом и парой сотен килобайт памяти? Но задумывались ли вы, как в своё время работали эти сами игры «под капотом»? В сегодняшней статье-ретроспективе предлагаю вспомнить мобильный геймдев нулевых и узнать, как же работали 2D Java-игры, какие API были доступны и что из себя представлял средний телефон тех лет! Интересно? Тогда добро пожаловать под кат!
❯ Предисловие
Пожалуй, геймдев всегда был одной из самых интересных сфер программирования. Множество нестандартных задач, возможность применить профильные математические и алгоритмические познания, а также огромный простор для архитектов в продумывании архитектуры будущей игры, ведь, например, в больших студиях комплексные и большие игры обычно очень сложные и нередко тянут за собой целый пласт легаси-кода и наработок чуть ли не из 90-х.
Но помимо десктопных и консольных игр, существуют и мобильные игры, которые в последние 5 лет вплотную приблизились к уровню AAA на консолях (привет порту GRID, AC Mirage, RE4 на мобилки). А ведь ещё 15-20 лет назад мы играли на кнопочных телефонах с небольшими дисплейчиками, которые в свое время подарили нам множество эмоций и кайфа от прохождения этих самых игр, несмотря на простенькую графику, не особо комплексный геймплей и относительно простой левел-дизайн. Продвинутые мобильные геймеры играли уже на Symbian-смартфонах и WinMobile-коммуникаторах (да, в какой-то момент времени, устройства на WM были весьма перспективными), но чаще всего — на Java-телефонах Nokia, Sony Ericsson, Siemens и, конечно-же, Samsung с LG!
По правде сказать, игры на смартфонах — тема отдельная, например на Symbian был полноценный телефон-игровая консоль Nokia N-Gage, о которой я писал отдельный материал, а о разработке игры под Windows Mobile я относительно недавно написал отдельную статью. У смартфонов обычно было несколько больше ресурсов: шустрее процессор, значительно больше памяти доступной игре, а также возможность запуска нативного кода, но и игры для них было разрабатывать значительно сложнее.
Зато о том, как работали игры на Java-телефонах информации практически нет и этот недостаток нужно исправлять, ведь это была одна из первых попыток унифицировать формат приложений на телефонах вне зависимости от архитектуры их процессоров и ОС на борту. Недавно я писал о том как работали 3D-игры на Java-телефонах, но там затрагивалась только 3D-часть без 2D, звука, обработки ввода и иных модулей, без которых игра не может работать!
❯ Каким был телефон?
В середине 2000-х годов, обычно телефон представлял из себя девайс в корпусе моноблок/раскладушка/слайдер и «флип» с весьма большим цветным дисплеем, одним/двумя (привет Motorola E398) динамиками и несколькими аппаратными кнопками. В зависимости от ценового сегмента устройства, обычно менялся корпус, разрешение и размер дисплея, а также материалы, из которого был изготовлен девайс. При этом у многих больших вендоров были собственные программные платформы — у Nokia это был S40, у Sony Ericsson своя, у Samsung и LG тоже свои.
В среднем, характеристики телефонов были следующими:
Процессор: ARMv4/ARMv5 на частоте ~100-200МГц. Есть исключения — Siemens E-Gold работал на базе архитектуры C166, а платформа Motorola работала на 66МГц (что и объясняет небольшую тормознутось).
ОЗУ: ~8Мб SDRAM. Эта память распределялась под все нужды системы, в том числе и обработку GSM, Java и пользовательский интерфейс. Java-приложениям было доступно ~1Мб ОЗУ.
Постоянная память: в среднем ~10-30Мб, плюс возможность расширения памяти за счет MicroSD или MS Pro Duo (Sony Ericsson).
Казалось бы, не густо. На самом деле вполне достаточно, учитывая все ограничения телефонов тех лет. Но почему именно Java?
Ещё в начале нулевых, когда прогресс развития телефонов шёл семимильными шагами, перед разработчиками телефонов встал вопрос, какой формат для программ выбрать, дабы привлечь как можно больше разработчиков на рынок мобильных приложений. Очевидно, что нативные программы на C/C++ точно не подойдут (разные архитектуры, большие отличия в платформах), поэтому нужна была виртуальная машина с собственным байткодом. Вариантов было несколько: Mophun, некая корейская виртуальная машина (точного названия, увы, не помню и инфы очень мало) и, конечно-же, Java с JVM. Со временем именно J2ME стала стандартом благодаря оптимальной скорости работы, хорошему и простому API и низкому порогу входа.
❯ Какие API существовали?
Несмотря на то, что игры под кнопочные телефоны писались на Java, набор API и поддерживаемых пакетов отличался от обычной JVM на ПК, которую использует, например, Minecraft. Всего существует три профиля — J2SE (Android и ПК), J2EE (серверы и энтерпрайз) и J2ME (встраиваемая электроника и телефоны). Однако сам по себе J2ME делится ещё на два стандарта — CLDC/CDC (набор поддерживаемых фишек языком — например, ранние телефоны не поддерживали float) и MIDP (набор поддерживаемых телефоном фишек — работа с дисплеем, проигрывание звуков, доступ в сеть и обработка ввода — всё это часть MIDP). За всё время существования было две версии MIDP — 1.0, которая была весьма ограничена в возможностях (например, нельзя было развернуть игру на весь экран) и использовалась с 2001 по ~2003 год и MIDP 2.0, которая использовалась вплоть до кончины J2ME.
Теоретически, появление J2ME должно было стандартизировать игры на телефонах разных производителей… но был нюанс — ведь функционал телефонов рос как на дрожжах, разрешение дисплеев тоже, у телефонов появлялась собственная память и файловая система, возможность подключения к интернету и Bluetooth и появился целых ворох API…
Несмотря на то, что игры по большей части были одинаковыми (или почти одинаковыми) на всех кнопочных телефонах, тем не менее набор поддерживаемых API каждым устройством значительно отличался. Вероятно, вы помните как многие игры подразделялись не только на версии для разных разрешений дисплея, но и на версии для каждого производителя отдельно: Nokia, SE, Samsung и т. п. Для реализации каких-то особых фишек (например, быстрая отрисовка изображений с регулируемой прозрачностью) требовалось использовать пакеты, неподдерживаемые в базовом профиле MIDP. И подобные пакеты делились на два типа — JSR и Vendor-specific пакеты.
JSR — это расширения-спецификации (то есть просто описание классов без какого либо кода), которые вносились в специальную базу Java community process и формально стандартизировались среди всех нормальных производителей телефонов. Среди таких JSR есть и поддержка 3D-графики (JSR184 — M3G, JSR239 — OpenGLES Bindings for J2ME), и доступа к файловой системе устройства (JSR75), и возможность использования Bluetooth для реализации мультиплеера (JSR82). Говоря простыми словами, это опциональные «фишки», которые могли быть доступны на каких-то телефонах, а на каких-то не поддерживались и соответственно игры, которые их используют, в большинстве случаев просто вылетают с ошибкой (однако особенно «умные» игры используют рефлексию и определяют поддерживается ли та или иная функция с помощью метода Class.forName).
Vendor-specific пакеты обеспечивали очень крутой функционал, характерный не просто одному производителю телефонов, а зачастую даже одной линейке телефонов на определенной платформе. На SE такие пакеты практически не использовались (кроме, конечно, Mascot Capsule), а вот на Nokia постоянно (Nokia UI, Nokia S40 API), позволяя на изначально «слабеньких» s40-телефонах рисовать в буфер дисплея напрямую, а также отрисовывать треугольники, рисовать полупрозрачные картинки и выполнять некоторые другие операции, недоступные на других телефонах. У Samsung, же, например, в свое время была поддержка MMF-звуков в мобильных играх, что в начале и середине 2000х годов было просто нереально крутым, даже несмотря на другие ограничения корейских телефонов.
❯ Графика
Возможности по отрисовке графики на кнопочных телефонах были не сказать что сильно широкие, но тем не менее позволяли легко реализовать графику уровня SNES или даже PlayStation 1. Например, в отличии от современных смартфонов, мы не могли использовать шейдеры, умножить спрайт на цвет (дабы придать ему другой оттенок) и даже использовать аффинные трансформации (поворот, скейлинг) — исключительно полупрозрачные спрайты даже без возможности плавно «растворить» спрайт путем изменения его альфы! Поэтому многие разработчики шли на «хак» и предварительно рисовали в редакторе 8-16 положений одного спрайтов с разным углом поворота, дабы потом выбрать нужный в зависимости от физического угла поворота в градусах!
Для графики использовался пакет javax.microedition.lcdui, в котором были классы для построения нативного интерфейса (выглядело так себе на большинстве телефонов), а также механизм фреймов (Form, Canvas).
Для игр же предлагался Canvas и GameCanvas, которые позволяли развернуть поверхность для рисования на весь экран и предлагали инстанс объекта Graphics, который сразу предоставлял механизм двойной буферизации! В свою очередь, Graphics предоставлял методы для отрисовки спрайтов (Image и drawRGB для «сырых» картинок не в нативном-формате, может быть медленно), примитивов (линии, прямоугольники, овалы), текста и… всё! Например, картинку можно было нарисовать вот так:
getGraphics().drawImage(img, 0, 0, Graphics.LEFT | Graphics.TOP);
При этом с шрифтами вопрос был отдельный: у каждого устройства был свой набор поддерживаемых шрифтов и свои фишки, о которых клиентская программа даже могла и незнать: например поздние телефоны поддерживали сглаживание шрифтов (что дико лагало на устройствах типа Nokia Asha), но что самое забавное — шрифты не могли быть произвольного размера, лишь 3х типов (один из них — моноширинный) и 3х размеров (маленький, средний, большой). Немудрено, что многие вендоры реализовывали свои рендереры битмапных шрифтов, которые точно будут нужного разработчику размера.
Но откуда же грузить картинки? Для этого, в Java был использован встроенный механизм открытия ресурсов из JAR: никакого кэша, никаких OBB, все нужные данные сразу в пакете с игрой. Да, это накладывало некоторые ограничения: например на телефонах Samsung долгое время было ограничение ~250Кб на приложение, зато было просто и портативно. Выглядело это вот так:
InputStreamReader reader = new InputStreamReader(getClass().getResourceAsStream('/img.png");
Или в случае картинок так:
Image image = Image.createImage("/img.png");
Всё очень легко и понятно, согласитесь?
❯ А звук?
Помните диалог «включить звук» при запуске почти каждой игры? Конечно же помимо графической части, в каждой игре должен быть и звук! И с его реализацией были свои нюансы: ведь в MIDP 1.0 звук поддерживался только с помощью Vendor-specific API (то есть его вообще могло и не быть, зато на телефонах Samsung поддерживался MMF, что, как я уже и говорил раннее, было очень круто).
MIDP 2.0 уже стандартизировал нормальный протокол для общения с мультимедийной подсистемой устройства с помощью пакета javax.microedition.media, в котором было три класса: Player (собственно, сам звук или музыка), PlayerListener (прослушиватель событий от плеера) и Control для управления различными параметрами воспроизведения (громкость, тональность и, вероятно, прочие расширения от производителей типа эквалайзера).
Конечно-же набор поддерживаемых форматов был невелик, но почти все устройства хотя-бы поддерживали wav (для коротких эффектов) и midi (для музыки), на ранних телефонах ни о каком mp3 и речи не шло (именно в Java-приложениях). При этом на некоторых телефонах, насколько мне известно, не было возможности воспроизводить одновременно звуки и музыку из-за отсутствия программного или аппаратного микшера. Интерфейс для воспроизведения звуков был один: мы создаём Player с помощью метода createPlayer, которому передаём адрес нужного ресурса и проигрываем его. Это мог быть как и трек на удаленном сервере (стриминг поддерживался не везде), так и в ресурсах программы:
InputStream is = getClass().getResourceAsStream("/music.wav");
Player player = Manager.createPlayer(is, "audio/x-wav");player.prefetch();
player.start();
Так почему-же в большинстве игр на телефонах тех лет были midi-мелодии вместо wav? Всё дело в размере и ресурсах: во первых, midi-мелодия на пару минут может весит пару десятков килобайт. Помните «бумер.mid», «europa.mid» и другие известные тогда файлы? Эти треки весили совсем немного благодаря тому, что в отличии от оцифрованных сэмплов (т.е аналоговых данных с микрофона), вес которых зависит от разрешения, наличие стерео и частоты дискретизации, midi оперировали лишь наборами инструментов: что где и когда нужно проиграть. Во вторых, в Java-телефонах был ограниченный объем памяти, а heap мог быть менее 1 мегабайта, поэтому загрузка даже небольшого wav-файла могло быть крайне проблематичным на таком устройстве. Поэтому выкручивались как могли!
Но в целом, аудио-возможности были хорошими. Java-игры славились весьма неплохим звуковым сопровождением для уровня телефонов, явно не хуже GBA.
❯ Мультиплеер! Давай про мультиплеер!
Вероятно многие читатели помнят, что локальный мультиплеер в Java-играх был зачастую Must-have: возможность игры с друзьями по «локалке» собирала все лавочки и подоконники в школах на переменах в жёстких баталиях на бипланах, или, например, в матчах CS для Java!
И для реализации мультиплеера у Java было довольно немало возможностей: в первую очередь, это наличие полноценных TCP-сокетов и Http-подключений с помощью класса Connection. Да, были некоторые ограничения (например на Nokia нельзя было установить TCP-соединение на порт 80 в обход встроенного клиента Http), но тем не менее даже через GPRS можно было создать с кем-то матч и попробовать поиграть, а чуть позже, к 2009 году, в РФ уже появился +- стабильный 3G и можно было поиграть в игры с достаточно быстрым и стабильным интернетом! Но интернет был дорогой, да и смысл ради сессионного матча подключаться к интернету, когда есть Bluetooth?
Появление Bluetooth в телефонах значительно расширяло возможности телефонов в обмене информации на короткой дистанции. Конечно и до этого уже был ИК-порт, который позволял передавать файлы на относительно низкой скорости, но у него была не самая большая стабильность, да и далеко не все можно было успеть перекинуть за время школьной переменной (и не все давали свой телефон «на урок»). Появление OBEX и возможности передачи файлов друг-другу через беспроводной канал дало возможность скидывать музыку и игры прямо на уроке, что было очень круто и позволило некоторым школьникам с флэшкой или телефоном с большим объемом встроенной памяти даже торговать контентом и скидывать, например, эротику за пирожок или школьную пиццу (я застал когда она уже стоила около 10 рублей — весьма немало!). Особо красноречивые ребята умудрялись уболтать друзей себе скидывать весь контент, что был у них на телефонах и становились центром внимания с новым крутым треком — я и сам в некоторой степени таким был (у меня была флэшка на 2 гигабайта!).
Но помимо возможности обмена файлами, Bluetooth также поддерживал некоторые профили: например, подключение к наушникам или протокол L2CAP/RFCOMM для установки соединения клиент-сервер между устройствами, которое и использовалось в Java-играх. Именно оно позволяло сделать один телефон сервером (хостом), а другому — клиентом, который подключается к серверу и они инициируют сессию игры!
❯ Проблемы мультиплатформенности
На бумаге все было хорошо: Java-машина была стандартизированной, поддерживаемые профили тоже и по идее игры и программы должны без проблем запускаться на большинстве Java-телефонов. Но как-бы не так: проблемы с кроссплатформенностью имели место быть. Начиная от упомянутых выше Vendor-specific API и версиями MIDP, заканчивая… как это ни странно, разрешениями экрана.
Да, сейчас игры не зависят от разрешения дисплея благодаря возможности скейлинга картинок до любого размера. Таким образом достаточно заранее нарисовать спрайты для, например, FHD разрешения и просто скейлить их по размеру дисплея в меньшую или большую сторону. Никто не мешает и отдалять камеру в зависимости от разрешения дисплея, впрочем, это считается не очень хорошей практикой (и зависит от игры).
Во времена Java-телефонов, зависимость от разрешения дисплея была критичной и поэтому игры для «не того» разрешения либо выходили за экран, либо наоборот — выглядели слишком маленькими и игрались в небольшом окошке. Многие вероятно вспомнят как устанавливая игру для малого разрешения дисплея, можно было заметить как шлейфом уезжают спрайты за виртуальный экран и остаются на белом фоне…
Небольшие проблемы были и с обработкой ввода. И если резистивные тачскрины поддерживались еще в MIDP 2.0 с помощью обработки определенных событий, то с мультитачем (во времена Asha и поздних телефонов Samsung) было уже сложнее. Другой вопрос что даже коды кнопок почему-то не унифицировали, из-за чего возникало деление на Samsung, Sony Ericsson и Nokia: разработчики J2ME предполагали что смартфоны будут в разных форм-факторах и предоставили лишь механизм для унификации «игровых» кнопок. Таким образом, некоторые игры, собранные под телефоны конкретного производителя могли не реагировать на нажатие кнопок клавиатуры из-за отличающихся кодов клавиш.
❯ Заключение
Друзья! Вы, вероятно, думаете что если телефоны с поддержкой J2ME больше не производятся, значит и коммьюнити уже «всё»? Как-бы не так: после моих статей мне продолжают писать читатели и спрашивать детали реализации тех или иных техник или игровых механик! Да, энтузиастов мало, но они есть, как и у ретро-компьютеров: например, спектрума, или консолей типа NES… А значит наше дело будет жить и Java-телефоны с их играми останутся в наших сердцах, а Java-телефоны останутся на скрижалях истории! Берегите своих кнопочных красавцев и восстанавливайте по возможности, благо пока-что даже корпуса на популярные модели кнопочных телефонов найти относительно легко.
Надеюсь, сегодняшний материал вам был интересен, писал его специально так, чтобы было понятно даже тем читателям, которые не пишут код или знакомы с программированием поверхностно. Подписывайтесь на мой Telegram-канал, куда я публикую различные мысли и советы по ремонту и программированию под гаджеты прошлых лет, подсъемы с новых видосов и всегда актуальные ссылки на новые статьи!
Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю!
Японский видеомагнитофон! Делаем ретро-фото в стиле VHS на смартфон
Автор текста: vladkorotnev
И вот уже после заголовка рука сама тянется к минусу, в ожидании статьи с рекламой очередного приложения «VHS ретро звездец стильный камера инстаграм 2022 голливуд эффекты» от какого-то сомнительного разработчика :-)
Увы, я и сам был бы рад, если бы всё так было просто. Однако для меня, как и большинства людей, заставших видеокассеты вживую, снимки, сделанные через такие приложения, смотрятся ненатурально и некрасиво — то бишь, как говно.
Поэтому в этот раз мы пойдём более закрученным путём.
❯ Источник изображения
От хорошего товарища, с которым мы в прошлой статье хабарили чипы, перепала пара интересных трансляционных камер из восьмидесятых. Характерное их отличие от более современных «твердотельных» аналогов в том, что для захвата кадра используется электронно-лучевая трубка!
Victor GX-S700
Поциэнт в процессе чистки от налипшего за 20 лет всего что можно
Первый экземпляр был в плюс-минус неплохом состоянии, и заработал сразу же после подачи питания с лабораторника. Периодически пропадало изображение, но это решилось пробрызгиванием «контаклином» всех переключателей на боковой панели.
Внутри у неё используется цветная трубка «Сатикон». Из-за этого камера весьма прожорлива по свету.
Также имеется знакогенератор, позволяющий выставлять дату аж до 99 числа 99 месяца 99 года, и набирать титры двумя размерами шрифтов.
Набор текста на знакогенераторе через видоискатель камеры
Помимо BNC для видеовыхода и входа синхронизации, камера использует проприетарный разъём по типу советских ОНЦ для соединения с видеомагнитофоном.
Да-да, в те годы магнитофон ещё не помещался в камеру, и поэтому его нужно было носить с собой отдельно! Страшно представить, с какой скоростью жрало батарейки такое чудесное сочетание. Видеомагнитофон у меня есть тоже, но из-за отсутствия кабеля между ним и камерой он малость бесполезен.
К счастью, разработчики магнитофона подумали если не о вашей спине, то хотя бы о вашем кошельке. Ну скажите, вот зачем вам покупать два видеомагнитофона, если в то время, когда вы на улице снимаете кино на второй, смотреть первый в доме всё равно некому?
Поэтому вы просто нажимаете на кнопку на своём «домашнем» видаке, и обычный видак превращается…
В два раздельных блока — ТВ-тюнер и зарядку, которые остаются в стойке, и, собственно, сам видеомагнитофон, к которому вы цепляете ремень, аккумулятор, и уносите с собой.
Питание имеет значение
Однако, в 2024 году питать видеокамеру от никелевых или свинцовых аккумуляторов уже как-то не комильфо — заряжать долго, ресурс вырабатывается быстро, да и ноги спасибо не скажут.
В своё время, снимая на обычную VHS-камеру, я какими только извращениями не занимался:
Не взорвался — значит, день удался!
К счастью, с тех пор на нашу голову был ниспослан такой стандарт, как USB Power Delivery, для которого нынче выпускается великое множество источников питания и аккумуляторов.
Поэтому заказываем с амазона сомнительную китайскую платку:
Выставляем её на 12 вольт и… сюрприз-сюрприз — то, что устройство запрашивает то или иное напряжение, вовсе не означает, что источник должен его предоставить. 12 вольт при этом не является напряжением, требуемым стандартом к реализации. Поэтому настольный китайский зарядник спокойно его выдаёт, а вот купленный под это дело поварбанк — нет, несмотря на наличие 12 вольт на маркировке.
К счастью, согласовывается ближайшее низкое напряжение — в данном случае 9 вольт, которых камере оказывается достаточно для полноценной работы.
Попутно выясняется второй подводный камень — для работы АЦП нужно так же и 5 вольт через miniUSB, а купленный поварбанк при подключении двух и более устройств, сваливается назад к 5 вольтам на всех портах, чего камере уже недостаточно.
Импульсного преобразователя под руками не оказывается, поэтому припаиваем КРЕНку и подсовываем под неё железяку потолще для рассеивания примерно ватта мощности :-)
Также к выходным контактам припаиваем два кусочка стали из мусорки, и размещаем всё это барахло внутри задней заглушки камеры так, чтобы оно контачило с контактами аккумулятора.
КРЕНка в прямом смысле присрана, так как через неделю очередная поездка в Акихабару, где уже можно будет купить импульсный преобразователь
Защёлкиваем этот тихий ужас на камеру, подключаем поварбанк — ура, камера запускается и показывает картинку. Искажения цвета при этом не настолько фатальные, чтобы их не вытягивал встроенный баланс белого — по крайней мере, в сравнении со стационарным источником питания :-)
«Мама, я хочу киношный риг!» — «Нет сынок, у нас уже есть киношный риг дома»
Камера — это, конечно, хорошо, но было бы неплохо картинку с неё и на что-нибудь записать. К счастью, на моём телефоне уже есть штатное приложение «Видеовход», которое может выводить и записывать картинку с любого устройства, поддерживающего USB Video Class — т.е. определяющегося в Windows как вебкамера, например.
И таковое устройство у меня нашлось — карманная карта видеозахвата, купленная в своё время для того, чтобы стримить из аркад. Подключаем её к телефону, в неё втыкаем адаптер AV2HDMI, а в тот — видеокамеру. На удивление, «наушниковый» выход камеры оказался вполне себе линейным, поэтому никаких аттеньюаторов паять не пришлось.
Обильно сдабриваем всё это липучкой-самоклейкой, и получаем новейший риг тысячелетия, на который хоть следующий «Оскар» снимать можно:
Скукоживаем картинку обратно
Остаётся последняя беда — встроенное приложение умеет писать только в 1080p, в соотношении сторон 16:9. Конвертер тоже применён самый дешёвый, и не умеет вписывать входное изображение в кадр правильно. Из-за этого картинка с камеры выглядит растянутой по ширине.
К сожалению, способа скорректировать это в самом приложении я не нашёл, а до декомпиляции его ещё руки не дошли. Однако, можно исправить это с помощью FFMPEG, который так же легко устанавливается на телефон. Параметры надо будет передать следующие:
-aspect 1440:1080 -c:v copy -c:a copy
Это лишь прописывает соотношение сторон в метаданные файла, но не перекодирует сами кадры, поэтому конвертация происходит моментально и без потерь качества.
Однако, не все приложения умеют обрабатывать эти метаданные корректно — например, твиттер всё равно показывает картинку растянутой. Напротив, ВК через Kate Mobile, а также Telegram X, загружают видео корректно. Также как и Google Photos, вследствие чего обрезанные/обработанные видео, а также сохранённые стоп-кадры имеют правильное соотношение сторон.
Смотрим на будущее из прошлого
После этого можно попробовать взять камеру на прогулку и поснимать на улице.
Из-за какого-то дефекта звук иногда трещит, но в остальном картинка получается примерно такой, как и ожидаешь от видеокамеры из конца восьмидесятых.
Больше кадров в таком духе можно посмотреть в Телеграме, который я специально под это дело завёл: «Японский магнитофон!»
Чем больше — тем лучше
Также мне перепала ещё и профессиональная трансляционная камера — Victor KY-1900.
В отличие от предыдущей, в ней используется аж три видикона — по одному на каждый цвет!
Вот они слева направо
Но увы — при первом включении оказалось, что синий канал не работает. Перетыкивания коннекторов привели к выводу, что проблема в плате обработки сигнала. То есть, где-то вот здесь:
Выяснилось, что испортились танталовые конденсаторы в позициях C37 и C40 — такие конденсаторы имеют свойство при поломке образовывать не обрыв в цепи, а короткое замыкание, поэтому задающая яркость синего цепь была всегда притянута к земле. Найти их было легко, так как они очень сильно грелись. Шутка ли, через такую фитюльку рассеивать под 5 ватт!
Однако после этого синий цвет работал только при минимально установленном уровне чёрного, любая же установка выше этого сразу заполняла синим весь экран. Несколько недель перебора компонентов и с десяток ударов анодным в палец спустя оказалось, что всё-таки отгнила одна нога у подстроечника, а я считал, что уже проверил его, и всё это время ходил вокруг да около. Даже удлинитель спаял, чтобы плату во время работы камеры обмерять где только можно.
До кучи маркировка на плате подкидывала приколов на некоторых компонентах. Кручу-верчу, запутать хочу!
Плюс у С21 справа?
Или таки слева?
Также у объектива при открытой диафрагме внутри торчала какая-то полоска. Она же создавала излишнее трение и мешала приводу автоэкспозиции нормально крутить колесо диафрагмы. Ну я и подумал, можно же аккуратненько разобрать объектив, загнуть её назад и собрать обратно.
Конечно же, при разборке я диафрагму уронил, лепестки разлетелись по полу, и следующие четыре часа я провёл, восстанавливая её по наитию :-) Зато теперь-то всё ходит идеально плавно и ничего ниоткуда не торчит!
Последней преградой осталось питание — этой камере уже 9 вольт для работы недостаточно. Однако, через Quick Charge поварбанк таки согласился выдавать 12 вольт.
Так как триггер ждать не хотелось, то из загашников была достата ардуина и россыпь резисторов. Прошиваем туда QC3Control, подключаем по схеме. Питание включаем напрямую туда же — ведь в даташите на ардуину сказано, что она работает и от 12В, да и перемычка обхода понижающего преобразователя у меня не запаяна, так что всё должно быть хорошо.
Втыкаем в поварбанк. Ардуина загружается, согласует напряжение и тут же взрывается. Перемычка запаивается, из загашников достаётся ещё одна кренка, а на полях мозгов делается заметка, что официальные даташиты к деталям с алиэкспресса лучше не применять.
В итоге «на соплях» проверить камеру удалось, однако для того, чтобы вытащить её на улицу, нужно всё ещё решить проблему с питанием АЦП. Здесь уже кренкой не обойтись — суммарное потребление не пролезает по току в лимиты поварбанка, да и так уже с полного заряда всего лишь 2 часа съёмки набирается. Поэтому фотографии с этой камеры будут уже после возвращения из очередной поездки.
Внутри дома снимает она вот так:
Видны характерные для камер на видиконах «хвосты» от светлых предметов, которые можно заметить в старых телепередачах, например, на бокалах или духовых музыкальных инструментах.
Картинка весьма тёмная, ведь в камере свет расщепляется на три луча, потом фильтруется по цветам, и оттуда попадает в отдельные видиконы, и без того не то чтобы очень чувствительные. Это тестовое видео было снято при максимальной, выжигающей глаза настройке люстры, да и автоматы на видео имеют весьма яркие в реальности светодиоды.
Однако в обычном дневном свете приходится диафрагму закрывать почти полностью даже в пасмурную погоду — удивительно, насколько велика разница, когда при восприятии человеческим глазом её как будто и нет.
Проверить это получится уже потом, когда я соберу по-нормальному кабель питания, и вытащу эту камеру на прогулку — если не отвалится спина и плечи, ведь она тяжелее предыдущей раза в два. Но об этом вы уже узнаете среди тонн фоток еды, Мику, и всякого древнего железного барахла, в моём Телеграм-канале :-)
Больше фото в источнике материала на Хабре. :)
Написано специально для Timeweb Cloud и читателей Пикабу. Подписывайтесь на наш блог, чтобы не пропустить новые интересные статьи.
Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать наши проекты.
Красивый?) Nokia 6233
Гейминг за 300: как я купил и оживил дешевую игровую консоль на Android. Можно ли поиграть, сэкономив на шаурме?
Несмотря на незаурядное название, наверняка многие олдовые читатели моего блога будут рады видеть статью в «старом» формате с оживлением и попыткой использования чего-то очень дешевого, грязного и нерабочего. В процессе подготовки подробного материала о том, как работали 2D игры на телефонах из прошлого, я не терял времени и искал различные интересные девайсы на онлайн-барахолках «за копейки». Так уж получилось, что на моей карте осталось 60 рублей, ещё 250 рублей задонатил читатель и я увидел её: Android-игровую консоль «на запчасти», которую мне удалось забрать всего за 300 рублей. Сегодня мы с вами: поговорим, есть ли смысл брать дешевые консоли на Android, во всех подробностях отремонтируем и отреставрируем нерабочий, грязный девайс «из подвала» и проведем бенчмарки эмуляторов, дабы понять — реально ли получить игровую консоль по цене шаурмы. Интересно? Тогда жду вас под катом!
❯ Предисловие
Друзья! Если вы хотите не только читать, но и смотреть, то для этой статьи доступна видео-версия. А те, кто любят читать текст - листают вниз!
Пожалуй, тематика портативного гейминга была актуальна всегда. Ещё в нулевых, многие мои читатели наверняка уже играли на своей личной игровой консоли: будь это тетрис, полноценная PSP, а то и редкая в СНГ Nintendo DS! С резким падением цены на дисплеи и относительно мощные чипсеты, китайские производители начали делать огромное количество своих собственных консолей. Но понятное дело, что в одиночку запускать собственную платформу без игровой библиотеки смысла нет и поэтому китайские вендоры решили поступить проще всего: они портировали эмуляторы NES, Sega Mega Drive и иных популярных консолей из прошлого и просто устанавливали пиратские ромы в подобные устройства. Одной из самых популярных ретро-консолей, которая в своё время произвело фурор на рынке портативного гейминга была известная в узких кругах Dingoo A320, которая стоила копейки для того функционала, который она предлагала (менее 100$ на релизе в 2009 году).
Та самая Dingoo A320 в форме кирпичика
Казалось бы, чем же могла быть интересна самая обычная, «стандартная» дешевая игровая приставка с кучей ретро-игр? И ответ прост: тем, что ОС устройства поддерживала запуск сторонних приложений, а производитель умудрился поделится (или слить, обычно такие вещи под NDA разработчика чипсета) исходный код прошивки устройства и SDK для разработки нативных программ для этой консоли. Стоит ли говорить о том, что энтузиасты сразу принялись портировать популярнейшие игры с открытыми исходниками и множество эмуляторов? Но настоящий успех к этой консоли пришёл лишь спустя год, когда энтузиасты портировали… полноценный Linux на это устройство и библиотеку SDL1.2, дав возможность запускать вообще любой софт, собранный под MIPS для Linux. Конечно-же, на волне популярности со временем у консоли появились и свои клоны, не имеющие отношения к Dingoo A320.
Спустя время, даже корейская Ritmix решилась выпустить RZX-50 на том-же чипсете, что и Dingoo A320 и сразу с Linux на борту, а хабровчанин, нынешний администратор форума «MotoFAN», под ником exl даже работал над разработкой и выпуском этого устройства в РФ! Благодаря дешевизне, такие игровые устройства раскупали как горячие пирожки себе или детям, создавая отдельный рынок дешевых ретро-консолей. Вплоть до того, что в 2012 году появилась первая игровая консоль на перспективной ОС Android — JXD S601 и всего чуть больше, чем за 100$!
В подарке читателя затесался RZX-50!
Идея китайцев была простой: они взяли дешевое, но относительно неплохое железо для планшетов и просто приделали ему аппаратные кнопки, проще уже не придумаешь! Многие Android-игры уже тогда поддерживали управление физическими кнопками (поскольку в те годы ещё выходили QWERTY-смартфоны, например HTC Desire Z), не говоря уже об эмуляторах, из-за чего, по мнению производителей, такие девайсы должны были сметать с витрин учитывая копеечную цену устройств. И в целом, так и происходило: со временем, некоторые бренды в РФ начали называть такие консоли своими именами и продавать в салонах сотовой связи за цену несколько выше, чем в Китае…
Я уже восстанавливал похожий девайс практически ровно год назад!
Помимо этого, JXD даже заморочились и реализовали свой собственный «магазин»… пиратских ромов! Да, в отдельном приложении можно было скачать нелегальные образы игр и сразу же закинуть их в папку эмулятора… Таким образом, получался «топ за свои деньги» тех лет. Покупаешь одновременно и игровую консоль, и планшет, из-за чего для рядового пользователя покупка подобного девайса была весьма неплохим решением: и дитю поиграть, и самому юность в играх для ретро-консолей вспомнить.
Продержались подобные устройства на рынке примерно до 2015 года. К сожалению, в таких консолях было слишком много недостатков и их нужно было вручную доводить до юзабельного состояния, как это часто бывает с дешевыми устройствами: например, многие вендоры почему-то реализовывали аналоговый стик как цифровой (!) в системе, прошивка очень часто была крайне лагучей и страдала от отсутствия оптимизации, а силиконовая токопроводящая резинка для кнопок быстро изнашивалась и кнопки имели уже далеко не такой плавный и мягкий ход как в новом устройстве. К слову, похоже рынок игровых консолей на Android понемногу возвращается: пару лет назад появилась консоль от Anbernic, в которой пофиксили эти недостатки и бонусом снабдили устройство нормальным OLED-дисплеем и чипсетом Unisoc, но цена в 15 тысяч рублей за Android-смартфон с кнопками наверняка вас отпугнет (это реально очень дорого).
Отпугнула и меня. В моей юности у меня тоже была подобная консоль на Android и я, оказавшись в один прекрасный день с 60 рублей на карте, начал листать онлайн-барахолки в поиске чего-нибудь интересного в пределах своего города. И нашёл: некий мужик продавал за копейки устройства на запчасти, среди которых оказалась и моя консоль: JXD S601.
Я предложил 300 рублей, продавец согласился, читатель задонатил ещё 250 рублей на контент и я выкупил консоль в абсолютно неизвестном состоянии, которая оказалась ещё грязнее, чем было на фото. Тем и интереснее!
❯ Реставрируем
Как я уже говорил выше, консоль я купил в совершенно непонятном состоянии: грязная, слишком легкая, резистивный тачскрин был в пузырях, а кнопка триггера вообще не работала. Кроме того, внутри консоли что-то болталось, но и мы не из робкого десятка и готовы отреставрировать старенькую консоль! Разбирается она очень просто: четыре винтика с обратной стороны консоли и расщелкиваем заднюю крышку пластиковой картой. Правда в моем случае, все винты были закисшими и зализанными, но главное что клипсы задней крышки не пострадали.
Разобрав консоль, я увидел вот такую картину (скриншот из видео): кто-то менял аккумулятор, просто припаяв новую банку к старой BMS без изоляции прямо поверх конденсаторов на линиях питания процессора. Само собой, это не дело, благо у меня был аккумулятор такого форм-фактора. Я выпаял остатки BMS и уже подготовил новый АКБ для подкидывания.
Что было особенно неприятно — прошлый мастер потерял динамик и оторвал полностью камеру с шлейфом:
Упомянутая мной кнопка продолжала болтаться по корпусу и её умудрились выломать даже при том, что она сидела с завода на герметике. Видимо уж очень активно её нажимали. Ну, это поправить несложно: убираем припой с посадочной площадки кнопки, вставляем её пинами вниз и припаиваем. Теперь кнопка держится надежно!
Затем я очистил спиртом контакты кнопок и пробрызгал WD'шкой стик и пошёл набирать воду в тазик, дабы отмыть корпус от грязи. После мытья корпуса, я просушил его феном.
Перед финальной сборкой консоли, я решил проверить плату на работоспособность, подключив дисплей и подпаяв питание и…
Да, даже дисплей оказался разбитым :( Но и это не беда, ведь в таких консолях используются экранчики от… навигаторов! Подкинув новый дисплей и убедившись что плата рабочая, я принялся собирать всё обратно…
Но не тут-то было! Консоль оказалась на пароле и очень сильно тормозила, каждое действие занимало ~5 секунд. Ну, тут уже и причина разбитого дисплея очевидна: видимо консолью пользовался ребенок, который психанул от лагов и разбил замечательный девайс. Благо фиксится легко: качаем прошивку, распаковываем в корень MicroSD-флэшки, включаем консоль нажатием «Питание + Меню» и ждём окончания процесса прошивки.
Наконец-то консоль снова в рабочем состоянии! Ремонт обошелся мне… ну, можно сказать 100 рублей за навигатор. Сейчас они вообще никому не нужны и стоят копейки… На ремонт я потратил где-то час своего времени — не так уж и много, зато фана от восстановления достаточно :)
Давайте же посмотрим, на что способна консоль по прямому назначению — в играх!
❯ Тесты
Как я уже говорил выше, фактически подобные консоли — это планшеты с аппаратными кнопками. Само собой у них есть и Wi-Fi, что позволяет их использовать как бюджетный планшет из начала 2010-х годов… например, накатить клиент ВК и YouTube, заюзать встроенный клиент-почты или использовать консоль как плеер.
Запускаем CPU-Z и видим, что характеристики у нашего девайса следующие:
Чипсет: AMLogic AML8726-M3 с одним ядром Cortex-A9 на частоте 600МГц. В качестве GPU используется Mali-400MP.
ОЗУ: 512Мб DDR3.
Flash-память: NAND-модуль на 4Гб.
Дисплей: 4.3", 480x232, TN. Резистивный тачскрин, само собой на одно касание.
Система: Android 2.3 с возможностью апгрейда до 4.0.
Видеовыходы: аналоговый TV-Out.
Для подобного устройства весьма неплохо! Уж, полагаю, подобных характеристик должно хватать и для достойной эмуляции PlayStation 1. Давайте проверим!
Начинаем с самого простого, конечно же NES: я использовал эмулятор emu.NES, настройки стандартные. Эмулятор сразу же подхватил аппаратные кнопки, всё работает шустро и без проблем:
Переходим к Sega Mega Drive, в этом случае я использовал эмулятор emu.MD. Ром «соника» запускается и работает шустро, без каких-то особых проблем или фризов. Но возможно, для кого-то окажется слишком большим инпут-лаг — тут всё сильно индивидуально.
Дальше — больше, переходим к эмуляции PS1. В качестве игры я выбрал Driver, эмулятор epsxe: игра идёт довольно неплохо, в почти стабильные 25-30 кадров. Не все современные консоли с алика могут позволить себе подобный уровень производительность в 3D играх на PS1!
И не забываем, конечно-же, о нативных играх! Здесь тоже всё весьма шустренько: можно погонять в Android-классику тех лет типа Temple Run и иную мобильную годноту тех лет. Ностальгия!
❯ Заключение
Вот такую игровую консоль я купил за 300 рублей. Да, многие читатели скажут, мол, твоё время и затраты на поиск подходящего дисплея это ещё плюс пару тысяч рублей… но лично мне в кайф было пополнить свою коллекцию консолей ещё одним рабочим устройством. Надеюсь и вам было интересно!
Если захотите поискать такие устройства на барахолках по дешману, то найти их можно по названиям брендов (func, exeq, spider) и по описанию (android консоль, android приставки и т. п.). А если вам интересна тематика ремонта и моддинга различных дешевых девайсов, в том числе и телефонов, программирования, DIY — то подписывайтесь на мой Telegram-канал, в котором есть ламповый чат!
Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю!
Ответ на пост «Оживляем неизвестный дисплей от японского поезда/автобуса»
Не знал, что они статьи и на пикабу выкладывают. Но самое главное отвалилось в посте — видео с итоговым результатом!
Вот такие часики-метеостанцию я запилил за пару недель из плазменного дисплея от старого японского автобуса.
Шрифты плюс-минус обычные, иконки погоды вышли как по мне шикарные, но самым тёплоламповым получился эффект дождя, который отрисовывается в дождливые (по прогнозу погоды) дни.
Ну и музыка тоже своя, да.
Кто нашёл отсылочки в видео (помимо самой очевидной на "Матрицу"), тому приз — два прекрасных нихуя %)
Безысходники прошивки положил на Гитхабе — https://github.com/vladkorotnev/plasma-clock/tree/develop/sr...
Отдельное спасибо @AlexGyver за его GyverPortal, иначе я бы на проект забил ещё на стадии размышлений о том, что придётся же админку писать с нуля.
Оживляем неизвестный дисплей от японского поезда/автобуса
Автор текста: vladkorotnev
Как-то раз, очередным томным субботним вечером, я в очередной раз листал от нефиг делать Yahoo! Auctions — одну из крупнейших японских сетевых барахолок. Внезапно, среди рекомендуемых лотов появился вот такой внушительных размеров электровакуумный дисплей:
Однако, рулить дисплеем, как правило, та ещё задача. «Особенно если динамическая индикация, да ну его, влом!» — подумал было я. Но у того же продавца обнаружилась и, судя по всему, управляющая плата:
На фотографии виднеется 8085 процессор, 8251 UART и ПЗУшка — казалось бы, дизассемблируй себе, разбирай протокол, да просто с ардуины выводи что угодно. Да ещё и за одну йену, это прям даром! После этого я решил всё же попытать удачу и выхватить этот дисплей. Тем более, что давно уже хотелось какие-нибудь красивые часики в комнату...
Конечно же, какая-то зараза попыталась из-под меня эти лоты перехватить, но в итоге за примерно десять тысяч йен весь комплект достался мне.
❯ Всё уже поломано до нас
Через пару-тройку дней приходит посылка. Продавец, конечно, пожалел упаковки, и поэтому плата и дисплей просто болтались в коробке — но, к счастью, всё выглядело целым.
Да, я в курсе, что полярность на коннекторе питания подписана задом наперёд %)
Первым же делом снимаю ПЗУ, кидаю в MSX, чтобы вычитать на комп, но увы — кроме нулей ничего не вычитывается, да ещё и греется оно очень подозрительно. При подаче питания сама плата тоже ничего не делает.
На шине процессора никакой активности нет, хотя тактовый сигнал в норме — то бишь, если бы даже ПЗУ и было целым, читать из него процессор не пытается. Плата ещё и закатана в какой-то лак, который не плавится и не растворяется, поэтому чинить такое будет то ещё «удовольствие». Даже масочные ПЗУ со шрифтами нормально не вытащить…
Гуглёж по маркировке (Morio Denki 6M06056) тоже ничего, кроме сайта производителя, не выявил. Судя по всему, они занимаются дисплеями для транспорта — так что, скорее всего, этот стоял в каком-то автобусе или поезде.
Вероятнее всего, это был автобус — ведь в поездах между станциями, как правило, на экране идёт бегущая строка. В старых автобусах же отображается лишь название следующей остановки. Выгоревший текст — 「次は、(неразборчиво)」(«Следующая: (нрзб.)») подтверждает эту догадку.
❯ Плата драйвера панели
Значит, придётся рулить панелью напрямую — благо, какая-то плата, адаптирующая его к какой-то шине, к дисплею уже прилагается.
А ведь в наше время вся эта требуха поместится в дешёвую ПЛИСку размером с ноготь…
Судя по наличию микросхемы ОЗУ (MN2114), плата представляет себе какой-то простенький фреймбуфер. Отлично, значит с динамической индикацией на 100+ катодов уже разобрались до меня :-)
Справа снизу находится трапециевидный «молекс», знакомый нам по старым жёстким дискам. Линия 5 вольт и общий провод совпадают по распиновке — отлично, значит запитать попробуем от обычного компьютерного источника питания.
Пара минут с тестером и карандашом — и вот уже отчётливо видно, где на разъёме шины данных входы, а где выходы.
Верхний ряд группами по 4 пина соединён со входом коммутатора 74LS257 — скорее всего, это вход данных шириной в 1 байт. Нижний ряд же идёт на инвертеры, выполняющие роль буферов — так хотя бы можно понять, что в нём есть 5 входных сигналов, и 2 выходных.
Быстренько раскидываем на огрызке старой макетки штуковину, чтобы накручивать произвольные значения на восьмибитном входе данных и перемычками дёргать остальные, а на светодиодах смотреть выходные сигналы.
Крутилки шестнадцатеричные дома были в избытке, а вот джамперы пришлось импровизировать паяльником на ходу
Ничтоже сумняшеся, я подключаю старый блок питания от компьютера к молексу на плате… И конечно же дисплей всё так же мёртв. Никакой реакции ни на входные данные, ни на закорачивание шины данных у чипа памяти на землю.
❯ Конструкция дисплея
Почему-то всё это время мне думалось, что это — ВЛИ, которому нужно около 20-30 вольт для свечения. Однако при прозвонке самой лампы тестером никакие пины между собой соединены не были — в случае ВЛИ так быть не может, ведь ему нужен накал катода. Ну, разве что, если нить накала перегорела…
Впрочем, пристальный взгляд на дисплей под лупой показал, что ни накала, ни сеток — типичных для люминисцентных индикаторов компонентов — там и вовсе нет:
Значит, скорее всего, это газоразрядный индикатор! По горизонтали у него расположены платы с кучей группированных транзисторов. По маркировке «L-S» никакие транзисторы в справочниках подходящих лет, увы, не находятся.
По бокам у дисплея — практически одинаковые платы с диодами, логическим инвертером (7414) и неизвестным модулем Mitsubishi MA7446-01.
Собираем мозги в кучу и пытаемся понять, что делать дальше:
Поперёк «12-вольтовой» линии питания стоит конденсатор на 250 вольт — значит, как минимум, там должно быть высокое постоянное напряжение. Очевидно, положительное, если этот конденсатор проектировщики не вставили туда в роли петарды.
На плате мультиплексора между питанием и выходом на дисплей есть цепь с транзистором 2SC1473 — он тоже рассчитан на 250 вольт.
Значит, скорее всего, на молексе вместо 12 вольт ожидается, как минимум, под сотню с лишним, а значит и индикатору для поджига нужно напряжение где-то такого порядка.
В итоге из загашников извлекается маленький инвертер для электролюминисцентных проводов, к нему приделывается диодный мост, и вуаля — у нас есть кривой маломощный источник 160 вольт постоянки.
Припаиваем к одному из горизонтально стоящих пинов минусовой выход через резистор на пару килоом, а плюсовым аккуратненько одной рукой ведём по вертикально-стоящим…
Ура, значит сам дисплей, как минимум, жив! Можно заказывать повышающий модуль на амазоне, а пока он едет — заняться восстановлением платы мультиплексирования.
Конечно, можно было бы сделать целиком свою, и управлять аж субпикселями, как на видео. Но динамическая индикация на сотню с гаком катодов — это то ещё развлечение, поэтому мне проще было оставить всё как есть.
❯ Диагностика платы мультиплексора
Под такое дело для проекта был куплен аж целый китайский лабораторник на амазоне — и подключение платы к нему показало, что жрёт она как не в себя! Почти что целый ампер, на конструкцию из 38 корпусов. Для логики серии 74LS это уж слишком много. Получается, в плате управления тоже что-то не так.
Так как компаратора навроде HP 10529A у меня нет, пришлось вооружиться осциллографом и таблицами истинности из даташитов.
На шине данных у ОЗУ хоть и завалены фронты, но в принципе всё смотрится не так и плохо:
А вот на прочих чипах местами встречается откровенная дичь — например, сигналы, у которых логический ноль где-то на 1,8 вольтах, а единица на 3,5.
В двоичной логике бывает True, бывает False, но встречается и «Да нет наверное»:
Местами и вообще какие-то непонятные лесенки, которых явно в цифровой схеме быть не должно. Ниже троичная логика, прямиком из семидесятых:
Видимо, собирали девайс на 74 логике из альтернативной вселенной.
По итогам пары дней такого копательства, вкупе с тыканием термопарой по всей плате даже туда, где солнечный свет не бывал, обнаружились следующие виновники:
107-1 (JK-триггер) — кипятится (60+°C) сразу при включении питания, выход закорочен на вход
107-2 — от выхода на вход 1кОм, в первом триггере выходной сигнал просажен (ну ещё бы), а второй вообще выдаёт не то, что в даташите, а погоду на Марсе. До кучи ещё и греется под 40 градусов.
107-3 — 2кОм со входа на выход, теплее всего остального.
393-1, 393-2 (сдвоенные 4-битные счётчики) — между тактовым входом и Vcc всего лишь 2 кОм, поэтому и сигналы выглядят странно.
До кучи, у сбоивших микросхем пин Gnd явно отличался по внешнему виду — припой был как будто потемневшим, и его там было больше, чем на остальных пинах в том же ряду/столбце.
Возможно, после пробоя там прошёл достаточный ток, чтобы расплавить припой и собрать его в такие горки?
В любом случае, другие чипы с таким же симптомом было тоже решено поменять на всякий случай.
Радиомагазинов в городе уже толком не осталось — поэтому берём вкусняшки, паяльник, и едем к товарищу хабарить полный комплект логики из ведра старых плат.
В четыре руки и два паяльника чипы хабарятся куда быстрее, чем просто в четыре руки
JK-триггеры оказались настолько сложной в применении штукой, что ими, видимо, никто пользоваться и не захотел — поэтому пришлось докупать их отдельно в интересном магазине, по сей день торгующем теми ещё музейными экспонатами.
❯ Повторный запуск
Выпаиваем всех подозрительных и заменяем их на панельки — ну вдруг опять вылетит, не паять же по новой :-)
Фото уже более позднее — заменил ещё и кварц, чтобы увеличить частоту развёртки, дабы экран не полосил на видео
Подаём питание. Один из светодиодов на макетке, раньше постоянно горевший, на сей раз гаснет — это хороший знак. Ставим крутилки в положение 0xFF, от балды трогаем один из джамперов, и…
Две негорящие строки — это от макетки один из проводов шины данных отвалился при проверке :-)
Оно живое!!! И жрёт со всеми включёнными пикселями аж 25 ватт.
Экспериментально подбираем распиновку коннектора:
Способ управления тоже оказался весьма простым и понятным.
После подачи питания нужно дождаться, пока ~READY не уйдёт в лог. 0. Затем выставляем биты данных и дёргаем ~CLOCK. Этот байт попадёт в верхнюю половину самого левого столбца — пиксели, выставленные в «1», загорятся, а в «0», соответственно, погаснут.
Следующий импульс на ~CLOCK запишет байт в нижнюю половину самого левого столбца, потом — верхнюю половину второго столбца, и так далее — сверху вниз, слева направо. После записи последнего байта (нижняя половина самого правого столбца), следующий байт опять попадёт в верхнюю половину самого левого, т.е. запись идёт в цикле.
Если мы хотим начать рисовать с начала, можно дёрнуть ~RETZ — это обнулит счётчик, и рисование опять начнётся с самого левого столбца. Можно сбросить вообще всё и очистить экран при помощи ~RESET.
Притянув BRIGHT к земле можно уменьшить яркость (и потребляемую мощность) дисплея вдвое. Притянув же к земле SHOW, можно отключить отображение на дисплее вообще, при этом рисовать в память платы всё так же возможно.
❯ Проба пера
Так как терпения у меня в организме ещё меньше, чем дофамина, то была распотрошена ещё какая-то плата из мусорки. Оттуда были извлечены TC4050B — буферы, которые отлично подойдут для согласования 3.3-вольтовой ESP32 с 5-вольтовой логикой на дисплее.
Переходник с 1980 года на 2016
На JLCPCB я всё ещё не зарегистрировался...
Схема в этот раз даже не рисовалась, всё соединялось сразу из головы. Пишем простенькую процедуру, двигающую бит в слове туда-сюда, заливаем скетч, и любуемся:
Дописываем ещё простенький рендер шрифтов, обновляем скетч:
Ну а дальше едем в Акихабару закупаться требухой для развития проекта до какого-то полезного состояния :-)
Котлета в комплект радиодеталей не входит!
Опытный читатель уже догадался по содержимому этого хабара из Акихабары, что дисплею уготована типичная радиолюбительская участь — стать будильником-метеостанцией %)
Операционная система же обрела рабочее название Plasma Information System OS — или, если коротко, PIS-OS.
Смотрится итоговый результат, как по мне, восхитительно:
Но о сборке девайса и написании прошивки — уже в следующей части :-)
В реалтайме за обновлениями, среди тонны фоток еды и Мику, вы можете также следить в моём телеграме.
Также, можно посмотреть ход описанного в статье «в реалтайме», прочитав тему на EEVBlog.
Написано специально для Timeweb Cloud и читателей Пикабу. Подписывайтесь на наш блог, чтобы не пропустить новые интересные материалы.
Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать наши проекты.
В среду выйдет новый подробный материал из рубрики "сам себе экосистема"
Где я подробно рассказываю о том, как реализовал клиент современного мессенджера Telegram на Android 1.5+ и выше. Таким образом, Telegram будет работать даже на самом первом Android-смартфоне в мире, T-Mobile G1, причём на стоковой прошивке!