Comments 23
Ох уж эти попытки структурирования в листинге ассемблера...
Круто - слов нет, одни приятные эмоции. А что Вас побудило создать её?
"...Регистр начала стека sp устанавливаем 0x7Bff - ближайшая пустая область в оперативной памяти. А регистр конца стека ss обнуляем (стек растёт вниз)..."
Так неправильно, нужно 0x7С00, (выравнивание).
Вообще, процесс загрузки сильно сложней -- в частности, она может производиться не только с дисков.
в последних двух байтах первого сектора которого находится специальная запись двухбайтовая
0x55,0xAA, указывающая, что он содержит загрузчик ядра. Обычно сектор равняется 512 байт, но на некоторых устройствах оооочень редко может быть другое количество байт на сектор
Угу, размер сектора не обязательно равен 512 байтам. А вот насчёт сигнатуры 55AA сказано неверно: она находится не в последних двух байтах первого сектора, а в байтах по смещениям 510 и 511 от начала первого сектора. Т.е. если сектор имеет размер 4 килобайта, весь загрузчик, включая эту сигнатуру, будет занимать его первые 512 байт, а остальные 3,5 килобайта игнорируются.
BootLoader должен после своего запуска найти на диске ядро системы, загрузить его с диска в оперативную память, перейти из реального режима (
x16) в защищённый режим (x32) и передать управление ядру
Вообще, в общем случае, первичный загрузчик (тот, что загружается кодом BIOS) ищет и загружает вторичный загрузчик, а уже вторичный что-то там делает для загрузки ОС.
Регистр начала стека
spустанавливаем0x7Bff- ближайшая пустая область в оперативной памяти. А регистр конца стекаssобнуляем (стек растёт вниз).
Насчёт выравнивания стека уже сказали (хотя я, честно говоря, не помню, является ли это требованием для IA-32 aka x86). А вот SS -- это не регистр конца стека, это регистр сегмента стека. Его содержимое совместно с SP и формирует физический адрес памяти, где находится текущая вершина стека.
В современном мире используется LBA запись, в то время, как биос для считывания использует систему CHS.
Вообще-то, BIOS, кроме самых ранних версий, успешно работает и с LBA, только номера функций другие. И они (эти функции), кажется, не умеют работать с дискетами -- только с жёсткими дисками.
Корневой каталог расположен после загрузочного сектора и таблиц FAT.
В FAT12 и FAT16 -- да, в FAT32 -- нет.
Отнимаем от
si3 - первые две записи в FAT заняты корневым каталогом и меткой тома
Неверно. Нулевой элемент FAT содержит в своём первом байте значение, хранящееся в поле BPB_Media; остальные его биты всегда установлены.
Первый элемент FAT12 всегда содержит значение, отмечающее конец цепочки кластеров файла. В FAT16 и FAT32 изначально это тоже признак конца цепочки кластеров, однако биты 15:14 в FAT16 и 27:26 в FAT32 имеют специальное назначение:
15/27 — если установлен, том является «чистым»; если сброшен, том является «грязным», т. е. он не был должным образом демонтирован драйвером перед завершением его использования, а соответственно, информация на нём может быть повреждена;
14/26 — если установлен, ошибок ввода-вывода при работе с томом не возникало; если сброшен, обращение к некоторым секторам раздела вызывало ошибки ввода-вывода.
Ну, я намеренно многое опустил.
Но на счёт выравнивания стека и регистра ss вы правы.
15/27 — если установлен, том является «чистым»; если сброшен, том является «грязным», т. е. он не был должным образом демонтирован драйвером перед завершением его использования, а соответственно, информация на нём может быть повреждена;
14/26 — если установлен, ошибок ввода-вывода при работе с томом не возникало; если сброшен, обращение к некоторым секторам раздела вызывало ошибки ввода-вывода.
Ого, этого я не знал🫠
Спасибо
Корневой каталог расположен после загрузочного сектора и таблиц FAT.
В FAT12 и FAT16 -- да, в FAT32 -- нет.
Технически - да. Область данных идёт после таблиц FAT. Ну а корень у FAT32 это цепочка кластеров начиная с кластера №2 (как уже сказано №0 и №1 - служебные везде). Таким образом они обошли жёсткое ограничение на количество файлов в корне, которое было у FAT12 и FAT16.
Где сама операционная система, её прикладные программы, команды управления, графический интерфейс командной строки, визуальный интерфейс с окошками, ромбиками, треугольниками, командерами или ещё чем?
Написание операционной системы на ассемблере, это дохлый треш. Надо использовать объектный язык программирования, Visual C++, да, да, именно его, пишем в винде, в хорошей среде разработке, на хорошем объектном языке, с использованием необходимых библиотек, и написанием своих, проект компилируем в то, что нам нужно, загрузчик, фигусчик и прочее, так же можем при сборке проекта использовать, чтобы в итоге он переводился а ассемблер и далее, собирался в итоговую программу. Если необходимо использовать, какие-то команды ассемблера для железа, так как не нашли доки или не додумались, как их же с C++ передать, то в необходимых местах делаем вставки кода асма, язык C++ при использовании Visual C++ это позволяет.
MenuetOS такая: ну да, нуда, пошла я нахер.
Извините конечно, что не оправдал ваши высокие ожидания в этой статье.
Над всем, что вы написали выше я уже задумался. И более того уже начал. Как будет готово что-нибудь стоящее обзора, я обязательно сделаю статью про это в качестве продолжения данной статьи.
Здравствуйте! Спасибо большое за статью! Очень интересная тема!
Под спойлером "Формулы для перевода LBA в CHS" похоже не хватает делителя в формуле для вычисления head. Я так понимаю, делителем будет H.
В коде формула такаяh = ((LBA - (s-1)) / SECTORS_PER_TRACK) % HEADS_COUNT
Поправьте, пожалуйста, если есть возможность.
Хорошее начинание! Вот Вам в мотивацию, glukOS http://old-dos.ru/index.php?do=show&id=4179&mode=files&page=files
, с task-ами!
Своя ОС?