Конечно ввести в BDOS функцию переключения всего ОЗУ до уровня BDOS совсем просто. Но сначала надо понять для чего это надо.Сообщение от Xrust
Если наличие доп.банок в ДОС использовать только для данных (не для кода ПО), то это ничем не отличается от ОРИОНА с кучей банок ОЗУ, в котором доп.банки истрачены не на VDISK, а свободны для хранения оперативных данных программ. Например текстовый редактор загружает в ОЗУ излишних банок весь текстовый файл с размером превышающим TPA (минус код редактора), избавляясь тем самым от необходимости дискового свопинга, что существенно ускоряет и сокращает износ дисковода и дискет. Но кто будет сейчас писать такой редактор или иные программы с обработкой больших данных в иных банках? К тому же и без таких наворотов, для обычного TPA в 48 кб уже написан редактор SuperText, в оригинале называемый 'Final Word', и это действительно оказалось "последнее слово", т.к за прошедшие 35 лет никто лучше не сделал.
Если использовать доп.банки, управлямые ДОС, для кодов программ, то где брать такие программы? У программ на ассемблере объём небольшой, тут нет необходимости вводить XTPA в других банках. А чтобы получить гигантские программы написанные на ЯВУ, которые раскидывают свой исполняемый код по всем банкам, надо иметь соответствующий компилятор.
Гораздо умнее использовать одну доп.банку ОЗУ иначе, перегрузив в неё исполняемую часть кода DOS, а именно CCP и BDOS. Так и реализуют версии CP/M, у которых вершина TPA достигает FF00. И так сделано не только в эмуляторе Z80MU, написанном Joan Riff, но и на реальных машинах 80-х годов. Это позволяет прогонять программы размером в 63,7 кб. Укажите на того, кто написал программу большего размера.
Таким образом достаточно иметь архитектуру ОРИОНА с 3-мя банками ОЗУ. Первая банка - банка CP/M, где только ZERO-page в области 0...100 и вход в BDOS в самой-самой вершине ОЗУ. Вторая банка содержит исполнительную часть кодов самой ДОС, драйверов и TSR-программ на прерываниях. И третья банка - это просто ОЗУ для данных, размером в 64 кб. Что очень полезно для графического интерфейса с окнами, чтобы сохранять там содержимое открытых окон и не мучиться, как сейчас, тщетно надрываясь в попытке уместить код программы, дисковый буфер и буфер сохранения окон в крошечном TPA в 30 кб (имею ввиду ОРИОН в банке 0 в CP/M с графическим драйвером 10 кб).
Такая трёхбанковая ДОС может быть и многозадачной. Но не в общепринятом смысле, а быть ДОС с процессами на прерываниях. Т.е грамотно поддерживать работу мелких резидентных и загружаемых драйверов на прерываниях. При этом на входе INT Z80 такт 50 ГЦ и почти все периоды частоты 50 ГЦ прогоняется основная программа. Загруженные процессы получают управление каждый только на 1 период частоты 50 ГЦ, да и то, если процессу много не надо, не целиком. И тут возникает проблема придумать какие же резидентные программы (типа TSR) могут стать процессом. Понятно, что процессом может быть опрос клавиатуры (по получении кода, положить его в кольцевой буфер), печать на принтер в фоновом режиме, обслуживание апп.часов с выводом текущего времени на экран в любой программе и управление автодоилкой домашнего бегемотика.
Но всё это необязательно и серьёзного рассмотрения заслуживает только сам факт получения в CP/M максимально большого TPA. Это не сложно сделать и error404 уже сделал для ОРИОНА максимально большое TPA в своей ДОС, совместимой с CP/M.
Исходя из вышеизложенного в этих 2-х постах, разумно использовать CP/M 3.0 в небанковом варианте. Что без хлопот даёт даты у файлов, все навороты, что даёт ZCPR и возможность использовать ПО для CP/M 3.0, а его будет намного больше, чем для CP/M 2.2, т.к для CP/M 2.2 западные фирмы прекратили писать программы в 1982, а для CP/M 3.0 и MSX программы писали аж до конца 80-тых.
Ответить с цитированием