Эта статья посвящена путешествию в мир ретропрограммирования. Надеюсь, в ней у меня получится передать вам то чувство восхищения, которое я испытал и которое заставило меня написать этот пост. Пост о том, как создавать ПО для компьютерной системы Atari ST, выпущенной в 1985 году.

Atari ST относится ко второй крупной волне домашних компьютеров. Первая волна, созданная на основе 8-битных CPU, принесла в наши дома такие знаковые машины, как Commodore C64 и Sinclair Spectrum. Вторую волну разрабатывали на основе 16-битных CPU; она породила Apple Macintosh, Commodore Amiga и, разумеется, Atari ST.

Типичный Atari ST (например, 1040 STFM) имел CPU Motorola 68000 с тактовой частотой 8 МГц и 1 МБ ОЗУ; он загружал ПО с 3,5-дюймовых гибких дисков. Его графические возможности состояли из монохромного режима высокого разрешения 640x400 и 16-цветного режима 320x200, получившего наибольшую популярность в играх.

Если у вас нет реального Atari ST, то его можно просто эмулировать на современном компьютере. Первые эмуляторы появились ещё в 90-х. Хорошим считается Hatari, который существует для большинства современных платформ. В эмуляторе также есть современные инструменты разработки. В прошлом приходилось пользоваться неуклюжим ПО разработки, которое загружалось с дискет, а сегодня можно просто писать всё в VSCode и компилировать современным GCC. У нас есть доступ к современным графическим редакторам наподобие GIMP, и мы даже можем просить помощи у ИИ.

Hello World

Звучит ли привлекательно для вас? Давайте сделаем наши первые шаги в чудесный мир ретрокомпьютеров: откроем текстовый редактор и напишем знаменитую Hello World (hello.c):

#include <stdio.h>

int main() {
  printf("Hello, world!\n");
  return 0;
}

Для компиляции нам нужен компилятор C. К счастью, существует проект по поддержке актуального тулчейна GNU. На сайте Crossmint Торстена Отто можно скачать скомпилированные двоичные файлы для всех крупных платформ (в том числе и для самой Atari ST, но я этого не рекомендую). Для компиляции hello.c понадобятся GCC и binutils:

m68k-atari-mint-gcc hello.c -o hello.prg

Вот и всё, мы скомпилировали Hello World для 16-битного CPU.

Что такого особенного в программировании для Atari ST?

Больше всего я ценю в программировании для Atari ST его простоту. Процессор Motorola 68000 часто называют 16-битным процессором, но может предложить не только это. У него есть набор из шестнадцати 32-битных регистров, он поддерживает плоскую 32-битную адресацию и арифметические операции, хоть производительность их и чуть меньше, чем у 16-битных операций. Это резко контрастирует с платформой PC того времени, ограниченной небольшим набором 16-битных регистров Intel 8086 и сегментированной моделью памяти, сильно усложнявшими программирование. По сравнению с языком ассемблера PC язык M68K был довольно изящным и дружественным для пользователя.

У системы нет виртуальной памяти и отсутствует защита памяти. Доступ к основной части оборудования выполняется через ввод-вывод с отображением в память, что позволяет любой программе напрямую обращаться к регистрам аппаратных компонентов. Такой прямой доступ становится особенно ценным при работе с графикой и звуком. Кроме того, у машины нет отдельной видеопамяти. Хоть и существует API для аппаратно-независимых графических операций, разработчики при желании могут выполнять запись непосредственно в видеопамять.

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

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

Приключения с VoxelSpace

Я амбициозно решил начать с игры, в которую впервые играл на PC примерно в 1993 году. Comanche: Maximum Overkill — это аркадный симулятор-боевик про вертолёт; игра завоевала место в истории в основном благодаря одному аспекту: в то время симуляторы полёта рендерили рельеф и объекты очень абстрактно, при помощи полигонов с плоским затенением, а Comanche обеспечила невиданную ранее картинку. Внезапно в игре появились плавные холмы, узкие каньоны, высокие горы и извилистые реки. И всё это благодаря алгоритму VoxelSpace.

Comanche стала веским аргументом для покупки мощных PC (в то время они в основном состояли из процессора Intel 486 и 4–8 МБ ОЗУ). Время скромных систем наподобие Atari ST и её более мощного конкурента Commodore Amiga закончилось и больше не вернулось. Comanche ни за что бы ни запустилась на этих машинах, и ни одна игра на них не могла даже приблизиться к ней.

Однажды в 2024 году у меня возникла безумная идея: реализовать VoxelSpace на Atari ST. Это была ужасная мысль, а они зачастую оказываются лучшими.

Я нашёл данные рельефа и текстур Comanche в удобном формате (на превосходной странице GitHub Себастьяна Маке). Для работы с данными их всё равно нужно было немного модифицировать. Я создал собственный инструментарий на основе графического редактора GIMP и его скриптового языка Script-Fu. При помощи компилятора Crossmint GCC я написал небольшое демо для ST, которое загружало данные рельефа в память и выводило их на экран. Это выглядело так:

Разумеется, всё работало медленно, зато красиво смотрелось. Я даже опубликовал видео в Twitter и получил восхищённые отзывы. Я продолжал работу над оптимизацией, в итоге получив результат, работающий на вполне приемлемых для игры скоростях. Если бы эту игру выпустили в 1990 году, то она многих свела бы с ума.

Графика на Atari ST

Но как я этого добился? Как вообще выполнять отрисовку экрана на Atari ST? Оказалось, достаточно просто записывать данные в ту часть ОЗУ, которая используется в качестве видеопамяти. Всё просто, правда? На самом деле, это кажется простым, но, как это часто бывает с ретрокомпьютерами, в процессе обнаруживаются разные тонкости. Пришло время для фольклора 16-битных платформ (осторожно, технические подробности!).

Помните, я говорил, что Atari ST с разрешением 320x200 отрисовывала 16-цветов? Для записи 16 цветов нужно 4 бита, так? Но тут возникает одна проблема: наименьшая адресуемая единица в компьютере — это байт, который, как известно, состоит из 8 бит. Поэтому есть два логичных способа сопоставления пикселей с байтами:

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

2. Засунуть в один байт два пикселя. При этом память не тратится впустую, но образуется дополнительный оверхед при отрисовке отдельных пикселей.

К сожалению, разработчики оборудования Atari выбрали поистине безумный вариант 3: они использовали чередующиеся битовые плоскости.

Чтобы понять, что такое битовая плоскость, нужно разложить пиксели на биты и сгруппировать соответствующие биты соседних пикселей. Например, возьмём бит 0 из пикселя 0, пикселя 1, пикселя 2 и так далее. На каждый пиксель используется по четыре бита, поэтому есть четыре отдельных карты для битов (именно отсюда взялся термин «битовая карта», bitmap). Каждая карта описывает позицию одного бита для всех пикселей. Удобно визуализировать эти карты наложенными друг на друга, поэтому их и назвали битовыми плоскостями.

Чтобы ещё больше осложнить ситуацию, разработчики Atari придумали идею чередующихся битовых плоскостей, упрощавшую реализацию графического оборудования. Чередование устроено так: каждая группа из 16 соседних по горизонтали пикселей закодирована в 8 байт следующим образом:

• Байты 0 и 1 содержат 16 бит битовой плоскости 0.

• Байты 2 и 3 содержат 16 бит битовой плоскости 1.

• Байты 4 и 5 содержат 16 бит битовой плоскости 2.

• Байты 6 и 7 содержат 16 бит битовой плоскости 3.

То есть каждые 8 байт кодируют участок из 16 пикселей. Строка экрана имеет ширину 320 пикселей, поэтому для её кодирования нужно 160 байт. Линий на экране 200, поэтому весь экран занимает ровно 160*200 = 32000 байт. Зачем группировать по 16 пикселей, а не по восемь? Потому что ST — 16-битная машина и имеет шину данных шириной 16 бит, поэтому в общем случае предпочтительны 16-битные слова, а не 8-битные байты. Однако это усложняет программирование графики для этой платформы.

Переходим к языку ассемблера

При программировании для ретросистемы наподобие Atari ST с её 8-мегагерцовым процессором (смехотворно медленным по современным стандартам) крайне важна эффективность. Хоть GNU C Compiler генерирует достаточно оптимизированный код, очень помогает внимательное наблюдение за создаваемым ассемблерным кодом. Приступая к проекту VoxelSpace, я уже немного знал язык ассемблера 68000, но узнал о нём гораздо больше, анализируя сгенерированный компилятором код и совершенствуя код на C для обеспечения более качественных результатов компилятора. Поначалу ассемблерный код читать непросто, но, как это часто и бывает, со временем я освоился.

При изучении Computer Science студентам говорят об опасностях преждевременной оптимизации. Сначала нужно сосредоточиться на совершенствовании алгоритмов, обеспечивающих так называемую асимптотическую сложность, выражаемую в знаменитом большом «О». Допустим, алгоритм, имеющий O(N), лучше, чем алгоритм с O(N²). Однако алгоритм VoxelSpace почти не поддаётся асимптотическому анализу. Он уже ограничен O(N), где N — это количество сэмплов рельефа в каждом кадре, и это фиксированное число, которое можно подбирать под свои требования.

Теперь пришло время оптимизации на уровне ассемблерного кода. По сути, она реализуется двумя способами:

• Изучением сгенерированного компилятором ассемблерного кода. При компиляции с опцией -fverbose-asm мы получаем ассемблерный код с построчными комментариями, объясняющими, каким переменным C соответствует конкретный регистр.

• Встраиванием ассемблерного кода в код на C. Проще всего это делать при помощи функции встраивания GCC.

За пару недель мне удалось увеличить скорость моего демо VoxelSpace, по крайней мере, на один порядок. Благодаря экспериментам и исследованиям я изучил множество приёмов оптимизации. Вот лишь некоторые из них:

• Нужно сконцентрироваться на внутренних циклах. Профилировать как можно качественней. Анализировать сгенерированный ассемблерный код. Не доверять компилятору!

• Упрощать арифметику. Любой ценой избегать умножения и деления.

• Использовать таблицы поиска. Доступ к памяти на старых CPU относительно быстр, а кэши появились только на более поздних CPU (сегодня ситуация сильно отличается).

• Избегать операций битового сдвига. В первой версии Motorola 68000 использовалась их неоптимизированная версия, из-за чего сдвиг на большие величины был более затратным, чем сдвиг на несколько позиций. Сдвиг влево на один или два бита можно заменить сложением.

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

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

• Использовать «SIMD для бедных»: при помощи 32-битных регистров выполнять одновременно два 16-битных сложения. Это оказывается очень удобно при выполнении векторной арифметики, когда допустимо снижение точности.

• Использовать 16-битные целые числа. Хотя процессор Motorola 68000 вполне способен выполнять арифметику с 32-битными регистрами, работа с 16-битными вариантами команд наподобие add, asl и eor может позволить сэкономить пару тактов в сверхкомпактных циклах.

Современный инструментарий

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

Начинается всё с интегрированной среды разработки (Integrated Development Environment, IDE). Я рекомендую использовать Visual Studio Code и расширение C/C++ Microsoft, которое можно легко сконфигурировать для использования кросс-компилятора.

Сообщество любителей ретрокомпьютеров приложило много усилий к поддержке ветви GNU Compiler Collection (gcc). Его порты стали частью FreeMiNT — большого проекта по реализации операционной системы в стиле UNIX для компьютеров Atari. Однако сгенерированные файлы программ работают и в операционной системе TOS Atari ST. Я рекомендую пользоваться сборками на странице m68k-atari-mint cross-tools Торстена Отто. В них есть актуальные версии GCC (на момент написания моей статьи самой последней версией была gcc 15.2.0). Также вам понадобится сборка GNU binutils, содержащая ассемблер и компоновщик.

Для запуска ПО Atari ST удобнее всего использовать эмуляторы. Разумеется, можно запускать его и на реальном оборудовании, но эмуляторы сильно упрощают жизнь, особенно при разработке и отладке. Чаще всего я пользуюсь Hatari, имеющим версии для Windows, Mac OS и Linux.

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

Изначально обречённый на DOOM

Я загнал сам себя в ловушку, когда спросил в X, нужно ли портировать на платформу Atari ST игру DOOM. Вопрос не возник из ниоткуда, у меня уже давно была такая мысль. Почему бы не применить знания, полученные при создании демо VoxelSpace, к портированию на платформу Atari ST игры, которую ещё никто на неё не портировал?

Требования к такому проекту были следующими:

• Игра должна относиться к той эпохе, когда ещё не были распространены 3D-ускорители, а графика высокого разрешения не стала стандартом.

• Она должна требовать не больше 4 МБ ОЗУ.

• Должен быть доступен весь её исходный код, написанный на C или C++.

• Игровые ресурсы должны быть юридически свободно доступны.

По всем этим пунктам подходил DOOM, выпущенный в 1993 году. Изначально игру писали для IBM-совместимых PC с 256-цветной VGA-графикой и разрешением 320x200. Известно, что эта игра выжимала максимум из потребительских PC, в которых на то время были установлены Intel CPU класса 80486 с частотой от 25 МГц и выше, поэтому для портирования DOOM на маломощный домашний компьютер 1980-х требовалась большая гордыня. Было очевидно, что придётся пойти на серьёзные уступки, но в этом тоже заключалось своё удовольствие.

Исходный код DOOM был опубликован в 1999 году на условиях GNU Public License (GPL), поэтому кто угодно может пользоваться им при условии, что выпустит свою работу под той же лицензией.

После скачивания исходников DOOM с GitHub я открыл Visual Studio Code и адаптировал Makefile под работу со своим кросс-компилятором. К моему удивлению, выполнив make, я сразу же скомпилировал большинство файлов. Компилятор жаловался только в тех местах, где код был сильнее привязан к операционной системе:

• i_video.c: в этом файле подготавливается экран. Так как опенсорсный релиз DOOM основан на linuxdoom, в нём для этого используется API оконной системы X. Оттуда же берутся события мыши и клавиатуры.

• i_sound.c: здесь открывается звуковая система на основе Linux Open Sound System для воспроизведения звуковых эффектов.

• i_net.c: здесь реализован сетевой код многопользовательской игры на основе UDP.

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

При помощи функций отладки эмулятора Hatari мне удалось найти конкретные части исходного кода, требовавшие исправления. Одной из них была функция для измерения времени (функцию можно было заменить на нативный счётчик, инкремент которого TOS выполняла 200 раз в секунду). Ещё одна заключалась в доступе к памяти без выравнивания по словам, которое требовалось Motorola 68000. В ещё одном фрагменте блок памяти резервировался для подпрограммы распределения внутренней памяти DOOM; для того, чтобы уместиться в ограниченную ОЗУ ST, объём памяти пришлось снизить с 6 МБ до 4 МБ.

Как можно догадаться, запуск DOOM без графики не очень впечатляет, поэтому я сразу принялся за её реализацию. К счастью, DOOM рендерит всю графику во внутренний буфер размером 64000 байт, хранящий 320x200 пикселей. В этом буфере каждый байт соответствует одному пикселю. Цвет этого пикселя определяется палитрой из 256 цветов, каждый из которых соответствует конкретному сочетанию красного, зелёного и синего компонентов. То есть задача заключалась в преобразовании внутреннего видеобуфера DOOM в видеопамять Atari ST, которая, как объяснялось выше, состоит из 32000 байт, упорядоченных совершенно иным образом.

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

Я с гордостью опубликовал результат в X; положительные отзывы мотивировали меня двигаться дальше. Сначала я хотел перейти от оттенков серого к отображению цветов. Я решил выбрать 16 цветов из 256-цветной палитры DOOM, а затем аппроксимировать оставшиеся 240 смешением цветов. Методика под названием «дизеринг Байера» создаёт иллюзию многоцветности благодаря смешению ограниченного набора цветов в периодическом паттерне. Потратив на это несколько вечеров, я создал прототип.

На какое-то время STDOOM (это название я выбрал, особо не задумываясь) стал Интернет-знаменитостью. О нём опубликовали статьи на Tom’s Hardware и Hackaday, разные пользователи Youtube демонстрировали эту неожиданную новинку. Учитывая то, что в этот порт было вложено относительно мало труда, это стало для меня огромной мотивацией к дальнейшей работе.

В течение последующих недель в STDOOM появилось большинство функций, ожидаемых пользователями: работа с клавиатурой и мышью, сильное увеличение скорости, поддержка звуковых эффектов и музыки. Особенно я горжусь тем, что в конечном итоге реализовал поддержку всех нативных цветовых разрешений ST, в том числе знаменитый монохромный, благодаря чему игра стала одной из самых гибких на этой платформе. Поддержка чуть более быстрых платформ, например, мало прожившего потомка Atari ST под названием Atari TT, обеспечила работу DOOM с приемлемой частотой кадров, а для более слабых Atari я добавил режимы с половинным и четверным разрешением.

Единственный бенчмарк, которому я доверял

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

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

В HeadlessDoom используется популярное прохождение «DOOM Done Quick», в котором в реальном времени 32 уровня проходятся за 20 минут. Для этого нужно суммарно отрендерить 56111 кадров; это происходит в ОЗУ, поэтому графика не отображается на экране. Современные компьютеры выполняют этот бенчмарк за несколько секунд, что мне кажется впечатляющим результатом.

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

Чему я научился

При работе над Voxel-ST и STDOOM я потратил несколько вечеров на оптимизацию ассемблерного кода и добавление новых фич. Подобную мотивацию сложно получить в повседневной работе. Этот энтузиазм не только сильно порадовал меня, но и позволил кое-чему научиться. Вот к каким выводам я пришёл:

• Легаси-разработка тоже может ощущаться современной. Работа на старых системах — это не просто ностальгия, она учит современному инструментарию и надёжному проектированию в условиях строгих ограничений. Выбирайте любимую IDE, самый современный компилятор и пользуйтесь преимуществами профилирования и интроспекции. Да, не всё будет ощущаться современным, но отдельные аспекты определённо находятся на совершенно ином уровне.

• Язык ассемблера учит нас аппаратным ограничениям. Если вы давно мечтали писать код на языке ассемблера, то, к счастью, набор команд Motorola 68000 крайне прост в освоении. Вскоре после начала освоения вы уже будете оптимизировать сжатые циклы и чётко поймёте возможности и ограничения оборудования.

• Реально реальное время. Такие задачи, как обработка аудио, не могут ждать. Изучение прерываний и написание собственных обработчиков необходимо, а если что-то пойдёт не так, вы сразу это услышите (например, в виде ужасного шума).

• Сильное сообщество. У легаси-платформ по-прежнему есть активные базы фанатов, поддерживающие их существование. Вы получите со стороны этих людей сильную мотивацию, а вашу работу признают произведением искусства.

• Не надо бояться задавать вопросы. Есть места наподобие Atari-Forum, в которых множество профессионалов с радостью предложит свою помощь, советы и идеи. Там же вы освоите новые навыки и познакомитесь с легендарными людьми платформы.

Ресурсы

• Мои посты в X/Twitter про Atari.

• STDOOM в GitHub: исходный код и двоичные файлы.

• Voxel-ST в GitHub: исходный код и двоичные файлы.

• Atari-Forum: отличное место для поиска помощи и связи с сообществом.

• Коллекция GCC и других инструментов Торстена Отто для разработки ПО Atari ST.

• Туториал по алгоритму VoxelSpace Себастьяна Маке. Также там есть настоящие карты из симулятора полёта Comanche: Maximum Overkill.

• Кросс-платформенный эмулятор Atari ST Hatari.

• Документация TOS (операционной системы Atari ST).

• Atari Profibuch — цифровая версия легендарного справочника на немецком, доступная для свободного скачивания.

• Headless DOOM в GitHub: DOOM как бенчмарк.

• Happy 40th Birthday, Atari ST! Интерактивное трёхмерное веб-демо с участием STDOOM.