Урок ОСдева №5: подготовка к работе с файловой системой FAT12.

В прошлый раз мы инициализировали сегментные регистры и обеспечили загрузчику безопасную среду

обитания. Сегодня будем готовить почву для работы с файловой системой FAT12. Для начала стоит

поподробнее ознакомиться с её структурой. В FAT12 пространство носителя можно разделить на

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

ЗАГРУЗОЧНЫЙ СЕКТОР - ЗАРЕЗЕРВИРОВАНО - FAT - КД - ОБЛАСТЬ ДАННЫX

Наша задача - вычислить начало и размер каждой области на нашем носителе. Эта информация понадобится

для загрузки файлов. Важный момент: при работе с контроллером флоппи-привода мы оперируем секторами,

а не байтами. То есть, когда я пишу "размер", я имею в виду количество секторов, занятыx

областью.

Загрузочный сектор - место, где обитает наша программа. Это всегда сектор

номер 1 на носителе, и занимает он ровно 1 сектор. Было несложно.

Далее, зарезервированныx секторов у нас нет. Вернее, есть один, загрузочный. Общее число

зарезервированныx секторов включая загрузочный можно найти в переменой BPB_reserved блока

параметров BIOS.

FAT, таблица распределения файлов. Будет чуть сложнее. Размер FAT в секторах xранится в переменной

BPB_FATsize. Но, как я уже писал ранее, часто на диске может быть дублирующая FAT на случай

повреждения данныx. Количество FAT на диске указано в переменной BPB_numFATs. Для вычисления

общего размера всех FAT на диске нам нужно умножить размер FAT на число FAT.

Дальше у нас идёт корневая директория. Это набор записей о размещении файлов. Размер записи КД

в FAT12 - 32 байта. Количество записей указано в переменной BPB_RDentries. Берём размер записи

и умножаем на число записей. Всё? Нет. Так мы получим размер в байтах, его нужно перевести

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

BPB_bytespersec.

Вот теперь всё. Вспомним, как выглядела программа в конце прошлого поста:

.386p

CSEG segment use16

ASSUME cs:CSEG, ds:CSEG, es:CSEG, fs:CSEG, gs:CSEG, ss:CSEG

begin:                    jmp short execute                    ;Точка входа. Перейти к исполняемой части.

                            nop                                         ;Пустой оператор. Заполняет 3-й байт перед BPB.

;БЛОК ПАРАМЕТРОВ BIOS======================================================================;

;=======================================;

;Блок параметров BIOS, 33 байта.;

;Здесь хранятся характеристики;

;носителя. Должен быть в 3 байтах;

;от начала загрузочного сектора.;

;=======================================;

          BPB_OEMname db 'BOOTDISK'          ;0-7. Имя производителя. Может быть любым.

          BPB_bytespersec dw 512                  ;8-9. Размер сектора в байтаx.

          BPB_secperclust db 1                        ;10. Количество секторов в кластере.

          BPB_reserved dw 1                          ;11-12. Число зарезервированныx секторов (1, загрузочный).

          BPB_numFATs db 2                          ;13. Число FAT.

          BPB_RDentries dw 224                     ;14-15. Число записей Корневой Директории.

          BPB_sectotal dw 2880                      ;16-17. Всего секторов на носителе.

          BPB_mediatype db 0F0h                   ;18. Тип носителя. 0F0 - 3,5-дюймовая дискета с 18 секторами в дорожке.

          BPB_FATsize dw 9                           ;19-20. Размер FAT в сектораx.

          BPB_secpertrack dw 18                    ;21-22. Число секторов в дорожке.

          BPB_numheads dw 2                        ;23-24. Число головок (поверxностей).

          BPB_hiddensec dd 0                        ;25-28. Число скрытыx секторов перед загрузочным.

          BPB_sectotal32 dd 0                        ;29-32. Число секторов, если иx больше 65535.

;===============================================;

;Расширенный блок параметров BIOS, 26 байт.;

;Этот раздел используется в DOS 4.0.;

;===============================================;

          EBPB_drivenumdb 0                         ;0. Номер привода.

          EBPB_NTflagsdb 0;1. Флаги в Windows NT. Бит 0 - флаг необxодимости проверки диска. Бит 1 - флаг необходимости диагностики поверхности.

          EBPB_extsigndb 29h;2. Признак расшренного BPB по версии DOS 4.0.

          EBPB_volIDdd 0;3-6. "Серийный номер". Любое случайное число или ноль, без разницы.

          EBPB_vollabeldb 'BOOTLOADER ';7-17. Название диска. Устарело.

          EBPB_filesysdb 'FAT12   ';18-25. Имя файловой системы.

;ИСПОЛНЯЕМЫЙ БЛОК========================================================================;

;Шаг 1. Исправить значения сегментных регистров.

execute:

         ;DS, ES, FS, GS.

                   mov ax,07C0h                    ;Сегмент загрузчика.

                   mov ds,ax                          ;Поместить это значение во все сегментные регистры.

                   mov es,ax

                   mov fs,ax

                   mov gs,ax

          ;СЕГМЕНТ СТЕКА.

                   cli                                      ;Запретить прерывания перед переносом стека.

                   mov ss,ax                           ;Поместить в SS адрес сегмента загрузчика.

                   mov sp,0FFFFh                   ;Указатель стека - на конец сегмента.

                   sti                                      ;Разрешить прерывания.

          ;СЕГМЕНТ КОДА.

                   push ax                              ;Поместить в стек сегмент.

                   mov ax,offset stop               ;Указатель на инструкцию после retf.

                   and ax,03FFh                      ;Обнулить 6 старших бит (аналогично вычитанию 7C00h, если смещение больше 7C00h).

                   push ax                              ;Поместить в стек смещение.

                   retf                                    ;Дальний возврат для смены CS.

stop:            cli

                   hlt

          org 1FEh;Заполняет память нулями до 511-го байта.

          dw 0AA55h;Байты 511 и 512. Признак загрузочного сектора.

CSEG ends

end begin

Как всегда я написал максимально подробные комментарии к каждому действию. Теперь после retf добавьте

следующий код вместо cli и hlt:

stop:           mov byte ptr EBPB_drivenum,dl

                  mov ax,BPB_RDentries

                  shl ax,5

                  div BPB_bytespersec

                  mov cx,ax

                  xor ax,ax

                  mov al,byte ptr BPB_numFATs

                  mul BPB_FATsize

                  mov total_FATs_size,ax

                  add ax,BPB_reserved

                  mov datasector,ax

                  add datasector,cx

                  cli

                  hlt

Давайте разбираться. С инструкцией mov мы уже знакомы, так что первая строка должна быть понятна:

команда помещает содержимое регистра DL в переменную EBPB_drivenum. Но что за byte ptr?

Это префикс смены разрядности. Так как мы работаем в 16-битном режиме, TASM предполагает, что

и разрадность всех ипользуемых ячеек памяти - 16 бит. Если мы хотим работать с 8-битной

переменной, её разрядность нужно указать вот таким способом.

И зачем вообще мы сохраняем DL как номер привода, с которого была загружена программа? Дело в

том, что по идее BIOS должна вернуть его в DL. В принципе, доверять этому значению не стоит,

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

Далее команда mov ax,BPB_RDentries считывает в AX число записей в корневой директории,

а команда shl ax,5 умножает его на 32. Команды shl и shr сдвигает биты числа влево и, соответственно,

вправо (сокращение от shift left и shift right). Сдвиг числа влево на 1 эквивалентен умножению

на 2. Сдвиг на 5 эквивалентен умножению на 32. На старых процессорах сдвиг выполнялся быстрее,

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

div BPB_bytespersec делит результат предыдущей операции на число байтов в секторе. Вы наверное

заметили, что регистр ax в команде нигде не указан: операция DIV всегда выполняется на этом

регистре. В результате деления мы получаем чсло секторов, которые занимает КД. mov cx,ax

сохраняет результат в cx, а xor ax,ax обнуляет ax, выполняя на нём "исключающее или" с ним же.

mov al,byte ptr BPB_numFATs считывает в регистр al количество FAT на диске. Кстати! Регистров

al и dl не было в списке, который я приводил на прошлом уроке. Сейчас поясню.

Четыре регистра общего назначения ax,bx,cx и dx делятся на две 8-битные половины.

ax на al и ah, bx на bl и bh, ... l в данном слуае значит low, то есть младшие 8 бит.

h, соответственно, старшие high. Так вот, получив число FAT в al, мы умножаем его на

BPB_FATsize (размер FAT в секторах). Обратите внимание, операция умножения выполняется

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

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

total_FATs_size.

Добавив к ax BPB_reserved, получим общий размер FAT и зарезервированных секторов.

Сохраним его в переменной datasector, а затем прибавим к ней cx, в котором хранится

размер КД. Теперь в datasector хранится общий размер КД, FAT и зарезервированных

секторов, то есть номер сектора, с которого начинается область данных. Обратите внимание,

с точки зрения быстродействия правильнее было бы сначала сложить ax и cx, а уже потом

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

времени, чем операции надрегистрами. Зачем я сделал именно так, станет понятно в

следующий раз. А на сегодня всё! Сегодня мы вычислили важные значения, которые помогут

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

В качестве ДЗ предлагаю самостоятельно объявить использованные нами переменные total_FATs_size и

datasector. Обе 16-битного формата. Переменные можно объявлять где угодно до тех пор, пока они не

встревают в исполняемый код. Например, можно вставить между dw 0AA55h и CSEG ends

Олдфажного геймдева пост номер 5

Выкладывал уже посты по Citadel, но как-то сумбурно. В этот раз напишу подробнее и с цифрами. Итак, что такое Citadel? Одскульная текстовая RPG/roguelike. И, говоря "олдскульная", я имею в виду рили олд. Вспоминайте не эти ваши новомодные Wizardry I, а Eamon и всякое такое из второй половины семидесятых. При этом я, конечно, не ставлю себе цели мучить игрока и стараюсь сделать интерфейс и управление максимально простыми и понятными. Нужные подсказки и требующая внимания информация всегда отображаются в нижней части экрана, так что Citadel можно просто запустить и начать играть, не вникая в многостраничный мануал, как это бывало со старыми играми.

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

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

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

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

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

- магия. Пока нет. Магические навыки нужно будет отыскивать в подземелье в виде свитков или книг, уже изученные будут прокачиваться при использовании. Будут полезны как в бою, так и для "улучшения качества жизни" в целом.

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

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

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

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

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

- враги. Есть небольшой стартовый набор существ. Бестиарий Citadel будет до краёв наполнен разной потусторонней нечистью со своими особенностями и умениями.

- боевая система. Есть, но далека от завершения.

- сюжет и основной квест. Прописан на бумаге, но в игре пока нет.

https://drive.google.com/file/d/1QlfeEDl6t5DlJ8fftaBwouK4jV48hs4p/view?usp=sharing

https://drive.google.com/file/d/16k2Gpr7oPSekq4rAhmtBV0IPnIteDLlE/view?usp=sharing

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

История видеоигр, часть 9: Star Trek (1971)

 Я помню, как в отрочестве, когда у нас ещё не было интернета, листал каналы на телевизоре и попадал случайно на серии Star Trek: The Next Generation. Сериал казался мне очень крутым, но не настолько, чтобы запоминать, когда и на каком канале он шёл. Позже я снова попробовал втянуться во вселенную Star Trek. Я скачал весь оригинальный сериал и начал смотреть. Меня хватило на один сезон - проблемы нервной взрослой жизни занимали намного сильнее, чем приключения команды "Энтерпрайза". В общем, настоящим trekkie я так и не стал. А вот авторы игры Star Trek, как мне кажется, этого звания достойны.

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

Позднее Дэвид Аль заметил игру, переписал на BASIC и включил в свою книгу 101 BASIC Games. Из этой версии выросла более дружелюбная к игроку версия Боба Лидома Super Star Trek для Data Digital Nova. Я буду рассматривать Java-порт именно этого варианта.

Star Trek - пошаговая стратегическая игра, где игроку в роли капитана корабля "Энтерпрайз" предстоит нелёгкая миссия по защите галактики от нашествия воинственных клингонов (см. выше). За отведённое время (около сорока ходов) нужно найти и уничтожить определённое количество (что-то между 10 и 20) клингонских кораблей. Задача выдаётся в коротком брифинге перед началом партии и слегка отличается для каждой новой игры.

Как только инструктаж закончен - игрок сам по себе. Для современного геймера Star Trek выглядит устрашающе. Ничего, сейчас во всём разберёмся! Прежде всего, в левом верхнем углу под надписью short range scan у нас находится карта квадранта, в котором находится Enterprise. Квадрант разделён на 64 сектора (8х8), каждый из которых может быть занят игроком "<E>", звездой "*", станцией ">!<" или клингонским кораблём "+++". Как видите, в этом квадранте ничего интересного нет. Об этом же говорит и надпись ниже: Condition: GREEN. Придётся искать приключений где-нибудь в другом месте. Сверху справа, под вывеской long range scan, у нас есть миникарта, которая показывает содержимое текущего (в центре) и соседних (вокруг) квадрантов. Трехзначное число - это кодировка, в которой единицы означают число звёзд, десятки - станций, а сотни - клингонов в квадранте. Видно, что в соседних квадрантах нас поджидают 4 клингона, а вот станций для ремонта и подзарядки корабля поблизости нет. Что же, будем осторожны и изучим управление перед тем, как кидаться в бой. Доступные команды у нас перечислены снизу (Commands).

nav - меню навигации. Все перемещения корабля осуществляются через него.

Для того, чтобы куда-то полететь, нужно ввести направление. На скриншоте выше видно, что 8 основных направлений пронумерованы. Кроме того, можно вводить дробные числа, например, 5,25 - чтобы пролететь между направлениями "5" и "6". После этого игроку предложат ввести "warp factor" - фактически, число клеток, на которое нужно переместиться. Выход за границы квадранта переносит игрока в соседний с ним в соответствующем направлении. Внимание: если на пути корабля в нынешнем квадранте есть звезда, то прыжка не получится, и Enterprise затормозит прямо перед ней. Перемещение расходует энергию и время, поэтому беспорядочные прыжки через всю галактику - верный путь к проигрышу. Как спланировать свои передвижения? Об этом чуть позже!

pha - управление фазерами. Если кто не знаком со Стар Треком, это такое энергетическое оружие будущего. Фазер позволяет наносить урон кораблям противника, не заботясь о прокладке курса или наличии препятствий на пути. Единственное, что требуется от игрока - указать, какое количество энергии он хочет вложить в залп (отняв, разумеется, от общего резерва своего корабля). Действие фазеров ослабляется с расстоянием, но запас энергии энтерпрайза (3000) настолько превышает силу щитов клингонов (300-400), что игрок без труда может разделать двоих-троих без подзарядки.

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

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

com - это подменю компьютера с кучей собственных важных функций.

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

Положение станций отмечено на карте с самого начала, но чтобы узнать, есть ли в квадранте клингоны, нужно его посетить (или просканировать при помощи long range scan). Области, которые я ещё не открыл, показывают нули (000). Карта помогает игроку спланировать маршрут патрулирования так, чтобы успеть облететь всю галактику с периодическими посещениями космических станций для ремонта и заправки. Кстати говоря, в какой-то более поздней вариации игры (Apple Trek, может быть?) станции исчезают после посещения, здесь же они "неисчерпаемые".

sta - отчёт о состоянии корабля и ходе миссии.

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

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

col и com - управляют цветом и контрастом экрана и нам неинтересны.

xxx - перезапускает игру, как и написано.

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

Оригинал статьи

История видеоигр, часть 8: Space Travel (1969)

     Немного странно писать об игре, которую невозможно найти даже в виде java-реплики, но не упомянуть Space Travel нельзя. Заранее прошу прощения, но большая часть этой статьи будет содрана со странички игры в Википедии.

Итак, в 1969 году Кен Томпсон, работая в Bell Labs над ОС Multics, написал игру Space Travel. Это был двухмерный космический симулятор, где игрок на корабле путешествовал по солнечной системе. Путешествовал без особой цели - занять себя можно было только маневрированием в гравитационных полях небесных тел и посадкой на планеты. Относительные размеры планет были переданы правильно, а вот орбиты упрощены до правильных окружностей - гравитация планет действовала только на корабль игрока, но не на другие тела.

Когда Bell Labs прекратили участвовать в проекте Multics, Томпсон, не желая забрасывать своё детище, переписал Space Travel на фортране, чтобы запускать под GECOS. Эта ОС была на компьютере GE 635. Оказалось, однако, что GECOS нуждам Томпсона не удовлетворяла - работала программа медленно, с перерывами на выполнение нескольких стоящих в очереди задач. К тому же, команды приходилось вбивать в виде текста, что сильно усложняло управление кораблём (под Multics можно было использовать отдельные клавиши для разворота, ускорения и замедления). Но Кен Томпсон не впал в уныние. Он взялся запустить Space Travel на голом железе, без посредничества ОС. Для этого ему пришлось писать с нуля все графические и математические процедуры, а затем и файловую систему. К моменту, когда Space Travel была перенесена на PDP-7, у Томпсона было уже практически готовое ядро операционной системы, которое спустя некоторое время легло в основу известной сегодня всем (ну почти всем) Unix. Сама игра за пределы Bell Labs не вышла и никакого влияния на развитие индустрии не оказала.

История видеоигр, часть 7: Hamurabi (1968)

Царь Хаммурапи, сын Син-мубаллита и внук Апиль-Сина (серьёзно), правил сорок два года (1792-1950 до н.э.). Он занимался строительством, воевал с соседями, расширил границы молодого государства Вавилонии, составил свод законов - древнейший из сохранившихся до наших времён. Появись игра о нём в наше время, в ней было бы чем заняться! Но Hamurabi (или её прототип) появилась в 1968 году.

Всё началось в 1964-66 гг., когда школьный учитель Мэйбел Аддис и программист Вильям МакКэй написали текстовый экономический симулятор для детей, который назвали The Sumerian Game. Это не был уникальный продукт, в то время уже существовало множество программ, обучающих основам экономики. The Sumerian Game не была ни самой продвинутой, ни самой популярной. Для нас она интересна тем, что вдохновила сотрудника DEC Дага Даймента в 1968 году создать свою упрощённую вариацию игры под названием King of Sumeria. Она была написана на только что разработанном его коллегой языке FORTRAN. А спустя несколько лет будущий основатель журнала Creative Computing Дэвид Аль (David H. Ahl) перевёл её на BASIC и опубликовал код сначала в книге 101 BASIC Games, а затем - в ещё более популярной BASIC Computer Games. Успех книг и языка BASIC сильно способствовали тому, что Hamurabi прижилась на многих персональных компьютерах.

Hamurabi - это текстовый экономический симулятор, где игроку на протяжении десятилетнего срока (или десяти ходов) нужно поддерживать баланс между тремя ресурсами: зерном, людьми и землёй. Люди обрабатывают землю и потребляют зерно. Зерно нужно, чтобы кормить людей и покупать землю. Землю можно обрабатывать для получения зерна, покупать или продавать. Расклад в целом понятен, но конкретные цифры игроку никто не говорит, выяснять их приходится самостоятельно по ходу игры. Так:

- 1 человек съедает в год 20 бушелей зерна.

- 1 человек может обработать примерно 10 акров земли в год.

- С 1 акра земли можно получить, по моему опыту, от 2 до 4 бушелей зерна. Соответственно, 1    человек приносит 20-40 бушелей зерна в год. То есть, по итогам года можно получить от (число обработанных акров*2) до (число обработанных акров*4) бушелей зерна.

- Стоимость покупки\продажи земли в бушелях зерна за акр варьируется от 17 до 25.

Жизнь царя,  по версии автора игры, не перенасыщена трудами. В начале года согнувшийся в поклоне слуга называет текущие цены на землю и спрашивает, сколько акров (шумерских акров, конечно же) мы хотим купить или продать. Затем он узнаёт, сколько бушелей зерна мы соизволим скормить подданным и сколько акров повелим засеять на будущее. На этом - всё. Наше царское дело сделано, можно до конца года валять дурака, мять служанок и ездить на охоту. Разумеется, только в своём воображении, игра всё это опускает. Не всегда дела идут гладко. Часть урожая обязательно съедят крысы. Может случиться чума и выкосить половину города, а люди, не получившие зерна, умрут. Впрочем, если не морить подданных голодом, то в конце года население вырастет.

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

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

Как всегда, ссылка на оригинальную статью.

История видеоигр, часть 6: Spacewar! (1961)

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

Осенью 1961 года на радость студентам, преподавателям и прочим сотрудникам в Массачусетском Технологическом Институте был установлен новый миникомпьютер фирмы DEC, PDP-1. Тут можно было бы сделать отступление и рассказать о нём подробнее, но это уведёт нас слишком далеко от темы блога, так что я просто оставлю ссылку для любознательных.

Разумеется, институтское сообщество тут же встало в очередь, чтобы побаловатьcя с новой игрушкой. Листались справочники, писались демонстрационные программы (всё больше графические, так как к PDP-1 прилагался дисплей!). Стив Рассел, который недавно закончил читать серию фантастических романов Дока Смита о линзменах (наивная, но по-своему обаятельная космоопера), высказал идею, что было бы неплохо сделать по нему что-нибудь такое интерактивное. Ему ответили: делай!

Будучи по характеру прокрастинатором, Рассел жаловался то на одно, то на другое, а в конце заявил, что без программы рассчёта траектории и начинать не стоит. К счастью, его знакомый Алан Коток позвонил в DEC, где ему сказали, что такая программа у них есть.

Разработка длилась до февраля 62-го, когда Рассел сотоварищи собрали готовую версию. В ней на круглом экране два управляемых игроками звездолёта ("Игла" и "Клин") бились не на жизнь, а на смерть на фоне случайно генерируемого звёздного поля. Для этого им был дан ограниченный запас топлива и торпед. Интересно, что после этого игра дорабатывалась и расширялась другими людьми: согласно возникшей примерно в то же время хакерской этике программы должны были свободно распространяться и модифицироваться. Так, Питер Сэмсон разработал программу, отображавшую карту звёздного неба - её Рассел включил в игру для отрисовки фона (первоначально был просто рабор случайных точек). Дэн Эдвардс добавил центральной звезде гравитационное поле, из-за чего маневрировать стало сложнее. Мартин Грец придумал кнопку гиперпрыжка, которая позволяла игроку в отчаянном положении телепортировать свой корабль в случайное место на экране. Первоначально способность была ограничена тремя "зарядми", но позже этот лимит убрали. В каноничной версии вместо него при каждом прыжке есть растущая вероятность разрушить корабль.

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

История видеоигр, часть 5: Tennis for Two (1958)

Вот мы и добрались до первого спортивного симулятора. В 1958 году американский физик Вильям Хигинботам (да, тот самый, который участвовал в создании первой ядерной бомбы) сконструировал на основе аналогового компьютера Donner Model 30 игровой аппарат, на котором все желающие могли погонять в виртуальный теннис. Как это часто (читай: всегда) происходило в пятидесятые, игровой автомат был собран не для продажи, а ради показа на выставке. На этот раз дело происходило в Национальной Лаборатории Брукхейвен, куда ежегодный смотр научных достижений привлекал большое количество посетителей. Для выставки 58-го года Хигинботам решил сделать некий интерактивный экспонат, с которым посетители могли бы взаимодействовать. За несколько часов он выдумал концепцию игры, а его коллега по лаборатории Роберт Дворак в течение трёх недель воплотил её в жизнь.

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

Забавно, но Tennis for Two фигурирует в разных источниках как первая видеоигра. Если вы читали предыдущие статьи в моём блоге, то знаете, что это неверно: она опоздала на целых 11 лет. Как водится, по окончании выставки агрегат был разобран и забыт. Позднее, в 1997 году, он был воссоздан и несколько раз выставлялся в той же лаборатории Брукхейвен во время публичных мероприятий. Сам же создатель скромно посчитал свой проект просто небольшой надстройкой над программой расчёта траектории Donner Model 30, недостойной патентования.

Симулятор игры за авторством человека под ником ApM можно взять на сайте журнала The Gamer's Quarter.

Оригинал статьи

Урок ОСдева №4: работа с RAM, адресация в 16-битном режиме, регистры процессора.

Поздравим себя. В прошлый раз мы добавили блок параметров BIOS, после чего винда перестала

ругаться на дискету. Пора начинать писать загрузчик. Но перед этим надо подробнее

разобраться в специфике программирования на ассемблере. Всё-таки он сильно отличается от языков

высокого уровня. Давайте вспомним, как выглядела программа в конце прошлого поста.

.386p

CSEG segment use16

ASSUME cs:CSEG, ds:CSEG, es:CSEG, fs:CSEG, gs:CSEG, ss:CSEG

begin:            jmp short execute                   ;Точка входа. Перейти к исполняемой части.

                     nop                                       ;Пустой оператор. Заполняет 3-й байт перед BPB.

;БЛОК ПАРАМЕТРОВ BIOS===================================================================;

;=======================================;

;Блок параметров BIOS, 33 байта.

;Здесь хранятся характеристики

;носителя. Должен быть в 3-х байтах

;от начала загрузочного сектора.

;=======================================;

BPB_OEMname    db 'BOOTDISK'    ;0-7. Имя производителя. Может быть любым.

BPB_bytespersec  dw 512              ;8-9. Размер сектора в байтаx.

BPB_secperclust   db 1                  ;10. Количество секторов в кластере.

BPB_reserved      dw 1                  ;11-12. Число зарезервированныx секторов (1, загрузочный).

BPB_numFATs     db 2                   ;13. Число FAT.

BPB_RDentries    dw 224               ;14-15. Число записей Корневой Директории.

BPB_sectotal       dw 2880             ;16-17. Всего секторов на носителе.

BPB_mediatype   db 0F0h              ;18. Тип носителя. 0F0 - 3,5-дюймовая дискета с 18 секторами в дорожке.

BPB_FATsize       dw 9                   ;19-20. Размер FAT в сектораx.

BPB_secpertrack dw 18                  ;21-22. Число секторов в дорожке.

BPB_numheads   dw 2                   ;23-24. Число головок (поверxностей).

BPB_hiddensec    dd 0                  ;25-28. Число скрытыx секторов перед загрузочным.

BPB_sectotal32    dd 0                  ;29-32. Число секторов, если иx больше 65535.

;===============================================;

;Расширенный блок параметров BIOS, 26 байт.

;Этот раздел используется в DOS 4.0.

;===============================================;

EBPB_drivenum   db 0                       ;0. Номер привода.

EBPB_NTflags      db 0                      ;1. Флаги в Windows NT. Бит 0 - флаг необxодимости проверки диска.

EBPB_extsign      db 29h                   ;2. Признак расшренного BPB по версии DOS 4.0.

EBPB_volID         dd 0                      ;3-6. "Серийный номер". Любое случайное число или ноль, без разницы.

EBPB_vollabel     db 'BOOTLOADER '  ;7-17. Название диска. Устарело.

EBPB_filesys       db 'FAT12   '           ;18-25. Имя файловой системы.

;ИСПОЛНЯЕМЫЙ БЛОК=====================================================================;

execute:                     cli

                                 hlt

           org 1FEh                              ;Заполняет память нулями до 511-го байта.

           dw 0AA55h                           ;Байты 511 и 512. Признак загрузочного сектора.

CSEG ends

end begin

Я снабдил всё подробными комментариями. Надеюсь, они помогут вам освежить память. Вкратце -

после запуска программы процессор выполняет переход к метке execute - и после этого останавливается

командами cli и hlt. Давайте добавим следующий код после execute, а потом разберём его.

execute:             mov ax,07C0h

                         mov ds,ax

                         mov es,ax

                         mov fs,ax

                         mov gs,ax

                         cli

                         mov ss,ax

                         mov sp,0FFFFh

                         sti

                         push ax

                         mov ax,offset stop

                         and ax,03FFh

                         push ax

                         retf

stop:                  cli

                         hlt

           org 1FEh                                     ;Заполняет память нулями до 511-го байта.

           dw 0AA55h                                  ;Байты 511 и 512. Признак загрузочного сектора.

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

Регистр - ячейка памяти процессора, которая может выполнять какую-то конкретную задачу

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

регистрами: помещать в них данные, извлекать, модифицировать и т.д. В 16-битном режиме

процессор использует следующий набор регистров: AX, BX, CX, DX, SI, DI, BP, SP, flags, CS, DS, ES,

FS, GS, SS. С функциями каждого из них будем разбираться по мере надобности.

Сегмент:смещение - устаревшая система адресации, применявшаяся в эпоху 16-битных процессоров.

Тем не менее, для нас она важна, так как ради обратной совместимости именно в этом

режиме BIOS оставляет систему перед запуском загрузчика.

Постараюсь объяснить. 16-битная разрядность процессора подразумевает, что за раз он может обработать

16 бит данных. Максимальное значение, которое можно передать 16 битами - 65535. Это ограничение

касается и адресации памяти. Выходит, процессору доступно всего (65536/1024) 64 килобайта RAM. Чтобы

обойти это ограничение, была придумана модель адресации segment:offset. Сегмент в ней - это базовый адрес,

от которого считается смещение. Регистры процессора CS, DS, ES, FS, GS и SS - сегментные. Они используются

для указания адреса в памяти, от какого отсчитывается смещение. Например, DS:0050h означает байт 0050h

от значения, помещённого в DS. Вернее, от значения в DS*16. Это называется гранулярностью. Единица,

помещённая в регистр DS, устанавливает основание сегмента не в 1-й байт, а в 16-й. За счёт этого нам

становится доступен целый мегабайт оперативной памяти! (или даже больше с некоторыми ухищрениями,

но рассказывать о них я большого смысла не вижу, т.к. мы всё равно скоро покинем 16-битное царство)

Стек - область памяти, через которую можно передавать параметры процедурам в си-подобных языках

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

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

используется некоторыми командами процессора.

Команда mov op1,op2 используется для того, чтобы переместить значение op2 в op1. В качестве

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

памяти, регистр или конкретное значение. Есть два ограничения: операнды должны совпадать по

разрядности (нельзя поместить содержимое 16-битного регистра в 32-битный, например) и в качестве

обоих операндов не могут быть адреса в памяти. Так что делает этот код?

mov ax,07C0h

mov ds,ax

mov es,ax

mov fs,ax

mov gs,ax

Правильно, он помещает значение 07С0h в регистр AX,  потом копирует AX в сегментные регистры

DS, ES, FS и GS. Зачем? Затем, что BIOS копирует загрузочный сектор в 07С0h:0000h. Так как

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

так, чтобы они указывали туда же. По какой-то причине (ей-богу не помню!) присваивать значения

сегментным регистрам напрямую нельзя, но можно через другой регистр - поэтому сначала мы загружаем

его в AX, а уже AX копируем в сегментные регистры. Вы наверое уже обратили внимание, что сегментные

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

cli

mov ss,ax

mov sp,0FFFFh

sti

Что происходит здесь? Пара команд cli и sti запрещает и разрешает прерывания. Прерывания - то, при помощи

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

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

знать, что команда cli вешает на процессор знак "не беспокоить". sti, соответственно, его снимает.

Дело в том, что SS - это сегментный регистр стека. При манипуляциях с ним лучше убедиться, что в

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

где и загрузчик. Получается, помещая данные в стек, мы затрём часть собственного кода? Нет. Позиция стека

передаётся парой регистров SS:SP. SS - сегмент, а SP - смещение. mov sp, 0FFFFh устанавливает начало

стека в конец сегмента. Получается, ему некуда расти? Тоже нет. Стек растёт в обратном направлении.

Если мы командой push отправим в стек 16-битное слово, то указатель изменит значение на 0FFFDh. Таким

образом, загрузчик и стек находятся в разных концах 64-килобайтного сегмента, и расстояние между ними

вполне приличное.

push ax

mov ax,offset stop

and ax,03FFh

push ax

retf

Соберитесь, последний на сегодня кусок кода. Здесь мы модифицируем сегментный регистр кода, CS. К нему

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

следующей. Как и в случае стека, существует указатель в виде пары регистров CS:IP. Каждый раз после

считывания из памяти инструкции IP увеличивается на её размер в байтах. Все модели BIOS помещают загрузчик

в 07C0h:0000h, но вот состояние CS:IP может быть разным: например, 07C0h:0000h и 0000h:7C00h указывают на

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

оказались регистры CS:IP при старте загрузчика, мы не знаем, поэтому лучше перестраховаться и установить

своё значение.

Как установить значение CS:IP? Например, при помощи инструкции дальнего возврата retf. Обычно она

используется для возврата из процедур, но подойдёт и нам, так кк делает именно то, что нужно: меняет

значения CS:IP. Сегмент и смещение для возврата должны быть в стеке. В AX у нас значение сегмента, 07C0h,

так что командой push отправляем его в стек. А вот с IP придётся повозиться. Щас объясню. CS в данный момент

может быть установлен либо в 07C0h, либо в 0000h. Значит, любое считанное нами смещение относительно его

начала будет равно или X или X+7C00h. Нам нужно однозначно привести его к X. Как это сделать? Команда

mov AX,offset stop помещает в AX смещение метки stop (то есть, конечно, команды cli, сами метки

в исполняемом файле физически не присутствуют и места не занимают). 7С00h, если его перевести в

двоичный вид, будет равно 111110000000000b. Соответственно, искомый X помещается в восьми нулях в начале

значения.  обнуление старших пяти единиц будет эквивалентно уменьшению значения на 7С00h, что нам и нужно.

Про логические операции поговорим позже, но пока знайте, что команда and AX,03FFh делает как раз это:

обнуляет все старшие разряды AX, начиная с первой единицы в 111110000000000b. 03FFh, кстати, в

двоичном виде будет выглядеть так: 1111111111b. Заметили связь? В общем, если кто-то не разбирается в

логических операциях, то ДЗ на сегодня - просветиться по этой теме.

Фух, чёрт возьми, на сегодня всё! Теперь наш загрузчик будет работать в предсказуемой среде, что сэкономит

нам море усилий.

Олдфажного геймдева пост номер 4

И опять времени для работы над игрой выдалось очень мало. Тем не менее, я успел внедрить важную фичу - фрейморк для вражескиx умений. Так, rotten beast теперь травит игрока, а drakeling дышит огнём.

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