Яндекс.Метрика

UzeBox – Шедевр или баян.

Первый свой UzeBox собрал еще несколько лет назад (в далеком 16-ом), навскидку протестировал и … фактически забросил. Хотя и планировал что он будет не последним и поиграться, в смысле по программировать, его тоже хотелось. Но как всегда руки не доходили.

Выглядел и тогда и сейчас он вот так:

Производство 5шт. печатных плат ревизии F2 (тогда видать самая свежая была) заказывал где-то в китае. Два оригинальных конвертера RGB->NTSC (AD725) купил, контролеры mega644p – тоже, прочие коннекторы и даже подходящее гнездо для карты (а вариантов их ой как много), а вот разъемов для джойстиков SNES найти не мог, как и оптопары, хотя DIN-5 новенький был даже в наличии. Посему было решено первый Юзбокс собрать по принципу минимализма, отказавшись от запайки всего необязательного. В процессе сборки выплыли еще некоторые нюансы. Трехвольтовый стабилизатор mcp1700 имеет распиновку отличную от классического 7803 – решением было изогнуть его ножки хитрым образом, благо место и длина позволяли. Резисторы в ЦАП-цепочке имеют весьма «нестандартные» номиналы, т.е. таких номиналов даже близко нет в кассе резисторов из порядка 50 значений – пришлось рассчитывать и ставить за место одного два резистора впараллель (как максимально конструктивно-изящный вариант), был удивлен что из набора номиналов подобрать пару для нужного значения было очень легко (не с потолка составляется ряд). Не стал запаивать гребенки пинов GPIO и выдеосигналов, а также все что касается midi-входа (не столько потому что непонятно зачем он нужен – не было ни оптопары ни кроватки под нее).

Работал первый Юзбокс? Работал и тогда и сейчас … Подробностей несколько летней давности уже не вспомню. Помню что зашивал в него имеющиеся скомпилированные программы и игры. Помню что шился достаточно большой контроллер (mega644) программатором типа USBasp весьма медленно и была мысль что нужен более шустрый программатор.

Прошли годы.

Несколько раз натыкался на коробку с подборкой деталей для Юзбокса, думал что да – нужно собрать второй, как и планировал. А именно собрать абсолютно полностью! Да, удалось купить разъемы для джойстиков SNES и оптопару, была куплена касса резисторов из более чем 100 номиналов, стабизаторы mcp1700 (остались от «спящей красавицы»), даже гребенки пинов разноцветные ;-) Получилось – красота:

Работает – внезапно даже лучше чем первый! В смысле лучше? Цвета изображения на первом собранном Юзбоксе имеют радужную помеху – в разных приложениях ее интенсивность и заметность разные. Вовсе не было стремления «чинить» первый Юзбокс – но был интерес понять из-за чего такое. Различия только в стабилизаторах (на первом русская КРЕНка 142ЕН5 и 7803; на втором оригинальный ST7805 и mcp1700) и количестве резисторов в ЦАП-цепочках … Не поленился поставил большую емкость по питанию на первый Юзбокс (как и на второй сразу) что хоть ожидаемо результата практически никакого не дало – хотя в целом удивляет жадность создателей Юзбокса до емкости шунтирующих питание конденсаторов. Так вот – а фишка оказалась (вернее выявилась случайно) в том что некорректно были установлены фьюзы (биты конфигурации) в контроллере первого собранного Юзбокса! Причем это была не ошибка! Специально проверил сохраненный годами ранее материал – тогда я не вникая в суть проставил то, что предлагалось. Сейчас же, задумавшись над смыслом устанавливаемых фьюзов в контроллер нового Юзбокса (т.к. разные материалы содержали отличную информацию) – полез в документацию и определился с корректным их значением (и оно отличается от рекомендуемых ранее и сейчас) - lfuse:0xE7 hfuse:0xD2. Именно с такими фьюзами оба Юзбокса работают максимально корректно! (некорректные значения не привожу)

Что и как прошивать, компилировать и т.п.?

Скомпилированную программу (игру) в формате *.hex можно напрямую записать в контроллер любым программатором через интерфейс ISP, при необходимости записать другую. Но есть и более интересный и удобный способ: программатором (единожды) в контроллер записывается загрузчик, далее файлы программ должны быть размещены на SD-карте. Загрузчик, получающий управление каждый раз при старте системы (как вариант) читает содержимое  карты и позволяет выбрать желаемую программу, далее происходит прошивка выбранной программы с карты в память контроллера средствами загрузчика и управление передается ей. Программы на карте должны быть в формате *.uze – это уже не *.hex а бинарник с заголовком (который можно состряпать как вручную, так и автоматически утилитой packrom). После сброса управление может получать как загрузчик, так и последняя программа (опция выбирается я в загрузчике), вернуться в загрузчик из программы можно несколькими способами: нажать SELECT, START, A, B; вместе с RESET нажать любую кнопку джойстика или же просто RESET – если выбран вариант старта загрузчика.

Прошивка программы загрузчиком в память контроллера происходит настолько быстро (пара-тройка секунд) и просто, что авторы Юзбокса предупреждают об ограниченности циклов перезаписи памяти контроллера в 10тыс. раз (по заявлению производителя). На самом деле это очень много – например по 100раз в день в течение 3 месяцев – т.е. серьезного внимания на этот момент обращать едва ли стоит.

Большинство программ для Юзбокса (равно как и его базовые библиотеки) создавались в среде AVR Studio 4, а поэтому и собираются вполне себе удачно в ней. Но т.к. роль компилятора с языка Си в студии выполняет WinAVR, то можно его использовать и без студии (что имхо не так удобно), или использовать вообще другую IDE – например Eclipse. Оправдано ли использование других сред разработки, когда есть Атмеловская студия и не надо ничего фантазировать? – однозначно не скажешь. Хотя учитывая факт того что конструкция (схемотехника) Юзбокса такова, что ноги интерфейса JTAG заняты (что делает его недоступным для использования) – смысл программирования именно в AVR Studio (с целью отладки) теряется (других отладочных интерфейсов у контроллера mega644 нет). Все равно отладка Юзбокса получается только по факту, а тут уже тогда без разницы: где писать, чем собирать и заливать программу … Есть и эмуляторы Юзбокса (все прям по серьезному – как у настоящих игровых консолей), причем даже два (cuzebox, uzem), им можно скармливать оба формата файлов (*.hex, *.uze) – однако отладочных функций (как например в Mesen - эмуляторе NES) – в этих эмуляторах нет.

Исходный код для большинства программ и игр для Юзбокса открытый. Последнюю версию программного ядра платформы с примерами программ и игр можно скачать с репозитория разработчиков. Ссылки и прочая информации по другому ПО для Юзбокса представлена в Вики или на Форуме. И все … вобщем то в сети в других местах об Юзбоксе практически ничего и не найти (за исключением разве что личных страничек создателей и энтузиастов, поддерживающих Юзбокс – известных по форуму).

А зачем вообще нужен Юзбокс? Этот вопрос я задавал себе и перед тем как собирался его конструировать и после того как сделал первый, и сейчас. Конечно вцелом устройство привлекает именно простотой своей конструкции в совокупности с результатом - «почти Денди». Тетрис так вообще не отличить ни графикой ни музыкой, в то время как Денди можно считать вообще двухпроцессорной системой (CPU и PPU). В Юзбоксе же все все крутится в одноядерном 8-разрядном контроллере, хоть и более шустром, а суммарное количество оперативной памяти такое же как и в Денди, например … Собрать и удивиться воочию (а может удивить друзей?) что ардуино-контроллер может выступить чуть ли не эмулятором Денди? Но шедевров под Юзбокс мало: Тетрис, Арканоид, Шахматы, Сапер, Солитер … можно конечно играть в них при очень малом затрате электроэнергии (Денди жрет больше). Но когда просмотришь все что народ накодил под Юзбокс (а «всего» не так уж и много) – то очевидно, что графический процессор Денди куда как более функционален и соответственно на Денди игры имеют значительно более привлекательную графику. Юзбокс получается сравним с самыми первыми Денди-играми (начала 80-х) – когда же в 90-х в дендевые картриджи стали добавлять дополнительно оперативную память, да и память программ и спрайтов маппингом расширялась прилично – Денди явно перешла уже в другую весовую категорию.

Так кому же правильно было бы адресовать сборку и программирование Юзбокса?

Желающим поэкспериментировать с созданием спрайтовых игр? – едвали … Хоть Юзбокс и позволяет программировать для его на Си (в отличие от Денди, например) – ограниченность его ресурсов и аппаратно-программные особенности в целом не делают его более привлекательным, в сравнении с тойже Денди, в плане удобства для гика решившего попробовать себя в этом направлении. Тут скорее можно порекомендовать сеговский Мегадрай (имхо, лучшая консоль со спрайтовой графикой). А вот уже имеющим опыт создания спрайтовых игр и хоть худо-бедно наблатыкавшимся и при этом жаждущим извратиться (т.е. показать мастерство) – Юзбокс пожалуй вполне подойдет. Хотя нет – такого уровня скилованности гик разработает свою консоль! (если только он не чисто-программер).

«Ардуино с TV-выходом»? – будь это лет 20, а то и более назад … Сейчас же порой приходится искать драйверы под карту видео-захвата совместимые с Win7, т.к. оцифровка аналоговых сигналов (PAL,NTSC) считается морально устаревшей … Маленькие цветные LCD-дисплеи к ардуине стоят копейки, да и под ардуину навскидку проще накидать код, когда нужно сотворить что-нибудь незамысловатое или поэкспериментировать. Заморачиваться с Юзбоксом чтобы сделать термометр с выводом информации на старенький телевизор? (а такой пример есть и он работает) – неет!

«Учебное пособие для студентов»? – пожалуй единственная разумная идея приходящая в голову (по воспоминаниям о лабораторных и курсовых работак на разным «железячным» и «программистским» дисциплинам). Можно было бы студентам сначала предложить самим спаять Юзбокс (нас, инженеров-системотехников, учили паять), а потом в рамках изучения архитектуры (почему бы и не на пример avr-mega) запрограммить чего-нибудь учебно-прикладное. Ну и на «бис» (для отличников) игру написать …

Подытоживая изложенное приходится констатировать, что Юзбокс – это безделушка, хоть безусловно милая и забавная. Да это шедевр «как факт» - но не как платформа для дальнейшего творчества или прикладного применения. Желающие же продемонстрировать свое мастерство, уверен, смогут это более полно и изящно сделать любом железе «с нуля». Программирование под Юзбокс – заморочка на ровном месте которая того явно не стоит, цена сборки Юзбокса выше чем цена Arduino DUE, когда последняя явно производительнее и функциональнее … Для желающих «потрахаться» - всегда есть Денди – платформа труды в рамках которой смогут оценить значительно большее количество народа … Но опять я про Денди … Просто смотрю на свой Юзбокс, с одной стороны  любуюсь, но в тоже время и думаю, что даже для гика это скорее «баян» (а кто другой так и вообще не оценит).

Совместимость карт памяти, возможность использования MMC.

Лучшей в плане совместимости будет древняя SD-карточка (не HC), т.е. объемом менее 4Гб. Дальше идут нюансы и «если». Загрузчиков для Юзбокса два разных типа. Эволюционно первый (Gameloader) с номерами версий 0.4.x вплоть до 0.4.6 поддерживает ММС и SD (не HC) карты c файловой системой FAT16, однако имеет ряд ограничений (требований) к контенту, основное из которых - нефрагментированность файлов. Также желательно наличие лишь коротких имен (8.3) у файлов. Не выполнение подобных капризов ведет к тому, что файлы на карте могут быть просто не видны. В этом случае нужно закопипастить содержимое карты, отформатировать ее и скопировать контент обратно (иногда это приходится делать часто, что раздражает). Форматировать же лучше эталонной утилитой (SDFormatter) от консорциума стандарта SD. Появившийся позднее (усилиями энтузиаста с ником Jubatian подключившегося к проекту позже) загрузчик (Bootloader5) с номерами версий 5.0.xx вплоть до 5.0.11 имеет расширенный функционал: поддержку SDHC и FAT32, также допускает фрагментацию файлов, толерантен к длинным именам (хотя использует в меню информацию из тегов заголовка *.uze файлов), но имеет существенный недостаток – не поддерживает ММС карты. Юзбокс одно из таких устройств куда совать карты на 4 и более гиг бессмысленно! Четверти гига и то многовато, лично у меня сохранились ММС карточки и на 16 и на 32 мегабайта, которые как нельзя кстати можно использовать в Юзбоксе … Благо есть модифицированная версия «пятого» загрузчика (5.0.10) с поддержкой MМC.

Midi-вход – распаивать?

Да, это именно вход в Юзбокс от midi-источника (подключен на rx-линию uart-интерфейса). С какого бодуна пришло в голову кому-то реализовать подобное на Юзбоксе? Ну «научили» (чисто-софтово) Юзбокс на одной из ног генерировать псевдо-аналоговый сигнал а-ля «аудио-выход» - для спецэффектов и незамысловатого музыкального сопровождения в таких же незамысловатых играх оно вроде как и ни че … Но подключать к Юзбоксу midi-источник (midi-клавиатуру, например)?! – смысл? Писать под AVR-mega частотную эмуляцию какого либо музыкально инструмента или нескольких? Зачем? Делать из маленького восьмибитного контроллера голимый частотный синтезатор? Вобщем бредовая идея и дурацкая затея (почти как и весь Юзбокс, если честно) … Практического смысла – твердый ноль! Лучше бы уж тогда midi-выход был: прочитать мидишник с карты или из памяти и отправить его проигрываться на внешний синтезатор (как это делали ПК в эпоху i80286) Юзбоксу было бы вполне под силу …

Luma-trap – распаивать?

На схеме эта цепочка (индуктивность и конденсатор) помечены как опциональные. На практике разницы их наличия (или отсутствия) не заметил. Искать подходящую индуктивность чтоб не пустовало место? Я не стал …

Отдельно хочу отметить, что в цепь светодиода (даже если он самый дешевый в цветном корпусе) целесообразно впаивать резистор порядка 10кОм – иначе это будет просто слепящий прожектор, а не индикатор питания.

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

PS. Разумным применением видится использования Юзбокса как тестового источника сигнала для проверки и настройки аналоговой техники (если этим конечно кто-нибудь еще занимается). Или как источник сигнала с отсчетом времени для очистки видео-кассет ;-)

MiGeRA (февраль 2020)



Заглавная » Радиоэлектроника » UzeBox – Шедевр или баян