Ответов на этот вопрос много. Каждый использует так, как хочет и может. Моя же концепция использования доп.ОЗУ следующая. Мне доп.ОЗУ нужно не только для загрузки программ в ОЗУ выше 8000, но и для организации из доп.ОЗУ RAM-диска.Сообщение от Vladimir_S
Область 8400...BFFF - это окно, через которое CPU получает доступ к памяти значительно больше его адресного пространства. Это архитектура с диспетчером памяти (в противовес архитектуре цельно банковой коммутации, которая тоже имеет свои плюсы).
Но одновремено, это не только окно, но и область где работают ДОС и все те программы, что не должны портить основное ОЗУ. В частности отладчики в этой области позволяют отлаживать любые программы РК86, тогда как отладчики в основном ОЗУ это делать не могут. Текстовый редактор и ассемблер могут иметь всё основное ОЗУ для хранения исходника. А Вы видели, что редактор с макро-ассемблером имеют размеры более 12 кб и если их загрузить в основное ОЗУ, то можно транслировать исходник лишь крошечного размера, что делает макроассемблер бессмысленным.
Программа в области 8400 может занимать своим кодом несколько сегментов по 15К. Но пока это не требуется. Я исхожу из того, что для работы программ из области 8400 отводится только один сегмент в 15 кб. Номер этого сегмента не важен (это первый сегмент, что не из основного ОЗУ). Если ОЗУ раздельные, то это сегмент 0, а если совмещённые, то 2 (тогда сегменты 0 и 1 это куски основного ОЗУ). ДОС при старте
грузится на 8400 и узнает номер текущего сегмента считывая байт из адреса F102. А затем все последующие сегменты использует под RAM-диск. Поэтому ROM-BIOS при сбросе должен инициализировать порт F102.
Из-за того, что для доступа к доп.ОЗУ используется тот же самый участок памяти (8400...BFFF), где работает ДОС, то возникают сложности программирования. Программа работающая в окне 8400 не может сама переключать ОЗУ в этом же окне (иначе при переключении, код самой программы исчезнет из адресного пространства и произойдёт улёт). Подпрограммы чтения/записи из доп.ОЗУ могут располагаться только в некоммутируемой памяти. Именно поэтому так необходимы две подпрограммы в ПЗУ позволяющие читать и писать в любое место ОЗУ, а не только в текущий сегмент, включённый в окне. В крайнем случае, некоммутируемый участок можно программно имитировать в коммутируемом ОЗУ.
П/п-ммы F836/39 не обязаны быть прошитыми в ПЗУ целиком. Достаточно иметь только входы и вектора (заглушенные по сбросу). Тогда для любой внешней памяти можно загрузить драйвер, что сделает входы F836/39 рабочими. Только грузить драйверы расширенной памяти придётся в основное ОЗУ (т.к эти драйверы переключают окно и не могут сами работать в окне 8400).
Пока я стремился сделать эти подпрограммы аналогичными орионовским, т.к тогда мне не требуется переделывать модули VDISK.INC во всех ДОС. Но видимо для такой архитектуры это не оптимально. Процедуры в ПЗУ получились слишком медленными и огромного размера. Это для 256К, а для 1 мб размер кода увеличится. Изменив программный интерфейс (т.е идеологию) можно в те же 75 байт засунуть вместо обмена по 1 байту, обмен целым сектором в 512 байт. Что раза в 3-4 ускорит работу с эл.диском.
Есть ещё один способ организовать доступ к эл.диску при такой архитектуре. При этом даже не требуется менять базовое ПЗУ. Суть в следующем. В каждом сегменте в адресах BFC0...BFFF программно имитируется непереключаемый участок. Для этого в каждый сегмент (программой из основного ОЗУ) в эти адреса записывается один и тот же код. Тогда при включении в окне любого сегмента по адресам BFC0...BFFF остаётся один и тот же код. Т.е этот участок стал как бы некоммутируемым. Где и располагаются две подпрограммы чтения/записи байта или сектора.
ОЗУ размером больше чем 32+16 кб нужно только для ДОС, точнее для эл.диска ДОС. Если же ДОС имеет другой массовый носитель, например "micro-SD"-карточку в 2 Гб, или плату внешнего эл.диска 512К, то доп.ОЗУ более, чем 15 кб не нужно. Для ДОС 15 кб как раз достаточно. Это 10-12 кб для самой ДОС, а остальное под дисковые буфера и системные таблицы (т.к при больших дисках очень большие 'Allocation Tables', VTOC или FAT).
Ответить с цитированием