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

Что за демка и где её искать?

Данную демку нашёл в этом гит репозитории: TreeOS: a 16-bit bootsector Christmas tree demo.
Как гласит название:

Добро пожаловать в TreeOS (древесную операционную систему)! Это очень простая, хакерская, но работающая демка, которая рисует крутящуюся новогоднюю рождественскую ёлку и выдаёт небольшое сообщение. При этом работает на голом аппаратном обеспечении персонального компьютера, без операционной системы, используя только стандартное VGA-оборудование. С Новым Годом Рождеством.

Забегая вперёд скажу, что там две версии: с надписью и без (как в картинке на заходнике). Демка это образ загрузочный дискеты. Написана она 16-ти битным кодом, который использует BIOS для загрузки с диска и изменяет видеорежим перед работой непосредственно с буфером кадра VGA. В коде используется стандартный 256-цветный режим 320х200 (режим VGA 13h). По идее это должно работать на любом персональном компьютере, но тестировалось только на виртуальной машине (в Quemu). Лично я протестировал, что она отлично работает и в VirtualBox. Ниже я расскажу, как её запустить.

Пробуем запустить

Ну как обычно, прежде чем посмотреть код, насладиться его работой, так сказать пошуршать мозгами, сразу запустим? Конечно же да!
Поехали!

Для старта нам понадобиться компилятор nasm, виртуальная машина quemu или VirtualBox, кому что милее. Лично я решил попробовать и там и там. Потому ставим всё вместе:

sudo apt install nasm qemu-system-x86

Клонируем репозиторий, переходим в него и пробуем собрать пример.

git clone https://github.com/cfallin/treeoscd treeos/make qemu

И И счастье не настало, хотя было так близко.

nasm -fbin -o treeos.img treeos.asmtreeos.asm:15: error: attempt to define a local label before any non-local labelstreeos.asm:47: error: attempt to define a local label before any non-local labelstreeos.asm:52: error: attempt to define a local label before any non-local labelstreeos.asm:60: error: attempt to define a local label before any non-local labelstreeos.asm:65: error: attempt to define a local label before any non-local labelsMakefile:5: ошибка выполнения рецепта для цели treeos.imgmake: *** [treeos.img] Ошибка 1

Пришлось расчехлить гугл, и вспомнить в чём же проблема. А проблема оказалась очень простая. Автор использовал метки с точкой, а компилятору это не нравилось. После того, как я поправил все метки, убрав из них точки, всё получилось.
Например:

...    jmp 0:.newseg.newseg:    mov ax, 0...

изменил на

...    jmp 0:newsegnewseg:    mov ax, 0...

Компиляция тоже идёт достаточно интересно. Не буду приводить Makefile, его каждый может посмотреть самостоятельно. Более интересно как идёт создание образа флоппи диска:

make qemunasm -fbin -o treeos.img treeos.asmrm -f floppy.imgdd if=/dev/zero of=floppy.img bs=1024 count=14401440+0 записей получено1440+0 записей отправлено1474560 байт (1,5 MB, 1,4 MiB) скопирован, 0,00373289 s, 395 MB/sdd if=treeos.img of=floppy.img conv=notrunc3+1 записей получено3+1 записей отправлено1998 байт (2,0 kB, 2,0 KiB) скопирован, 0,000193295 s, 10,3 MB/sqemu-system-x86_64 -fda floppy.img

Как видно, идёт компиляция ассемблеровского файла.
Затем идёт удаление возможного старого образа флоппи диска.
Команда dd создаёт чистый образ дискетки, после чего в начало записывается готовый бинарник ёлочки.
Ну и последняя команда запускает виртуальную машину quemu с этим образом. В результате получим вот такую замечательную демку.


В реальности не так сильно тормозит, как гифка.

Что делать, если сижу под Windows, а посмотреть демку хочется?

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





После чего, скармливаем ему готовый образ TreeOS и наслаждаемся новогодним настроением.


Ёлка на VirtualBox.

Если очень хочется в живую запустить?

Зазгрузка с флешки

Как я уже сказал, идеально записать образ на флопи-диск. Но если его нет, можно записать на флешку. Для начала стираем флешку, забивая её нулями.

dd if=/dev/zero of=/dev/sdx

После этого копируем образ TreeOS в начальный бутсектор диска.

dd if=/mountedlocation/treeosFloppy.img of=/dev/sdx bs=512 count=4

Затем, используя утилиту CFDISK c помощью командной строки, помечаем сектор MBR как загрузочный сектор тип 0c FAT32.

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

Загрузка с жёсткого диска

Есть два пути загрузки с жёсткого диска. Первый путь, это подготовить его точно так же, как мы делали флешку, но тогда все данные на жёстком диске будут уничтожены.
Есть альтернатива этому решению. Копируем файл treeosFloppy.img в корень NTFS раздела: c:\treeos.mbr.
После этого настраиваем Windows BOOTMGR и/или NTLDR чтобы TreeOS было помещено в загрузочное меню Windows вместе с самой Windows.
В результате при загрузке можно будет выбирать что загружать, Windows или эту микроОС.

Точно так же можно настроить и GRUB.

Пару слов об ассемблере

Буду честен, в х86 ассемблере слаб. Но всё же крупными штрихами постараюсь описать то что происходит. Гуру ассемблера могут справедливо меня поправить в комментариях. Прошу не бить сильно, и не пинать. Разберём свежую (последний коммит был пять дней назад) 512 байтовую версию.



Запрещаем прерывания и очищаем регистры. Инициализируем указатель стека. Разрешаем прерывания.



Очищаем экран, записывая чёрные пробелы на экран. Поясняю, что можно иметь цвет фона и текста.



Здесь идёт инициализация системного таймера.



Здесь мы переходим с помощью 13-прерывания BIOS в VGA-режим.. Код 0x13 соответствует разрешению 320x200 и 256 цветовой палитре.



После чего попадаем в глобальный цикл. Где мы получаем текущий тик системного таймера в регистр BX и очищаем буфер картинки для следующего фрейма.

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



И ниже пошёл ассемблер работы с плавающей точкой. Там в памяти рассчитывается и формируется новый фрейм ёлки.
Обратите внимание на операцию сравнения регистра cx c 1000 и если он равен, то мы переходим на метку treedone. Гланем, что же на этой метке.



Итак, в clipped мы инкрементируем регистр cx и джампимся опять в цикл расчёта ёлки. В treedone мы копируем буфер получившейся ёлки в реальный фреймбуффер видеокарты с помощью магической инструкции rep movsw (чесслово только узнал о ней).



Тут не самое элегантное место, мы просто тупо крутимся в цикле, пока счётчик таймера у нас не изменится.



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



В самом низу у нас находятся вспомогательные расчётные константы (я не стал все приводить сюда).

В версии от 2019 года, есть ещё дополнительная надпись. Она задана константно и выводится с помощью кода:



А сама надпись представляет собой просто изображение, скрытое в бинарных константах.



Не буду приводить всё, и так понятно.

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

С Наступающим Новым Годом!!!

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


Рождественская демка под ДОС 1986 г.

Демосцена разновидность творчества на стыке компьютерной графики, музыки и, собственно, программирования, а также сложившаяся вокруг него субкультура. Первые демоэксперименты относятся к 1980-м времени, когда в Европе и США появилось достаточное количество домашних компьютеров, обладатели которых стремились заставить машину выполнять несвойственные ей задачи. Обычно это были короткие интро к взломанным компьютерным играм, созданные на Commodore 64, Amiga, ZX Spectrum. Расцвет демосцены пришелся на 1990-е, тогда же она пришла и в Россию.

Пётр Соболев, также известный как frog, один из организаторов компьютерного фестиваля ENLiGHT первой в России демопати. В первой части интервью музейному проекту DataArt он вспоминает компьютеры 1980-х и рассказывает, как в нашей стране появились первые интро и демо.

Начало

Я родился в Ленинграде в 1973-м. Мать и отец были инженерами-конструкторами в оборонке. В детстве я увлекался всякими железками, что-то паял по мелочи какие-то простые схемы. Семья никакого отношения к вычислительной технике не имела, но в середине 1980-х в СССР возникла идея, что надо форсировать все, что связано с ЭВМ, и внедрять на производстве. У отца на заводе тоже стали этим заниматься. Закупили ЭВМ Искра 226 аналог Wang 2200, что-то среднее между домашней и профессиональной машиной. Она на микропроцессорных секциях собрана, такая специфическая архитектура, не похожая ни на что, в качестве основного языка там был Бейсик. Отец стал в этом участвовать, потому что на заводе в вычислительной технике никто не разбирался и любой, кто проявлял инициативу, мог взяться за это дело.


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

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


Справочное руководство для специалистов и всех желающих использовать в своей деятельности возможности программно-управляемых ЭВМ, 1988 г.

Помню, в середине 80-х отец принес домой здоровенную распечатку по R-Base. Тогда это была достаточно популярная СУБД. В какой-то момент он позвал меня на завод, посмотреть на компьютеры. Но я интереса не проявил.

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

Недокументированные возможности

Следующим этапом моего знакомства с вычислительной техникой стали микрокалькуляторы. Шел где-то 1986-й год. Мне купили МК-54. Базовых программируемых калькуляторов в середине 80-х в СССР было два Б3-21 и Б3-34. На тот момент ни тот, ни другой уже не продавался. МК-54, что мы купили, был совместим с Б3-34.


Демонстрация работы программируемого микрокалькулятора Электроника МК-54

Надо сказать, что у Б3-21 и Б3-34 разные системы команд, разная архитектура, а все книжки, которые мне попадались, были, к сожалению, про Б3-21. Это стало большой проблемой, потому что программирование для калькуляторов было, по сути, в машинных кодах. Ты некие значки вводишь, получается программа длиной, допустим, 100 команд. Она какие-то расчеты производила, или можно было сделать простую игру типа крестиков-ноликов, где тебе выдается номер поля, в которое ты мысленно или прямо на бумаге ставишь крестик, а в какое нолик. Всё очень примитивно. Индикатор цифровой, никаких букв. Ну и никакой интерактивности в процессе работы программы.

В 1986-1987 гг. в журнале Техника молодежи начала публиковаться серия рассказов Михаила Пухова смесь научной фантастики и программ для калькулятора, чтобы читатель мог сам что-то запустить и попробовать. К примеру, посадка на Луну: вводишь цифрами тягу, направление, нажимаешь пуск, калькулятор считает и показывает, сколько осталось до поверхности. Сейчас это звучит смешно, а тогда было очень необычно и интересно.


Коллекционер и историк вычислительной техники Сергей Фролов рассказывает, как читатели с помощью микрокалькуляторов участвовали в игре через журнал. Из интервью Музейному проекту DataArt

Затем был куплен следующий калькулятор МК-61. Тогда это было целой проблемой из-за дефицита. Даже если есть деньги, ты не мог пойти в магазин и приобрести, что хочешь. Надо было ждать, искать. В какой-то момент мне повезло: зашли в Электронику на Гагарина единственный большой магазин такой тематики в Питере и купили этот калькулятор. Он был немного получше старого, на нем шло больше программ.


Магазин-салон Электроника на проспекте Гагарина в Ленинграде был еще и важным местом встречи радиолюбителей с перекупщиками деталей. Источник фото

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

Параллельно появилась еще одна тема. В журналах Радио, Моделист-конструктор, Юный техник стали публиковать статьи по сборке самодельных компьютеров. Выбор был не очень большой. В Юном технике, по-моему, о Микро-80 рассказывали. Помню точно, что была серия статей про какой-то модульный компьютер, где ты сначала собираешь что-то без подключения к телевизору, с индикатором простым и несколькими кнопками. Затем контроллер монитора, потом еще что-то. Там была нужна куча микросхем собрать это было для меня совсем нереально. В журнале Радио публиковалось описание Радио-86РК, со схемой попроще, но там было не достать микросхему контроллера дисплея 580ВГ75 тоже дефицит. Все остальное пожалуйста, а вот ее нет.


Тестовый образец персонального компьютера Радио-86РК, предназначенного для сборки радиолюбителями, из коллекции DataArt

Чуть позже, в журнале Моделист-конструктор стала публиковаться схема компьютера Специалист. Еще выходил профессиональный журнал Микропроцессорные средства и системы, уже не для радиолюбителей. Там печатали схему ещё одной ЭВМ Ириша более серьезной, чем вышеупомянутые. Как и предыдущие, она была основана на микропроцессоре 580ИК80, аналоге Intel 8080. Возможности впечатляли, но машина была очень сложная, с кучей микросхем, в том числе, редких.

В условиях дефицита

Еще один интересный момент. В то время каждое предприятие считало своим долгом изобрести собственный компьютер. Сейчас это кажется глупым, все думают о совместимости. Если соберешь свой компьютер, что будешь на нем запускать? Тогда этот вопрос не стоял, потому что программ не было никаких. Если соберешь и хорошо работает ты молодец. Отец приносил схему ЮКУ (Juku эстонский компьютер. Прим. ред.). Я пытался искать, что это вообще такое никаких следов. Тоже на 580ИК80, схема достаточно простая. Мне приносили платы, я пытался паять, но быстро забросил, потому что радиолюбитель из меня никакой. Что-то простое паял, но собрать компьютер, тем более редкий и непонятный конечно, не мог.


Juku E5101 персональный компьютер, производившийся на заводе Балтиец в Нарве в 19881991 гг. Из коллекции эстонского Музея компьютерной техники

Тогда было как? Допустим, увидел в журнале какую-то схему неважно, компьютера или, например, усилителя. Хочешь ее собрать. Сейчас это достаточно просто. Ты можешь пойти в магазин и купить все необходимые элементы. Тогда это было невозможно. По списку этих элементов купишь треть, остальные надо искать, заказывать, долго ждать. Желание теряется. Кто-то этим занимался, конечно. Основной источник радиокомпонентов люди, выносившие их с предприятий. Это было воровство по большому счету, но фактически им занимались все, поскольку всё было государственное типа общее. Все считали, что это их. Практически узаконенная штука. Это касалось не только радиокомпонентов всего. Все понимали, что, если этот процесс резко остановить, многие важные вещи просто станут недоступны. К тому же, люди на их сборке занимались самообразованием. Фактически, предприятия закрывали глаза на то, что на их ресурсах граждане что-то делают для себя. Ну а граждане получали навыки, которые потом могли использовать и на производстве.

Соответственно, периодически что-то появлялось и у меня дома: какие-то светодиоды, транзисторы, конденсаторы. Из-за специфики работы практически все было из ВПК. Приходилось придумывать, как ими заменять ширпотреб, который использовался в схемах публикуемых в журналах. Военка такие транзисторы или микросхемы не использовала, потому что они ненадежные и не пройдут никакие приемки.

Потом, в какой-то момент, началась тема со Спектрумами, и она, конечно, многих вдохновила. Идея была такая: в отличие от всех этих устройств Радио-86РК, Специалиста и прочего, здесь, собрав компьютер, ты сразу получал доступ к уже написанным за рубежом программам. Их было много, это очень большой плюс. Потому что для Радио-86РК, самого популярного тогда компьютера, на начальном этапе был доступен может десяток или два программ это ни о чем. А здесь цветной компьютер, сразу игры все, что хочешь. Поначалу, конечно, это все тоже было проблематично. Надо было искать компоненты, из которых самым дефицитным был Z80, поскольку импорт.


Плата ZX Spectrum-совместимого компьютера такую же спаял и использовал прямо без корпуса Пётр Соболев. Источник фото

Информатика в спортивной школе

Году в 87-м у нас в школе начались уроки информатики. Это последние два класса 10 и 11. Компьютеров в школе не было никаких. Максимум несколько калькуляторов. И на первом уроке нам просто рассказывали о Бейсике, а мы смотрели на доску и записывали в тетрадку операторы. Потом нас стали водить в соседнюю спортшколу на Брянцева, в которой стояли компьютеры Commodore 64. Достаточно необычная тема для СССР, потому что тогда в образовании использовались в основном отечественные Корветы, Агаты, либо закупались Ямахи MSX-2 по договорам с японцами.


Компьютер Commodore 64 поступил в продажу в августе 1982 года. За 12 лет было продано более 15 млн компьютеров

Мне повезло, эти Commodore 64 хорошие машины. По тем временам для нас просто верх. Отличные цветные мониторы, клавиатура, звук. Значительно лучше, чем в Спектруме, и уж тем более в Радио-86РК и прочих. Соответственно и игры, в большинстве своём, были лучше.


Скрин отладки ассемблерного кода

Нас привели в класс, посадили по два человека за каждый компьютер, включили. Там сразу Бейсик и мигает курсор. Помню, на первом уроке мы просто гоняли курсор по экрану и радовались. Нам показали, как менять цвет курсора. Это нас, конечно, заворожило. Думаю, если бы компьютеры были чёрно-белые, скорее всего, мы бы так не заинтересовались. Но вот этот приятный синий экран с курсором любого из 16 цветов, нас, конечно, привлёк.

Мы стали туда ходить, причем не только для официальных занятий информатикой, которые проводились раз в неделю. С приятелями заглядывали после уроков, а иногда даже прогуливали что-нибудь вроде физкультуры. Нас не были обязаны пускать но, по счастью, учителя в этой школе были понимающие. Марк Соломонович Сегаль, Елена Исааковна Лозинская и секретарь Елена Петровна всегда находили для нас места. Приходишь, открываешь дверь, видишь, что все занято и ждешь в коридоре, пока освободится комп.


Справка о посещении факультатива по информатике. Из личного архива Петра Соболева

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


Игра Ghost'n'Goblins, выпущенная в 1985 году для аркадных автоматов и позднее портированная на другие платформы, в том числе и Commodore 64

Когда народ уходил, но оставался кто-то из учителей, мы, бывало, играли. В Arkanoid, который очень качественно был сделан в плане звука и графики. Я его потом много на каких машинах видел, могу сравнивать. Была игра Ghost'n'Goblins, где чувак ходил по кладбищу с привидениями. В трехмерной игре Driller надо было разбираться, куда пойти, что сделать, куда выстрелить, чтобы что-то переключилось и открылось. Типа квеста. Помню, мы рисовали карты на листах А4. Поскольку эта игра к нам не в коробке попала, а просто в виде файла, мы вообще не понимали смысл того, что там происходит. Когда нарисовали, и увидели додекаэдр, поняли, что это вроде планета какая-то. Ещё хорошая игра была Cauldron II: прыгал там такой колобок по комнаткам, где обитали привидения, всякие скелеты, и надо было что-то собирать. Стандартная игра тех времен. Сидели, разбирались, тоже рисовали карты. Играм и чему-то серьезному мы, наверное, 50 на 50 уделяли внимание.


Инструкция, как пропатчить код игры DRILLER, оставленная одним изнас вшколе наБрянцева ($EA инструкция NOP процессора 6502). Пётр Соболев

Лаборант

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

Подготовительные экзамены я провалил. По физике попался 19-й билет (как сейчас помню), на который я не ответил. Пошел сдавать обычные экзамены с потоком и провалил еще раз мне попался тот же самый билет. Ну, естественно, я его не стал учить кому попадается один и тот же билет дважды! Оказалось, мне. Я пролетел, но по возрасту до армии оставался год. Пошёл работать лаборантом в ЛИТМО. Тогда он не был так известен, как сейчас. Обычный технический вуз, как ЛЭТИ, ЛИАП и многие другие. Лаборантом я стал на кафедре вычислительной техники. В мои обязанности входило подпаивать на стендах провода, которые со всей дури выдергивали студенты, и раз в месяц выносить мусор из аудитории. Дальше я мог заниматься, чем хочу.

В аудитории, в которой я работал, стояла Искра-1030. Такая советская PC/XT с 512 килобайтами памяти и зелёным монитором ужасного качества, от которого очень уставали глаза. Я на ней пытался что-то делать. В соседней аудитории через коридор стояли Искры 226, как у отца на работе. По сравнению с Искрой 1030, они были еще хуже. На этой можно хоть какие-то вещи запускать, для PC предназначенные. А там вообще ничего только Бейсик, по сути.


Рабочая среда Turbo Pascal 4.0

На Искре 1030 я что-то писал на Turbo Pascal 4.0. Это первый Turbo Pascal, где появилась более-менее нормальная среда с менюшками. Про игры там говорить тяжело, потому что на такой машине нормальные игры не работали. Какие-нибудь Xonix, Тетрис, с трудом Prince.

Потом в той же аудитории появился болгарский Правец 16. Это тоже PC/XT, но повыше уровнем. Там уже шли многие вещи, но монитор тоже был черно-белым.


Игра Commander Keen 4 на Правец 16

Рядом с нашей аудиторией была аудитория заведующего лабораторией, основная на кафедре. Там стояла PC AT 386SX/16 очень крутая машина по тем временам. На ней шли игры, была хорошая графика, правда памяти там было, вроде, всего 1 MB. Когда машина была свободна, без проблем можно было за ней сидеть. Преподаватели сотрудники кафедры, видели, что я чем-то интересуюсь, а не просто пришел поиграть и не возражали.

Домашние компьютеры

Была при этом параллельная история, которая началась чуть раньше, до института. В годы перестройки мы начали мириться с США, пошли общие темы, и многие пытались делать какой-то свой бизнес, хотя никакого представления о бизнесе у советских людей не было. Почитали, посмотрели фильмы и вперед. Друг нашей семьи открыл совместное предприятие с американцами. Контора называлась Вабог, потому что его звали Валерий Боголюбов. Под это дело ему из Америки привезли компьютер PC/AT 286. 640 килобайт памяти, 20 МГц тогда это было очень круто, тогда даже PC/XT 8 Мгц считалась серьезной машиной. Компьютер был с цветным монитором, правда, CGA. Приехало это всё в большом, окованном по краям железом, сундуке, который у меня до сих пор дома лежит и все, кто видят, спрашивают, что это такое. Поскольку наш друг понятия не имел, что с этим компьютером делать, а я тогда как раз всем этим увлекался, он нам его на время отдал.


Тот самый сундук

Компьютер стоял у меня дома. Там был DOS. Ты компьютер включаешь, с дискеты загружаешься. Мигает курсор, написано MS-DOS, версия 3.10 и всё. Текстовый режим, никакой графики. Сначала я пытался команды изучать, потом кто-то дал пару дисков с играми, тот же Turbo Pascal, что-то еще. Затем, когда этот компьютер унесли, к тому времени я уже окончил школу, домой купили Commodore 128. Это такая странная, даже по тем временам, машина попытка фирмы Commodore усидеть на двух стульях. С одной стороны, они старались не потерять любителей Commodore 64, которые очень любили игры их для 64 было много написано. С другой стороны, пытались влезть в бизнес, чтобы текстовые редакторы с 80 столбцами нормально работали. Электронные таблицы вот это вот всё. Забегая вперед, это им не удалось. Не они одни были такие умные. То есть, фактически, они в один компьютер запихали целиком схему Commodore 64 и рядом присобачили Z80 и еще один видеоконтроллер, который на другой монитор выводил 80x25 текст. Ну или 640x200 монохромную графику. Фактически, это был двухпроцессорный компьютер, в котором работать параллельно процессоры, конечно, не могли. Ты должен был выбирать. И два видеовыхода на два монитора.


Телевизионная реклама Commodore 128, 1985 г.

Я довольно долго за этим компьютером сидел, что-то писал, разбирался, было довольно интересно. Два монитора по тем временам тоже было круто.

Впрочем, полезного я ничего сделал. Ни одной демки или интры ничего. Всё, что я тогда писал это какие-то полуфабрикаты. Допустим, я разобрался, как цветные полоски рисовать красивые и, удовлетворенный, делаю что-то другое. То есть, фактически, написание сводилось к тому, чтобы просто разобраться с какой-то темой. Спрайты там, например, или как шрифты перепрограммировать. Разобрался и всё. С Commodore 64 и 128 дело обстояло так. Более-менее что-то законченное я стал писать, уже на PC.

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

Это была PC/XT, мегабайт памяти, 4,77 МГц-тактовая, 8086-й процессор (не 8088!), с цветным CGA монитором. Фишка была в том, что эта машина была в форм-факторе Full Tower. Я долго развлекался с этим компьютером, разгонял его. То ли кварц поменял, то ли перемычки переставил, сделал 8 или 10 МГц. При этом контроллер дисковода стал смешно выскакивать из кроватки. Видимо, нагревался. Там кроватки советские были, из них выскакивало всё при любом удобном случае. Нитками примотал заработало стабильно.

Рейтрейсинг

В институте кроме Правеца и 386SX появились и другие машинки. В мою учебную аудиторию поставили PC/AT 286 c EGA адаптером. Еще там был Amstrad PC1640 с монохромным EGA. Интересно, что эта PC/AT 286 с цветным EGA была югославской, причём в военном исполнении. Серьезная вещь. Металлический корпус очень грубый, с ребрами охлаждения, монитор соответствующий, обрезиненный со всех сторон. Если ударят, чтобы амортизировал. Неплохая была машинка. 16 МГц, по-моему.

В комнате заведующего лабораторией поставили еще две штуки PS/2 модель 50. Это были PC/AT 286, по-моему, около 20 МГц с шиной Micro Channel (MCA). Графика у этих машин была MCGA (MultiColor Graphics Adapter). Это такое VGA, только без высокого разрешения. Можно было выводить 320x200, 256 цветов. Точнее, в нашем случае, 64 градации серого, т.к. мониторы были чёрно-белые. На PS/2 мы впервые пробовали развлекаться рейтрейсингом обсчитывали всякие красивые стеклянные сферы, которые друг в друге отражаются и преломляются.

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

Тогда 3D пакеты типа, скажем, Maya, были только на дорогих и недоступных почти никому компьютерах типа Silicon Graphics. На PC же всё только начиналось. Обсчитать самому красивую картинку при помощи собственной программы это было круто и вполне адекватно.

Студент

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

Мехатроника это, грубо говоря, приборостроение, смесь электротехники, электроники и механики. Естественно, вычислительной техники там особо никакой не было. Было всякое ТОЭ, сопромат, конструирование, материаловедение По диплому я, в итоге, инженер-электромеханик. Что касается компьютеров, у нас были раз в несколько недель занятия по специальности прикладная математика на СМ-4. Стояла она в отдельной комнате за стеклом и мигала лампочками, как в фильмах. Очень модно. По другую сторону стекла стояли 6 терминалов с черно-зелёным текстом. Многопользовательская такая машина. Студенты пытались что-то вводить, но это была жесть. Чтобы написать программу, ты должен был запустить текстовый редактор. Он сколько-то запускается, у тебя появляется курсор. Вбиваешь эту программу, потом выходишь из редактора, запускаешь компилятор, линкер. При этом всё, как правило, периодически падает, ты начинаешь заново. Я там был один-два раза, потом понял, что больше не хочу. Романтики не ощутил совсем и стал думать, что делать.


ЭВМ СМ-4 с 1979 года выпускалась в СССР, Болгарии и Венгрии

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


Университет ИТМО, Санкт-Петербург, переулок Гривцова. 2008 г.

Государство в государстве

ЛИТМО стал известен за счет парфёновской кафедры (В 1991 году по инициативе профессоров Парфёнова и Васильева в СПбГУ ИТМО начался проект по созданию системы для подготовки и трудоустройству одарённых школьников и студентов. Прим. ред.). Когда я поступал, ректором был Новиков. В последние годы моего обучения его сменил Васильев. Компьютеров у нас было очень мало, в учебном процессе их не задействовали вообще, кроме СМ-4. Парфёновская кафедра располагалась в подвале. Там отдельная дверь, в ней глазок с камерой. По тем временам прямо как банк иностранный. Однажды я туда пришел что-то забирать и был просто в шоке.


Основатели кафедры Компьютерные технологии: Владимир Васильев, Владимир Парфенов и Алексей Сигалов, на банкете выпускников ЛИТМО в 1990 г. Источник фото

ЛИТМО в те годы это ободранные стены, развалившийся местами паркет, старые двери, перекошенные окна. А заходишь на эту кафедру там ковровое покрытие, прозрачные перегородки, люди сидят за компьютерами PC с цветными мониторами. Такое вот эээ цифровое неравенство. Кафедра как государство в государстве. Но за счёт неё и других вещей Васильев вытянул ЛИТМО в известные вузы.

Знакомство с демосценой

В соседней школе, куда нас водили в детстве на Commodore 64, у учителей был некий набор программ. Среди них попадались такие, которые ни для чего не были предназначены просто показывали под музыку красивые графические эффекты. Мы иногда ставили и смотрели, поскольку прикольно. Но мы, конечно, не знали, что такое демосцена и демки. Сейчас все ходят в интернет, читают иностранную прессу, книги, смотрят новости а тогда этого не было. Об иностранной культуре мы практически не имели представления. Всё, что знали, из фильмов, которые проходили цензуру, то есть достаточно нейтральных. Тоже самое касалось и музыки. Поэтому для нас многие вещи были в новинку.
В последний год хождения в школе на Commodore 64 у нас стали заводиться знакомства с людьми, у которых этот компьютер стоял дома. В основном, это ребята, у кого родители ездили в загранку. Дальнобойщики, моряки люди, которые оказывались за границей и могли там что-то покупать. Было 3-4 человека, у которых оказался Commodore 64. Мы ездили к ним домой, обменивались софтом. Сетей нет, модемов нет. Просто приходишь с пачкой дискет (по 300 кб) и говоришь: У меня есть то-то и то-то. Давай посмотрим. Ставили в дисковод, смотрели: О, это мне интересно. Копируем. Были программы-копировщики. Запускаешь, она пишет: Вставьте диск исходный. Вставляешь: Вставьте диск, куда копировать. Так несколько раз. На копирование одного диска уходило минут 10.

Так постепенно у нас появлялось что-то новое. Тогда я познакомился с одним человеком Кириллом Антоновым, никнейм GhostRider. Не знаю, куда он исчез, много лет назад растворился в воздухе. У него был Commodore 64, при этом он более-менее знал английский язык и переписывался с иностранцами. Он установил контакты с некоторыми группами, которые чисто для души занимались написанием программ: музыка, графические эффекты какие-то. Кирилл им писал, они ему присылали диски. Тогда мы начали проникаться понятием демосцена.


Hello GhostRider! Письмо Кириллу Антонову из-за границы, написанное на конверте с дискетой, содержащей программы

Что нам попадало в руки? Во-первых, программы, где что-то красивое показывается на экране под музыку. Во-вторых, программы-журналы. Запускаешь diskmag (disk magazine Прим. ред.) как исполняемый файл. Тебе выводится меню. Там статьи, интервью. Заходишь, читаешь. Были еще noters тоже исполняемые файлы. Типа diskmag'ов, только из одной статьи. Как сейчас в архивах кладут README-файлы. Тогда их не было. На Commodore 64 текстовых файлов, как таковых, не было вообще. Потому что не было единого формата текста, который могли бы читать все программы. Включаешь компьютер у тебя один Бейсик, можешь только загрузить и запустить что-то. Поэтому все эти readme были в виде исполняемых файлов и это был большой плюс в плане возможностей самовыражения. Люди писали такой исполняемый readme, запускали. Текст мог появляться разными шрифтами, разными способами. Иногда он появлялся постепенно, как будто от пишущей машинки. Имитировалось стирание будто человек прямо при тебе пишет. И под музыку. Были noter'ы специальные, когда ты мог не только прочесть текст, но и написать ответ. Нажимаешь кнопочку, у тебя появляется курсор, и ты это все можешь писать сам. Потом нажимаешь другую кнопочку, делается копия исполняемого файла, только с твоим текстом. Можешь добавить музыку свою, если хочешь.

История интро и демо

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


Cracktro конца 1980-х (короткое интро, предваряющее взломанные игры) группы Xadez Society для Commodore 64

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

Допустим, кто-то сломал игру, чтобы скопировать и нелегально распространить, потом кто-то следующий сделал в ней бесконечные жизни. Он тоже добавлял свое интро. Когда запускаешь такой диск, сначала одна интра показывается, потом другая, третья. До пяти бывало. В каждой команде были так называемые swapper'ы, которые занимались пересылкой дисков по почте. Таким вот образом это всё дошло до нас.


Cracktro 1990 года (короткое интро, предваряющее взломанную игру 3D International Tennis) группы IKARI для Commodore 64

Вопроса, зачем это делается, не возникало. Было очевидно, что это интересно. Ты сделал прикольную вещь, другие оценили. Потому что, если к тебе попал Commodore 64 в голом виде, без всего, только лишь со встроенным Бейсиком, ты ничего подобного не сделаешь даже близко. Надо писать на ассемблере, очень хорошо знать, как работает оборудование, как программировать видеочип, звуковой чип. Надо понимать, как все это оптимизировать и как запаковать в небольшой объем кода. Потому что, когда эти интры лепили к играм, сама игра ведь всё равно должна как-то влезать на диск и грузиться достаточно быстро.

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

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


Демо Red Storm группы Triad для Commodore 64

Помню, меня впечатлила демка Legoland группы Fairlight. Там была такая часть при помощи рейтрейсинга летали зеркальные шарики вокруг какого-то столба, с отражениями. Понятно, что на Commodore 64 этого сделать было нельзя, просто потому, что там процессор был 6502 1 МГц. Авторы же просто взяли более мощную машину Commodore Amiga, все это сделали покадрово, потом собрали такой мультик. Но тогда нам это было неочевидно, складывалось впечатление, что это реально происходит.


Демо Legoland группы Fairlight для Commodore 64

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

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

Напомним, что в первой части речь шла о компьютерах 1980-х и знакомстве с первыми интро и демо.

Частичка души

Полноценную демку я ни разу в жизни не написал. Несмотря на то, что очень этим увлекаюсь и фестиваль организовывал. Фактически все вещи, которые я делал, были интро. Первую написал в 1994-95 гг. в связи с тем, что мы организовывали в Питере ENLiGHT'95 первую в России (и странах бывшего СССР) демопати. Не скажу, что та интро что-то собой представляла заняла она то ли последнее, то ли предпоследнее место. Но я на самом деле не особо и старался просто хотел, чтобы моя работа была на фестивале. Там у меня в хитром видеорежиме имитировалось сражение процессоров Pentium и 6502. Типа они летят друг на друга, в итоге 6502 стоит с копьём над Pentium, и кровь стекает.


Титры той самой интро, в которой 6510 Победоносец поражает Pentium

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

Кроме того, раньше каждый процессор, каждая архитектура, каждый видеоконтроллер, любой компьютер имели некую индивидуальность. Тот же Commodore 64. Его люди делали не потому, что маркетинговый отдел им сказал, будто компьютер с таким процессором и таким программным обеспечением будет продаваться. Они просто решили: так будет правильно. Процессор 6502 выбрали, потому что могли позволить себе по деньгам. Сделали такой звук, потому что человек, который его разрабатывал, начинал с синтезаторов. Он хотел, чтобы в Commodore 64 были реализованы схожие возможности никто не давал ему распоряжений. В каждой такой платформе была частичка души разработчиков. Это очень чувствовалось.

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


Интро No shaders размером 256 байт, созданная Петром Соболевым для игровой консоли 1977 года RCA II Studio. Заняла 4-е место в категории Tiny intro compo на фестивале СС2018

История демопати

Идею фестиваля мы подсмотрели за рубежом. В конце 80-х в Европе, в том числе Восточной, стали организовывать что-то типа copy party. Вот мы обменивались софтом, и то же самое делали они, только у них было гораздо больше людей и софта. Заодно пиво или что-нибудь покрепче. Постепенно на таких копипати стали возникать идеи: Давайте мы не просто соберемся и что-нибудь скопируем, а еще покажем, что умеем, что сделали сами. Стали приносить и показывать свои интро и демки. За пару лет это вылилось в то, что теперь называется демопати. То есть люди уже целенаправленно собирались в каком-то зале, показывали, кто что принес, кто что написал. Оценивали и восхищались.


Одна из европейских копипати. Конец 1980-х

Следующим шагом стали правила. Потому что глупо, если соревнуются демки, одна из которых занимает целый диск, а другая 1 Кбайт. Несопоставимо. Поэтому придумали и согласовали отдельные категории, например, в 256 байт, 1 Кб, 4 Кб, 64 Кб. Если у тебя ограничение 64 Кб, ты должен очень сильно извратиться, чтобы запихнуть туда достаточно впечатляющий сюжет и звуковой ряд. Тем более, если у тебя 4 Кб, или 1 КБ, или 256 байт. Понятно, что когда человек пишет работу в 256 байт, он в основном думает о коде, а не о том, чтобы музыка была хорошая.
Потом сделали отдельные номинации под музыку и под картинки. В результате с 1992 года появились уже вполне официальные международные демопати, где были совершенно чёткие правила, номинации графики, музыки, демо, интро.

Где-то в 1991 или 1992 году в Скандинавии начали проходить первые демопати. Почему именно там, а не в Америке большой вопрос, на который никто четкого ответа до сих пор не дал. Может, это связано с тем, что люди в странах Северной Европы не слишком парятся о завтрашнем дне и могут себе позволить заниматься чем хотят. В Штатах, несмотря на то, что там тоже были демопати и их пытаются проводить сейчас, демосцена представлена в очень ограниченном виде. Хотя другие, во многом похожие вещи радиолюбительство, например там очень распространены.


Впечатляющая демо на 256 байт от команды RSI. Желающие убедиться в его оригинальности могут скачать исполняемый файл в описании

О появлении демопати мы, конечно, узнали. В начале 1990-х у нас уже были PC, появилась сеть FidoNet, модемы. До нас всё это доходило, мы скачивали работы, смотрели и тоже восхищались. В какой-то момент захотели и сами сделать похожее мероприятие. Начали с эхоконференции FidoNet с названием DEMO.DESIGN своего рода офлайн-форума. Я там устроил, грубо говоря, открытый конкурс по переписке. Сначала это было соревнование типа кто сможет нарисовать треугольник, уложившись в меньший размер кода. Обозначено условие: процессор 286, VGA, например. Потом сделали поинтереснее. Надо было написать небольшое интро в каком-то ограниченном объеме. Народу понравилось нам присылали работы, в том числе, довольно интересные. Был такой Patson, который, как я помню, прислал впечатляющее интро с фейерверком что-то там разлеталось красивое. Часть этих людей, как и на Западе, раньше ломали софт и точно так же переквалифицировались, можно сказать легализовались.


Пётр Соболев в 1990-х. Слева над розетками виден модем USR Sportster (с апгрейдом до HST)

Мы с друзьями организовали группу Realm Of Illusion, от имени которой в 1994-1995 гг. вышло два номера электронного журнала Infused Bytes для PC. Безусловно делались они, с точки зрения как дизайна, так и контента под впечатлением электронных журналов, которые я видел на Commodore 64.


Электронный журнал (diskmag) Infused Bytes. Выпуск 1995 года

ENLiGHT95

В 1994 году мы решили, что надо у нас провести мероприятие по типу демопати. Денег не было в стране тогда были очень большие проблемы с экономикой, спонсоров реклама среди каких-то непонятных личностей интересовала мало. Нас спасло то, что в некоторых фирмах нашлись люди, которым эта тема просто нравилась. Они уговорили своё руководство помочь: не деньгами, а оборудованием и помещением. Один из организаторов, например, работал сисадмином в Российской федерации шейпинга и договорился, что нам на выходные отдадут их офис. Другой человек одолжил у фирмы LANCK два компьютера PC AT 486 с VGA. У кого-то взяли пару телевизоров, чтобы работы видело побольше людей видеопроекторов тогда не было. Ну, может, был один на весь город.

В итоге в августе 1995 года мы провели первую демопати. Выглядело это по сегодняшним меркам довольно странно. На Казанской в старом доходном доме с двором-колодцем какая-то квартира, переоборудованная под офис. Три комнаты одна большая, две поменьше и коридор. Типичная бывшая коммуналка. Один телевизор мы повесили в комнате, другой стоял в коридоре на полу. Каким-то образом подключили их к PC, Commodore Amiga, Commodore 64. Как ни странно, конкурсные работы были по каждой номинации, хоть и немного. Народу пришло и приехало из разных городов человек 150, в этой квартирке было не протолкнуться.

В коридоре стояла Сонька маленький контрольный монитор из телестудии. В большой комнате висел здоровый советский телевизор типа Фотон-716. Стояли колонки S-90 и какой-то усилок. Как на любой демопати, объявлялось: Сейчас будут показаны конкурсные работы в такой-то номинации. Дальше на двух телевизорах подряд показывали демки. Зрители запоминали работы, которые им понравились, и на листах бумаги голосовали за первое, второе и третье места по каждому конкурсу. У меня до сих пор эти листочки лежат с 1995 года всё сохранено.


ENLiGHT'95. Кадры с VHS кассеты

Еще был конкурс Real time coders compo. В два захода сажали людей за PC, давали им час времени и задание. Надо было написать код, который красиво преобразует одну заданную картинку в формате VGA в другую. У кого красивее, тот выиграл, размер не важен. Писали на Turbo Pascal, со вставками ассемблера. Участвовали Андрей Заболотный, Mad Max и еще кто-то третий. Написали достаточно впечатляющие вещи.

Так прошли эти два августовских дня. Мы запустили IRC-клиент и в чате писали, что происходит. Тусовка шла непрерывно, конкурсы занимали процентов 10 времени. Это был чуть ли не первый раз, может, за исключением сисопок на Комтеке, когда встречались люди, которые не просто интересуются IT, а конкретно пишут код или хотя бы регулярно смотрят демки. Причём, со всего Союза из Белоруссии, Молдавии, Украины, Москвы, Воронежа Все они общались. Были ребята, которые ломали софт это достаточно близко демосцене. Фидошники были, естественно. Сохранились кадры на VHS, на которых можно увидеть людей, позднее ставших известными.

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


Видеоролик с кадрами первой демопати в Петербурге. 1995 год

ENLiGHT96

На следующий год мы решили демопати повторить. Денег больше не стало, но удалось выбить помещение попросторнее в Кораблестроительном институте на Ленинском проспекте, где была приёмная комиссия. Повесили в холле несколько телевизоров, поставили несколько компьютеров, было больше конкурсов, Интернет поприличнее стал Появился Спектрум, он уже становился основным компьютером отечественной демосцены, много народу под него начало писать. В 95-м Спектрум в конкурсах еще не присутствовал, спектрумисты только присматривались, что это за зверь демопати. Но в 1996-м по полной программе. И организатор свой был у них Володя Ларьков и куча работ.

Иногда смотрю отснятое тогда видео такое впечатление, что на ENLIGHT и CC побывали буквально все, кто хоть как-то интересовался IT.


ENLiGHT'96. Кадры с VHS кассеты

Народу стало больше, может, под 300 человек, и уже появились проблемы с безопасностью. Обеспечить профессиональную охрану мы не могли, потому что денег не было. Народ напивался, спал на столах, местами буянил. Кого-то вывозили, кого-то выносили. Однажды Mad Max запустил трёхдюймовый диск и попал в машину на стоянке. Через 10 минут подъехали тонированные жигули, оттуда вылезли человек пять бандитов и сказали, что надо платить. Mad Max начал возбухать он приехал из Самары, там, видимо, так не было принято но ему объяснили, что будет хуже. Отделался в итоге то ли 200, то ли 300 баксами. Думаю, охранник стоянки позвонил, бригада и приехала. В принципе, она могла тут же фестиваль и прекратить, если бы мы дело не уладили.


Анкета для голосования на ENLiGHT'96. Из личного архива Петра Соболева

ENLiGHT97, последний

В 1996-м было много работ, всем понравилось, на следующий год мы опять решили повторить. В 1997-м демопати принимал Военмех благодаря моему шефу (я поступил туда в аспирантуру после ЛИТМО) нам дали актовый зал. Как и на двух первых фестивалях, была регистрация участников. Стоял стол, и каждый заполнял анкету. Все три года всё было бесплатно. Таким образом мы избегали проблем: до нас не докапывались, ну и вряд ли многие стали бы за это платить. Очередь на регистрацию выстроилась практически до метро Технологический институт. Только по анкетам пришло 1600 человек. И на всех лишь два добровольца, поддерживающих порядок.


Та самая очередь. Фото из личного архива Петра Соболева

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


ENLiGHT97, актовый зал Военмеха

Поначалу всё шло неплохо. Мы начали показывать работы на VGA-мониторах проектор до сих пор был недоступен, а мониторы стали заменой телевизорам. Потом народ частично перепился, кто-то с пневматической винтовкой бегал, кто-то разрисовал туалет. К концу дня это приобрело нехороший характер, и руководство вуза сказало нам, что подобное недопустимо. Мы посовещались и решили фестиваль закрыть. Повесили бумажку: Извините, второй день отменяется. Народ пришел, стал буянить прямо у входа. Приехала милиция.

После этого мы поняли, что надо что-то менять. Пытались искать спонсоров, но, к сожалению, на тот момент это было нереально. Те, кто были на выставке Инвеком-98 в Ленэкспо, могли видеть странный транспарант ENLiGHT98. Кто-то даже удивлялся: мол, показалось. Нет, не показалось. То была репетиция для небольшого количества человек. Но спонсоров в итоге мы тогда так и не нашли, так что ENLiGHT на этом закончился.

Chaos Constructions

В 1999 году совершенно другие люди, большинство из которых с нами знакомо не было, сделали практически то же самое своими силами. Правда, масштабом поменьше. В школьном актовом зале (по странному совпадению, в двух шагах от школы, где мы когда-то сидели за Commodore 64) они организовали демопати Chaos Constructions'99. Та же идея конкурсы: музыка, демки, графика, около сотни человек народу. Как ENLiGHT95, только проектор у них появился, и в целом поприличнее всё стало.



Публике понравилось, да и нам тоже было интересно. Потом они провели Chaos Constructions в 2000-м, 2002-м, 2003-м. Организаторы бывали разные, но в основном этим занимался Всеволод Потапов с друзьями. Я был на всех СС, два года они проходили в кинотеатре Восход. А перед 2004 годом мы организаторы ENLIGHT и CC договорились попробовать провести очередной фестиваль вместе.

Chaos Constructions'2004 мы провели в ЛДМ, и это был уже другой уровень. Большое помещение, нормальный проектор, первая выставка ретрокомпьютеров (позднее ставшая ежегодной). Приходилось решать достаточно серьезные организационные вопросы, в том числе такие, которые не были видны посетителям. Грубо говоря, все росли: кто-то как организатор, кто-то как программист, кто-то как админ. Никто никому из нас не платил, но люди очень много от этого получили. Кто-то благодаря новым знакомствам нашел работу, кто-то повысил свою квалификацию. С точки зрения организации опыт совершенно бесценный. Ты руководишь 20-30 людьми, которым не платишь и которые не обязаны тебе подчиняться. Исключительно за счет авторитета и того, что какие-то здравые мысли высказываешь.


Пётр Соболев пишет программу в машинных кодах для ПЭВМ Агат, представленной на выставке ретрокомпьютеров части фестиваля Chaos Constructions'2004

Я даже написал тогда полноценную систему для управления проектами именно для CC. А дружественная компания специально под нас писала 3D-движок, чтобы заставки и расписание показывать на большом экране.


Скриншот системы управления проектами для фестиваля Chaos Constructions, написанной Петром Соболевым

В 2005-м фестиваль там же в ЛДМ по смыслу был похож на предыдущий, а вот в 2006-м уже сильно отличался. Мы провели его около метро Лесная, в павильоне выставочного центра Евразия. Зал большой, и чтобы поднять уровень мероприятия и привлечь людей, мы решили добавить ещё тематики. Сетевая безопасность, игры всё подряд, вплоть до блогов. Разделили помещение на зоны для геймеров, хакеров и т. д. Некоторые направления потом отвалились, но другие оказались многим интересны.

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


Большой экран с пролетающими в эфире паролями Wi-Fi. Хакзона Chaos Constructions'2009

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


Задание одного из конкурсов на Chaos Constructions разобраться в схеме и разминировать бомбу с обратным отсчётом

Ещё важно, что CC'2006 был первым, куда довольно много народу пришло со своими компьютерами, как на западных demo party. Раньше подобное у нас было невозможно ноутбуков ни у кого толком не было, а для перевозки громоздких настольных компьютеров с мониторами мало у кого были личные автомобили.


Хроника с фестиваля Chaos Constructions2006

Демосцена сейчас

С 1996 по 1999 год, на мой взгляд, был кризис. Я говорю не про Россию, а про весь мир. Появились 3D-ускорители, и народ, вместо того чтобы подумать о сюжете, ринулся во всё это: Давайте покрутим бублик, покрутим 5 бубликов, а если 100 бубликов, вообще супер будет! Демки, которые занимали первые места на крупнейших мировых пати, были сделаны технически круто, но чаще всего смотреть их было совершенно неинтересно. Это затронуло и те платформы, с которых демосцена начиналась. Если на PC хотя бы есть 3D-ускорители т. е. было понятно, почему они стали эти бублики крутить, то на Commodore 64 и Amiga ускорителей не было, а бублики крутить многим там почему-то тоже хотелось. Выглядело это печально. То есть, когда на 6502 1 МГц с жутко медленным видеобуфером пытаются что-то крутить это, возможно, само по себе достойно уважения, но смысл неясен.

Где-то в конце 90-х начале 2000-х народу это надоело, снова начали появляться работы с интересным сюжетом, дизайном. Люди стали задумываться не только о технологии. Сейчас все нормально в принципе, демосцена существует и развивается. Причем, для старых платформ пишут не меньше, чем для современных. Пишут для удобства на эмуляторах, а демонстрируют уже на железе на старых машинах.


Футболка для фестиваля ENLIGHT'96 с напечатанным на ней кодом интро Cross (автор MadMax), занимающим всего 128 байт

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

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

Командная работа

На современной демосцене знаковых фигур, на мой взгляд, почти нет. Это не та область, где главную роль играет отдельная личность, здесь больше командная работа. Потому чаще известны именно названия команд. Возьмём какую-нибудь из известных демок, например, Second Reality 1993 года. Хотя она уже очень старая, на PC написанная, её успех определяется именно сочетанием графики, музыки и кода. Если что-то убрать, демка уже не будет такой. Это легко проверить, к примеру, просто выключив звук.



Финская команда Future Crew, которая эту демку написала, была знаменитой, я даже не могу назвать никого, сопоставимого с ними по известности в те годы. Из старых команд по-прежнему хороша та же Fairlight. Они начинали на Commodore 64, потом был Fairlight на Commodore Amiga частично с другими людьми, потом они перешли на PC. Но на всех трёх платформах Fairlight периодически выпускает очень приличные вещи.

Искусство и код

Многие называют демосцену современным искусством, но мне кажется, что их разделяет грань, которая проходит по линии кода. Если человек сделал, например, анимационный ролик, даже абсолютно напоминающий демку, демкой он не становится. Анимацию люди делают с другими целями, а суть демосцены подразумевает написание кода. Демка обязательно должна работать и что-то делать в реальном времени. Поскольку сейчас ограничение для нее десятки мегабайт, туда можно запихать анимацию достаточно приличного качества, но это будет неадекватно. Тебя высмеют. Никто не против каких-то мелких анимационных вставок, но люди понимают, что суть именно в коде, а в современном искусстве код не при чем. Совершенно другая область.

Что будет дальше вопрос сложный. В середине 1990-х или начале 2000-х мало кто мог предвидеть, что написание работ под старые платформы 19701980-х станет популярным, и что эта популярность будет только расти. Странно: железо всё лучше становится, добавляются возможности, но людям интереснее получать больше от старых платформ, а на новых платформах растёт популярность конкурсов с жёсткими ограничениями по размеру. Сейчас вроде очевидно, почему это так, но тогда было неясно. Так и в будущем совершенно непонятно, чего ждать. Мне кажется, что направление, в котором сейчас развиваются компьютеры не очень демосценерское. Это касается, в частности, ухода от привязки софта к конкретным платформам, эмуляции всего и вся и т. п. В отношении демосцены я скорее поверю, что старые платформы будут ещё более популярны, чем сейчас.

Что будет дальше в плане технологий мы не знаем. Скажем, скачка, связанного с компьютерами, никто предвидеть не мог. Когда-то эксперты говорили, что компьютер никому не нужен, кроме производства и бухгалтерии, а вышло не так. Что будет дальше дело тёмное.

Всего каких-то 26 лет назад прослушивать музыку на компьютере было не таким уж и простым делом. Еще до появления Windows 95, смело заявляющей о своей мультимедийности, люди слушали музыку прямо в среде MS-DOS. Причем не только трекерную, но и MP3. Стряхнем пыль со старого софта и погрузимся в чудесный мир музыки начала 90-х.

Для начала вспомним о популярных музыкальных форматах и оборудовании тех годов. В основном это были поздние 486DX и пришедшие им на смену Пентиумы с тактовой частотой от 60 до 133 МГц. Технология MMX (MultiMedia eXtensions), ускоряющая декодирование аудио- и видеопотоков, появилась лишь в 1997 году. Меломанам 1994 года приходилось довольствоваться тем что есть.

Без чего нельзя слушать музыку на компьютере? Разумеется, без звуковой карты. Это сейчас звук встраивается прямо в материнские платы и работает, что называется, из коробки. Но раньше звуковых карт было не так-то уж и много. С 1989 года на рынке безраздельно правила Creative Technology со своим знаменитым семейством звуковых карт Sound Blaster. Разумеется, были и альтернативы в виде редкой и очень дорогой Gravis UltraSound (его еще называли гусь по сокращению GUS), а также доброго десятка ее клонов.


Последнее десятилетие 20-го века ознаменовалось бурным развитием трекерной музыки, корнями уходящей в семейство компьютеров Amiga. Эти компьютеры имели крутой звуковой сопроцессор, что позволяло воспроизводить достаточно качественную сэмплированную музыку. Существовали соответствующие форматы (нечто среднее между аудиозаписью и MIDI), позволявшие хранить сэмплы, последовательности и параметры воспроизведения нот.

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

Сформировалась целая плеяда музыкантов, пишущих такую музыку. Зародившаяся в конце 1970-х годов киберкультура демосцены активно стала использовать трекерную музыку и развивать собственные форматы.

Так, например, появился знаменитый формат XM, созданный демогруппой Triton. В нем был значительно расширен список команд для создания эффектов и каналов. 16-битная поддержка и гибкость сделали этот формат основным для большинства трекерной музыки. Сообщество MOD-музыкантов исповедует принцип открытости своих произведений, что делает его схожим с движением Open Source.

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


Удивительно, но факт. Если у вас был процессор 486DXII и Windows 95, то для проигрывания MP3 требовались некоторые танцы с бубном. Дело все в том, что ресурсов процессора на все банально не хватало и звук периодически прерывался. Так что если хотелось послушать MP3 с помощью WinAMP, то приходилось либо переключаться в режим Mono, либо вдвое уменьшать частоту дискредитации выходного сигнала. Секретным оружием как раз и был Cubic Player, запускаемый из-под DOS. Его возможностей вполне хватало, чтобы послушать MP3-трек 128 kbit/s в стерео-режиме.

С тех пор прошло уже много времени. Тем не менее, оценить работу Open Cubic Player можно и сейчас, воспользовавшись старой версией под MS-DOS (с помощью DosBox) или современной версией, доступной в репозиториях своего Linux-дистибутива.


Поскольку я использую OpenSUSE, то установка плеера сводится к простой команде:

sudo zypper install ocp

Уверен, что для Debian-like систем это также сработает с пакетным менеджером apt. Запускается командой ocp, после чего открывается встроенный файловый менеджер. Выбрав композицию, подтверждаем нажатием Enter и воспроизведение начинается.


Прелестью трекерных форматов был, разумеется, малый размер файлов. Во времена, когда операционная система помещалась на трех дискетах, MP3 был почти непозволительной роскошью. Шутка ли, каждый MP3-трек, сжатый в среднем качестве, занимал от 3 до 5 мегабайт дискового пространства. Сжатый с помощью ZIP-архиватора XM-трек той же длительности занимал всего лишь 300-500 килобайт.

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

Open Cubic Player был отнюдь не единственным плеером под MS-DOS. Широкую популярность также получил Mpxplay, требующий как минимум 100 Mhz процессора и имеющий поддержку вполне современного комплекта форматов. Среди них есть и ставшие весьма популярными форматы сжатия аудио как без потерь (ALAC, FLAC), так и с ними (Vorbis, MP3, WMA, etc ). Плеер обладал широчайшими возможностями для своего времени, поддерживая даже воспроизведение аудиопотоков по сети (интернет-радио).


Развитие мультимедийных возможностей компьютеров в середине 90-х стало мейнстримом. Увеличивающиеся мощности и новые модели звуковых карт стали воспроизводить звук все качественнее, а появление новых технологий объемного звука совершили революцию как в создании музыки, так и в кинематографе и компьютерных играх. Что нас ждет еще через 20 лет, сказать сложно. Но, видя столь значительный прогресс, можно осторожно предположить, что это будет здорово!

NedoOS многозадачная операционная система для русского ZX Spectrum со средами программирования на ассемблере, Basic, Pascal, C, NedoLang. Работает на TR-DOS, FAT16 и FAT32 с длинными именами, поддерживает tar, gz, zip, rar2 и практически все реально используемые форматы спектрумовских файлов, сетевые утилиты включают Web-браузер и Web-сервер, Telnet-клиент и Telnet-сервер, IRC-клиент и др. Под ОС пишутся игры, в том числе сетевые. Сейчас в репозитории 6 участников. Исходный код всей системы (58 программ) составляет 230 тысяч строк на ассемблере и 70 тысяч строк на Си.

Введение

Архитектура компьютера

ZX Spectrum 8-битный компьютер на базе процессора Z80. От прочих подобных компьютеров отличается тем, что вместо специализированного видеоконтроллера у него просто комбинация счётчиков и мультиплексоров (в оригинале собранная в БМК, но легко переводимая на рассыпуху микросхемы мелкой логики). За счёт этого компьютер сначала победил в ценовой гонке и стал машиной по умолчанию для bedroom programming, а потом легко убежал от оригинального производителя и завоевал важнейшее место в компьютеризации многих стран мира. В том числе стран, бывших в составе СССР, где Spectrum-совместимые машины выпускались околомиллионными тиражами (во всяком случае, больше, чем БК, ДВК и УКНЦ, вместе взятые).

Потрясающий воображение список известных клонов тут. Открытость архитектуры (с точки зрения паяльника а без паяльника наши клоны даже к телевизору было подключить проблематично) превратила ZX Spectrum в весьма навороченную платформу, с нетипичными для других 8-битных платформ (которые уже мертвы или заспиртованы) мегабайтами, мегагерцами, винчестерами и сетевыми картами.

ZX Spectrum до сих пор работает как платформа для инди-игр (см. идущие сейчас конкурсы Yandex Retro game battle и Твоя игра 6, дедлайн которого продлён до 1 декабря), но разработка уже редко происходит в первоначальном формате, т.е. на самом Спектруме. Это объясняется среди прочего тем, что нативные среды разработки, написанные под TR-DOS в 90-х и 2000-х, отстали от жизни, а на смену им не пришло ничего нового.

Необходимость операционной системы

Операционные системы для Спектрума пишутся с давних пор. Операционная система, которая сидит в ПЗУ, позволяет писать на языке Бейсик и возиться с магнитной лентой. Дисковые операционные системы TR-DOS, GDOS, +3DOS и т.п. добавляли в Бейсик команды работы с дискетой, однако серьёзными утилитами обросла только TR-DOS, причём не за счёт довольно неуклюжего бейсик-интерфейса, а за счёт документированных (и не очень) точек входа в ПЗУ TR-DOS.

Если не считать нескольких версий CP/M (которая изначально писалась не для Спектрума и не использует по достоинству его возможности), первой серьёзной спектрумовской ОС была однозадачная iS-DOS (раз, два, три, архив), разработанная в Санкт-Петербурге в самом начале 90-х. Она из коробки предоставляла командер и файловую систему с подкаталогами (ни с чем не совместимую), редактор текстов произвольного размера, много дисков утилит и возможность расширения своими резидентами. К сожалению расширения только в пределах окна ОЗУ размером 48K. Первые версии iS-DOS довольствовались 41K под всю систему, резиденты и программу пользователя, остальное пространство ОЗУ занимал экран размером 6912 байт.


iS-DOS в естественной среде обитания

Последние версии, до сих пор выходящие под названием TASiS (раз, два) и заточенные под клон ATM-Turbo 2+, позволяют развернуться на все 64K адресного пространства, убрать экран из памяти и переключать странички ОЗУ, но ядро системы в адресном пространстве всё равно остаётся. (То же касается и CP/M во всех известных версиях система занимает верхние адреса и неистребима.)

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

Уже упомянутый iS-DOS получил распространение в Санкт-Петербурге и Москве. Примерный функциональный аналог iS-DOS на TR-DOS диске X-DOS остался в пределах Кирова.


X-DOS и её командная строка

Многооконная система ДОМЕН ОС/Pink Floyd, также из Санкт-Петербурга, не дожила до юзабельного состояния. В частности, жёсткие диски она не поддерживала, и в ней не было никаких средств разработки.


ДОМЕН ОС и её документация в HTML

Харьковская система DNA OS, в основном заточенная на копирование файлов, принесла определённую пользу хозяевам винтов, но софт под винт в ней так и не появился.


DNA OS и её файловый менеджер

Не дожили до жизнеспособных релизов московская NK-DOS, братская NeOS, гродненская DOORS\AQUA и саранская ZX-OS/ZXRTK. Из многозадачных ОС ближе всего к пользователю подошли многооконные MythOS (Днепропетровск) и ChaOS (Таганрог), но и они закончили свою жизнь в исходниках тоже без поддержки жёстких дисков и без средств разработки.


MythOS и её консоль


ChaOS и её хаос

Почему же было так много неудач?

Аппаратные требования для многозадачной операционной системы

Проблема всех ранних ОС для Спектрума была в том, что разработчики пытались обеспечить своему творению максимальную совместимость. Например, на iS-DOS с машинами начиная с ZX Spectrum 48K (с дисководом или HDD), а на большинстве последующих систем с ZX Spectrum 128K. Это накладывало неизгладимый отпечаток на распределение памяти.

Дело в том, что на 48K-машинах полное адресное пространство Z80 размером 65536 байт разделялось на 2 части: 48K ОЗУ (из которых 6912 байт отъедал экран, что оставляло 41 килобайт под всё остальное) и 16K ПЗУ Бейсика, от которого реальной пользы для ОС нет. В 128K дела обстояли лучше, но ненамного. Экран из адресного пространства Z80 там можно убрать (выбрав второй видеобуфер), но переключать страницы ОЗУ можно только в верхней четвертинке (с адреса 0xc000) адресного пространства. Остальные 32K ОЗУ не переключаются. А нижние 16K так и продолжают содержать ненужное для операционной системы ПЗУ. Конечно, фирменный 128K позволяет внешним устройствам (таким как LEC Memory Extension, DISCiPLE/+D, MB-02) подменять нижние 16K, а его потомки, начиная с +3, обычно имеют тот или иной встроенный порт для этого (чаще всего там доступна только одна страница ОЗУ), но половина адресуемой памяти всё равно не может меняться с переключением задач.

Представьте, что вы пишете текстовый или графический редактор под операционную систему для ZX Spectrum 128K. Очевидно, верхние 16K слишком маленький объём для текста или иллюстрации (речь не о стандартных экранах в 6912 байт), и надо либо постоянно подгружать файл с диска (что медленно и неудобно), либо раскидать документ по страницам. Где же в этом случае будет располагаться код самого редактора, его переменные и стек? Не в верхних 16K ОЗУ, потому что там документ. Не в нижних 16K, потому что там, скорее всего, ПЗУ. Выходит, всем задачам придётся делить между собой один общий блок в 32K ОЗУ. _{Релоцируемые резиденты, разбитые, допустим, по 256 байт, вызывают процедуры из верхнего ОЗУ, отдельные резиденты буферы для работы с данными, стек тоже ограничен 256 байтами} Это очень неудобно для разработчиков. Результат: под такие системы писали только сами авторы, да и у них хватало запала только на год-два, чего недостаточно даже для создания среды разработки.

Таким образом, для удобной многозадачной системы на Спектруме жизненно необходимо иметь переключаемые страницы ОЗУ в каждой из четвертинок (выбор именно четвертинок по 16К традиционен для Speccy) адресного пространства Z80. Спектрумовских схем, которые умеют это делать, немного: это малоизвестная ZX-MMU от fk0 (2000) и более-менее распространённая ATM-Turbo 2(+) (1992, 1993):


Из документации. Установленный бит 6 включает управление через порт #7ffd (ПЗУ TR-DOS автоматически подменяет ПЗУ 48 Бейсика при исполнении кода в #3dxx), в противном случае бит 7 просто включает заданную страницу ПЗУ. ROM2 бит 4 порта #7ffd, он работает всегда.

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

Разработка

Предыстория; что такое NedoPC

В 2002-2003 годах на просторах трёх континентов родилось движение NedoPC, которое кратко можно описать как эмм разработку компьютеров из подручных средств. И начали NedoPC с того, что другие на тот момент закончили производить Спектрумы и устройства для них. А в качестве Спектрума взяли тот самый Turbo 2+ (1993) потомок ATM-Turbo 2 (1992), который потомок ATM-Turbo (1991), который потомок Pentagon 128 (1990), известного в узких кругах как АТМ 128 (историю борьбы фирм в лихие 90-е можно прочитать в описании к Honey Commanderу). В своё время Turbo 2+ (к которому уже автоматически приклеилось обозначение ATM, как в прошлых версиях) замахивался чуть ли не на замену IBM PC ранних комплектаций с HDD (потом и CD-ROM), аналогом EGA, XT-клавиатурой (потом и AT), COM-портом, ЦАП, АЦП (также игравшими роль модема) и играми Принц Персии и Gobliiins, передранными абсолютно точно с PC-версии (не упоминаю весь софт, его много). Но часть остроумной схемы была упрятана в ПЛМ, из-за чего скопировать её мог мало кто. На просторах Украины раздавались слухи о замене ПЛМ на ПЗУ и о копировании отдельно контроллера HDD, но в общем и целом компьютер в 90-е встречался куда реже Пентагона. К счастью, потом разработчики Turbo 2+ фирма МикроАРТ передали всю документацию в свободное пользование.

Практически сразу в орбиту NedoPC втянулось несколько разработчиков софта, и пошла речь об операционных системах. Иначе ответ на вопрос куда нам плыть не получался. Первым плодом тяжких раздумий в 2005 году была уже упомянутая система TASiS, ради которой были приобретены исходники iS-DOS.

Параллельно, в 2007 году, один из авторов этой статьи создал виртуального персонажа SMAN, который как раз и разрабатывал многозадачную операционную систему. И да, она тоже прошла через этап резидентов в нижнем ОЗУ. Этот этап затянулся на годы, в 2016-2017 был даже написан компилятор Си-подобного языка NedoLang, влезающий в 48K (также компилирует под ARM Thumb). Гордиев узел был разрублен только с появлением графического редактора Scratch (2018).


Scratch и его меню

Выбор в 2018 году было совершить уже легко: совместимость с ATM-Turbo 2+ была доступна всем пользователям если не на оригинальной железке и не на NedoPCшных ZX Evo и Pentagon 2.666LE, то на ATM3 от Zorelа или хотя бы в эмуляторе (Unreal Speccy, Xpeccy, ZXMAK2, Es.pectrum и др.).


Turbo 2+ (1993, но плата явно новее)


Pentagon 2.666LE (2009), весьма редкая машина


ZX Evolution (2009), можно купить в любой булочной


ATM3 (2017), достать можно только по знакомству или изготовить самому

С этого момента система получила название NedoOS и стала развиваться взрывообразно.

Надо отметить, что для сдерживания фантазий на первоначальном этапе этого взрыва система была построена в основном на командах, совместимых с CP/M и MSX-DOS. До сих пор список команд разбит на три раздела: совместимые с CP/M (сейчас их 13, их использование не рекомендуется из-за неудобной системы FCB), совместимые с MSX-DOS (их 11, там имя файла уже идёт текстом, а вместо структур FCB используются числа хэндлы) и несовместимые (в основном нефайловые, их сейчас 48, но некоторые планируется выбросить).

Система разработки на текущий момент

Исходные тексты NedoOS всё ещё не адаптированы под имеющиеся в системе компиляторы (NedoLang и его ассемблер NedoAsm, Turbo Pascal и BDS C). Пока только 5 утилит компилируются внутренними инструментами. А основная часть пакета собирается на PC с помощью SjASMPlus (основной код) и Z80 IAR C (файловая система FatFs и некоторые утилиты).

Файлы размещаются на выделенном SVN-сервере и состоят из исходников, бинарного релиза и коллекции тулзов для сборки на PC.

Система собирается одной кнопкой (батник или Makefile две системы сборки). Можно также одной кнопкой отдельно собрать один из таргетов (под HDD, SD-карту и т.п.) и сразу запустить эмулятор. Можно отдельно собрать каждую утилиту батником нижнего уровня. Две системы сборки получилось потому, что некоторые разработчики NedoOS сидят в Windows, а некоторые в Linux.

Кроме компиляторов имеются также командный процессор cmd.com (может исполнять *.bat) и написанный с нуля интерпретатор NedoBasic с графическими возможностями.


NedoLang компилирует себя

Архитектура системы

Устройство ядра

Часть NedoOS, видимая программе пользователя, это ряд вызовов в области памяти 0x0000..0x0038, так называемый керналь. Последний из этих вызовов обработчик прерывания 50 Гц, а далее с 0x0080 следует командная строка с параметрами для программы. Пока ещё устройство керналя совместимо с CP/M (вызов через 0x0005), но мы потихоньку от этого отходим (CP/M-вызовы используются только в 4 программах из 58). Все системные вызовы организованы как макросы (программы используют модуль /src/_sdk/sys_h.asm с этими макросами и константами) и могут быть существенно изменены по мере развития ОС. Следствием этого является необходимость пересборки всей системы и прикладного софта при каких-либо изменениях в этих макросах но, как мы видели, это делается одной кнопкой.

Внутренняя часть NedoOS спрятана в страницах ОЗУ и содержит:

• обратные стороны вызовов керналя;
• продолжение обработчика прерывания с планировщиком задач (шедулером);
• системный обработчик прерывания, он без планировщика, зато вызывается всегда читает клавиатуру, мышь и часы, по комбинации клавиш переключает фокус (см. ниже), выставляет палитру и видеорежим;
• набор файловых и управляющих функций (BDOS), вызываемый через call 0x0005, как в CP/M и MSX-DOS;
• драйверы блочных устройств (SD-карта на Z-Controller, SD-карта на NeoGS, IDE HDD, дискета, USB flash на плате ZXNetUSB);
• драйвер клавиатуры (обычная 40-клавишная или PS/2-клавиатура ZX Evo);
• драйвер мыши (Kempston mouse с колёсиком);
• драйвер часов реального времени (по схеме Mr. Gluk), также система предоставляет время от начала работы в 50-герцовых квантах;
• драйвер сетевой карты (Wiznet W5300 на ZXNetUSB);
• файловую систему FatFs для FAT-16 и FAT-32;
• файловую систему TRDOSFS для TR-DOS дискет и RAM-диска;
• описатели смонтированных файловых систем;
• описатели открытых файлов FatFs, открытых файлов TR-DOS и открытых очередей (пайпов);
• описатели запущенных задач.

Все драйверы вкомпилированы в ядро, поэтому есть несколько разных таргетов сборки системы (ATM2, ATM2+HDD, ATM3, ZX Evo, Pentagon 2.666LE).

Обработчик прерываний, который располагается в пространстве пользователя, выглядит так:

        push af        push bc        push deuser_fdvalue6=$+1        ld a,fd_system ;зависит от текущей страницы экрана        out (0xfd),a ;уходим в контекст ядра (короткая адресация порта допустима на этом железе), там сохраняются прочие регистры и происходит переключение задач;---------;после выхода из контекста ядра:;bc=memport0000;d=pgmain        out (c),d ;may switch this code pagecurpg16k=$+1        ld a,0        ld b,memport4000/256        out (c),acurpg32klow=$+1        ld a,0        ld b,memport8000/256        out (c),acurpg32khigh=$+1        ld a,0        ld b,memportc000/256        out (c),a        pop de        pop bc        pop af        ei        ret

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

Задача может сменить обработчик прерываний, можно с возвратом в него и произвольным кодом после него. Для этого есть определённые рекомендации и примеры.

Система терминалов

Задачи делятся на три типа:

1. те, которым экран вообще не нужен,
2. те, которым достаточно текстового терминала,
3. графические с собственным экраном требуемого разрешения и собственной палитрой.

В NedoOS, помимо понятия текущей задачи, имеется понятие фокус (доступ к клавиатуре, мыши и экрану). Фокус между задачами переключается вручную (по комбинации Symbol Shift+Enter) или автоматически (при включении графики, выключении графики или закрытии задачи).

Задачи типа (1) никогда не получают фокус. Более того, задачи типа (2) тоже не получают фокус, вместо них фокус имеет текстовый терминал, к которому они привязаны. А привязаны они через потоки stdin и stdout, по которым гуляют буквы, цифры, закорючки и коды терминала VT-100 с некоторыми дополнениями. Stdin и stdout реализованы через библиотеку stdio.asm как очереди (пайпы). В ядре очередь имеет буфер в 255 байт. Функции записи и чтения из очереди возвращают, сколько реально прочитано или записано (как и для файлов) и не закрыта ли очередь с другого конца. Эти потоки наследуются от отца к сыну. Но в конечном итоге отображается всё терминалом term.com, который можно скроллить и даже копипастить. Есть также сетевой Telnet-сервер netterm.com. Этот netterm.com можно и не запускать, а вот term.com запускается автоматически при старте системы.


Nedovigator в терминале, а терминал прокручивается колесом мыши

Для задач типа (3) речи о рисовании пикселей через систему, конечно, не идёт для этого не хватает мегагерцев Z80 (у большинства пользователей их всего 14). Поэтому рисовать надо через память. А поскольку экранных областей на ATM всего две (как и на 128K), только одна задача может иметь собственные страницы экрана. Страницы экрана перехватываются при смене фокуса, а вместо них задаче-лузеру отдаётся фальшивый номер страницы страница, которую можно просто портить. Когда задача получает фокус, ей приходит об этом отдельное сообщение как бы от клавиатуры, но не соответствующее ни одной реальной кнопке. Это позволяет задаче вовремя восстановить экран. Ещё задача может включить режим, когда система сама хранит за неё экран и восстанавливает его.

Командная строка

Функции командной строки реализует утилита cmd, которая автоматически запускается при запуске системы. Точнее, первая задача idle запускает term с параметрами cmd.com autoexec.bat. Это значит, что cmd выполнит указанный батник. Команды, прописанные там, выполняются по порядку. По умолчанию команды выполняются с ожиданием окончания, но если команда это запуск программы, то перед ним можно поставить start программа будет работать в фоновом режиме (только это не совместимо с концепцией наследования stdin и stdout данные в очередях могут быть перемешаны).

После окончания операции, указанной в параметре (если параметр вообще был), cmd обычно завершается. Исключение оставлено только для autoexec.bat, чтобы после его окончания не остаться с разбитым корытом. Правда, в случае чего idle ожидает одновременного нажатия C+M+D и может перезапустить term с cmd.

Работа в командной строке напоминает MS-DOS. Можно перенаправить вывод запущенной операции в файл (например, dir > filename) или в другую программу (например, dir | more.com), можно перенаправить ввод (например, more.com < filename). Но передача по цепочке пока не поддержана.

Для более удобной работы с файлами используется командер Nedovigator (nv.com).


Котик, потому что Nedovigator вы уже видели

Размещение системы

Надо уточнить, что каждая файловая система у нас примонтирована к определённой букве, так что пути выглядят как m:/bin/filename.txt. Очереди имеют букву монтирования z:, но пока открываются без имени связь между задачами идёт путём передачи номера (хэндла) очереди.

Чтобы избежать специализированных загрузчиков типа GRUB, NedoOS надеется на то, что в ПЗУ компьютера имеется возможность запуска хобетного файла (*.$C) с нужного устройства например, в ZX Evo файловым браузером или по кнопке 5 в главном меню, а на Pentagon 2.666LE через встроенный копировщик Fatall. В противном случае придётся грузить ОС с TR-DOS дискеты. Системные файлы располагаются в каталоге /bin системного диска, игры лежат в /nedogame. Дополнительные файлы игр обычно размещаются в подкаталоге, одноимённом игре: например, раскрашенная под NedoOS игра /nedogame/br.com (Чёрный Ворон) имеет также каталог /nedogame/br с графикой, музыкой и уровнями.


Цветной Ворон

Текущие возможности

Память: поддерживается до 4M ОЗУ (настраивается в системе сборки), память выдаётся задачам по запросу страницами по 16K, задачи могут и сами их возвращать в систему. Из-за отсутствия защиты памяти в железе всю память можно считать разделяемой. По умолчанию страницы выделяются с начала памяти, не считая нескольких системных страниц. Своп не поддерживается (он рассматривался на ранних этапах, но требует перенумерации страниц, что сильно снизит производительность обычных задач).

Многозадачность: вытесняющая (по прерыванию 50 Гц) и кооперативная; одновременно может быть запущено до 16 задач (одна из них idle, её можно снять, но тогда YIELD не даёт гарантий); можно подставить свой плейер музыки в системный обработчик прерываний будет выполняться в контексте ядра с тремя страницами пользователя (переключать их на лету пока нельзя). Задачи могут быть в замороженном состоянии (если они только что созданы, удаляются или ожидают потомка). Можно в cmd смотреть список задач, их активность и наличие графического режима, снимать с исполнения (при этом освобождаются их страницы, файловые записи FatFs и сетевые сокеты).

Файлы: можно одновременно открыть до 16 файлов FAT, 8 файлов TR-DOS и 8 очередей. Можно одновременно читать и писать несколько файлов (важно для компилятора) даже на дискете! Можно считывать параметры файла, указатель на текущую позицию, менять эту позицию, создавать и переименовывать директории. Очереди предполагают две задачи-пользователя, их требуется открывать один раз (при создании), но закрывать дважды. Файловые операции выполняются в контексте ядра, в это время не работает планировщик задач, но работает системный обработчик музыки.

Работа с сетью: протоколы ICMP, TCP, UDP, одновременно до 8 сокетов. Имеются утилиты ping, time, telnet, netterm (Telnet-сервер), dmirc (IRC-клиент), dmftp (FTP-клиент) 3ws (Web-сервер для копирования и удалённого запуска файлов), NedoBrowser (текстовый браузер с возможностью отдельно смотреть картинки jpg, gif, png, bmp и svg последние два формата с ограничениями; поддерживает протоколы http и gopher, https через прокси), wget (фоновая скачка файлов, запускается из браузера, умеет автоматически запускать просмотр графики и плейер музыки).


NedoBrowser что-то ищет в Интернете

Работа с архивами: .tar и .rar доступны на чтение и запись (ZXRar урезанный аналог Rar 2.x под DOS без ряда кодов, solid архивов, мультимедийного формата и шифрования, ZXUnRar поддерживает все коды и solid архивы, но тоже не поддерживает мультимедию и шифрование), .gz и .zip только на чтение. Пока всё только через утилиты командной строки.

Типы документов: файловые ассоциации прописаны для встроенного командера Nedovigator в файле nv.ext. Сейчас этот файл выглядит так:

bmp:scratch.combat:cmd.comtxt,new,ext,ini,nfo,diz:texted.comgif,jpg,png,htm,svg:browser.comtfc,pt2,pt3,mt3,m  :player.com (pt3 можно редактировать специальной версией Pro Tracker под NedoOS)bas:basic.comzip,gz :pkunzip.comtrd,scl,fdi,tap:dmm.com (программы TR-DOS и ленточные  они запускаются на ZX Evo путём монтирования образа, их можно переключать, сохранять и выключать по кнопке Magic; то есть можно, например, играть в игру и периодически переключаться и писать описание)16c,scr,fnt,img,3  ,888,y  ,+  ,-  ,plc,mc ,mcx,grf,ch$,mg1,mg2,mg4,mg8,rm ,mlt:view.commod:modplay.comtar:tar.comsna,b  ,z80:nmisvc.comrar:unrar.com

Имеется также с десяток игр, в том числе эмулятор Супер Марио (для работы требуется дамп картриджа), раскрашенный Eric and the Floaters, частичный порт Бесконечного лета и сетевой Snake.

Планы

• Расширение функционала батников (уже передаются параметры)
• IDE и self-hosting
• Слои в графическом редакторе
• ...

Заключение

На текущий момент в NedoOS реализован весь нужный костяк функций, так что при наличии нужного железа системой удобнее пользоваться, чем не пользоваться.

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


В основном разработчики NedoOS обитают в IRC-канале #mhm на irc.forestnet.org (также доступно через http://chat.forestnet.org/). Существует вечерний Twitch-канал (с зеркалом на YouTube). С сайта NedoOS можно скачать стабильную версию и свежие исходники.

"...Often you need to execute a synthetic two-byte instruction from the keyboard. This can occur during your day-to-day user of the HP-41..."
/ HP-41 Advanced Programming Tips /


Как многие знают, в конце 1980-х в СССР были весьма популярны программируемые микрокалькуляторы, совместимые с Б3-34: МК-54, МК-61, МК-52. Для них создавали программы, игры, исследовали недокументированные возможности, писали статьи. Я и сам через это прошёл в своё время. И вот недавно задумался: а ведь в США тоже должно было быть что-то подобное, близкое по духу именно ко всему тому, что происходило вокруг наших программируемых калькуляторов. И да я оказался прав. Встречайте: HP-41.

Как и Б3-34, HP-41 это программируемый RPN калькулятор (RPN обратная польская запись, вычисления в форме 2 2 +, а не 2 + 2 = ) с похожей идеологией, но значительно более функциональный. Появился он практически в то же время, что и наш Б3-34 1979 год и вскоре стал культовым: для него написано множество программ, книги в том числе, о недокументированных возможностях, и даже до сих пор выпускаются модули расширения. Всего было выпущено полтора миллиона этих калькуляторов.

К схожей судьбе можно добавить что, как наш МК-52 летал на Союзах в качестве резервного вычислительного устройства, так же и HP-41 летал на Шаттлах.

Хотя существует три модификации HP-41 (C, CV, CX), их можно считать полностью совместимыми, так как отличаются они очень незначительно по сути, только объёмом памяти. Калькуляторы HP с другими номерами несовместимы с HP-41, хотя и имеют некоторые общие черты.

Одной из особенностей HP-41 является достаточно редкий для калькуляторов индикатор 14-сегментный. Это позволяет отображать на HP-41 буквы и различные символы что, наряду со звуком и модулями расширения, является большим преимуществом перед Б3-34.

Память HP-41C с точки зрения пользователя 63 регистра, по 7 байт каждый. При этом можно выбирать, сколько используется под программу и сколько под данные. Модули расширения увеличивают доступный объём памяти скажем, 82106A это ещё 64 регистра. Максимум при помощи таких модулей можно получить порядка 2кб, если занять все четыре слота.

Процессор свой, специфический. Чаще всего его называют NUT CPU, хотя это обобщённое название нескольких разных процессоров. Тактовая частота 0.35 мГц. Что касается разрядности то, как это нередко бывает с калькуляторами, в силу специфики архитектуры сложно назвать точную цифру.

Помимо модулей памяти (для HP-41C) существует много других модулей расширения библиотеки программ на ПЗУ, устройство записи/чтения на магнитных картах, считыватель штрихкодов и пр.

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

Первый и основной из них штатный язык программируемого калькулятора. Идеологически он похож на язык Б3-34 и, хотя и называется FOCAL, к одноимённому языку программирования отношения не имеет расшифровывается слово как Forty One Calculator Language. Команды FOCAL это, по сути, вызовы подпрограмм в машинных кодах что-то вроде инструкций виртуальной машины, заточенной под вычисления, десятичную систему и плавающую точку.

Второй, весьма популярный, способ называется Synthetic programming и является набором недокументированных расширений FOCAL, основанных на использовании уязвимости в прошивке калькулятора, позволяющей создавать новые команды.

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

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

Клавиатура и командный режим

Несмотря на продвинутый алфавитно-цифровой индикатор, клавиатура у калькулятора самая обычная. Что, при огромном числе различных режимов и функций, делает ввод программы и операции с ней весьма утомительным занятием (вполне сопоставимым с таковым для Б3-34 совместимых калькуляторов).

Каждая клавиша имеет три функции (в отдельных случаях больше). Скажем, кнопка 0, помимо цифры 0, предназначена для ввода пробела и числа Пи.
Не все функции доступны через комбинации кнопок некоторые требуется набирать по буквам, в режиме ALPHA. Буквы подписаны над кнопками в порядке ABCDEF....


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

Интересно, что операторы доступные через комбинацию кнопок можно вводить и побуквенно. К примеру, звуковой сигнал (BEEP) получается нажатием SHIFT 4, но можно нажать кнопку XEQ, затем ALPHA, набрать слово BEEP по буквам, снова нажать ALPHA.

Собственно, XEQ (от слова execute) позволяет сразу выполнить любую встроенную функцию или вызвать имеющуюся в ОЗУ или ПЗУ в том числе, в модуле расширения.

Список всех фактически доступных в калькуляторе функций можно получить через SHIFT CATALOG 3 (управление просмотром через R/S, SST, BST)

Регистры и работа с ними

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

Регистр ALPHA (A) может хранить до 24 символов и его содержимое отображается на экране.
0,1,2,3, регистры данных, могут хранить или одно число или до 6 символов (или до 7 шагов программы)
X,Y,Z,T стековые регистры (на самом деле тоже регистры данных, но организованы в виде стека). X верхний.
L сюда сохраняется последнее, перед изменением, содержимое регистра X
PC текущий шаг программы

На дисплее обычно отображается содержимое X или ALPHA регистра, но можно вывести и другие.

Если просто набрать число на клавиатуре, оно попадает в X регистр (соответственно, он и отображается на экране).
Если набрать на клавиатуре строку символов (после нажатия кнопки ALPHA), то строка помещается в ALPHA регистр (аналогично, он и отображается на экране).

Однако, само нахождение на экране какой-либо информации не означает, что она находится в регистре. Это касается, к примеру, сообщений об ошибках и результатов VIEW. Они как бы закрывают сверху отображаемый регистр. В таких случаях, чтобы убрать сообщение не меняя содержимого регистров, используется клавиша "<-".
В случае же, когда на экране отображено содержимое регистра, та же клавиша "<-" удаляет его содержимое.

Нажатие ENTER проталкивает копию числа в стек. Т.е., если набрать 1 ENTER то 1 окажется и в регистре X и в регистре Y. Если затем набрать 2, то в регистре X будет 2, в регистре Y будет 1.

CLX очищает X, CLA очищает ALPHA

X<>Y меняет местами содержимое X и Y
+, -, *, / совершают операцию над содержимым X и Y и помещают результат в X, при этом то, что было в Y регистре теряется, а то, что было в X помещается в регистр L (при необходимости может быть скопировано обратно в X командной LASTX).

RCL номер_регистра копирует содержимое регистра данных с указанным номером в X (т.е., отображает его)
ARCL номер_регистра присоединяет содержимое регистра данных с указанным номером к регистру ALPHA

ASHF сдвигает содержимое регистра ALPHA влево на 6 символов (первые 6 символов теряются).

Просмотреть содержимое регистра можно и не помещая его в отображаемый X. Для этого используется команда VIEW (для просмотра регистров стека) и AVIEW (для просмотра ALPHA регистра)

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

STO номер_регистра копирует содержимое регистра X в указанный регистр данных
ASTO номер_регистра копирует содержимое регистра ALPHA (только первые 6 символов!) в указанный регистр данных

Чтобы RCL и STO работали с именованными регистрами стека, нужно добавлять ".":STO .Z

Команда SIZE устанавливает количество регистров данных, которые можно использовать (соответственно, при этом увеличивается или уменьшается количество доступных шагов программы):
Чем меньше SIZE, тем больше места под код.

Чтобы очистить всю память, нужно включить калькулятор, удерживая кнопку "<-" и после включения сразу отпустить её. Должно появится сообщение MEMORYLOST (срабатывает не очень стабильно).

Программный режим

Переход в режим программирования (и обратно) по клавише PRGM. В отсутствие программы отображается 00 REG nn. Число nn показывает количество регистров, доступных для шагов программы (см. выше про SIZE). По мере набора программы калькулятор иногда пишет PACKING, пытаясь уплотнить код. Если памяти для очередной команды не хватает, пишет TRY AGAIN.

При вводе программы слева показывается текущий шаг. Один шаг одна команда (неважно, введённая одной клавишей или побуквенно). Но надо учитывать, что один шаг может занимать разный объём памяти мало, если это простая команда типа CLA, и много, если это, скажем, длинная текстовая строка.
Перемещение по шагам SST (вперёд) и BST (назад). Удаление текущего шага "<-".

Программа запускается из командного режима (т.е. надо снова нажать PRGM) клавишей R/S. Ей же и останавливается.

В программном режиме доступны практически все функции имеющиеся в командном. Ввод команд, которые отмечены на клавишах, производится простым нажатием. Остальные команды вводятся через XEQ. Например, чтобы ввести TONE 3 надо нажать XEQ потом нажать ALPHA потом набрать побуквенно TONE снова нажать ALPHA и затем нажать 3.

Стирание программы: CLP метка (стирается от метки до END)

Переход на конкретный шаг: GTO.002 (предварительно надо выйти из программного режима).
Переход на начало: SHIFT RTN

Узнать текущее положение из командного режима можно, нажав и удерживая клавишу R/S либо SST

Метки, на которые потом можно осуществить переход, задаются через LBL метка и бывают двух типов глобальные (имена текстовые, вводятся в режиме ALPHA) и локальные (имена цифровые, либо однобуквенные текстовые). Цифровые занимают меньше памяти.
Переход на метку GTP метка

Полезно всегда ставить метку в первый шаг программы. Это позволяет запускать её, не переходя каждый раз в начало через XEQ метка или GTO метка.

Есть также косвенный переход GTO IND (фанаты HP-41 приводят это как свидетельство того, что машина Turing complete ;).

В конце программы вводится GTO (при этом появляется сообщение PACKING). В этом месте на экране появляется END

Например, программа по умножению любого числа на 2 выглядит так:

LBL "PRGNAME"2*END

Работа с подпрограммами (допускается вложенность до шести):

XEQ 04...LBL 04...подпрограмма...RTN

Условные переходы:

X=Y?21

В этом примере если X равно Y, то в стек (регистр X) помещается 2. В противном случае 1
Другими словами, если условие выполняется, то команда следующая после проверки пропускается.

Циклы

ISG Increment and Skip if Greater
DSE Decrement and Skip if Equal to or less than

Пример

1.00301STO 01LBL 01     BEEPISG 01     GTO 01     

Этот фрагмент можно использовать на собеседовании вместо крышек люков. С вопросом Сколько раз выполнится BEEP и почему?. Правильный ответ 3 раза.

Объяснение: параметры цикла задаются единственным дробным числом, которое помещается в стек. Число имеет формат iiiii.fffcc, где:

iiii начальное, оно же текущее, значение счётчика (индекс),
fff конечное значение
cc шаг

Таким образом, 1.00301 означает счёт от 1 до 3 с шагом 1
Очевидно, такое своеобразное решение позволяет экономить память, хотя читаемость кода, скажем так, слегка страдает.

Немного о выводе на экран строк:

AVIEW выводит на экран регистр ALPHA, VIEW регистр X

Команда APPEND присоединяет указанные символы к строке в ALPHA регистре. Вводится с клавиатуры как SHIFT K, в исходниках это выглядит как >TEXT

Пример:

"HELLO WORLD!";помещаем строку в ALPHA регистрAVIEW ; выводим на экранPSE ; делаем паузуCLD ; очищаем экран

При очистке экрана на него возвращается стандартный символ летящего гуся, показывающий, что программа выполняется. Если на экране текст, гусь не появляется.

Хотя на экране 12 знакомест, максимальная длина строки в одном программном шаге 15. С применением APPEND можно получить 24 (т.е. полная длина регистра ALPHA). При выводе на экран длинной строки, она автоматически скроллится:

"1234567890">"ABCDEFGHIJKLMN"AVIEW

Операции со строками ограничены тремя командами:
ASTO X помещает 6 первых символов из ALPHA в указанный регистр
ARCL X присоединяет в конец ALPHA строку из указанного регистра
ASHF сдвиг ALPHA на 6 символов влево (они теряются)

Ввод данных:

PROMPT выводит на экран содержимое ALPHA регистра и останавливает программу (соответственно, можно что-то ввести и нажать R/S, таким образом продолжив выполнение)
PSE приостанавливает выполнение программы примерно на секунду. При этом, если были нажаты цифры или буквы, пауза продлевается ещё на секунду, а итоговое значение помещается в регистр для дальнейшей обработки.

О звуке:

BEEP проигрывает стандартную последовательность одних и тех же четырёх нот
TONE цифра короткий писк одной из 10 частот (0 самая низкая...9 самая высокая). Частоты выбраны довольно странным образом. По-видимому, это было обусловлено экономией памяти.

Периферия

Среди периферийных устройств есть модули расширения памяти, ПЗУ с готовыми программами, устройство чтения/записи магнитной ленты (HP 82161A), магнитных карт (HP82104A), считыватель штрих-кодов, инфракрасный порт, принтер, плоттер, часы, интерфейс HP-IL (через который можно подключить калькулятор к различному оборудованию) и другое.

Модуль чтения/записи на магнитные карты мне достался в комплекте с HP-41. Карты это полоски магнитной плёнки на бумажном основании (в московском метро раньше были похожего типа проездные).


Каждая полоска имеет две дорожки т.е. её можно вставлять левой, либо правой стороной. На каждую сторону влезает 112 байт. Типичная программа занимает несколько карт.
Можно защитить сторону карты от записи, отрезав уголок.
Когда модуль вставлен в калькулятор, задействовано его ПЗУ. Соответственно, в калькуляторе появляется много новых команд для работы с картами. Можно читать и писать программы, регистры, и т.п. Можно даже защитить записываемую программу от просмотра (т.е. можно будет её загрузить и запустить, но нельзя будет увидеть саму программу).

Здесь можно посмотреть, как работает накопитель на магнитных картах.

К сожалению, устройство это ненадёжно и очень прожорливо до батареек (питается от самого калькулятора). Моё не работало жужжало мотором, но не протягивало ленту. Оказалось, что прижимной ролик внутри не просто развалился, а полностью исчез, оставив после себя лишь каплю вязкой грязи. Ролик я поменял на самодельный, но ленту он протягивает явно с трудом нужно точно подгонять диаметр. Проблема настолько типична, что на ebay даже продаются комплекты этих роликов.

Другим интересным устройством. также довольно распространённым среди владельцев HP-41, является считыватель штрих-кодов, который используется, в том числе, для загрузки программ в калькулятор непосредственно из книг. Представьте никаких долгих вбиваний программ с клавиатуры!.. Выглядит это так:

Разработка

Конечно, писать на FOCAL можно и прямо на калькуляторе. Но это довольно утомительно куда удобнее писать программу в текстовом файле. Но с компиляторами и эмуляторами ситуация сложная. Все они довольно странные и не очень стабильно работающие. Из тех, что запускаются под Win10, есть sim41 и v41 (v.7b). Первый запускается только из Visual Runfox, но зато в нём есть отдельный редактор программы (т.е. необязательно вводить и редактировать её с клавиатуры калькулятора).
Второй запускается без прелюдий, заметно лучше эмулирует калькулятор (хотя и не на уровне железа, о чём говорит, например, рассинхронизация звука с кодом), но программу вводить надо либо полностью вручную, либо загружать в виде бинарного .raw, который является не машинным кодом, а бинарным представлением FOCAL). Проблема в том, что для компиляции текстового исходника в raw придётся использовать утилиту HP41UC.EXE, которая запускается только из под DOS. Я использовал vDos с батником, замапив нужный директорий на диск через use f: c:\tmp

Компиляция исходника в бинарник:
hp41uc /t=test.txt /r=test.raw

Декомпиляция бинарника в исходник:
hp41uc /r=text.raw /t=text.txt

Чтобы лучше прочувствовать платформу, я написал небольшое 256 байт интро для DiHALT demo party.


Именно 256 байт просто потому, что больше в калькулятор, даже с установленным модулем расширения ОЗУ, не влезло бы. Понятно, что особых визуальных эффектов ожидать от калькулятора не приходится. Используется вывод различных строк, в том числе автоматический скроллинг длинных строк. Анимация с лицом вывод двух строк в цикле. DTMF имитируется очень условно, музыка тоже совершенно не похожа не оригинал в силу того, что не получится выбрать ни нужной тональности, ни длительности. Тем не менее, на музыку это всё же похоже. В конце используется стандартная особенность калькулятора отображать летящего гуся при занятости процессора и пустом регистре ALPHA.

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

Здесь можно посмотреть оба исходника.

Синтетическое программирование

Synthetic programming методика, основанная на использовании уязвимости, обнаруженной в редакторе программы калькулятора. Обычные штатные инструкции закодированы в памяти калькулятора несколькими байтами. Уязвимость позволяет (после довольно сложной подготовительной процедуры) изменять эти байты, получая новые инструкции с разнообразной функциональностью. К примеру, можно получить от команды TONE больше звуков, чем позволено штатно. Можно вывести на экран больше символов (из прошитого в ПЗУ набора), получать доступ к системным флагам и ряду других полезных вещей. Повторюсь, на практике использовать эту методику сложно и утомительно. Правда, существуют модули с подпрограммами, которые это облегчают.


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

Ещё одна сложность с применением синтетический инструкций заключается в том, что иногда они состоят из не-ASCII символов. Там возникают специфические сложности как с их вводом, так и с печатью такой программы на штатном принтере для HP-41. Да даже просто опубликовать такую программу в книге или журнале целая проблема (обычно рядом с командами пишут пояснения, как их следует понимать). Одно из решений проблемы считывание каждого символа при помощи считывателя штрихкодов из специальной таблицы:



Собственно, synthetic programming очень близко по духу к еггогологии в Б3-34 совместимых калькуляторах. В качестве иллюстрации можно посмотреть вот это письмо.

Люди даже писали на эту тему стихи! (взято из книги Synthetic Programming for the HP41C (W.C.Wickes)

MCODE

Машинный код, выполняемый непосредственно микропроцессором калькуляторам HP-41 называемый MCODE он в 5-120 раз быстрее, чем стандартный FOCAL.

Для запуска на калькуляторе программа в MCODE должна быть записана в ПЗУ (либо в эмулятор ПЗУ). Существуют специальные модули, позволяющие загружать в себя код по USB или RS232 и даже писать в M-CODE непосредственно на калькуляторе. Обобщённо они называются MLDL и бывают как древними, от самой HP, так и современными.
Из кросс-ассемблеров я нашёл только древний под DOS.

Пара слов об архитектуре процессора. Поскольку он заточен главным образом под математику, есть своя специфика. Основные регистры (а регистры процессора это вовсе не регистры используемые в FOCAL!) A,B,C,N,M 56-разрядные.
Есть также более короткие регистры флагов, клавиатуры, динамика, указателей, 16-разрядный счётчик команд, а также четырёхуровневый стек возвратов (четыре 16-разрядных регистра).

В ПЗУ, связанном с процессором последовательной шиной и где, собственно, находится управляющая программа калькулятора, написанная на MCODE, байты имеют ширину 10 бит. Процессор адресует 64K ПЗУ, из которых 12K занимает операционная система. Что касается ОЗУ, то оно не отображается в адресное пространство и является для процессора периферийным устройством. Байты ОЗУ имеют ширину 8 бит, но логически процессор работает с ОЗУ как с 56-разрядными регистрами.

Поскольку я не писал на MCODE (задушила жаба на $250 за эмулятор ПЗУ), личным опытом программирования в MCODE поделиться не смогу.

Инструкции там вполне традиционны, хотя многие мнемоники довольно специфические. К примеру:

B=A; скопировать содержимое регистра A в BA<>C; поменять местами A и CA=A+B ; сложить A и B и поместить результат в AA=B=C=0; поместить 0 в регистры A,B,CC=0 M; поместить 0 в мантиссу (нибблы 3-12) регистра C?A<C; установить флаг переноса, если A меньше CJC -02; перейти по смещению, если установлен флаг переносаREAD n; поместить содержимое регистра ОЗУ (от 1 до 15) в регистр CPUSH addr; поместить адрес в стек подпрограммGOSUB 815B ; переход к подпрограмме

Примерный MCODE аналог FOCAL команды TONE n:

178 C=REG 5/M; recalls status register M358 ST=C; rightmost byte (nybbles 1 and 0 ) are loaded in status bits (flags 0 to 7)379 *05A NCGO 16DE ; переход на адрес подпрограммы XTONE в ПЗУ

Что касается управления индикатором, то его контроллер не позволяет включать и выключать произвольные сегменты можно выводить лишь существующие в знакогенераторе символы. Это тоже стало причиной, по которой я не стал заморачиваться с эмулятором ПЗУ и программированием в MCODE.

Для вывода символов нужно выбрать индикатор инструкцией процессора PRPH SLCT FD и далее работать с регистрами индикатора через WRIT/READ

Эпилог

Честно говоря, логика работы и система команд калькулятора довольно запутанные. На мой взгляд, для человека, который может освоить подобное нет никакой проблемы просто писать в машинных кодах какого-нибудь простого процессора. В наших Б3-34 совместимых калькуляторов всё, конечно, тоже непросто, но там и возможностей намного меньше, из-за чего не было ощущения такой запутанности.
В принципе, аргумент за нагромождение в HP-41 псевдокода поверх микропроцессора необходимость математических вычислений, поскольку, всё же, именно это должно быть простым для типичного пользователя калькулятора.

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

Я собрал различную документацию по HP41 в один архив, если кому интересно можете скачать (выложил на время, потом уберу).

Недавно я написал своё первое интро 4K на Rust и представил его на Nova 2020, где оно заняло первое место в конкурсе New School Intro Competition. Написать интро 4K довольно сложно. Это требует знания многих различных областей. Здесь я сосредоточусь на методах, как максимально сократить код Rust.


Можете просмотреть демо-версию на Youtube, скачать исполняемый файл на Pouet или получить исходный код с Github.

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

Конфигурация

Всё интро написано на комбинации Rust и glsl. Glsl используется для рендеринга, но Rust делает всё остальное: создание мира, управление камерой и объектами, создание инструментов, воспроизведение музыки и т.д.

В коде есть зависимости от некоторых функций, которые ещё не включены в стабильный Rust, поэтому я использую набор инструментов Nightly Rust. Чтобы установить и использовать этот набор по умолчанию, нужно запустить следующие команды rustup:

rustup toolchain install nightlyrustup default nightly

Я использую crinkler для сжатия объектного файла, сгенерированного компилятором Rust.

Я также использовал shader minifier для препроцессинга шейдера glsl, чтобы сделать его меньше и удобнее для crinkler. Shader minifier не поддерживает вывод в .rs, так что я брал необработанную выдачу и вручную копировал её в свой файл shader.rs (задним умом ясно, что нужно было как-то автоматизировать этот этап. Или даже написать пул-реквест для shader minifier).

Отправной точкой послужила моё прошлое интро 4K на Rust, которое тогда мне казалось довольно лаконичным. В той статье также более подробная информация о настройке файла toml и о том, как использовать xargo для компиляции крошечного бинарника.

Оптимизация дизайна программы для уменьшения кода

Многие из наиболее эффективных оптимизаций размера никак не назовёшь умными хаками. Это результат переосмысления дизайна.

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

Анализ ассемблерного кода

В какой-то момент придётся посмотреть на скомпилированный ассемблер и разобраться, во что компилируется код и какие оптимизации размера стоят того. В компиляторе Rust есть очень полезная опция --emit=asm для вывода ассемблерного кода. Следующая команда создаёт файл ассемблера .s:

xargo rustc --release --target i686-pc-windows-msvc -- --emit=asm

Не обязательно быть экспертом в ассемблере, чтобы извлечь выгоду из изучения выходных данных ассемблера, но определённо лучше иметь базовое понимание синтаксиса. Опция opt-level = "z заставляет компилятор максимально оптимизировать код для наименьшего размера. После этого немного сложнее выяснить, какая часть кода ассемблера соответствует какой части кода Rust.

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

Дополнительные функции

Я работал с двумя версиями кода. Одна протоколирует процесс и позволяет зрителю манипулировать камерой для создания интересных траекторий. Rust позволяет определить функции для этих дополнительных действий. В файле toml есть раздел [features], который позволяет объявлять доступные функции и их зависимости. В toml соего интро 4K есть следующий раздел:

[features]logger = []fullscreen = []

Ни одна из дополнительных функций не имеет зависимостей, поэтому они эффективно работают как флаги условной компиляции. Условным блокам кода предшествует оператор #[cfg(feature)]. Использование функций само по себе не делает код меньше, но сильно упрощает процесс разработки, когда вы легко переключаетесь между различными наборами функций.

        #[cfg(feature = "fullscreen")]        {            // Этот код компилируется только в том случае, если выбран полноэкранный режим        }        #[cfg(not(feature = "fullscreen"))]        {            // Этот код компилируется только в том случае, если полноэкранный режим не выбран        }

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

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

Использование get_unchecked

При размещении кода внутри блока unsafe{} я вроде как предполагал, что все проверки безопасности будут отключены, но это не так. Там по-прежнему выполняются все обычные проверки, и они дорого обходятся.

По умолчанию range проверяет все обращения к массиву. Возьмите следующий код Rust:

    delay_counter = sequence[ play_pos ];

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

Преобразуем код следующим образом:

    delay_counter = *sequence.get_unchecked( play_pos );

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

Более эффективные циклы

Изначально все мои циклы использовали выполнялись идиоматически как положено в Rust, используя синтаксис for x in 0..10. Я предполагал, что он будет скомпилирован в максимально плотный цикл. Удивительно, но это не так. Простейший случай:

for x in 0..10 {    // do code}

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

    setup loop variableloop:    проверить условие цикла        если цикл закончен, перейти в end    // выполнить код внутри цикла    безусловно перейти в loopend:

тогда как следующий код

let x = 0;loop{    // do code    x += 1;    if i == 10 {        break;    }}

непосредственно компилируется в:

    setup loop variableloop:    // выполнить код внутри цикла    проверить условие цикла        если цикл не закончен, перейти в loopend:

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

Другая, гораздо более трудная для понимания проблема с идиоматическим циклом Rust заключается в том, что в некоторых случаях компилятор добавлял некоторый дополнительный код настройки итератора, который действительно раздувал код. Я так и не понял, что вызывает эту дополнительную настройку итератора, поскольку всегда было тривиально заменить конструкции for {} конструкцией loop{}.

Использование векторных инструкций

Я много времени потратил на оптимизацию кода glsl, и одна из лучших оптимизаций (которая ещё обычно и ускоряет работу кода) состоит в одновременной работе со всем вектором, а не с каждым компонентом по очереди.

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

Чтобы использовать встроенные функции, я бы преобразовал следующий код

        global_spheres[ CAMERA_ROT_IDX ][ 0 ] += camera_rot_speed[ 0 ]*camera_speed;        global_spheres[ CAMERA_ROT_IDX ][ 1 ] += camera_rot_speed[ 1 ]*camera_speed;        global_spheres[ CAMERA_ROT_IDX ][ 2 ] += camera_rot_speed[ 2 ]*camera_speed;

в такое:

        let mut dst:x86::__m128 = core::arch::x86::_mm_load_ps(global_spheres[ CAMERA_ROT_IDX ].as_mut_ptr());        let mut src:x86::__m128 = core::arch::x86::_mm_load_ps(camera_rot_speed.as_mut_ptr());        dst = core::arch::x86::_mm_add_ps( dst, src);        core::arch::x86::_mm_store_ss( (&mut global_spheres[ CAMERA_ROT_IDX ]).as_mut_ptr(), dst );

что будет немного меньше по размеру (и гораздо менее читабельно). К сожалению, по какой-то причине это сломало отладочную сборку, хотя прекрасно работало в релизной. Ясно, что здесь проблема с моим знанием внутренних средств Rust, а не с самим языком. На это стоит потратить больше времени при подготовке следующего 4K-интро, поскольку сокращение объёма кода было значительным.

Использование OpenGL

Есть множество стандартных крейтов Rust для загрузки функций OpenGL, но по умолчанию все они загружают очень большой набор функций. Каждая загруженная функция занимает некоторое пространство, потому что загрузчик должен знать её имя. Crinkler очень хорошо сжимает такого рода код, но он не в состоянии полностью избавиться от оверхеда, поэтому пришлось создать свою собственную версию gl.rs, включающую только нужные функции OpenGL.

Заключение

Главная цель состояла в том, чтобы написать конкурентоспособное корректное интро 4K и доказать, что язык Rust пригоден для демосцены и для сценариев, где каждый байт имеет значение и вам действительно нужен низкоуровневый контроль. Как правило, в этой области рассматривали только ассемблер и C. Дополнительная цель состояла в максимальном использовании идиоматического Rust.

Мне кажется, что я довольно успешно справился с первой задачей. Ни разу не возникало ощущения, что Rust каким-то образом сдерживает меня или что я жертвую производительностью или функциями, потому что использую Rust, а не C.

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

Всем привет,

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

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

Немного о PowerPacker

Кранчер (упаковщик) PowerPacker использовался во множестве старых игр (для AmigaOS в частности). Видимо, на то время он обладал очень хорошим сжатием и временем работы, по сравнению с другими кранчерами. К тому же, он позволяет шифровать сжимаемые данные, давая возможность защитить ресурсы игры или программы (да, можно упаковывать и исполняемые файлы).

Сначала PowerPacker распространялся в виде самостоятельных исполняемых файлов: упаковщика и распаковщика. Затем, похоже, спрос на данный алгоритм сжатия вырос, и автор (Nico Franois) решил сделать своё творение платным, при этом перейдя на распространение уже в виде библиотеки powerpacker.library.

Получение исходников

Для получения исходников, как и в случае с RNC ProPack, пришлось написать множество вспомогательного инструментария:

1. Плагин-отладчик для IDA Pro (не работает, забросил)
2. Загрузчик Amiga Hunk для Ghidra (помог)
3. Загрузчик для library-файлов для Ghidra (очень помог)
4. gdb-сервер для AmigaOS, работающий на ней же (не работал на моих файлах)

Отдельным пунктом идёт покупка kickstart rom (это что-то типа биоса, нутрянки AmigaOS, без него работать ничего не будет).

Потом у IDA появилась возможность отлаживать через GDB в том числе и для m68k. Правда серверной части, которая могла бы при этом эмулировать и мои файлы, и AmigaOS, у меня не было. WinUAE не умеет в gdb до сих пор.

Затем, спустя несколько лет, появилось расширение для Visual Code: https://github.com/BartmanAbyss/vscode-amiga-debug, которое позволяет отлаживать исходные файлы на C, при помощи модифицированного WinUAE с добавленным в него gdb-сервером. Вот здесь я и осознал шанс на декомпиляцию есть.

Декомпиляция

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

• циклы (бесконечные goto)
• использование одного и того же регистра как для хранения 16-битных значений, так и для хранения 32-битных. А ещё они в какой-то момент становятся знаковыми, хотя до этого использовались как беззнаковые.

Отладочный стенд

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

C:\Users\<USER>\.vscode\extensions\bartmanabyss.amiga-debug-1.0.0

Создаём и компилируем тестовый пример (да, у расширения он имеется). В подпапке .\bin имеется следующий список файлов:

• dh0\
• dh0\runme.exe
• dh0\s\
• dh0\s\startup-sequence
• opt\
• default.uae
• elf2hunk.c
• elf2hunk.exe
• gnumake.exe
• winuae.ini
• winuae-gdb.exe

Подкаталог .\dh0\s содержит файл startup-sequence, в котором указываются команды, запускаемые при старте операционной системы. У меня он выглядит вот так:

:runme.exe

Здесь можно добавить нужные аргументы или команды. Для моих целей необходимо заменить файл runme.exe на исполняемый файл от PowerPacker-а, который затем будет загружать ту самую powerpacker.library. А вот куда класть эту библиотеку я понял не сразу. Оказывается, нужно было создать в каталоге .\dh0\ подкаталог Libs (я подсмотрел эту структуру в уже запущенной AmigaOS) и положить туда. Запускаю.

После выполнения данной команды произойдёт запуск winuae-gdb.exe, открытие порта 2345 для работы с gdb, и остановка на точке входа запускаемой программы. Остаётся только подключиться с помощью IDA и её Remote GDB debugger к сессии WinUAE.

Меняем порт на 2345, жмём Debugger->Attach to process..., затем выбираем процесс с id = 0.

После этого у нас появляется окно отладки:

Как видим, адрес на котором мы стоим, отличается от адреса, на котором создавалась idb 0x10000, поэтому останавливаем отладку и делаем Rebase на 0x27D30. Это поможет в дальнейшей отладке не терять изменений, сделанных в базе.

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

Библиотека powerpacker.library

Тут пришлось изощряться, попутно найдя изящное решение, которое может помочь и вам при отладке загружаемых библиотек. Дело в том, что загруженные в память библиотеки (как и другие появляющиеся только во время отладки регионы памяти), можно сохранять прямо в idb, и работать с ними, при желании, в статике. При этом, при перезапуске процесса отладки, вы не потеряете свои наработки по переименованию переменных, меток, и т.п. Для проворачивания этой хитрости необходимо на необходимом сегменте, после загрузки нужной библиотеки, зайти в его свойства (выбрав Edit segment...):

Вы увидите, что там присутствует галка Debugger segment, при снятии которой и нажатии OK, данный сегмент будет сохранён в базу. Единственный момент: стоит следить за размером сегмента, иначе сохранение его в базу может растянуться, или вообще не закончиться.

Теперь можно входить в вызовы экспортируемых функций, и, при одном и том же адресе загрузки библиотеки, вы будете попадать в свой, уже проанализированный, код. Удобно.

В случае AmigaOS вызовы экспортируемых функций выглядят как вызовы по отрицательным смещениям относительно базы, по которой загружена библиотека:

Далее выяснилось, что у библиотеки имеется множество различных версий, которые, как оказалось, отличаются силой сжатия. Изначально, кое-как разреверсив одну версию библиотеки, я столкнулся с тем, что на выходе получались отличные от оригиналов файлы. Пришлось реверсить вторую библиотеку, более новую. Различие оказалось всего лишь в размере окна.

Результаты работы

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

Протестировав всё на 210 файлах, найдя и исправив другие вылезающие баги (такие как выход за границы массива в оригинальном алгоритме), я готов опубликовать результаты своей работы:

Ссылки

Исходники: https://github.com/lab313ru/powerpacker_src
Релизы: https://github.com/lab313ru/powerpacker_src/releases