OSDev

Я использую память, начиная с адреса 0x500. Всюду работает.

Все современные компьютеры являютя PS/2 совместимыми. Первые IBM PS/2 (1988-1990 г) Открываем документацию на БИОС PS/2 и видим что hex 50:00 (500h) используется для print screen. Это последний адре BDA.
ps2bios3.pdf
Открываем документацию на Phoenix там тоже.
BIOS Programmer's Guide v10.pdf


Совместимые не значат орегинальные. Вполне что-то могло поменяться.

Также гдето читал что память 500h-5FFh использует встроенные BASIC.
Но в 1996 была принята спецификайия BIOS Boot Specification которая говорит что бесик использоваться не будет. Вернее номер прерывания там задействуется для других целей.

Также в качестве спавочника можно смотреть Таблицы Ральфа Брауна (interupt) и книги Гука. Подрукой нету.

Тем не менее, лично я бы использовал с адреса 0x600 -- на всякий случай. Вдруг где попадётся особо извращённый БИОС.

Ну и не надо забывать, что доступная нижняя память кончается не на границе 640 килобайт, а меньше, поскольку верхние несколько килобайт также использует БИОС.

Это да, до 0x0007_FFFF (510 КиБ) все свободно, кроме 0x7C00-0x7DFF, где помещается загрузочная запись. Её можно, в принципе сразу тереть, как отработает.

Потом идет область от 0x0008_0000 - 0x0009_FBFF, про которую написано

То есть её может и не быть по какой-то причине.

Надо у БИОСа спрашивать одним из древних вызовов, имевшихся ещё в первых версиях, который сообщит общий объём нижней памяти (до 640 Кбайт), и ориентироваться на его результаты. Физически-то память имеется всегда, просто этот вызов скроет объём, занятый БИОСом вверху. Какой вызов, не помню, но на Вике в своё время описывал (в статейке про определение доступного объёма памяти ПК).

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

Где размещать, по адресу 0x500 или 0x600? Если разрабатываете что-то под реальный режим, возможно небольшая экономия играет роль. Однако, на практике гораздо большую роль играет не экономия, а насколько удобно размещение ядра в памяти для программирования. Нужно помнить что к примеру начальная загрузка MBR происходит по адресу 0x7c00, что выше упомянутых выше и 0x500 и 0x600. Так что даже при загрузке ядра придется делать дополнительные телодвижения. Поэтому лучше размешать ядро не по адресу 0x500 и не 0x600, а где-то выше. Либо со смещением 64K, либо со смещением 1М, как и делают многие операционные системы защищенного режима.

У меня начальный стек ядра лежит в диапазоне 500h-8000h, причем дно используется также интенсивно, как и вершина: начиная с адреса 500h и до 1000h-7*8 встроенные компоненты ядра могут статически резервировать небольшие участки для передачи параметров из RM в PM, если у них нет возможности это сделать в вершине стека (для передачи параметров через вершину стека нужно соблюдать правильный порядок помещения параметров в стек в RM/извлечения параметров из стека в PM). Конец первой страницы сразу отдается для будущего размещения в нем начала IDT. Потом эта страница будет отображена в пространство ядра и объявлена некэшируемой, чтобы предотвратить возможность появления одного опасного бага на пентиумах.

Извиняюсь за столь детальное описание. Это чтобы картина была полностью ясна.

??? MBR-загрузчик сам себя перемещает, причем обычно как раз по адресам 500h или 600h. Я обычно компилирую MBR-загрузчики как раз с перемещением по адресу 500h. У моего последнего MBR-загрузчика использование этого адреса вообще является обязательным, т.к. задекларировано, что именно по этому адресу после своей работы он должен сохранять всю таблицу разделов (код идет вслед за таблицей).

Согласен. MBR загрузчики всегда себя перемещают. Тем не менее следом они грузят Boot Loader на свое место. Так что все-равно адрес 0x7c00 оказывается использован. Конечно Boot Loader тоже может себя переместить, но это и есть те самые телодвижения, про которые я и говорил.

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

Изначально разговор был о возможности использования диапазона 500h-5FFh в принципе, т.е. для любых целей.

Для загрузки файла ядра в RM я считаю самой удобной базу 8000h. Стартовый 32-разрядный код вообще не выравниваю или выравниваю, как обычные подпрограммы на 16. Образ основной секции ядра с фактическими кодом и данными выравниваю на 4 байта для дальнейшего переноса образа на постоянное место (иногда выравниваю на 8 байт, если данные для первичной GDT находятся внутри этого образа).