В прошлых постах мы упоминали скриншот из редактора.
Да. Как верно подметили некоторые пользователи: мы используем Unity.
К Unity мы пришли рассматривая множество вариантов движков, фреймворков и библиотек.
Нам было необходимо:
1. Возможность кроссплатформенной сборки для iOS, Android, Mac, Windows.
2. Наличие готовых инструментов для работы со спрайтами, импорта и преобразования текстур и сборка атласов.
3. Наличие системы сцен и пользовательского интерфейса
4. Наличие готовых инструментов для работы со звуком
5. Наличие поддержки системы частиц и шейдеров
6. Хорошая документация по api
7. Большое сообщество, повышающее вероятность того, что кто-то уже сталкивался с той или иной нашей проблемой
На втором плане, но не менее важно
8. Готовые инструменты для работы со скелетной анимации
9. Наличие сносного менеджера сцен
10. Система предметов, системы квестов, сохранения состояний при переключений сцен
В нашей команде один программист и так же он занят в разработке анимации и пользовательских интерфейсов, мини игр, загадок и паззлов, это приводит к значимым ограничениям в вопросе разработки.
Наша художница ранее работала с dragon bones. Тот поддерживает Unity, Egret и Cocos2d.
Собственно Unity
Плюсы:
1. Широкий набор инструментов работы с графикой
2. Поддержка как direct x для windows билдов, так и opengl es 3 для android
3. Система сцен и объектов сцены
4. Обфускатор
5. Набор инструментов для работы со звуком
6. Сборщики и упаковщики с разными вариантами сжатия
7. Достаточно хорошая симуляция прямо из редактора, уменьшающая необходимость различного железа в процессе разработки.
И многое другое
Значительные недостатки:
1. Отсутствие адекватного менеджера сцен для их переключения
2. Отсутствие адекватного способа хранения данных между сценами
3. Отсутствие определенной главной сцены, сцены \ экрана загрузки
4. Отсутствие адекватной системы единого пользовательского интерфейса для всех сцен
5. Отсутствие инструментов для простой организации многоязычного перевода
6. Значительное потребление ресурсов на целевых для нас платформах
И ряд других менее значительных, как например некоторые баги.
И благодаря тому, что мы смогли решить значимые для нас недостатки, мы решили его в дальнейшем использовать.
Значимую часть из этого нам очень сильно помогло реализовать сообщество за счёт множества готовых примеров решения тех или иных вопросов, что в значимой степени ускорило разработку.
Просто скриншот из редактора в процессе разработки
Главный герой и сюжет
Ежевика - главная героиня игры.
Маленькая послушная девочка, живущая в приюте для детей волшебников. В магии полная неумеха, с единственным талантом, разрушать все на своем пути. Из-за чего еще в раннем детстве крепко накрепко усвоила урок - никогда не нарушай правил, иначе быть большой беде.
В приюте ее самым верным и любящим другом была Малина.
Но в один ужасный день Малина получает смертельное проклятие и только Ежевика в силах ей помочь.А для этого Ежевике придется нарушить самое главное правило этого приюта - никогда не покидать его стен.
Всем привет! В первую очередь хотелось бы поблагодарить за отзывы и предложения.
Итак, самый часто задаваемый вопрос был:
А как собрать команду?
(Мне задавали его в дискорде реактора и на других сервисах и по частоте он оказался первым, обогнав подробности об игре)
Сразу отвечу, у меня специфического опыта менеджмента. И команды я раньше никогда не собирал, максимум рейды в варкрафте.
Но на тему интересно было бы повспоминать и рассказать, как я дошел до жизни такой, с маячащей впереди перспективой регистрации компании и приближающимся релизом проекта.
Начнем с самого начала. В далеком далеком детстве, пройдя квест Петька и Василий Иванович Спасают галактику, я загорелся сделать игру своей мечты. И пошел учиться на программиста.
Но выучившись и пощупав множество игровых проектов, понял, что лично для меня возможность сделать что-то достойное даже не мизерна, а скорее отрицательна.
Сейчас, уже есть более-менее четкое видение, чего на тот момент мне не хватало для своего проекта.
Идея. Конечно, если покопаться, можно сгенерировать тысячу идей, но нужна именно такая, которой ты не только загоришься, но и сможешь её осилить.
Моей розовой мечтой было сделать свою рпг, но сами понимаете, в одиночку, я дай бог закончу ее к своей пенсии.
Графика. В следствии детской травмы руки не могу рисовать. Так что художник из меня никакой.
Сюжет. Тут, наверное сказывается недостаток опыта, да и в принципе не большое желание этим заниматься
Деньги. Это самый главный недостаток. Если бы они были, то и вышеперечисленные проблемы решились наймом команды.
Мотивация самое главное. То что будет заставлять тебя изо дня в день продолжать делать проект
Так что в моем случае было единственное решение, примкнуть к инди компании, либо собрать ее вокруг себя.
Итак, особо не имея при себе талантов и денег и главное мотивации, я особо проекты не разрабатывал. Только изредка ковыряя что-либо мелкое, оставляя свою мечу где-то на задворках сознания.
Но вот в один промозглый осенний вечер, моя супруга пришла с командного хакатона и выдала : Мы будем делать игру!
Первой моей реакцией было: Что? Куда бежать? Ты не больна?
Но обдумав и все взвесив я решил. А почему бы и нет?
После нескольких дней, или даже недель горячих споров о том, за какой же проект нам взяться решили сделать 2д адвенчур. Тк жанр нам обоим был понятен и горячо любим. Я взял на себя роль программиста, а супруга решила взяться за отрисовку всего и вся (она, к слову не художник, но очень старается). Вместе мы придумывали сюжет и загадки.
Думаю, здесь стоит заострить внимание, тк это переломный момент, который и дал толчок к старту проекта. Если у вас нет мотивации - найдите своих единомышленников, даже если вы, как и я, махровые интроверты. Ну, лично мне повезло, в моем случае единомышленники нашли меня сами.
Первые скетчи
Прожужжали уши всем знаком и любому, кто готов слушать.
На самом деле обсуждение со всеми знакомыми и незнакомыми дает эффект. Ты и получаешь фидбек, который может помочь тебе улучшить проект. Ты заряжаешься мотивацией для дальнейшей работы. А также можешь найти себе еще людей, которые готовы вписаться. Так мы нашли нашего редактора и тестировщика, которые опрометчиво согласились помочь (а я запомнил!).
Для поддержания морального духа мы назначили менеджера - знакомьтесь Раджа.
Это самый лучший менеджер, отвечаю. Не орет, не требует отчетов. Одобрительно мурчит. Ты всегда можешь к нему прийти со своей бедой и он выслушает.(А если будет отказываться, ты можешь его посадить к себе на колени и выслушает в любом случае)
Два года разработки пролетели как миг (ого, ничего себе, как долго) были и споры и ругань в чатах. И крики, что ничего не работает и ничего не выйдет. Но больше было интересных моментов и множество очень ценного опыта.
Так, что мой посыл, как бы банально это не звучало, если есть желание - делайте. И показывайте и рассказывайте другим и своем проекте.
Да, в одиночку можно делать очень крутые проекты, но трудно идти по пути одному и не выбросить все в мусорку.
Всем добра и до встречи в нашей игре!
Дисклеймер: эта серия постов не про UEFI. Это не значит, что я не знаю о существовании UEFI. Про UEFI будет отдельная серия постов. Почему я не пишу про UEFI прямо сейчас? Потому что UEFI - это уровень абстракции над железом, а мне интересно именно железо и работа с ним.
Продолжаем? Сейчас наш загрузчик второго уровня работает в "немом" режиме - без возможности подать сигнал об ошибке или выполнении операции. Это необходимо исправить. Самое очевидное решение - вывод информации на дисплей. Мы уже условились, что на нынешнем этапе для работы нашей ОС будет необходима VGA-совместимая карта и дисплей, так что вправе рассчитывать на их наличие.
Программирование VGA-контроллера - сложная штука. Однажды мы ею обязательно займёмся, но сейчас, раз уж мы всё ещё в Реальном режиме, есть вариант попроще: функции BIOS. Функции, связанные с работой дисплея, доступны через прерывание 10h. Мы уже пользовались им для вывода текста в первичном загрузчике, но так как теперь мы не ограничены в размере программы, функционал можно будет расширить.
Первое, что нам стоит сделать - установить нужный видеорежим на случай, если BIOS этого не сделала. Кроме того, понадобятся функции считывания положения курсора, прокрутки экрана и вывода строки. Весь код, связанный с вводом/выводом будет храниться в отдельном файле. У меня он называется io.inc. Мы ещё не использовали подключаемые файлы, но ничего сложного тут нет: в TASM они объявляются директивой include, после которой идёт путь и имя файла. Единственная тонкость тут в том, что подключенный файл не будет вынесен в какую-то изолированную область памяти, как это делается в языках высокого уровня, а окажется в исполняемом файле именно там, где был объявлен. Поэтому лучше объявлять подключаемые файлы где-нибудь в конце, за пределами основного кода.
VGA имеет набор стандартных режимов отображения, с которым можно ознакомиться тут:http://www.columbia.edu/~em36/wpdos/videomodes.txt
Нас интересует режим номер 3 - 80х25 символов, 16 цветов. Для его включения создадим в файле io.inc процедуру set_vmode3. Её полный текст будет выглядеть так:
set_vmode3 proc
push ax
push bx
pushf
xor ax,ax
mov ah,0Fh
int 10h
cmp al,03h
je @@exit_good
mov ax,0003h
int 10h
xor ax,ax
mov ah,0Fh
int 10h
cmp al,03h
jne @@exit_bad
@@exit_good: mov byte ptr vmode,al
mov byte ptr vcol,ah
mov byte ptr vrow,19h
mov byte ptr vpage,bh
popf
clc
pop bx
pop ax
ret
@@exit_bad: popf
stc
pop bx
pop ax
ret
set_vmode3 endp
Начинается процедура, как и почти всегда у меня, с сохранения состояния используемых регистров в стеке. Это нетипичный для ассемблера подход. Обычно, создавая низкоуровневый код, программист стремиться максимально оптимизировать использование инструкций, по возможности обходясь без обращений к памяти, использования стека и вызова процедур. К сожалению, при работе над большим проектом это невозможно, и я на горьком опыте выяснил, что лучше потратить лишние циклы на инкапсуляцию процедуры, чем потом мучительно отлавливать баг, который появился из-за того, что какой-то регистр внепланово изменил значение.
xor ax,ax mov ah,0Fh
int 10h
cmp al,03h
je @@exit_good
Этот блок нужен для того, чтобы остановить выполнение процедуры, если режим 3 уже установлен. Сначала регистр AX обнуляется, чтобы мы точно знали его значение. Функция 15 (0Fh) прерывания 10h возвращает в регистре AL номер установленного режима. Далее мы сравниваем результат с нужным значением (3), и если они равны, то переходим к завершению процедуры, метка @@exit_good. Если режим 3 не установлен, продолжаем.
mov ax,0003h int 10h
Здесь мы опять вызываем прерывание 10h со следующими параметрами: AH = 0(функция 0, установка видеорежима), AL = 3(номер режима). После этого снова идёт проверка режима. Если AL всё ещё не равен 0 - вероятно, возникла проблема, которую мы не сможем решить. Переходим к метке @@exit_bad. Если AL равен 3, продолжаем от @@exit_good. Первым делом - сохраняем в переменные параметры режима, которые вернуло прерывание 10h. В AL - номер режима; в AH - количество колонок символов; в BH - активную страницу видеопамяти (об этом позже). Параметр vrow не возвращается, потому что технически количество символьных строк ограничено только объёмом видеопамяти, а не размером дисплея. После этого восстанавливаем сохранённые в начале регистры, устанавливаем CF (флаг переноса) в нужное положение и завершаем процедуру.
Готово. Теперь в основной модуль после call read_BPB добавляем call set_vmode3 и после этого jc panic. JC - инструкция условного перехода. Переход выполняется при установленном флаге CF. То есть, если наша процедура set_vmode3 завершилась неудачно, программа продолжится от метки panic. Так как невозможность установить видеорежим говорит либо о серьёзных неполадках, либо о несовместимом оборудовании, продолжать выполнение смысла нет. После метки panic останавливаем программу инструкциями cli и hlt.
Далее стоит вывести какое-нибудь приветствие или заголовок, просто чтобы уведомить пользователя о том, что программа работает. Для этого первым делом стоит узнать положение курсора, ведь на экране скорее всего уже есть какой-то текст от BIOS. Это тоже можно сделать с помощью прерывания 10h. Добавьте в io.inc процедуру get_cursor_pos:
get_cursor_pos proc push ax
push bx
push cx
push dx
pushf
mov ah,03h
mov bh,byte ptr vpage
int 10h
mov byte ptr cursor_X,dl
mov byte ptr cursor_Y,dh
popf
pop dx
pop cx
pop bx
pop ax
ret
get_cursor_pos endp
Про сохранение/восстановление используемых регистров объяснять больше не буду, а в остальном тут всё просто: вызываем функцию 3 прерывания 10h, в BH передаём активную страницу видеопамяти. Прерывание возвращает в DL позицию курсора по X, а в DH - по Y. Сохраняем в переменных. Готово. Далее нам понадобится процедура для прокрутки содержимого дисплея. Тут чуть сложнее, добавьте в io.inc:
scroll_up proc push ax
push bx
push cx
push dx
pushf
mov ah,06h
mov bh,CS_DEFAULT
xor cx,cx
mov dl,byte ptr vcol
dec dl
mov dh,byte ptr vrow
dec dh
int 10h
popf
pop dx
pop cx
pop bx
pop ax
ret
scroll_up endp
Функция прокрутки экрана BIOS требует, во-первых, цветовую схему, которой будут заполнены очищенные строки, а во-вторых, координаты верхнего левого и правого нижнего углов сдвигаемой области. Цветовая схема передаётся в регистре BH и состоит из цвета фона и цвета символа. Мы ещё не объявляли константы, давайте посмотрим, как это делается. Константы в отличие от подключаемых файлов можно объявлять где угодно, так как они нужны только на этапе компиляции и не попадают в исполняемый файл. В TASM для объявления констант используется инструкция equ. Вся конструкция выглядит так: ИМЯ КОНСТАНТЫ equ ЗНАЧЕНИЕ КОНСТАНТЫ. Так как в стандартной палитре третьего режима всего 16 цветов, уместно будет определить их в виде констант. Добавьте в код такую запись:
;Цвета фона.BC_BLACK equ byte ptr 00h
BC_BLUE equ byte ptr 10h
BC_GREEN equ byte ptr 20h
BC_CYAN equ byte ptr 30h
BC_RED equ byte ptr 40h
BC_MAGENTA equ byte ptr 50h
BC_BROWN equ byte ptr 60h
BC_LIGHTGRAY equ byte ptr 70h
;Цвета символа.
SC_BLACK equ byte ptr 00h
SC_BLUE equ byte ptr 01h
SC_GREEN equ byte ptr 02h
SC_CYAN equ byte ptr 03h
SC_RED equ byte ptr 04h
SC_MAGENTA equ byte ptr 05h
SC_BROWN equ byte ptr 06h
SC_LIGHTGRAY equ byte ptr 07h
SC_DARKGRAY equ byte ptr 08h
SC_LIGHTBLUE equ byte ptr 09h
SC_LIGHTGREEN equ byte ptr 0Ah
SC_LIGHTCYAN equ byte ptr 0Bh
SC_LIGHTRED equ byte ptr 0Ch
SC_LIGHTMAGENTA equ byte ptr 0Dh
SC_LIGHTBROWN equ byte ptr 0Eh
SC_WHITE equ byte ptr 0Fh
;Несколько готовых цветовых схем.
CS_DEFAULT equ BC_BLACK or SC_CYAN
CS_CLASSIC equ BC_BLACK or SC_LIGHTGRAY
CS_DARK equ BC_BLACK or SC_DARKGRAY
CS_BLUE equ BC_BLUE or SC_LIGHTBLUE
CS_ALARM equ BC_BLACK or SC_RED
CS_DEBUG equ BC_BLUE or SC_WHITE
CS_INVERT equ BC_LIGHTGRAY or SC_BLACK
CS_PANIC equ BC_RED or SC_BLACK
Как видите, для передачи цвета фона/символа используется один байт. Нижние 4 бита отвечают за цвет символа, верхние - за цвет фона и некоторые другие эффекты (подчёркивание, мигание), которые нам сейчас не нужны. Теперь разберёмся с рабочей областью. Мы хотим сдвинуть вверх весь экран, поэтому верхняя левая точка будет в (0,0), а правая нижняя - в (число символов по X-1,число символов по Y-1). Первая передается в CX, вторая - в DX. Таким образом, код процедуры расшифровывается так:
AH=номер функции (6)BH=цветовая схема
CX=верхний левый угол рабочей области (0,0)
DX=правый нижний угол
Вызвать прерывание 10h
Процедура принимает число строк, на которое нужно прокрутить экран вверх, в AL. Добавьте после jc panic такой код:
call get_cursor_pos mov al,01h
call scroll_up
Последнее, что мы рассмотрим сегодня - вывод строки. Это функция 19 прерывания 10h. В качестве параметров она требует: сегмент и смещение строки в ES:BP; цветовую схему в BL; активную страницу видеопамяти в BH; позицию начала вывода по X в DL; позицию начала вывода по Y в DH; длину строки в CX; режим вывода в AL. Номер функции как всегда передаётся в AH.
Зная всё это, давайте подумаем, как организовать процедуру. В принципе тут всё почти однозначно, но что\ делать с длиной строки? Заносить в CX вручную перед каждым вызовом процедуры? Можно, но зачем раздувать код. Лучше включить эту информацию в саму строку. Например, приняв, что первые 16 бит строки будут содержать число символов в ней. У меня строка с заголовком загрузчика выглядит так:str_title dw 31 ;Длина строки. db '=== Tardigrada Loader v.1.1 ===' ;Строка. Теперь давайте напишем саму процедуру в io.inc. print_string proc push ax Наша процедура будет принимать два параметра: смещение строки в BP и цветовую схему в BL. Практически весь код - это заполнение регистров для вызова прерывания. В основном модуле после call scroll_up добавим: mov bl,CS_DEFAULT mov bp,offset str_title Этот код выведет заголовок и прокрутит экран ещё на одну строку вверх. Если всё сделано правильно, должно получиться что-то вроде этого:
push bx
push cx
push dx
push bp
push es
pushf
mov ax,0050h
mov es,ax
mov ax,1300h
mov bh,byte ptr vpage
mov cx,es:[bp]
mov dh,byte ptr cursor_Y
mov dl,byte ptr cursor_X
add bp,0002h
int 10h
popf
pop es
pop bp
pop dx
pop cx
pop bx
pop ax
ret
print_string endp
call print_string
mov al,01h
call scroll_up
Исходники: https://drive.google.com/file/d/144cHXVlBskSiKt9zTAR1V535UQCeUyBL/view?usp=sharing
Bochs: https://drive.google.com/file/d/16k2Gpr7oPSekq4rAhmtBV0IPnIteDLlE/view?usp=sharing
Дисклеймер: эта серия постов не про 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
В прошлый раз мы написали процедуру загрузки данных и использовали ее для того, чтобы
поместить корневую директорию нашей дискеты в оперативную память сразу после собственно
программы-загрузчика по адресу 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 поддерживает вложенные директории, и они ничем принципиально не отличаются
от корневой, так что всё нижеизложенное касается и их.
