Полное руководство по аппаратному мультиколору для тех, кто не знает, что это такое и зачем он нужен.

Преимущества и недостатки, прототип игры, перспективы

---

См. также первую, вторую и третью части.

Аппаратный vs Программный

Аппаратный мультиколор
Всем был бы очень нужен
Программные мультиколоры
Обязаны сидеть в луже!

Эта часть могла бы быть первой (и единственной). Тем не менее в силу незнакомства широких масс с аппаратным мультиколором и/или поверхностного понимания особенностей его программирования потребовались предыдущие три части для понятного (надеюсь) разъяснения: насколько это просто, широко доступно и практически бесплатно.


Будем предельно откровенны: с самого начала мультиколор представлял собой перформанс. На вопрос «Зачем нужен мультиколор?» никогда не было ясного ответа, но бытовало представление, что это просто «круто».

Демо, имевшее мультиколорную часть, считалось более технологичным и стоящим на ступень выше других, оно поднимало статусность авторов.

Вопрос «Зачем?» не задавался: мониторы спектрумистов были обклеены бумажками, на которых они мерили INT, отмечая его карандашом. Ответ на этот вопрос мог звучать так: «Потому что Code Busters!»

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


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

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

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

В 2018 году появилась игра «Старая башня» от Retro Souls, с которой многие связывают переход от применения программного мультиколора исключительно в демостроении к использованию его в геймдизайне. На следующий год Денис Грачёв опубликовал историческую статью «Мультиколор будет побеждён», обосновавшую дальнейшее увеличение игрового пространства.

Сложно не заметить, что на эту победу ушло больше четверти века, т. е. 35 лет (если считать с 1983 года). Всё это время рядом находился копеечный, но неизвестный и поэтому нераспространённый аппаратный мультиколор, вообще не требующий, чтобы его «побеждали».

С точки зрения потерянного времени дела в демостроении обстоят не лучше. Для написания чанковой цветной демки в разрешении 64×48 не надо писать ещё один мультиколорный движок с именем шумерского бога. Достаточно заполнить область изображения числом #33 или #CC и выводить чанки расширенными атрибутами. Никакого пафоса и минимальные трудозатраты. Подытожим:

Мультиколор	Программный	Аппаратный
Порог вхождения	Высокий	Низкий
Доступность	1) Любой ZX Spectrum 2) Фиксация на INT	1) Простая доработка 2) Встроен во многих клонах ZX Spectrum
Совместимость	Тотальная несовместимость	Любой клон с поддержкой режима Hi-Color
Графический редактор	multiArtist (ограниченно)	ZX-Paintbrush (универсально)
Создание графики	Плохо стандартизировано Изобретение форматов удобных для вывода и хранения	Стандартные форматы Элементарно, но требует привычки
Динамичные игры и демонстрации	Через вывод чанков	Также, как в стандартном режиме
Адаптация ПО	1) Сложно и времяёмко 2) М.б. невозможной	1) Обычно не требуется 2) Добавление значений в стандартные порты
Мультигигаскрин	128×192 (16×24 знакоместа)	Полный экран 256×192

Прискорбно, но многие спектрумисты-разработчики сегодня переориентировались на поддержку зарубежных коллекционеров, разворачиваясь пердимоноклем к пользователям отечественных клонов. Новые релизы всё чаще ориентированы на оригинальный ZX Spectrum 128 и формат TAP (иначе зарубежные коллекционеры и пользователи FPGA-клонов не смогут это запустить и не захотят покупать).

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

Речной рейд

Спектрумизм в целом неизлечим.
Вот зачем — ты пойди спроси.
Пишут демки ассемблерные,
Мультиколорные россыпи!

Одной из важных вех развития программного мультиколора считается вышедшая в 2009 году техническая демонстрация «River Raid» от британского разработчика Джейсона Дж. Рейлтона. Она пародирует одноимённую классическую игру от Activision, существующую на Спектруме, но в худшем (по сравнению с Commodore 64, Atari и т. д.) качестве.

Для увеличения цветового разрешения автор использует следующую хитрость: по центру экрана располагается область шириной 14 знакомест, в которой отрисовывается программный мультиколор. Эта область продолжается совмещённой с ней отрисовкой атрибутов и полос на бордюре, что даёт иллюзию полноэкранной игры в разрешении более высоком, чем доступно Спектруму.

Создать настоящую игру на таком фундаменте невозможно, а сложность кодирования подобного эффекта достаточно высока. В то же время написание эквивалентной демонстрации для режима Hi-Color тривиально. Но пока не откажем себе в удовольствии посмотреть на мультиколорные россыпи:

Эти снимки хорошо отражают недостатки программного мультиколора, а сама программа отлично подходит для демонстрации разницы в подходах.

Иллюзия движения в оригинальной демке создаётся синхронной прокруткой изображений мультиколора, атрибутов и бордюрных полос сверху вниз. При этом сам крохотный самолётик стоит на месте. В режиме Hi-Color мы не ограничены мультиколорной областью и можем нарисовать кукурузник размером хоть во весь экран. Хотя из скромности предлагаю ограничиться изображением советского истребителя МиГ-29.

Ландшафт логично рисовать расширенными атрибутами, и детализации вполне хватает для изображения такой игры. С точки зрения художника, мы должны отрисовать самолёт цветом тона (чернила), а весь ландшафт — цветом фона (бумага). С точки зрения кодера, мы имеем область изображения (куда заранее впечатан самолёт) и область расширенных атрибутов (6144 байта), которую необходимо прокручивать сверху вниз.

Аппаратный мультиколор может выводить картинку в разрешении 32×192. Стандартная программная прокрутка: запоминаем в буфер 32 байта расширенных атрибутов из нижней 191-й строки, прокручиваем расширенные атрибуты на пиксель вниз и выводим буфер в верхнюю (нулевую) строку. Повторяем в цикле.

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

Не скажу, что сильно перетрудился, но итоговая техническая демонстрация «Речной рейд» (с музыкой, печатью текстов и другими добавлениями для выполнения требования об отсутствии сплошной анимации) под аппаратный мультиколор будет отправлена на фестиваль DiHalt 2026 Summer. Попробуйте, может быть, у вас выйдет лучше (самолёт меняется на звездолёт, вертолёт, и т.д.)?

К вопросу о «жирных» 12К картинках (этот вопрос уже рассматривался в предыдущей части руководства): графику в современных программах для Спектрума принято (де)компрессировать. Для компрессии можно использовать zx7mini, пример для данной программы:

$ zx7mini.exe res/Landscape.C res/Landscape.Z
Optimal LZ77/LZSS compression by Einar Saukas
File converted from 12288 to 592 bytes!

Конечно, компрессия сильно зависит от типа графики, но надо отметить, что расширенные атрибуты обычно имеют значительные однотонные области и сжимаются гораздо лучше изображений. Можете себе представить, сколько такой графики можно поместить в 4 Мб современного клона типа ZX Evolution? Посчитайте)

Ошибка Зонова

Все за и против взвесив,
Дело осталось за малым:
Добавь своему Спектруму,
Аппаратный живой мультиколор!

На легендарном фестивале Enlight’97 фирма «Скорпион» показала предсерийный образец платы GMX (Grafic Memory eXtension). По сути, это была видеокарта для Scorpion ZS 256, обладавшая следующими характеристиками:

• 512 КБ ОЗУ
• Графический режим 640x200 @4
• Текстовый режим 80x25
• Аппаратная прокрутка экрана вверх-вниз
• Стоимость эквивалентная $35-$40

Что с ней было не так?

GMX никогда не предназначался для вывода графики. Графический режим был задуман для вывода текста с символьным разрешением 80×25, хорошо подходящем для адаптированной Андреем Ларченко версии CP/M 2.2. Если текст был цветным, то этот видеорежим потреблял все 512 КБ.

Видеокарта не работала при установленной звуковой карте General Sound. Пользователь должен был выбирать между видео и звуком. Кто-то говорил, что Зонов устраняет конкурентов, а из ларька Scorpion на радиорынке доносилось что-то про MIDI-контроллер.

Официально инфляция за 1997 год составила 11% при официальном же курсе 5600–5960 руб. за доллар. Средняя зарплата была эквивалентна $159, поэтому приобретение платы GMX выглядело как выбор между едой и Спектрумом.

В действительности фирма «Скорпион» проводила опросы пользователей, а Сергей Юрьевич внимательно слушал критику, просто трактовал её по-своему. После эпичной осады пользователями на фестивале Enlight’96 в рамках проекта GMX должен был появиться режим совместимости (позволяющий смотреть мультиколорные демо для Pentagon без адаптации).

Когда GMX был показан «вживую», пользователи стали требовать уменьшить разрешение до 320×200 и предоставить видеорежим с цветом на точку. По коллективной мысли пользователей, это должно было привести к удешевлению (в 2 раза меньше памяти) и появлению видеорежима для вывода именно графики, а не текста.

Зонов трактовал это пожелание как добавление нового видеорежима в существующий концепт, требующее доработки и изменений ПЗУ. Пользователи пожали плечами и массово начали дорабатывать свои Scorpion для видеорежима Timex Hi-Res (начавшийся в 1997 году в Санкт-Петербурге тренд докатился к 1999 году до Саранска). Разрешения 512×192 хватало для работы с текстовыми редакторами и почтовыми программами. То есть ровно для той ниши, в которую был нацелен GMX. Себестоимость добавления видеорежима 512×192 составляла какие-то десятые доли доллара.

Если Клайв Синклер продвигал свой ZX Spectrum по принципу «лучше хуже, но больше», то бизнес-логика Сергея Зонова, наблюдавшего стремительное сокращение популяции спектрумистов, лежала в плоскости «лучше меньше, но дороже». Более развёрнуто: «Лучше получить с каждого пользователя больше денег сейчас, потому что потом они всё равно все будут на PC».

Предположим, что копеечные режимы Timex были бы добавлены Сергеем в 1993 году при запуске производства Scorpion. Это никак не повлияло бы на совместимость с ПО и стоимость, но закрыло бы вопрос с мультиколором (1996) и разрешением для почтового ПО (1997). Пользователи не корябали бы красивые зелёные платы. Такое решение неузнаваемо изменило бы ландшафт ПО для всего ZX Spectrum.

Возможно, кто-то составит впечатление: «Ну вот, во всём виноват Зонов». Это не так. Сергей Юрьевич действовал в конкретную и непростую историческую эпоху, исходя из своих представлений о предпринимательской деятельности, и был во многих отношениях первопроходцем.

Однако развитие любой платформы может быть только эволюционным и никогда скачкообразным. Видеорежимы Timex сродни тем вещам, которые человечество изобретало раз за разом «с нуля»: колесо, письменность, бетон и даже телевидение.

Казалось бы, после популяризации шин ZXBUS и NemoBUS, что могло бы быть более эффективным, чем небольшая платка изменяющая логику работы ULA и добавляющая режимы Timex любому клону Спектрума? Ровно эти два нативных режима, и ничего более, то есть никаких GMX, никаких HRC, HAM, EGA, VGA и прочего. Подозреваю, что в таком виде платка могла бы не только иметь копеечную стоимость и продаваться в 1996-99 гг как горячие пирожки, но и быть вообще сквозной.

Проблема вот в чём. Разработчикам железа было (и есть) гораздо интересней:

1. Реализовать нестандартный и ни с чем не совместимый видеорежим, который не будет иметь никакой поддержки;
2. Провести работы по реверс-инжинирингу и переизданию какого-нибудь мертворожденного железа (например, GMX);
3. Провести работы по синхронизации с экраном Спектрума чего-нибудь совершенно чужеродного (например, Dendy);
4. Подключить видеопроцессор в неожиданный разъём (например, VDAC2 для порта IDE);
5. Создать видеокарту на базе чипа выпаянного из фоторамки и закрыть проект в связи с недоступностью фоторамок на AliExpress.

Список можно продолжить.

Если пользователю нужен Dendy, то он пойдёт и купит Dendy. Спектрум ему для этого не нужен.

Если пользователю будет нужен режим HAM, то он пойдёт и купит Амигу. Ему не нужен этот режим на Спектруме. Хотя бы потому, что весь инструментарий для режима HAM — на Амигах. Он даже не сможет этим нормально пользоваться без покупки Амиги.

Точно так же пользователь говорит: «Зачем мне GMX «за много денег», если, припаяв пять проводов, я получу почти то же самое в существующих условиях?». И на этом заканчиваются продажи.

Как мы знаем хотя бы из опыта создания GMX фирмой «Скорпион», построение замкнутых экосистем для полутора пользователей, имеющих возможность покупать железо по цене крыла самолёта, — путь в никуда.

Самовоспроизводящийся парадокс двух почти не пересекающихся вселенных: разработчиков железа и его пользователей. Точно такая же коллизия, как и в стане разработчиков: аппаратный мультиколор имеет перспективы (позади себя), в то время как программный навсегда останется «вещью в себе» и не вернёт ни копейки из вложенных в него усилий. Как в той поговорке про мышей плачущих и жрущих кактус.


Тестирование новой видеокарты для ZX Spectrum

Конец