OSDev

Я не сведущ в технических тонкостях, но вот простое решение. Сделать проверку источника с чего идет чтение, если с флопика то грузить по адресу 600h, а если не с флопика то грузить по адресу 500h. Просто у загрузчика будет 2 адреса загрузки, и 600h он будет использовать крайне редко, так для совместимости с флопами, а обычно все будет грузиться на 500h. Тем кому бедет нужен флоп будут знать что загрузчик их ядро будет грузить на 600h.

P.S. А вообще не знаю кому нужно это "гнилое наследие". Я даже не смогу припомнить сколько лет назад я избавился от скрежетавшего при инициализации BIOS монстра вечно голодного до дискет, сунешь свеженькую а он ее запорит бедами, сожрет не подавиться. Да и в те давние года он нужен был только для взлома всяких хитрых защит на программное обеспечение, а так он изжил себя чуть ли не в день рождения )). Нет смысла жертвовать 500h адресом из за него, оставить тем кому надо 600h и все.

Это понятно. Ты же сказал 628, 12 - резерв под BDA, я это помню. Кстати был бы загрузчик в начале, был бы доступен участок размером 6,75 Кб

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

Уже. Ты, случаем, телепатией не страдаешь?

Поддерживаю.

Да, нет же. Я кажись у тебя видел 2.01. После твоих неудачных экспериментов со сменой базы я хотел тебя попросить поднять номер версии до 3.01, потому что меня достало перевыкладывать GRUB, править историю и страдать фигней типа:

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

Это все понятно. Я уже забыл когда реальный флоппик в руках держал, хотя для меня он пока остается единственным сменным носителем, с которым моя ось может работать в режиме чтения/записи. Тут скорее дело в том, что образ флоппика по прежнему достаточно удобен для запуска в эмуляторе.

Сомнительно, каждый понимает единообразие и фишки по своему - это субъективно, и стоит оно?


Так в эмуляторе любой образ удобен, а если пишется ОС то понятное дело не для работы с флоппом, сл. с образом харда можно работать. Современные ОС не должны даже и знать что такая шелезяка как флоппик была они должны с USB2.0, USB3.0 и беспроводными интерфейсами работать. По моему надо исходить из текущих реалий и практических задач.

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

Ты это разработчикам популярных осей скажи. Они по прежнему тянут в свои новые творения поддержку флоппика. Я, как обзаведусь полноценной поддержкой USB, сразу же вынесу все компоненты, касающиеся флоппика, в отдельный аддон.

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


Здесь можно со спокойной совестью убрать cli/sti. В соответствии с интеловскими спецификациями, любая загрузка сегмента стека автоматически запрещает прерывания до окончания следующей за ней инструкции. Это специально сделано для безопасной настройки стека и существует ещё с первых 8086/8088.


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

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

ИМХО, от поддержки флопа всё ж стоило бы отказаться, но больше из-за того, что ресурсы разработчиков (Йоды в данном случае) отнюдь не бесконечны, и тратить силы на поддержку заведомо мёртвого оборудования как-то не шибко целесообразно. Во всяком случае, от этого куда меньше пользы, чем от обеспечения загрузки с USB и сидюков (хотя они тоже уже не шибко живы, но уж точно куда живее флопов), поддержки UEFI и т.д.

Я сказал что в тех. не сведущ, но неужели BIOS не сообщает откуда идет инициализация? Ну да и бог с ним, еще проще встраивается новый управляющий ключик в утилиту boot специально для флопа. И вся ответственность перекладывается на пользователя. Если он установит загрузчик на дискету и при этом не применит ключик то просто не загрузится поскольку по умолчанию будет 500h. А если юзер не лопух и сам на себя не захочет обижаться то при инсталляции на дискету использует ключик /floppy для адреса 600h. Это же вполне соответствует твоим взглядам Сергей, по аналогии с проверкой доступной памяти. Как говорится ситуация от этого не меняется только взгляд чуток по другому. Кроме того мы говорим о "гнилом наследии" как ты сам выразился, пережитке прошлого за который стоит цепляться? А сделать образ диска из директории с файлами заданного размера на 1,5 или 10 мегов нет проблем, хоть на 0,5 мега. А для отладочного процесса, программисты гипотетически хотящие использовать твой загрузчик, могут начать с того, что написать поддержку только одного формата харда и его только в образах и использовать пока не будет написана полная поддержка всех форматов харда. Получается тот же флоп по сути но другой по содержанию. По крайней мере то что они напишут они потом доработают и буду использовать, а если они начнут с того что напишут поддержку флопа, то потом это будет выброшенная работа, вот как у phantom-84 который выкинет ее нафиг в отдельный модуль не используемый, а можно сразу писать то что будеш использовать. Короче по моему нет таких категорий которым нужен этот флоппик, особенно в будущем и не целесообразно за него цепляться и других к нему цеплять.

Не, в 8086/8088 этого не было. Вообще меня не напрягает писать это в коде реального режима. Будем считать это данью традиции.

Да, надеюсь, что BIOS'ы не поддерживают флоппики с 1-килобайтными секторами и что такое чудо нам никогда не встретится.

Я про историю файлохранилища говорил. В принципе вполне возможно существование одной и той же версии в компактной редакции и нет. Если забыть во второй сборке про наличие базы 500h, то это так и было. А 3.0 я приписал как раз по причине появления этой базы. Изначально я, естественно, этого делать не планировал, т.к. не ожидал, что "grub.sys" начнет зависеть от версии твоего пакета. Хотел бы надеяться, что в дальнейшем этого не случится, но в свете возможного появления передачи номера раздела в dh на это опять рассчитывать не приходится. Разве что снова заставлять юзера патчить бинарник, на этот раз в зависимости от используемой версии твоего пакета (к примеру затирать nop'ами многострадальную mov dh,im). Может, лучше придумаем какое-нибудь подтверждение наличия номера раздела в dh, чтобы я смог выполнять проверку уже сейчас, а пользователь пусть патчит бинарник, когда использует устаревшую версию твоего пакета. Еще лучше сделать откат. Типа номер передавался всегда, но часто с ошибкой, а вы про этот параметр не знали, что в общем-то было даже к лучшему (из-за ошибки). Короче я пока не выкладываю новую сборку, чтобы по возможности избежать привязки к версии твоего пакета. Но название уже придумал: sys-grubldr-1(.0)-updated(-compact).zip

Да, "ресурсы разработчика" тут не особо тратятся. Загрузчик-то по сути универсальный (специфика флоппика кроме применения подходящей базы для образа ядра вообще никак не учитывается). Просто тестирование как-то странно проводится (подозреваю, что вообще никак). Я почти не тратил времени, не выискивал баги целенаправленно. Просто взял самый простой загрузчик, поместил его в образ самого простого носителя, запустил в моем привычном и, надо сказать, достаточно популярном эмуляторе и ОП-ПА. Не буду же я человека учить основам тестирования. Тут, видимо, присутствует какой-то другой фактор, о котором мы не знаем или знаем, но не хотим озвучивать.