Как стать автором
Обновить

Культурный феномен клипа Bad Apple и мой BAD AON

Уровень сложностиПростой
Время на прочтение20 мин
Количество просмотров18K
Всего голосов 132: ↑132 и ↓0+174
Комментарии36

Комментарии 36

НЛО прилетело и опубликовало эту надпись здесь

Когда увидел в телеграмме примерно месяц назад, то был неспособен прокоментировать увиденное - мысленно не мог поверить что кто-то это сделал: этого не может быть потому, что не может быть :)

«Крут, а мы перед ним сынки!» ©

Да не, дум на таком экране мне кажется не вариант, и на классическом z80 со стандартной скоростью. Да, можно собрать N аонов в дисплейное поле как у Гайвера, и дум все-таки будет узнаваем на таком дисплее (привет порту FastDoom с его текстовыми режимами), но вот что делать с CPU не ясно - в кластер их (АОНы) не особо объединишь, ибо z80 по-момему не заточен под мультипроцессорность по умолчанию (в отличии, кстати от 8080). Хотя конечно можно попробовать изобрести свой арбитр шины и попробовать построить мультипроцессорную z80 систему, но она уже не будет классическим АОНом. Ну и не потянет Z80 оригинальный дум на приемлемой скорости даже в этом случае, ибо там мало что параллелится. Вон, недавно все-таки собрали Doom для 8088 с помощью опенваткома и какой-то матери, но естественно столкнулись с проблемой 640Кб памяти и медленным маппером немножко дополнительной (EMS), и как итог - один кадр в пять минут примерно и только первый уровень, ибо остальные падают из-за нехватки памяти и прочего. Даже на 286 ситуация не лучше. Убрали текстурирование вообще - стало получше, но все равно далеко от идеала. Поэтому мне кажется АОН себя уже полностью раскрыл -) Могу посоветовать другую платформу, для которой нет демок - это УКНЦ МС 0511. Ну ладно, есть одна демка, но и она порт с БК, и на этом всё. А УКНЦ это два (sic!) 16-битных проца, 8 цветов в довольно приличном разрешении экрана 640 × 288, 96Кб памяти. А с хитрыми трюками и все 128 цветов (правда с очень большими ограничениями). Ну и плюс много много фана с попыткой хотя-бы просто вывести точку на экран в заданных координатах. Рекомендую -)

Я согласен, настоящий Дум на АОНах не взлетит никак, хоть их сто штук в стопку поставь и в вычислительный кластер объедини. Но может взлететь типичный вариант, когда что-то просто называют Doom, и придают ему пару узнаваемых черт. Как-нибудь напишу про это занимательное техно-культурное явление (новости типа «Doom запустили на этом и на том»).

С УКНЦ я знаком, но не близко: она была у меня в школе в кабинете информатики, и я там успел потыкать в Бейсик Вильнюс-88. В 2000-х неоднократно пытался делать подходы к этому снаряду, находил и читал документацию, и так далее. Но сначала остро стояла проблема отсутствия эмуляторов, а потом отсутствия средств разработки. Кросс-средств ещё пару лет назад не было совсем, и предлагалось пользоваться нативными внутри эмулятора. Сейчас кросс-компиляторы вроде появились, так что приоритет УКНЦ в списке потенциальных платформ для моих будущих демок конечно же растёт.

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

Наблюдаю за чатом в телеграмме и не заметил использования кросс-компиляторы - в чате делают магию в MACRO-11

Ничего, если никто не, побуду первым. Главное, чтобы сами кросс-компиляторы были в принципе, это критически важный момент. И как минимум один есть: БК Турбо8. По описанию выглядит достаточно рабочим, но это ещё предстоит проверить.

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

Два процессора - стандартная ситуация на 16-битных игровых машинах, но там высокая специализация. В УКНЦ более универсальная система. Учитывая, что со звуком на УКНЦ всё плохо, самая очевидная идея - попробовать загрузить один процессор синтезом звука. Но пока непонятно, сработает ли это, как там со стабильностью таймингов в том числе.

В чате видел использование AY и аппаратного MIDI синтезатора на плате расширения - думаю они не сильно нагружают процессор. А вот по музыкальным способностям встроенного бипера там много претензий - и плохая пьезопищалка и нет таймера.

И AY, и MIDI можно послушать на чём угодно. Зачем делать это на уникальной машине? Гораздо интереснее заставить её звучать своим голосом. Вместо (или вместе) пищалки можно выводить звук на любой порт, даже на тот же магнитофонный выход. Таймер - не проблема, главное, чтобы тайминги выполнения операций не плыли.

По-моему там пьезо такое как в электронных часах и способно только пропищать +/- одним тоном.

Я много лет специализируюсь именно на принуждении одиноких пьез к пищанию множеством тонов. Это наименьшая из проблем, опять же, при условии стабильности (предсказуемости) таймингов. Так как вроде бы в истории была наполовину успешная попытка сделать MOD-плеер для УКНЦ, полагаю, что с таймингами там всё нормально, и всё получится.

Бери лучше PDPy11. Он красиво сопрягается с Sublime Text и с эмуляторами. Кстати, PDPy11 был создан специально для работы над «Good Apple» для БК 0011. Потом мы его допилили, чтобы компилировал файлы в формате RT-11 для УКНЦ и Союз-Неона.

Еще б кто написал обзор как это использовать в эмуляторе УКНЦ, подобно найденной сейчас статье https://eax.me/bk-0010-01-assembly/

Текстовый редактор подойдет любой по вашему вкусу. Я в последнее время предпочитаю Sublime Text. Подсветка ассемблера PDP-11 для этого редактора вместе с инструкцией по установке доступны здесь.

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

А чем именно 8080 лучше Z80 подходит для многопроцессорных систем?

Ну и плюс много много фана с попыткой хотя-бы просто вывести точку на экран в заданных координатах.

Хммм... не помню серьёзных проблем с выводом точек по координатам - моя "курсовая" на УПК была как раз на УКНЦ, и там не только рисовался человечек (в стиле Lode Runner), но и считывались "препятствия" с экрана...

Вот еще примечательные экземпляры:

Первый абзац так и задумывался текст? "в условиях крайне ограниченных ограниченных ресурсов"

Издержки быстрого редактирования. Спасибо, поправил.

Самую мякотку забыли: в отличие от Doom, Bad Apple черно-белый и контрастный, а значит его контур можно запускать и на векторных экранах, не поддерживающих растр. Вон посмотрите что с ними @pyhesty вытворяет.

P.S. Ну и сам себя не похвалишь - никто не похвалит ;)

Возможно, я не акцентировал на этом достаточно внимания, но векторную версию для Vectrex-то упомянул.

Да, такое нужно хвалить, очень прикольная идея! Похоже, что яблоко — оно как атом, практически неисчерпаемо.

Добавлю версию для MSX, не требующую никаких дополнительных устройств для выполнения (не считая контроллера дисковода с приводом и дискеты). Про неё даже была статья @Pyhesty на Хабре "Bad Apple для MSX на CC'21" с описанием "внутренней кухни".

Больше яблок, хороших и разных! Радует, что и на Хабре уже есть материалы на эту тему. Традиция живёт.

Небольшая пометка о БК 0011М – приведённая версия работает только на разогнанной до 6 МГц БК. Но есть и другая версия, для стандартной БК. При этом она выглядит интересней: https://www.youtube.com/watch?v=8Q1vN51o-Dg

А почему при быстрых перемещениях картинки влево-вправо видны артефакты в виде горизонтальных полос, похожие на "интерлейс"? Какие-то особенности, связанные с малым количеством памяти или быстродействием?

Особенность всех старых компьютеров – малое быстродействие. БК 0011 исполняет в секунду 250 000 операций регистр-регистр, а более сложные пересылки в памяти могут занимать и 72 такта (при частоте процессора всего 4 МГц).

Поэтому на БК 0011 я использовал дельта-компрессию – хранил только разницу между кадрами. При частоте кадров 25 в секунду БК успевает обновить только небольшую часть экрана. Поэтому при больших изменениях от кадра к кадру удаётся обновить не всё. Потом оно постепенно докрашивается на следующих кадрах.

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

Спасибо за объяснение, очень круто. ZX Spectrum у меня был, проблемы старых компьютеров мне понятны. Но про БК 0011 я ничего не знаю, поэтому всё это очень интересно.

А как готовились скомпрессированные данные? Была сделана какая-то программа на PC, которая готовила данные так, чтобы артефакты при воспроизведении были минимальны?

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

Классно получилось! Я пока читал, мысль была "да там же вообще ничего не будет видно", а по факту был приятно удивлен, некоторые сцены прям отлично выглядят и без прищуриваний)

Господи, как же это прекрасно. Главное Зуну не показывать, а то пивасом поперхнётся от такого зрелища.

Doom и Bad Apple- они вечны!

Больше "Bad Apple", хороших и разных!

James Sharman Bad Apple on the Homebrew CPU!

Porting Bad Apple to the Homebrew CPU!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий