shiru8bit 

Вспомнил про ещё один музыкальный проект, который не перечислял в творческих планах. Это, получается, уже два: четырёхбитник и вот этот. Задумал я его давным-давно, и писал про него аж два года назад, в посте про покупку видеоплеера IconBIT. Он был нужен для этой темы. Сейчас я подумал, что надо бы всё-таки сделать, благо теперь это стало проще.

Суть идеи: формируя изображение определённым образом, можно получить в композитном видеосигнале управляемую составляющую звуковой частоты, и таким образом проиграть музыку. Услышать её можно через втыкание видеовыхода в звуковой вход. Таким образом роль звукового чипа-синтезатора выполняет видеочип. Прикольно? Прикольно.

Формировать такой сигнал можно чем угодно: любым компьютером, видеомагнитофоном, видеокамерой, снимающей нужные паттерны. Я не думаю, что задумка настолько прикольная, чтобы ударяться во все тяжкие, и делать её на какой-нибудь ретро-технике. Для начала вполне подойдёт USB-медиаплеер, а потом можно сделать демонстрацию на VHS-кассете (записав с плеера).

Давно не было радиодеталей. Так вот же они!

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

Из доступного чего-нибудь четырёхбитного оказался только Nibbler, самодельный компьютер без микропроцессора: реальные исторические четырёхбитные процессоры, которые можно программировать дома, стоят огромных денег: тот же Intel 4004 на eBay стоит порядка 150 тысяч рублей, и это без доставки в РФ, а ROM-less версия TMS 1099 или отечественный клон КР1814ВЕ3 ныне, похоже, вообще невозможно достать. Остаётся вариант собрать что-то самодельное, и только Nibbler обладает компактной схемой при наличии достаточного объёма памяти. Впрочем, в нём нет косвенной адресации, и поэтому не всё так просто, но это тема для отдельного разговора.

Так или иначе, я решил подобрать необходимые для сборки детали. Причём советского происхождения, чтобы мой Nibbler был более уникальным. Сначала мне казалось, что у меня есть почти всё, но оказалось, что казалось. Я начал докупать необходимое, мне было лень ехать в Кварц за одной-двумя микросхемами, где они дешевле, и я брал их на Озоне втридорога. В итоге оказалось, что почти всю комплекцию я там и купил, и в итоге на комплектацию (с излишками) ушло почти 5 тысяч. Стало быть, переплатил. Ну да ладно, тоже опыт.

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

Первое пополнение простое, но с непростым названием: тактический шутер SOCOM U.S. Navy SEALs; Fireteam Bravo 2 для PSP.

Рассказываю про легендарный Rebirth RB-338, программу для создания танцевальной музыки, открывшую массовому пользователю идею: для этого достаточно только компьютера. Плюс краткая история синтезаторов и эйсид хауса.

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

Дело в том, что у Nibbler’а нет не только стека, но и косвенной адресации. Совсем, полностью. Первое означает невозможность подпрограмм с возвратом. Второе означает невозможность доступа к данным по указателю. Ни к каким, ни в ПЗУ, ни в ОЗУ.

Это особенность именно Nibbler’а, значительно упрощающая его устройство, и она лежит в основе схемы: как-нибудь прикрутить эти возможности нельзя. В промышленных 4-битных процессорах типа SM510 и TMS1000 рудиментарные реализации стека (один вызов) и косвенной адресации (регистр-указатель) есть.

Подпрограммы на нормальных процессорах обычно реализуют через механизм call/return: call запоминает текущий адрес исполнения на стеке и переходит на новый адрес, а return забирает адрес со стека и переходит туда. Глубина вложения определяется размером стека. Например, у 6502 это может быть аж 128 уровней, хотя в реальных программах это всего один-два десятка.

У ранних процессоров нет стека, а только регистр возврата: call запоминает один-единственный адрес в этом регистре, а return совершает обратный переход. Если нужна вложенность вызовов, нужно изобретать собственную альтернативу стеку. Это может быть пересохранение адреса возврата в фиксированные для каждой подпрограммы ячейки ОЗУ (без возможности самовызова), или реальный многоуровневый стек. Но он требует косвенной адресации.

В Nibbler’е механизма вызова подпрограмм просто нет. Их реализуют jump-переходом. Перед вызовом в ячейках ОЗУ сохраняют номер (не адрес, это очень важно!) возврата. Для возврата выполняется диспетчер выхода: если индекс такой-то, jump на метку. У каждой точки возврата есть своя метка, и в диспетчере вручную, длинной колбасой сравнений, выясняется, на какую метку нужно перейти. Потому что команды перехода по указателю, то есть косвенной адресации, в архитектуре нет.

Также в Nibbler’е нет указателей в принципе. Хуже того, он имеет Гарвадскую архитектуру: код в одной памяти, ОЗУ в другой, в раздельных пространствах. Единственный способ загрузки данных из памяти кода (ПЗУ) — непосредственная загрузка, типа lit #N (4-битное значение в аккумулятор). Для памяти есть только ld ADDR и st ADDR, загрузка и сохранение аккумулятора в абсолютный адрес ОЗУ. Никакой альтернативы ld a,(hl) на Z80 нет.

Дописал и подготовил к публикации очередной материал, про ReBirth RB-338. Уже давно лежал в планах, и тут как раз случился 30-летний юбилей. Выйдет наверное в конце следующей недели.

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

Не отходя от кассы, продолжил эксперимент: с помощью того же DeepSeek сгенерировал версию игры Dino Run (динозаврик из Chrome) для четырёхбитного Nibbler’а.

За основу взял версию для того же LCD1602 и Arduino. ИИ без проблем разобрался, что к чему, и сгенерировал упрощённый аналог на ассемблере никому толком не известного процессора: для Nibbler’а почти ничего нет, это весьма обскурное самодельное устройство, которое в мире собрали лишь несколько человек, а его эмулятора до вчерашнего дня и вовсе не было.

Я специально не стал наворачивать дизайн игры. ИИ хорошо справлялся, ошибок было очень мало, но это не та платформа, от которой ожидают сильно навороченных программ. Места в ПЗУ ещё много, при желании можно насовать ещё всякого. Главное, что код активно использует ресурсы аппарата, позволяя протестировать и реальный аппарат, и ранее сгенерированный эмулятор.

Позавчера что-то вдруг вспомнил про такой проект, как самодельный 4-битный процессор-микрокомпьютер Nibbler. Когда-то думал собрать, но не дошли руки.

Сейчас захотелось поизучать его архитектуру. Есть программный симулятор. Но он не работает в реальном времени и не эмулирует LCD1602. Существующие программы с его помощью не посмотреть и не услышать. Обломно. Нужен нормальный эмулятор, а его нет, и писать лень.

Иии что же вы думаете? Есть ИИ. Этот самый норовящий вот-вот лопнуть «просто T9», который «просто предсказывает вероятные буквы». За пару часов с помощью обычного чата DeepSeek, без единого гвоздя и набранного руками кода, по коду симулятора, игр и пояснениям архитектуры ИИ сгенерировал мне нормальный эмулятор на Java, с графикой и звуком. Без отладочных функций, для них есть вышеупомянутый симулятор. Который, к слову, даже не удалось собрать из исходников.

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

С момента выпуска Floppy Beast прошло около месяца. Ещё не полный месяц, но ситуация уже совершенно очевидна, и можно подвести итог.

За это время я опубликовал альбом, раскидал анонсы повсюду, сделал видео на YouTube, четыре шортса с разными треками, опубликованные на YouTube, в FB и X, и подробную статью на Хабре. Показатели:

• Полное видео на YouTube: 2468 просмотров

• Шорт #1: 192 просмотра

• Шорт #2: 461 просмотр

• Шорт #3: 209 просмотров

• Шорт #4: 48 просмотров

• Статья: 8.5 тысяч показов, около 1200 читателей

• Bandcamp: 4 продажи на сумму 37 долларов (я их не получу, вывести невозможно)

По сравнению со всеми моими подобными прошлыми проектами всех видов это абсолютное фиаско. И другие мои музыкальные релизы, и проекты с вау-фактором раньше получали гораздо больше внимания, на порядок или и того больше. Я надеялся, что хотя бы статья разгонит популярность, но… это худшая статья за год. Она опубликована в пятницу и уже полностью перестала набирать просмотры. У неё худший старт и худший результат. То есть чуда уже не случится.

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

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

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

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

Но незатыкающаяся народная молва о том, что на готовом-то движке проще и эффективнее, ведь его десятилетиями пилили лучшие умы человечества, а не я, делает своё дело, и время от времени я проверял, так ли это: пробовал осваивать GameMaker, Unity, или, вот, Godot. Без особого успеха, для моих целей всё это оказывалось не применимо.

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

Проекты — простые 2D игры с пиксельной графикой, аутентичные 8-16 битной игровым эпохам. Соответственно вопрос я рассматривал именно с этой точки зрения. Думаю, для игр иного рода, более современных или 3D, выводы будут иными. Но у меня конкретный практический интерес: решается моя задача или не решается.

Скачал последнюю стабильную (это важно) версию 4.7.2 и начал тыкаться, пытаясь создать примитивное подобие Super Mario Bros: простой уровень, перемещается персонаж, взаимодействие с фоном. По идее, движок, который разрабатывается уже 12 лет, и применялся в реальных проектах, без проблем может решить эту задачу за считанные часы. Совсем без движков это делается за день. Спойлер: я потратил три дня, получил крайне негативный опыт, и задачу не решил ни в каком виде.

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