История видеоигр, часть 22: Depthcharge (1977)

     Depth charge в переводе на русский означает "глубинная бомба". Все себе представляют? Наполненная взрывчатым веществом ёмкость с детонатором, настроенным сработать на определённой глубине. Глубинные бомбы сбрасывались с кораблей или самолётов для борьбы с подводными лодками. Активно применялись в Мировых войнах, но сейчас постепенно выходят из употребления, уступая место более точным видам оружия. Помянуть уходящего на покой ветерана можно, поиграв в Depthcharge.

Как можно догадаться из названия, игра посвящена активному применению ГБ. Задача игрока -- управляя миноносцем, подбить как можно больше подводных лодок до истечения 90 секунд. Идея, в общем, не оригинальна: ещё год назад появилась Sea Wolf. Но есть существенное отличие: в Depthcharge корабль игрока физически присутствует на экране и может быть подорван одной выпущенных подлодками мин.

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

На скриншотах видно, что борта лодок украшены цифрами. Это число очков, которое получит игрок за уничтожение цели. Уменьшенное изображение каждой сбитой лодки появляется в полоске у нижней границы экрана. При подсчёте в конце игры каждое из них приносит дополнительные 30 очков. Если в конце счёт игрока оказался выше 500, он получает 45 секунд дополнительного времени. Подрыв на вражеской мине, кстати, не означает конец игры, просто лишает половины очков.

Интересна история игры: её придумал уборщик компании Gremlin Кристофер Гальяс. Не получив за свою идею ни копейки, он, тем не менее, был рад узнать, что игра стала одной из самых популярных в истории компании. Более того, он, видимо, сам настолько загорелся своей задумкой, что ушёл на флот спустя всего два месяца.

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

Урок ОСдева №8: основной загрузчик, вводная.

Дисклеймер: эта серия постов не про UEFI. Это не значит, что я не знаю о существовании UEFI.

Про UEFI будет отдельная серия постов. Почему я не пишу про UEFI прямо сейчас? Потому что

UEFI - это уровень абстракции над железом, а мне интересно именно железо и работа с ним.

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

свобода. Если в случае ПЗ ограничения на объём памяти ставят разработчика в жёсткие рамки

и ограничивают полёт фантазии, то теперь вы можете строить архитектуру программы

по своему усмотрению и добавлять фичи сколько душа пожелает. Те решения, которые принял

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

что сможете сделать лучше - пробуйте. В любом случае стоит держать в голове минимальный

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

- Переключать процессор из 16-битного в 32-битный или 64-битный режим.

- Включать доступ к расширенной памяти.

- Составлять карту RAM и передавать её ОС.

- Минимально взаимодействовать с устройствами ввода-вывода, чтобы показать сообщение об ошибке

или принять ввод пользователя.

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

- Находить на диске и загружать в указанную область памяти ядро ОС.

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

- Предоставлять ОС базовую GDT (об этом позже).

Важный момент: рано или поздно перед вами встанет вопрос совмещения в одной программе

16-битного и 32-битного (или 64-битного) кода. Лично я предпочёл с этим не заморачиваться и

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

модульной структуре. Если вы всё-таки хотите запихать весь код в один файл, стоит заранее

выбрать ассемблер, который это поддерживает.

Ещё один важный момент: достоверное определение аппаратных ресурсов может быть (было до

появления UEFI - вставят тут апологеты) сложной задачей. Там, где это можно сделать

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

на технологии, рассказ о которых выйдет слишком объёмным для одного-двух постов (ACPI, UEFI) -

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

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

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

в некоторых местах повторять первичный. Такие участки кода я буду давать без объяснений.

Ну и - этот пост можно назвать вводным в новый этап программы, так что кода будет

немного. Поехали.Если вы вместе со мной писали ПЗ, то сейчас, запустив машину, получите вот такое

сообщение:

Создайте в папке boot папку stage2, а в ней - текстовый файл loader.asm. Заголовок и конец

модуля выглядят почти идентично ПЗ:

.386p

CSEG segment use16

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

LOCALS @@

begin:

CSEG ends

end begin

Добавилась только директива LOCALS @@. В TASM эта команда разрешает использование локальных

меток. Начинающаяся с символов @@ метка или переменная будет работать только в границах

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

переменные и указатели с одинаковыми именами. Вы оцените полезность фичи, когда начнёте писать

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

сегментных регистров. Совсем как в ПЗ, изменилось только значение. Если помните, loader.bin

у нас был загружен в 0050h:0000h. Выглядит так:

begin:

     ;DS, ES, FS, GS.

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

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

          mov es,ax

          mov fs,ax

          mov gs,ax

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

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

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

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

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

          cli

          hlt

Регистр CS мы не трогаем, так как его значение было корректно установлено ПЗ. Для комфортной

работы нам понадобится информация из блока параметров BIOS. Мы знаем, что он был загружен в

память вместе с ПЗ, поэтому обращаться к диску нужды нет. Собственно, я мог бы просто

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

Будет лучше считать структуру из RAM. Для этого нам понадобится неинициализированный

дубликат BPB и процедура, которая его заполнит. Добавьте эти переменные в конец модуля:

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

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

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

;носителя.;

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

BPB:BPB_OEMnamedb ?,?,?,?,?,?,?,?     ;0-7. Имя производителя. Может быть любым.

BPB_bytespersecdw ?     ;8-9. Размер сектора в байтаx.

BPB_secperclustdb ?     ;10. Количество секторов в кластере.

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

BPB_numFATsdb ?     ;13. Число FAT.

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

BPB_sectotaldw ?     ;16-17. Всего секторов на носителе.

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

BPB_FATsizedw ?     ;19-20. Размер FAT в сектораx.

BPB_secpertrackdw ?     ;21-22. Число секторов в дорожке.

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

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

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

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

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

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

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

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

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

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

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

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

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

db ?     ;Еще один байт для того, чтобы структура занимала 15 32-битных слов.

Как видите, в этом варианте переменным не присвоены значения. Кроме того, в конце

зарезервирован ещё один байт. Он нужен для того, чтобы размер таблицы делился на 4

и её можно было загрузить как последовательность 32-битных слов, не перетерев

ничего лишнего. Теперь нужна процедура.

read_BPB proc

     push cx     ;Сохранить регистры.

     push di

     push si

     push ds

     push 07C0h

     pop ds     ;DS=07C0h, сегмент первичного загрузчика.

     mov si,3     ;SI=смещение BPB в ПЗ.

     mov di,offset BPB     ;DI=смещение BPB в loader.bin

     mov cx,15     ;CX=счётчик для копирования.

     rep movsd     ;Скопировать 15 32-битных слов, размер BPB+1 байт.

     pop ds     ;Восстановить регистры.

     pop si

     pop di

     pop cx

     ret     ;Завершить процедуру.

read_BPB endp

Тут в общем всё просто. Устанавливаем пару регистров DS:SI на начало BPB в первичном загрузчике,

а ES:DI - на нашу неинициализированную структуру. Потом командой rep movsd копируем всю

конструкцию + 1 байт. Вызовите процедуру инструкцией call после установки сегмента стека -

и готово. Кстати, вопрос знатокам: что быстрее выполнит 32-битный процессор в 16-битном

режиме - копирование 15 32-битных слов или 30 16-битных?

На этом пока всё. Сделайте новый батч файл с примерно таким текстом, чтобы не возиться

с инструкциями вручную:

tasm project\boot\stage2\loader.asm

tlink loader.obj

exe2bin loader.exe

Слинкуйте файл, закиньте на дискету - и готово. Сообщение о том, что loader.bin

не найден, должно пропасть. В следующий раз - установка видеорежима и методы вывода

текста.

Ссылка на полный полный текст модуля: https://drive.google.com/file/d/1rFc3OcEDmf7Rs_hEJ6iX98-1SimN_dx_/view?usp=sharing

История видеоигр, часть 21: Empire (1977)

Empire - игра с тяжёлой судьбой. Задуманная Уолтером Брайтом ещё в 1971 году, она оформилась в виде рабочей версии только 6 лет спустя. Первая вариация использовала символьную графику и была написана для компьютера PDP-10, который стоял в Калифорнийском Технологическом Институте. Несмотря на то, что игра стала расползаться по другим PDP вирусным методом, Брайт попытался сделать коммерческую версию. Успеха затея не имела -- было продано всего две копии. Хуже того -- некий злоумышленник взломал защиту КалТеха и выкрал исходники программы. Спустя ещё 10 лет Брайт обнаружил своё детище в библиотеке DECUS и заявил права.

Проще всего сейчас поиграть в версию 1987 года для DOS.

Брайт переписал Empire для IBM PC и отправил в журнал BYTE. Вопреки ожиданиям, вскоре посыпались заказы, и игра всё-таки принесла своему автору умеренные деньги и славу. Empire переиздавалась несколько раз, но к следующим вариациям мы обратимся, когда придёт время.

Empire, Wargame of the Century - глобальная пошаговая стратегия, в которой два или три игрока сражаются за контроль над, ни много ни мало, целой планетой. Статья в Википедии, кстати говоря, ошибочно причисляет Empire к варгеймам, хотя устоявшееся определение жанра подразумевает наличие начального набора юнитов, который убывает в процессе игры; в Empire же производство и организация доставки войск к фронтам - ключевой момент игры.

Война идёт за контроль над городами. Города позволяют производить армии и военную технику. Лишившись последнего города, игрок выбывает из партии.

Начало игры. 

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

Пехота (armies): медленные и уязвимые, но без них не обойтись: только пехота может захватывать города. Перемещаются на одну клетку за ход и только по суше.

Истребители (fighters): основная боевая сила. Перемещаются на четыре клетки за ход по воздуху, поэтому тип поверхности игнорируют. Имеют запас топлива на двадцать клеток, после этого нуждаются в дозаправке в городе или на авианосце. Без дозаправки разбиваются. Подходят для защиты городов и перехвата слабых кораблей противника.

Эсминцы, крейсеры, линкоры (destroyers, cruisers, battleships): боевые корабли. Различаются скоростью перемещения и живучестью.

Транспортные корабли (transports): слабо защищены, перевозят пехоту.

Подводные лодки (submarines): подходят для охоты на вражеские суда, т.к. каждое попадание по кораблю наносит тройной урон.

Авианосцы (carriers): плавучие аэродромы. Могут нести до шести истребителей.

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

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

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

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

Середина игры. 

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

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

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

Конец игры. 

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

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

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

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


Геймплей:
классическая пошаговая стратегия. Этот игровой процесс ещё долго будут копировать -- влияние Empire можно почувствовать в Civilization, Master of Magic и многих других ставших классическими стратегических играх.

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

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

Звук и музыка:
Наименее, по-моему, важный аспект для стратегии. Звуки ограничиваются гудением и жужжанием при схватке двух юнитов. Зато на титульном экране звучит "В пещере горного короля" Грига.

Оригинал статьи: https://silicondarwin.blogspot.com/2017/04/empire-1972.html

История видеоигр, часть 20: Sea Wolf (1976)

Имя компании Namco, наверное, знакомо всем моим читателям. Тем, кто постарше -- как создательницы Splatterhouse и Tekken, тем, кто помоложе -- по серии Souls, правда, уже в составе холдинга Bandai Namco. А вот самым первым продуктом Namco, по словам её основателя Масайи Накамуры, был электромеханический игровой автомат Periscope 1965 года. В нём на фоне изображавшего океан задника проплывали вырезанные из картона корабли, которые игрок, глядя в перископ, должен был сбивать торпедами. Траектории торпед обозначались световыми полосками, а попадания -- звуковым эффектом. Игра имела успех, и, кто бы мог подумать, у неё возникли подражатели. Например, Midway выпустила очень похожую игру под названием Sea Devil. Мой блог -- про видеоигры, и всё вышенаписанное меня бы не касалось, если бы Midway к 76 году не решила проапгрейдить последний до полноценного электронного автомата с дисплеем. Так появилась Sea Wolf. В ней точно так же по экрану, изображающему морскую гладь, проплывают военные корабли и катера, а невидимый и неуязвимый игрок разит их торпедами. Попадания вознаграждаются очками, а наивысший счёт - главная и единственная цель игры. Наводятся торпеды при помощи прицела, который перемещается влево и вправо вдоль линии горизонта. Торпеды плывут медленно, так что стрелять приходится с упреждением.

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

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

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

По традиции для тех, кто не видел прошлые посты, скопирую короткое вступление.

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

Кстати, сегодня, если кому интересно, проект перевалил за 13 тысяч строк ассемблерного кода (правда, считая с текстовыми и "табличными" ресурсами) и вес в 50 Кбайт.

Версия 0.16

Что нового? Пункт "интро" в главном меню работает, так что теперь пользователь наконец узнает, что случилось и кто его персонаж. Hurray. Кроме того, альтернативные способы создания персонажа, бесполезно висевшие в стартовом меню, теперь работают. Premade - это такой стандартный стандартный герой, сбалансированный для относительно комфортного начала игры (по замыслу. Балансом, честно говоря, я пока пренебрёг). Random - для любителей экстрима. Да, самое главное - рабочее название сменилось на Beneath the Citadel. Типа отсылка к Beneath Apple Manor.

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

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

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

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

Игра: https://drive.google.com/file/d/1z1qm71SDUYMYn5M1UjU7rHY5F9OzjB6g/view?usp=sharing

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

История видеоигр, часть 19: The Amazing Maze Game (1976)

Помните газеты, которые покупали ваши родители? Они обычно заканчивались блоком кроссвордов, а последняя страница отводилась под детские задачки и головоломки. Иногда там попадались простенькие лабиринты. Читателю предлагалось взять карандаш и прочертить линию от старта до финиша. Удивительно, но кому-то в Midway это занятие показалось достаточно увлекательным, чтобы сделать на его основе игровой автомат.

Прохождение лабиринта на время - хорошая тренировка внимания, памяти и рефлексов. А если делать это наперегонки с приятелем, то ещё и весёлое времяпрепровождение. The Amazing Maze Game -- как раз об этом. Получив пятак, автомат генерирует лабиринт с выходами в правой и левой части. Первый игрок начинает справа, второй -- слева. Задача -- добраться до противоположного выхода раньше соперника.

Без живого оппонента играть можно, но неинтересно. Компьютер прокладывает идеальный маршрут и не делает ошибок. Единственное преимущество игрока -- в скорости движения. Если игрок выигрывает, в следующих трёх-четырёх раундах компьютер наращивает скорость. После этого она остаётся фиксированной и всё ещё меньше скорости игрока, чтобы человек мог тягаться с машиной. The Amazing Maze Game стала одной из первых игр такого рода. Если вы большой фанат лабиринтов, а все старые подшивки газет уже израсходованы, то она увлечёт вас надолго, а может быть и навсегда, ведь карты генерируются случайно. Для всех прочих TheAmazing Maze Game -- просто диковина из прошлого, о существовании которой стоит знать, но знакомиться лично -- не обязательно.

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

История видеоигр, часть 18: Night Driver (1976)

Night Driver - игра о безответственном водителе, мчащемся тёмной ночью по извилистой трассе с явной целью совершить [роскомнадзор]. Кроме того, это одна из первых гоночных игр с видом от первого лица. Оригинальный аркадный автомат с рулём, педалями и рукояткой переключения передач был разработан в 1976 году фирмой Micronetics. Позже игра была портирована на Atari 2600 (1980) и Commodore 64 (1982).

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

Night Driver предлагает на выбор три трассы, различающихся крутизной и частотой поворотов. Цель игрока - набрать как можно больше очков за отведённый промежуток времени. Чем быстрее едет игрок - тем быстрее растёт счёт. Столкновение с ограждением не заканчивает гонку, а просто останавливает машину. После набора 350 очков игрок получает дополнительное время. После 1000 счёт обнуляется, так что умелый гонщик может продлевать заезд не один раз. Как видно на скриншотах, оформление игры более чем аскетично. Это не неудачные кадры, вы действительно не увидите ничего, кроме столбиков ограждения. Нет соперников, нет окружения, только дорога, игрок и тикающий таймер. Звуковое сопровождение под стать: монотонный гул мотора, который через минуту начинаешь воспринимать как абсолютную тишину, изредка нарушает только визг покрышек при особенно крутом повороте. Хотя в вышедшем 4 года спустя порте для Atari 2600 уже были элементы окружения и даже другие авто, от которых надо было уклоняться.

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

Оригинал: https://silicondarwin.blogspot.com/2017/03/night-driver-1976.html

История видеоигр, часть 17: Blockade (1976)

У кого из вас, читатели, был телефон Nokia 3310 или что-то из той же эпохи? Помните игру "змейка"? Вот откуда она произошла:

Компания Gremlin, которая до того занималась механическими аркадными автоматами, в 1976 году решила выйти на рынок видеоигр. Дебютным проектом стала игра Blockade для двоих игроков. При помощи четырёх направляющих кнопок каждый управлял стрелкой, оставляющей за собой кирпичную стену. Как и в "змейке", стрелки всегда находились в движении, игрок мог только менять его направление. В отличие от "змейки", хвост каждого игрока всегда оставался в стартовой точке, т.е. стена просто закрашивала пройденный игроком путь. Первый игрок, столкнувшийся со стеной (своей или чужой), проигрывал. Партия продолжалась 6 раундов.

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

История видеоигр, часть 16: Breakout (1976)

Почему-то все игры от Atari, которые я рассматриваю в рамках этого блога, во время разработки обязательно сопровождались попахивающей мошенничеством или авантюрой историей. Computer Space, например, была коммерческой калькой с бесплатной Spacewar!; Pong, разработка которой в принципе была одной громадной афёрой, тоже была доработанной версией чужой игры; Gotcha с её неоднозначным геймплеем и контроллером в виде женской груди -- и вовсе история из анекдота. Не исключение и Breakout, но об этом ниже.

Идея игры зародилась в головах основателей Atari Бушнела и Бристоу. Бушнел, поглощённый борьбой с клонами-конкурентами Pong, хотел делать новые игры на той же аппаратной основе. В частности, его изводила идея адаптировать Pong для одного игрока, заменив соперника на разрушимую кирпичную стену. Алан Алкорн, которому было поручено руководство проектом, доверил реализацию некоему Стиву Джобсу.

Джобсу было обещано 750$ за рабочий прототип через 4 дня и бонус за сокращение количества аппаратных элементов, так как Бушнела злило увеличение затрат на производство последних игр компании. Инженерных навыков Джобса было недостаточно для выполнения задачи, но вот его друг, Стив Возняк, однажды собрал клон Понга с меньшим количеством деталей, чем у самой Atari.

Джобс убедил Возняка разработать прототип, пообещав поделить гонорар поровну, но умолчал о бонусе за миниатюризацию. Возняк уложился в дедлайн, работая четверо суток подряд по ночам, так как днём был занят на своей основной должности в Hewlett-Packard. За его финальный дизайн Джобс получил надбавку в 5000$, а сам Возняк заработал всего 350. Причём он много лет не знал об обмане, и даже в 1984 году в одном из интервью утверждал, что за работу они получили 700$. Кстати, пустить версию Возняка в производство Atari не смогла. Дизайн оказался слишком миниатюрным и сложным. Позже компания разработала свою версию с абсолютно идентичным геймплеем, но большим числом деталей.

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

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

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

Breakout имела успех, и имитаторы снова напали на лакомый кусочек. Война Нолана Бушнела с клонами продолжалась.

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

https://silicondarwin.blogspot.com/2017/02/breakout-1976.html

Урок ОСдева №7: первичный загрузчик, финал.

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

поместить корневую директорию нашей дискеты в оперативную память сразу после собственно

программы-загрузчика по адресу 07C0h:0200h. План действий на сегодня:

-Найти в КД номер первого кластера файла.

-Загрузить первый кластер.

-Следуя по цепочке записей в FAT, загрузить остальные кластеры.

Перед тем, как кодить дальше, давайте  разберёмся, что такое КД и как её использовать для

поиска файлов*.

По сути корневая директория в FAT12 - это таблица, в которой каждому файлу или

поддиректории соответствует одна 32-байтная запись. Давайте посмотрим, что в ней есть.

Байты 0-10: имя файла в формате 8:3. Этот формат подразумевает, что имя файла занимает

ровно 8 байтов, а расширение - 3. Если имя файла меньше 8 символов, оно дополняется

пробелами: так, файл 'loader.bin' в КД будет проходить под именем 'LOADER  BIN'.

Байт 11: атрибуты записи. Набор флагов, позволяющий придать записи особые свойства.

          00000001b = только для чтения

          00000010b = скрытый

          00000100b = системный

          00001000b = метка раздела

          00010000b = директория

          00100000b = архив

          00001111b = LFN (long file name), запись имеет особый формат, поддерживающий длинные

                              имена файлов.

Байт 12: зарезервирован для Windows NT.

Байт 13: время создания в десятых секунды (почему-то 0-199 согласно OSDev Wiki).

Байты 14-15: время, когда был создан файл. Младшие 5 бит - секунды/2 (то есть при интерпретации

значения, например, для вывода на экран, эту часть надо умножать на 2). Следующие 6 - минуты.

Последние 5 бит - часы.

Байты 16-17: дата создания файла. Примерно та же история. День(0-4), месяц(5-8), год(9-15).

Байты 18-19: дата последнего доступа в том же формате, что и дата создания.

Байты 20-21: старшие 16 бит номера первого кластера файла. В FAT12 и FAT16 не используется.

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

Байты 24-25: дата последнего изменения в том же формате, что и дата создания.

Байты 26-27: младшие 16 бит номера первого кластера файла.

Байты 28-31: размер файла в байтах.

Довольно много информации, но нас интересуют только два поля: имя записи и младшая часть номера

стартового кластера (старшая половина в FAT12 не используется). Вырисовывается в общих чертах

алгоритм поиска файла? Если нет, я помогу:

1. Переходим к началу КД

2. Считываем имя записи

3. Сравниваем имя записи с именем искомого файла

4. Если имена совпали, файл найден, SUCCESS!

5. Записи кончились?

6. Если кончились - файла нет, аварийно завершаемся

7. Переходим к следующей записи

8. goto 2

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

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

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

конце. Это позволит вместить в пост больше полезной информации, не растягивая его до

нечитабельных размеров. А теперь давайте выполним наш поисковый алгоритм в коде. После

call read_sectors пишите:

                   mov cx,BPB_RDentries

                   mov di,0200h

                   mov si,offset fname

                   mov bp,si

next_entry:   mov ax,cx

                   mov bx,di

                   mov cx,11

                   rep cmpsb

                   mov si,bp

                   mov di,bx

                   mov cx,ax

                   je load_FAT

                   add di,32

                   loop next_entry

                   mov ah,3

                   xor bh,bh

                   int 10h

                   mov ax,1300h

                   mov bx,0007h

                   mov cx,22

                   mov bp,offset fname

                   int 10h

                   cli

                   hlt

Что всё это значит? В строчке mov cx,BPB_RDentries мы устанавливаем счётчик основного

цикла. Напоминаю, что в переменной BPB_RDentries у нас хранится число записей корневой

директории. 0200h - смещение загруженной в RAM КД. В SI мы помещаем смещение строки с

именем искомого файла. Кстати, впишите в переменные fname db 'LOADER  BIN'. После этого

мы сохраняем это же смещение в регистре BP. Это может быть пока неочевидно, но позже вы

поймёте, зачем.

Следующий блок кода, начинающийся с метки next_entry, - это собственно цикл просмотра

записей КД и сравнения имён. Первым делом мы сохраняем счётчик цикла и смещение текущей

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

строковые инструкции вроде cmpsb изменяют значения регистров SI и DI. Кстати, теперь вам

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

mov cx,11 - установка счётчика вложенного цикла. Имена в FAT12 хранятся в формате 8:3,

значит, нам нужно сравнить две строки по 11 символов. Надеюсь, тут вопросов нет?

Инструкция cmpsb сравнивает значения двух байтов (в нашем случае символов), находящихся

в DS:SI и ES:DI. Префикс rep повторяет инструкцию, пока не обнулится счётчик в CX.

Далее мы восстанавливаем счётчик основного цикла в CX, смещение текущей записи в DI и

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

push/pop, но потом я подумал, что трансфер из регистра в регистр быстрее, чем обращение

к стеку, и поменял. Никогда не вредно сэкономить пару циклов.

Если в результате rep cmpsb все символы совпали, в регистре флагов будет установлен бит

ZF. Команда je load_FAT выполняет переход к метке load_FAT если флаг ZF установлен.

В случае если строки не совпали, мы переводим DI к следующей записи в КД и продолжаем

цикл командой loop next_entry. Тут бы можно было и закончить, но нужно обработать

отсутствие файла. С этим набором инструкций мы уже знакомы по предыдущему посту.

Первый блок возвращает положение курсора в DH,DL, а второй выводит от этой позиции

сообщение. Отличается только само сообщение. Вместо 'Disk read error.' мы выводим строку

с именем файла. Внимание, тут небольшой хак. Идея в том, чтобы вывести следующий текст:

'{filename} not found!'. Вызвать вывод строки два раза, но зачем? Если поместить в

разделе переменных текст ' not found!' сразу после переменной fname, а при вызове int 10h

указать в CX не 11 символов, а 22, то выведется сначала имя файла, а потом ' not found!'

Конечно же, этот текст обязательно должен быть сразу после fname. Добавьте строчкой ниже

db ' not found!' После этого останавливаем процессор парой команд cli и hlt. Не так-то

сложно, да? Впрочем, файл ещё нужно загрузить.

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

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

После hlt набирайте:

Load_FAT:          mov ax,[di+26]

                         mov cluster,ax

                         mov ax,BPB_reserved

                         mov cx,total_FATs_size

                         mov bx,BPB_RDentries

                         shl bx,5

                         add bx,0200h

                         mov FAT_offset,bx

                         call read_sectors

В строчке mov ax,[di+26] мы считываем из записи КД номер первого кластера файла, а затем

сохраняем его в переменной cluster. Далее, мы помним, что FAT у нас идут сразу после

зарезервированных секторов, поэтому в AX помещаем BPB_reserved. В CX у нас будет число

секторов, которое надо загрузить, то есть total_FATs_size. Загружать FAT будем сразу после

КД, то есть в 07С0h:0200h+размер КД. Размер КД = число записей КД*размер записи (32 байта).

Помещаем в BX число записей (BPB_RDentries), умножаем на 32 (shl bx,5 эквивалентно умножению

на 32, но выполняется быстрее) и добавляем 0200h. Готово! Сохраняем на будущее в переменной

FAT_offset (кстати, объявите её рядом с прочими) и вызываем read_sectors.

А теперь время вернуться к теории. Что такое FAT? Не поверите, но это тоже таблица, и её

структура ещё проще, чем у КД. Каждая запись в FAT соответствует кластеру на диске. FAT

можно назвать оглавлением диска (украл с OSDev Wiki). Кластер может быть свободен, занят

частью файла, зарезервирован ОС или испорчен. Если кластер хранит часть файла, то его

запись в FAT будет содержать номер следующего кластера файла. Понятно? Зная номер первого

кластера файла, мы можем загрузить его в память, потом заглянуть в FAT, найти нужную запись

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

всегда, есть большое "НО"! Размер записи в FAT12 - 12 бит. Мы не можем оперировать

12-битными ячейками. Мы можем считать 8 или 16. То есть, если мы загрузим в AX начало FAT,

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

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

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

но поделенная на 8-битные куски.

0 0 0 1 0 1 1 1 0 0 1 0|0 1 1 1 0 0 1 0 1 0 0 0|0 0 1 0 0 1 0 0 0 1 1 1          3 Записи.

0 0 0 1 0 1 1 1|0 0 1 0 0 1 1 1|0 0 1 0 1 0 0 0|0 0 1 0 0 1 0 0|0 1 1 1         4,5 байта.

Решение в том, чтобы, считывая каждый нечётный кластер, сдвигать значение на 4 бита вправо, а

у чётного - обнулять 4 старших бита. Зная всё это, давайте писать код:

                             push 0050h

                             pop es

                             xor bx,bx

read_cluster:           mov ax,cluster

                             sub ax,2

                             movzx cx,BPB_secperclust

                             mul cx

                             add ax,datasector

                             call read_sectors

                             mov ax,cluster

                             mov si,ax

                             shr ax,1

                             add si,ax

                             add si,FAT_offset

                             mov dx,[si]

                             mov ax,cluster

                             test ax,1

                             jnz odd_cluster

                             and dx,0000111111111111b

                             jmp short done

odd_cluster:           shr dx,4

done:                     mov cluster,dx

                             cmp dx,0FF7h

                             jb read_cluster

Финальный рывок. Первое, что мы делаем - устанавливаем сегмент для загрузки файла. Так как

BIOS нам больше не указ, выбирать можно самостоятельно. Я бы с удовольствием отправил его

в 0000h:0000h, но первые 1280 байт заняты важными вещами, о которых поговорим позже.

Ближайший свободный участок RAM - 0050h:0000h (или 0000h:0500h, это тот же самый адрес

если вы вдруг забыли правила адресации сегмент:смещение). Обнуляем BX, так чтобы пара

ES:BX указывала на 0050h:0000h. Считываем в AX номер первого кластера файла. Дальше мы

вычитаем 2 из этого номера. Зачем? Затем, что значения 0 и 1 в FAT зарезервированы и не

используются в качестве номеров, а номер, указанный в таблицах, на 2 больше, чем правильное

значение. Да, это идиотизм.

Загружать будем не сектор, а кластер (что в нашем случае одно и то же, но всё-таки),

поэтому в качестве числа секторов помещаем в CX переменную BPB_secperclust и на неё же

умножаем номер кластера. AX*CX в данном случае дадут нам номер первого сектора нужного

кластера. А так как кластеры в FAT начинают считаться от начала области данных,то для

абсолютного значения добавляем к AX datasector. Готово. Вызываем read_sectors и загружаем

первый кластер файла в RAM.

Дальше будет немножко математической магии, объяснять которую я не буду. Если интересно -

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

смещение записи кластера внутри FAT = 3/2 номера кластера. Значит, берём в AX номер

кластера, его же помещаем в SI, делим AX на 2 и прибавляем к SI. Вуаля, смещение

записи от начала FAT найдено. Добавляем к нему смещение FAT_offset и считываем в DX

значение записи.

Теперь надо проверить, чётная ли запись. Для этого опять берём в AX номер кластера и

делаем сравнение с 1. Если флаг ZF не установлен (то есть 0 бит значения равен 1),

значит, номер записи - нечётный, переходим к odd_cluster и сдвигаем значение вправо на

4 позиции. Если чётный - делаем логическое "И" с маской 0000111111111111b и обнуляем

тем самым 4 старших бита. Теперь у нас есть содержимое нужной записи без всяких

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

cluster. Дальше у нас идёт сравнение с номера с числом 0FF7h. Дело в том, что,

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

файла, испорченный сектор и т.д. Для нас это значит, что если в качестве номера

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

продолжаем цикл только если DX меньше 0FF7h. Я умышленно оставляю здесь дыру и

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

связанной с битым кластером (код 0FF7h). Код конца файла, кстати, 0FF8h. Вся необходимая

для этой задачи информация и примеры кода уже есть в этом посте.

А мне остаётся только добавить в конце три строчки:

                    push 0050h

                    push 0000h

                    retf

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

смещение, и передаём управление загруженному файлу командой retf. Поздравим себя!

Первичный загрузчик готов. Да, он умеет немного, но и задача у него всего одна:

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

скомпилируете файл без инструкций org 1FEh и dw 0AA55h, то увидите, что программа

занимает всего 447 байт. Значит, у нас есть в запасе ещё 63. Как раз должно

хватить на проверку успешного считывания кластеров. У меня вместе с ней вышло 497

байт. Можете подсмотреть в приложенном файле, хоть это и неспортивно. Если вы

поместили загрузчик на дискету и получили в bochs (или на реальной машине) вот такой

экран, то всё работает как надо!

Чистая дискета:

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

Листинг:

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

Bochs:

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

* FAT поддерживает вложенные директории, и они ничем принципиально не отличаются

от корневой, так что всё нижеизложенное касается и их.