OSDev

Я с другой стороны смотрю.
У меня есть мой вторичный загрузчик "KLOADER.EXE". Формат файла MZ-EXE. В качестве входных параметров ему нужен номер диска в DL.
А так как файл имеет формат MZ-EXE то его может грузить DOS. Особенность у меня такая - если загружен при помощи DOS, то для доступу к диску используются интерфейсы DOS. DOS не имеет признака . Поэтому пришлось добавить признак первичного загрузчика проверяю магическое слово по адресу 07C05h-07C09h.

Хочу приобщится к народу смотрю в какую сторону двигаться.

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


Да в общем-то это не должно быть проблемой. Я же читаю через БИОС, а он сам должен обходить такие моменты.


Чёрт, действительно. Именно FAT12 и именно на флопике. HDD с FAT12 грузится нормально. Уже начал разбираться.
Я же говорю, отладить начальную загрузку, так чтобы всё везде работало - весьма непростая задача .


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


Пасиб!


Да просто. Джамп через BPB/BS data, как в обычном VBR, а там код грузит первый сектор первого раздела, без проверки флага активности.


Уже обсуждали этот момент. Моё IMHO, что это мало что даст. Только вербальное уведомление пользователя о невозможности загрузки из-за нехватки памяти, но это потребует ОЧЕНЬ много места, а оно на вес золота.


Никак. А и не надо. Альтернативы всё-равно нет.


Я не смогу загрузить этот формат. Только raw binary.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Ё-моё! Так и есть. С самим загрузчиком всё в порядке. Проблема возникает именно на границе сегментов. Пока база была 600h, граница приходилась ровно между двумя секторами. А сейчас сбой происходит при чтении сектора по адресу FF00h. Гнилое наследие отжившего своё старья! Блин, что делать, что делать!?...

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Все-таки бокс - хороший эмулятор

Я вижу три выхода из этой ситуации:

• использовать предбуфер (геморно; не эффективно, даже если кэшировать только сектора, пересекающие границы; я использую похожий прием в CDFS-загрузчике при загрузке последнего сектора, когда остается 1 Кб доступной памяти);
• забить на флоппик (желание может быть велико, но лично я не стал бы этого делать - люблю флоппики );
• сделать базу 800h (чтобы не повторяться ), тогда я смогу сделать начальный стек за пределами файла (надеюсь, 768 байт должно хватить, т.к. на участке использования этого стека я обращаюсь только к int 12h + возможны аппаратные прерывания), а ты к примеру сможешь кэшировать бутсектор в начале памяти.

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

Чувствую, что мне скоро предстоит собирать версию 3.1


Физически первого раздела или первого раздела в таблице? На флешках иногда встречается неестественный порядок следования разделов в таблице (обычно как результат операции swap partitions/hide current partition). На хардах такое тоже возможно. В любом случае, нужно ориентироваться на физическое местоположение раздела. Кстати теоретически возможно расширить до MBR раздел, не являющийся первым физически, главное, чтобы разрядность поля ReservedSectors позволяла до него "дотянуться".

Я уже знаю, что нужно делать, чтобы запустить файл любого формата Кстати оборачивание в твой формат - не первый мой опыт в этом направлении. Я давным давно научился запускать fs-файлы, как com-. Простейший вариант:Поэтому у меня много демок в com-формате. На этом форуме вроде проскакивала vesainfo - написал на коленке меньше чем за час (если нужно, могу выложить). Там и pavia поучаствовал.

А вообще я не уверен, что pavia именно это имел в виду. Честно говоря, я вообще не понял концовку его поста (касающуюся вопроса по существу, а не про "приобщится").

Я всегда об этом говорил.


Это потребует столько кода, что места уже нет.


Не, забивать не надо.


Не, тоже нехорошо. Во-первых, 768 байт - может оказаться мало для стека. Сейчас многие БИОСЫ по каждому удобному случаю делают PUSHAD/POPAD, что быстро его забивает. Стек должен быть вверху и организовать его там - вопрос пары инструкций. Во-вторых, меня будет мучить сознание пропадающих зря 768 байт. В-третьих, как я уже писал, перенести базу выше - хуже, чем ниже. В-четвёртых, при переносе выше 620к будут поджимать загрузчик вверху, придётся сокращать размер файла до 616к, а мне не нравится это число. Поэтому я, пожалуй, выберу четвёртый путь - с позором вернусь к базе 600h. Сейчас пересоберу архив, выложу, будем считать, что этого пункта не было.


Век живи - век учись, дураком помрёшь.


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


Ну так я давно уже об этом молчу, а ты читаешь мои мысли . Я именно и планировал подготовить комплект стабов на все случаи жизни.
В данном случае я хотел сказать, что после добавления стаба он перестанет быть MZ-EXE, т.к. заголовок будет невалидным. А вот COM можно сделать универсальным.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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

Думаю сделаю stub для загрузки MZ-EXE. Причём бинарник буду получать простой конкатенацией. Этого как я понял достаточно?

И второе всё-таки уйти от своего первичного загрузчика в сторону ваших.


COM должен иметь размер менее 64КБ (не помню точно цифру), а у MZ-EXE такого ограничения нет. То что у меня сейчас вторичный загрузчик всего 16 КБ это не значит что в будущем он не превысит 64КБ.

Перезалил!
Скачиваем...


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


Да, но как я уже писал, при этом потеряется заголовок EXE. Один и тот же файл нельзя будет использовать и для первичной загрузки и для загрузки ДОСом.


Мне кажется, это разумный шаг. Хотя бы потому, что использование ДОСа в качестве загрузчика - само по себе достаточно сложное решение. Я не планирую бросать этот проект. Как я уже писал, сейчас очень много планов на развитие, будет поддержано всё, необходимое для комфортной жизни. Благо, переписал структуру "boot.exe", так что развивать и модифицировать его теперь очень просто. Ещё сделал большую ассемблерную библиотеку, на которую опираются все загрузчики, так что поддержание любой новой ФС - это фактически разбор этой ФС, весь каркас и набор функций уже есть.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Зря. Про int 12h+аппаратные прерывания я сказал специально, т.к. это наименее ресурсоемкие в плане использования стека процедуры BIOS. Вместо вызова int 12h можно вообще читать соответствующую ячейку BDA. У меня этот стек действует только при выполнении адаптационного кода "sys". После передачи управления в точку входа PK сразу же устанавливается стек в стиле GRUB'а с вершиной 2000h. Размер файла сокращать не пришлось бы. Кстати я добавил к твоей прежней базе 600h только 200h, поэтому откуда ты взял уменьшение размера файла на 4 Кб (620-4=616), не понятно. Причем я объяснил, что ты можешь компенсировать увеличение базы за счет копирования бутсектора не в конец памяти, а в начало (ну или загружать один доп. сектор в начало, или использовать это место для чего-то еще, чтобы компенсировать возможную нехватку памяти в конце). Я конечно понимаю, что если твой код успел успешно отработать, то это означает, что выше образа файла в памяти наверняка есть какое-то свободное пространство, которое код "ядра" может использовать под стек. Но ты опять разработчиков вгоняешь в большие раздумья: "А сколько там доступного пространства? Лучше сделаю стек поменьше, чтобы случайно не повредить EBDA!" К тому же гипотетически существует возможность, что код твоего загрузчика находится выше первого мега и при загрузке образа заполняет доступную базовую память под завязку. Ты же не задекларировал, что выше загруженного образа должно оставаться N-ое количество не занятой образом памяти. Лично я поэтому и размещаю стек "в файле" (стековый дамп обычно имеет размер 1 Кб), т.к. 256 байт перед образом может быть действительно мало, а после фиг знает сколько доступно - пока не обратишься к BIOS, не узнаешь, для чего нужно использовать текущий стек, а о его характеристиках, а также о состоянии флага IF в спеке ничего не говорится, поэтому и возникает необходимость устанавливать новый стек как можно раньше.

Ну, если ты это проверяешь, хорошо. Кстати если проверяешь в установщике, а не в самом загрузчике, то ситуация после установки могла и поменяться.

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

Как вариант можешь начинать писать мультиформатный вторичный загрузчик Правда, там своя извечная дилемма: поддержать ли определенный формат нативно или при помощи расширения. Лично я предпочитаю обычные exe-шники (elf, mz и т.п.) запускать через расширения.

В смысле? Жесткая привязка одного к другому?

Если все-таки конечная цель - загрузить ядро, то лучше сразу в него добавлять различные точки входа (Multiboot, Linux kernel).

Для MZ достаточно.

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

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

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


Именно. 8 кБ со 100% гарантией. Ну хорошо, я подготовлю новый демо-образ ядра, в котором будет правильная инициализация стека.


Этот вопрос элементарно решается. Будет в демо-образе.


Это нереально.


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


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


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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>