Как установила современная наука, SDK — это набор инструментов для разработки программного обеспечения, как правило, под определённую компьютерную платформу, операционную систему или устройство. Весьма полезная в хозяйстве вещь.
Это довольно древнее изобретение человечества, однако есть устройства, созданные ещё раньше, и по этой причине изначально никаким SDK не обладающие. Также есть и новодельные, современные любительские платформы. Для всего этого безобразия тоже крайне полезно иметь какое-то подобие SDK. Чем полезно, а также кто, как и зачем может его сделать — разберёмся в этой статье. А в качестве примера возьмём некоторые мои старые проекты, главным образом Evo SDK для 8-битного компьютера ZX Evolution.
▍ Ретрокомпьютеры
Среди энтузиастов устаревшей вычислительной техники, сиречь «ретро-компьютеров» и «ретро-консолей» (игровых), есть такая народная забава — создавать ещё больше новых старых компьютеров. Создаются они либо из старых деталей по старым лекалам, либо из новых, но по образу и подобию устройств из прошлого, только с новыми, более продвинутыми возможностями — например, такими, которые не были осуществимы технически в 1980-х годах, или стоили бы слишком дорого.
Подобных разработок за прошедшие с момента окончания их актуальности три десятка лет накопились многие сотни, и даже просто перечислить их было бы крайне затруднительно. Некоторые из них создаются в качестве разовой акции, пет-проекта, на потеху их автору, обычно для получения опыта в разработке подобных устройств, и остаются на GitHub-страничке автора. Иные же тиражируются мелко-кустарным, как ZX Evolution, или вполне себе заводским образом, как ZX Spectrum Next и Commander X16, и известны вполне широкому кругу неустановленных лиц, коллективно известных как «ретро-компьютерщики».
На Западе ретро-машины представлены в основном разработками, имеющими отношение к крайне популярному в тех краях 8-битному компьютеру Commodore 64. Другая крайность — совсем ни с чем не совместимые машины на процессорах 6502 и Z80. В европейских краях мира наблюдается интерес к более местечковым машинам, в том числе Amstrad CPC в Германии и Atari в Польше.
На постсоветском же пространстве ретрокомпьютерное движение в основном сплотилось вокруг ZX Spectrum — самого популярного бытового компьютера на постсоветском пространстве 1990-х годов. Но хотя Спектрум и лидирует в топе местных ретро-симпатий, не им единым жива ретро-сцена — есть ещё БК-0010/11, Вектор-06ц, и многие другие редкоземельные, уникальные машины местного производства.
Создание доработок и улучшений для этих машин началось ещё во времена их активной жизни — увеличение объёма ОЗУ и скорости процессора, подключение мыши и клавиатуры от PC, добавление дисководов, жёсткого диска, улучшенных видеорежимов и звуковых карт.
Тогда же были созданы первые «супер-спектрумы» и «супер-неспектрумы»: компьютеры, совместимые с ПО их прародителя, но также обладающие новыми продвинутыми возможностями: графикой высокого разрешения, продвинутым звуком. ОС CP/M или чем поинтереснее. Несмотря на потерю актуальности, в 2000-х годах это движение только набирало силу, так как развитие технологий и элементной базы открыло широчайшие возможности для подобного технического творчества.
Чтобы перейти к теме значения SDK для народного ретро-хозяйства, нужно признать очевидный, но неудобный факт: энтузиасты наплодили настолько много разных машин, что самих энтузиастов на них уже не хватает. Выбор ретро-платформ огромен, как классических, так и новодельных. Встаёт проблема, от которой страдал ещё изначальный рынок домашних компьютеров: нехватка программного обеспечения.
Здесь возникает другая народная же забава среди тех же самых энтузиастов — создание программ для всего зоопарка разнообразных машин. Дело в том, что мало сделать мощную железку, нужно ещё задействовать её возможности и раскрыть заложенный в ней потенциал.
На Западе эту проблему решал рынок и капитализм, а в СССР обладание собственным компьютером было само по себе высшим и достаточным благом, а ПО пользователям предлагалось создавать самим, для чего им, как правило, выдавалась инструкция по Бейсику, а заодно и схема компьютера. Тем же самым приходится заниматься сейчас и энтузиастам ретро-платформ, особенно новодельных.
И если в формате разовой акции это осуществимо традиционными путями, простым обычным процессом разработки для подобных машин — всё с нуля и на ассемблере, то создать хоть сколько-то развитую библиотеку программного обеспечения так просто не получится. Возникает замкнутый круг: на платформе ещё нет ПО, значит, её возможности нельзя увидеть иначе как в виде списка характеристик, значит, они не привлекают пользователей, значит, некому создать ПО.
Частично ситуацию спасает портирование разнообразных проектов между платформами. Это проще и быстрее, чем разработка с нуля. Но это только набор массы, необходимой, но недостаточной для полноценной жизни платформы. Ведь подобные порты, как правило, не раскрывают уникальные возможности платформ и не становятся пресловутыми «killer app» и «system seller».
Чтобы разорвать порочный круг, нужно максимально упростить процесс создания нового ПО. И в качестве меры первой помощи здесь пригождается пресловутый SDK. Он призван обеспечить энтузиастов готовой средой для разработки, в которой уже есть все необходимые инструменты и предусмотрены готовые решения для всех типовых проблем. Главная его задача — снижение порога входа для новых разработчиков, пусть ценой ограничения доступных возможностей и менее эффективного итогового кода.
Но SDK тоже должен кто-то создать. Не всегда разработчик самой платформы компетентен в этом вопросе, а если речь идёт о классических платформах древности, то и вовсе крайних нет — спасение утопающих дело рук самих утопающих, SDK нужно изобретать самим энтузиастам.
Одним из таких энтузиастов побывал и я. В разные годы я решал эту задачу для NES, SNES, и некоторых других платформ игро-консольной направленности. Но эти машины не так популярны в наших краях, поэтому я расскажу об этом деле на примере Evo SDK для отечественных «супер-спектрумов» ATM Turbo и ZX Evolution.
▍ ATM Turbo и ZX Evolution
Для начала несколько слов о самой платформе.
Не буду слишком углубляться в историю: это слишком горячая и опасная тема среди её поклонников и отрицателей — краеугольным камнем многолетнего конфликта является вопрос «спектрум ли оно» — но пройдусь по вершкам энциклопедического характера. Погрузиться же в самую гущу вопроса вы при желании можете с помощью специализированного сайта, оснащённого встроенной ностальгией по диал-апу начала 2000-х годов.
Компьютеры линейки ATM Turbo изначально были созданы творческим коллективом «МикроАРТ», состоящим из студентов МФТИ, и фирмой «АТМ», но не той, которая делает банкоматы (главная шутка юмора про данные компьютеры). Касательно последней существует две версии расшифровки названия: «Ассоциация Техники и Микроэлектроники» и «Ассоциация Творческой Молодёжи». Насколько я понимаю, «МикроАРТ» разрабатывал схемы, а фирма «ATM» занималась производством, но это не точно, показания очевидцев разнятся.
Первой разработкой коллектива, выполненной в самом конце 1980-х годов, была версия стихийно развивающегося на постсоветском пространстве клона ZX Spectrum 128K — Пентагон 128. Называлась она ATM 128, а также известна под названием Пентагон 2+ (без музыкального сопроцессора). Однако стихийность стала и недостатком: подобные клоны делали все кому не лень, и сохранить контроль над платформой было невозможно — из-за простоты копирования устройства нельзя было заработать на этом деле деньги. К тому же, сам по себе ATM 128 не обладал дополнительными преимуществами.
Для решения этой проблемы был создан новый конкурирующий стандарт, оснащённый защитой от копирования в виде применения в схеме ПЛМ 1556ХЛ8.
Первый компьютер линейки, ATM Turbo без дополнительных цифр (позже его стали называть ATM Turbo 1 или ATM Turbo 512), был создан в 1991 году. Помимо защиты от копирования, он был оснащён немалым количеством улучшений: турбо-режим 7 МГц (отсюда и название), поддержка до 512 КБ ОЗУ, два дополнительных графических видеорежима, звуковое устройство Covox и поддержка ОС CP/M. Получилась довольно интересная и мощная ZX Spectrum-совместимая машина.
В 1993 году была создана улучшенная версия компьютера: ATM Turbo 2. Из улучшений — новый менеджер памяти, напоминающий компьютеры MSX (четыре окна по 16 килобайт), аппаратный текстовый видеорежим 80x25, контроллер IDE-устройств (жёсткий диск и CD-ROM), восьмиканальный АЦП и поддержка стандартной клавиатуры для PC XT.
В том же году коллективы разошлись своими путями, и ATM Turbo какое-то время выпускался двумя конкурирующими организациями. В итоге права на все разработки остались у «МикроАРТ», она преобразовалась в фирму и продолжила выпуск новых версий компьютера.
Начиная с 7-ой ревизии платы, компьютер стал носить название ATM Turbo 2+. Главными отличиями этой версии является поддержка 1 мегабайта ОЗУ, порт RS-232 и поддержка AT-клавиатуры.
Производство компьютера его оригинальным разработчиком было прекращено в 1995-96 годах, а поддержка завершилась к 1998 году.
Однако, в 2004 году на сцену выходит творческий коллектив NedoPC. С помощью безвозмездно полученного от «МикроАРТ» комплекта документации, а также добытых там же «ХЛ-ок», коллективом было выпущено и распространено среди страждущих около полусотни новых плат ревизии 7.10, с исправлением некоторых ошибок.
В 2009 году коллектив NedoPC решил пойти дальше и разработал свой собственный новый ZX Spectrum-компьютер ZX Evolution, также известный как просто Evolution, Evo и Pentevo. Он выполнен на современной (тому времени) элементной базе, с применением FPGA, и обладает обратной совместимостью с ПО для Pentagon и ATM Turbo 2+. Из заметных улучшений этой версии — ещё более турбо-режим 14 МГц и поддержка до 4 мегабайт ОЗУ, а также много полезных в современном мире мелочей: SD-карта, часы реального времени, поддержка PS/2 клавиатуры, и так далее.
Резюмируя вышесказанное, можно сказать, что существует целая линейка ATM Turbo-совместимых компьютеров, как «классических», родом из 1990-х годов, так и относительно новых, и эти машины обладают некоторыми особенными техническими характеристиками. Как-то: новыми видеорежимами, большим объёмом ОЗУ и более быстрым процессором.
Однако, надо заметить, что хотя у компьютера и появились новые видеорежимы, и более быстрый процессор, графика во всех режимах по-прежнему выводилась чисто программными средствами, как и на классическом ZX Spectrum. Никакого аппаратного ускорения предусмотрено не было, а объёмы данных выросли больше, чем скорость процессора: раньше было 3.5 мегагерц и 6 килобайт, а теперь стало 7 (14) мегагерц и 32 килобайта. Справиться с таким объёмом и получить динамическую графику весьма непросто.
И хотя в былые времена усилиями «МикроАРТ» было создано некоторое количество программ и игр для этих машин, среди которых есть даже умопомрачительно неспешные порты игр «Prince of Persia» и «Goblins» с IBM-совместимых ПК, с EGA-подобной графикой, в целом ситуация с новым ПО была довольно печальной, ввиду (поначалу) не очень широкой распространённости этих компьютеров и довольно высокой сложности их освоения.
Тут-то и пригодился он: Evo SDK.
▍ Путь к Evo SDK
Разработал этот проект я вместе с Дмитрием «Alone Coder» Быстровым, широко известным в узких кругах энтузиастом платформы ZX Spectrum, в 2012 году.
Пришли мы к проекту с двух разных сторон: я — с опытом разработки игр для разных 8-битных и 16-битных платформ с применением компиляторов C, Дмитрий — с опытом работы с графикой ATM Turbo, в том числе разработки нескольких игр, и идеями по максимально быстрому выводу графики.
Разработка игр на C для ZX Spectrum и NES в те годы ещё считалось моветоном: это же расточительная растрата и без того скромных вычислительных ресурсов, как же можно допускать подобную мерзость, и не выжимать всё до последнего такта и байта!
Тем не менее, компиляторы языка C для 8-битных машин существовали с древних времён, и в том числе кросс-компиляторы, работающие на современном ПК. Среди них был z88dk, изначально созданный в конце 90-х годов для весьма редкого портативного компьютера Cambridge Z88 (наследие Sinclair Research), с целью реализации протокола TCP.
В начале 2000-х годов z88dk был адаптирован и для ZX Spectrum, а в 2002-2003 годах для него была разработана библиотека SPLib, сначала первой. а потом и второй версии, позволяющая довольно эффективно выводить небольшие подвижные пиксельные изображения — «спрайты», которые на ZX Spectrum реализуются чисто программной отрисовкой, с преодолением немалого количества сложностей, непосильных для начинающих программистов. Это само по себе открыло некоторые горизонты для создания игр.
Но потребовалась горячая испанская кровь, чтобы решиться обскакать этого скакуна: команда The Mojon Twins. В 2005-2006 годах эти смелые ребята создали свои первые игры для ZX Spectrum, написанные на языке C. За пять лет они успели понаделать около 20 игр, и к 2009 году оформили свои наработки в движок Churrera. С его помощью для ZX Spectrum и самими The Mojon Twins, и прочими энтузиастами, были созданы десятки новых игр — довольно простеньких по содержанию, состоящих из статичных экранов и движущихся по ним спрайтов. И всё же, теперь создание игр стало доступно людям, для которых ассемблер был слишком сложен.
Публика, впрочем, принимала новый подход к разработке для любимой 8-битной платформы в штыки. Игры на движке поначалу получались весьма однообразными, особенно по физике, и ограниченными по содержанию. Зато их было очень много, десятки их.
На это довольно интересное явление в 2010 году обратил внимание и я, и тоже захотел попробовать. Не то чтобы мне не хватало знания ассемблера, но затея показалась перспективной, особенно в области ускорения процесса разработки. Однако, идти проторенным путём мне было неинтересно, и я решил изобрести свой велосипед на основе другого кросс-компилятора, SDCC. Я написал свои процедуры вывода графики и сделал простенький клон Bejeweled — Magic Tokens.
Воодушевившись результатом, я перенёс этот удачный опыт на другую платформу — игровую консоль NES. Там разработка игр на C также считалась блажью, но я видел количественный успех игр The Mojon Twins и верил в успех. Я взял компилятор CC65, поддерживающий процессор 6502 и имеющий рудиментарную поддержку NES, создал библиотеку под уникальным названием neslib, а на её основе — игру Alter Ego.
Вскоре к ней добавилась моя же Zooming Secretary, а также я уговорил The Mojon Twins попробовать освоить новую платформу, и они портировали на NES свою игру Sir Ababol, которая обладала горизонтальной прокруткой уровня и, будучи написанной на C, выглядела серьёзнее многих тогдашних homebrew-игр, написанных на ассемблере. Местная публика это оценила. И тут всё завертелось.
Связка CC65+neslib быстро набрала популярность, и к настоящему времени с её помощью созданы десятки игр (в том числе Денисом Грачёвым), написаны многие туториалы, в том числе и переводные их версии здесь, на Хабре. Это решение зарекомендовало себя как хороший инструмент для разработчиков начального уровня, особенно до появления конструктора игр NES Maker. Вскоре я также сделал аналогичный проект sneslib и для 16-битной Super Nintendo, но из-за местного очень нестабильного компилятора C он остался практически неизвестным, и пользовался им, вероятно, только я сам.
Этот опыт показал мне, что использование компилятора C в связке с простой и понятной библиотекой для работы с графикой — верный путь для наполнения платформы программным обеспечением. Также я понял, какие именно возможности минимально необходимы для создания игр.
В это же время со стороны Рязани мерным шагом приближался Alone Coder. В котомке он нёс идею по максимально быстрому выводу спрайтов в 16-цветном графическом режиме 320x200 на ATM Turbo, ценой неимоверного расхода оперативной памяти.
▍ Устройство Evo SDK
SDK изначально был ориентирован на создание простых игр уровня Churrera, поэтому возможности его весьма специфичны. Дополнительно их окрасил мой опыт работы с игровыми консолями: мы организовали всё по образу и подобию тайлово-спрайтовой графики, типичной для 8-ми и 16-ти битных игровых консолей.
Поддерживается только один графический режим: 320 на 200 в 16 цветах на точку. Графика состоит из фоновых изображений и подвижных спрайтов.
Фоновые изображения разбиваются на «тайлы», блоки размером 8 на 8 пикселей. Работа с изображениями всегда идёт по тайлам: можно выводить их на экран целиком, а можно блоками, состоящими из тайлов. Функции для работы с отдельными пикселями изображения в SDK не предусмотрены.
Вывод тайловых изображений довольно медленный, и перерисовывать элементы фона предполагается нечасто. Зато тайлы очень экономно расходуют ОЗУ: одна точка — четыре бита, один тайл — 32 байта.
В отличие от игровых консолей, тайлов может быть произвольное количество, и их нумерация начинается заново в пределах каждого исходного изображения. Самих таких изображений может быть до 256 штук, а их размер до 2048 на 2048 пикселей (65536 тайлов), но, конечно, на практике он ограничен объёмом ОЗУ.
Поверх фонового изображения выводятся спрайты — маленькие подвижные изображения. Они имеют фиксированный размер 16 на 16 точек, и всего может выводиться до 64 спрайтов. Это связано с тем, что спрайты автоматически восстанавливают фон при перемещении.
Скорость вывода спрайтов зависит от их сложности, а точнее, количества «прозрачных» пикселей, поэтому она может занимать разное время, и все 64 спрайта могут двигаться не так уж и быстро. Но небольшое количество спрайтов, порядка 20, вполне может успевать обновляться за один телевизионный кадр при тактовой частоте 14 МГц.
Количество разных изображений спрайтов теоретически ограничено числом 5376 (из-за размера структуры описателя), но фактически, конечно, объёмом ОЗУ. Формат хранения спрайтов экстремально расточителен. Собственно, такой способ хранения является главной идеей, лежащей в основе графической составляющей SDK.
Дело в том, что для 8-битного Zilog Z80, даже работающего в турбо-режиме 14 МГц, а тем более 7 МГц, вывод спрайтов в 16-цветном видеорежиме 320 на 200 на ATM Turbo — очень непростая задача. И нормальный вывод графики, с чтением точки из источника и записью в приёмник, будет работать довольно медленно.
Дмитрий предложил радикальное решение: графические данные хранятся прямо в коде, в командах загрузки регистров. Конвертор спрайтов генерирует для каждого изображения свой уникальный, максимально оптимальный код вывода, пропускающий «прозрачные» пиксели и учитывающий повторяющиеся коды цвета. Вертикальная точность вывода составляет один пиксель, а горизонтальная — два пикселя, так как экран ATM имеет структуру типа «чанк», два пикселя в байте.
Из-за такого способа вывода в SDK присутствует крайне неприятное ограничение: отсутствие клиппинга. Изображение спрайта не может частично выходить за границу экрана. Это действительно существенный недостаток. Однако, как показала практика, некритичный. Оказалось, что и с таким ограничением можно делать достаточно разнообразные игры, и оно не будет сильно бросаться в глаза. К тому же, это вполне классическая проблема: в играх на NES спрайты часто пропадали целиком при достижении верхней или правой границы экрана, и игроки не особо обращали внимание.
Также к экрану применяется 16-цветная палитра, набираемая из исходной 64-цветной EGA-подобной палитры. В проект импортируется до 256 палитр, и потом специальной функцией может быть выбрана одна из них. Также можно устанавливать нужные цвета программно. Предусмотрена виртуальная «яркость» для плавного гашения и появления изображения на экране.
Важнейшей особенностью SDK является полностью автоматизированная сборка проекта, «в один клик». Нечто подобное было реализовано в SGDK для Sega Genesis, но я традиционно изобрёл собственный аналогичный велосипед.
Идея заключается в том, что все ресурсы игры хранятся в легко редактируемом на ПК формате — графика в 16-цветных BMP файлах, музыка в файлах формата PT3, для которого есть редакторы на ПК, а звуковые эффекты — в формате AFB, который поддерживает уже существовавшая на тот момент утилита AYFX Editor (моего авторства) для создания соответствующих эффектов. В момент сборки проекта все ресурсы преобразуются в нужный вид.
Мы не стали изобретать свой собственный скрипт, и даже не стали пытаться прикручивать make, а просто использовали стандартные BAT-файлы Windows. Решение, конечно, не кросс-платформенное, зато быстро реализуемое и понятное для пользователей этой ОС.
В скрипте сборки перечисляются все ресурсы, после чего вызывается основной скрипт компиляции:
@echo off
rem имя SCL файла
set output=sprites.scl
rem сообщение, которое отображается при загрузке
rem 32 символа, стандартный шрифт
set title=" SPRITES DEMO"
rem список изображений, откуда брать палитры
rem в программе они вызываются по автоматически генерируемым
rem идентификаторам в файле resources.h
rem нумерация после точки должна быть возрастающей
set palette.0=back.bmp
set palette.1=balls.bmp
rem список изображений, откуда брать графику
set image.0=back.bmp
rem спрайты
set sprite.0=balls.bmp
rem набор звуковых эффектов, если нужен
rem он может быть только один
set soundfx=
rem музыка, нужное число треков
set music.0=
call ..\evosdk\_compile.bat
@if %error% ==0 ..\evosdk\tools\unreal_evo\emullvd %output%Исходный код игры пишется на вполне нормальном классическом ANSI C. Библиотека Evo SDK состоит из единственного подключаемого файла evo.h, в котором объявлена пара десятков необходимых функций. Редактировать исходник предлагается в своём любимом блокноте. IDE и средства отладки не предусмотрены. А что вы хотели — у нас тут ретро!
Помимо функций вывода графики и проигрывания музыки, в SDK предусмотрен опрос управления в виде джойстика, стрелок и 40 кнопок стандартной клавиатуры. Стандартные библиотеки C отсутствуют, но есть упрощённые реализации memset и memcpy, а также 16-битный rand. Память должна всегда выделяться статически.
Данные спрайтов, тайлов, музыки и прочие ресурсы хранятся в расширенном ОЗУ объёмом 4 мегабайта. Для кода игры предусмотрена линейная область объёмом около 55 килобайт. Как показала практика, это довольно сильное ограничение — скомпилированный код имеет довольно большой размер. Но для игр всё же хватает.
Вся игра загружается с дискеты в ОЗУ целиком и не содержит подгрузок. Дело в том, что объём ОЗУ превышает объём дискеты, и таким образом просто нечего и незачем подгружать (думали мы). Впоследствии подгрузку данных с дискеты пришлось всё же добавить. Также энтузиасты добавили поддержку музыки для FM-синтезатора дополнительной звуковой платы TurboSound FM, со звучанием «как на Сеге».
//этот пример отображает движущиеся спрайты на фоне изображения
#include <evo.h>
#include "resources.h"
//структура объекта
struct spriteStruct {
i16 x,y; //координаты
i16 dx,dy; //дельты скорости
};
//список объектов
#define SPRITES_ALL 22 //в этом примере столько спрайтов успевает отрисоваться за кадр
struct spriteStruct spriteList[SPRITES_ALL];
void main(void)
{
static u8 i;
static u8 palette[16];
//чёрный экран на время подготовки
pal_bright(BRIGHT_MIN);
//инициализация параметров объектов
for(i=0;i<SPRITES_ALL;++i)
{
spriteList[i].x=1+rand16()%(160-8-2);
spriteList[i].y=1+rand16()%(200-16-2);
spriteList[i].dx=rand16()&1?-1:1;
spriteList[i].dy=rand16()&1?-1:1;
}
//вывод фона на теневой экран
draw_image(0,0,IMG_BACK);
//переключение экранов, теперь фон на видимом экране
swap_screen();
//запуск спрайтов
sprites_start();
//установка палитры, она собирается из двух разных палитр
//цвета 0..5 для фона, цвета 6..15 для спрайтов
pal_copy(PAL_BACK,palette);
for(i=0;i<6;++i) pal_col(i,palette[i]);
pal_copy(PAL_BALLS,palette);
for(i=6;i<16;++i) pal_col(i,palette[i]);
//установка нормальной яркости
pal_bright(BRIGHT_MID);
//главный цикл
while(1)
{
//перемещение объектов и заполнение списка спрайтов
for(i=0;i<SPRITES_ALL;++i)
{
//i&3 выбирает один из четырёх разноцветных шариков
set_sprite(i,spriteList[i].x,spriteList[i].y,i&3);
if(spriteList[i].x==160-8 ||spriteList[i].x==0) spriteList[i].dx=-spriteList[i].dx;
if(spriteList[i].y==200-16||spriteList[i].y==0) spriteList[i].dy=-spriteList[i].dy;
spriteList[i].x+=spriteList[i].dx;
spriteList[i].y+=spriteList[i].dy;
}
//обновление экрана, спрайты выводятся автоматически
swap_screen();
}
}В качестве компилятора C я применил уже знакомый мне SDCC. Это оказался спорный выбор, и он подбросил немало проблем.
Дело в том, что это открытый проект, и на момент реализации Evo SDK он находился в переходном состоянии, от одного способа компиляции и оптимизации к другому. Оказалось, что старая версия выдаёт не очень хороший код, но зато быстро собирает исходник, и код просто работает (или кончается память, тогда не работает). Новая же версия могла собирать исходник на пару тысяч строк десять минут, и хотя код получался оптимальнее, он мог по случайным причинам не работать вовсе. Простая замена версий была невозможна, так как изменился синтаксис и наименования компонентов компилятора. Пришлось оставить в SDK старую версию компилятора.
Хотя в SDCC предусмотрен собственный кросс-ассемблер Z80, он имеет нестандартный синтаксис и довольно неудобен в использовании. Поэтому в дополнение к нему был задействован более продвинутый кросс-ассемблер SjAsmPlus. С его помощью собираются исходники самого SDK. Для упаковки загружаемых с дискеты данных также применяется компрессор MegaLZ.
Поддержка ATM и Evo имеет отличия в низкоуровневом коде и требует отдельной сборки проекта под каждую из платформ. Модификаций исходного кода самих игр при этом не требуется.
▍ Результаты
Хотя возможности SDK получились весьма небогатыми, тем не менее, они позволили осуществиться ряду проектов разной степени интересности. Перечислю несколько. Большинство из них, правда, принадлежат курсору одного разработчика под псевдонимом Hippiman.
Для начала, это тестовая игра, разработанная мной специально для проверки возможностей SDK — простой вариант игры Xonix (Qix). Я думаю, многие помнят игру под названием SeXoniX для MS-DOS. Вот и тут примерно то же самое. Только киски тут натуральные.
Далее следует квест-приключение Innsmouth, по мотивам произведения «Мгла над Инсмутом» Говарда нашего Лавкрафта.
Стрелялка NOMAD, напоминающая уровни на джет-байке из игры Contra Hard Corps для Sega Mega Drive. Пожалуй, показывает предел динамичности действия, достижимого средствами Evo SDK.
И, наконец, другая крайность: пошаговая псевдотрёхмерная ролевая игра SpaceMerc: Liberation в стиле Eye of Beholder и жанре научной фантастики.
▍ Заключение
Evo SDK смог выполнить поставленную задачу и позволить появиться некоторому количеству новых игр. Однако он показал и пределы возможностей Z80, работающего на частоте до 14 МГц, которому приходится врукопашную перекладывать немало килобайт графических данных.
Так сложилось, что потенциал аппаратной части платформы ZX Evolution вскоре раскрыл другой, сторонний проект, меняющий саму её сущность, добавляющий аппаратные спрайты и другие мощные возможности. Не буду сейчас называть эти сакральные буквы, но, возможно, однажды я расскажу и про эту спорную грань эволюции Спектрума. Возможно. Угрожаю? Возможно, да.
© 2025 ООО «МТ ФИНАНС»
Telegram-канал со скидками, розыгрышами призов и новостями IT 💻
