|
EXTENDED ROM-BIOS в ROM-диске ОРИОНА-128
Платы Орион-128 и наборы микросхем, куплю микросхемы z80 Как купить платы на ПК Орион-128Аннотация: Данный файл предназначен для матерых хакменов, описывает некоторые особенности версии ROM-BIOS и ORION-DOS V3.0 с точки зрения грамотного юзера или матерого программиста, стремящегося использовать все имеющиеся возможности ORION-DOS 192238, Санкт-Петербург, А/Я 175 Чистяков Владимир (1997) EXTENDED ROM-BIOS в ROM-диске ОРИОНА-128ORION-DOS исходит из двух основных предпосылок, на которых и основаны все преимущества ORION-DOS перед антикварными ДОС ОРИОНА. Первое - в системе всегда имеется эл.диск. Второе - в ЭВМ имеется мощнейший ROM-BIOS, рассчитанный на поддержку графического интерфейса из программ на ЯВУ. Без разницы как устроен этот ROM-BIOS, без разницы какой эл.диск в системе (внутренний из 'излишнего' ОЗУ или внешний на доп.платке). Важно что все это есть и доступно. EXTENDED ROM-BIOS удобнее всего хранить в ROM-диске паршивой системы ORDOS, причем 'замаскировав' этот ROM-BIOS под файл системы ORDOS. Для этого файл прошивается с адреса 800h с любым именем (и даже с любыми адресами загрузки). Этот ROM-BIOS в ПЗУ ROM-диска идентифицируется следующим образом. Сначала по адресу (по адресации ROM-диска) 813h контролируется следующая строка, являющаяся 'идентификатором' ROM-BIOS: "(C) CHISTYAKOV VL. 199X". Если такая строка обнаружена то осуществляется загрузка ROM-BIOS в ПЗУ. Для этого используются байты с 'оффсетом' в 82Ch-82Fh, являющиеся адресом загрузки и длиной ROM-BIOS. Сам код ROM-BIOS занимает в ПЗУ ROM-диска адреса с 830h. Длина зависит от версии (16К). Но еще более удобен вариант, когда гнусной ORDOS в ROM-диске вообще нет и с адреса 0000h в ROM-диске прошита программа стартового меню, которая грузится на B800-BFFF любым ПЗУ для ОРИОНА-128. Тогда этот стартер грузит Ваш XBIOS автоматически, без участия ДОС (XBIOS не зависит от ДОС и может использоваться отдельно). ORION-DOS при старте проверяет наличие в системе XBIOS и если не обнаруживает его после обработки файла CONFIG.SYS, то тогда осуществляет проверку ROM-диска ОРИОНА на предмет наличия EXTENDED ROM-BIOS там. Таким образом ROM-BIOS может грузиться до загрузки ДОС, во время загрузки ДОС (как драйвер) и после загрузки ДОС (как внешний драйвер замаскированный под ORDOS-файл в ROM-диске) Расширитель ROM-Bios для Ориона-128 Ниже идет список ТОЛЬКО ИМЕЮЩИХСЯ в твоей версии ROM-BIOS ROM-BIOS ПОДДЕРЖИВАЕТ СЛЕДУЩИЕ КОМАНДЫ ВХОДОВ F00X01 QINFO запрос номера версии драйвера (и адр.TABLE) ПОМНИТЕ: Эти данные верны для EXTENDED ROM-BIOS V1.47 В версиях с меньшими номерами части функций нет, а в
более поздних версиях могут быть изменения и дополнения. Номер версии ROM-BIOS можно посмотреть в дампе
ROM-диска в начале кода или любым отладчиком по адресу B2:EFFB/EFFCh. Языки высокого уровня такой возможностью не обладают. Зато они могут передавать п/программе в маш.кодах параметр. Этот параметр (номер функции) передается, как и принято в ЯВУ не непосредственно в виде его значения, а лишь указателем на ячейки в ОЗУ где начинается область хранения этого параметра. Таким образом подпрограмме в маш.кодах передается всего два байта, которые передаются в регистровой паре HL. При этом фактически п/программе передается не два байта, а больше - в зависимости от той переменной котороя передается в п/программу в машинных кодах. Если речь идет о целочисленной переменной, то это два байта, если константа с плав.запятой одинарной точности, то это 4 байта. Если константа двойной точности, то это 8 байтов. И если строчная переменная или массив, то 255 байтов или даже более. Но в регистровой паре HL передается только указатель на эти переменные То есть адрес области начала их хранения в ОЗУ. В целой переменной это указывает на 2 байта значения. А в строчной на байт описателя (длина, затем 2 байта адреса). Таким образом интерфейс с ROM-BIOS для ассемблера и ЯВУ - в корне различен. Именно поэтому и имеется целых 6 входов. Собственно для вызова функций используется два входа - один для ЯВУ - это по адресу F000, и второй для ассемблера - по адресу F006. А четыре других входа - это входы PEN-команд. Также два из них для ЯВУ и два для ассемблера. Эти входы PEN-команд не имеют параметров, передаваемых через ОЗУ и команда здесь передается как номер функции для входов F000/F006. В принципе вход ЯВУ можно использовать и из ассемблера. Но
тогда номер функции надо 'положить' в какую-либо ячейку ОЗУ
а в регистровую пару HL загрузить адрес этой ячейки, а так-же подготовить регистры связи R1-R7. Тогда и из ассемблера
можно вызывать вход F000. Но для ассемблера проще использовать вход F006, который специально предназначен для этого.
При вызове входа F006 в регистре A микропроцессора передается номер функции, а параметры передаются в регистрах HL,
DE и BC и соответствуют регистрам связи R1/R2, R3/R4 и (!!)
R6/R7 соответственно. Т.к регистров не хватает, то параметр
регистра связи R5 передается в ячейке памяти (R5) как и при
ЯВУ. Но возвращаются параметры только в регистрах R1-R7,
т.к используются те-же самые п/программы, что и для ЯВУ. Итак вот список входов с их адресами и назначением: F000 - ЯВУ, командный вход. В HL - указатель на функцию В PEN-командах F00F/F015 используются только младшие четыре бита команды. Т.е испольняется только один шаг перемещения пера с рисованием или без. В PEN-командах F01E/F024 содержатся две 'упакованные' PEN-команды и первым исполняются 4 младших бита, затем 4 старших. Эти входы используются для ускоренного вывода заранее подготовленных PEN-фрагментов, а одинарные входы используются для оперативного черчения, когда нецелесообразно тратить время ЯВУ на 'упаковку' нибблов в байты по-двое. В данной версии имеются и другие функции ROM-BIOS, но они или в данной версии не отлажены либо 'не публикуются', т.к используются для защиты от нелегального использования лицами не знающими верный пароль. В данной версии ROM-BIOS использован несколько 'устаревший' стадарт устройства GRI. Как выяснилось для программ не для EMJOY, а с настоящим JOY или MOUSE выгодно иметь возможность перемещать указатель с нажатой кнопкой, что эмулятор на клавиатуре обеспечить не мог и поэтому это не нашло своего отражения при разработке 'протокола' устройства граф.ввода GRI. После того, как автор подключил мышь выяснилось несовершенство такого протокола. Поэтому Вы можете сами грузить свой более мощный драйвер GRI функцией LDGRI, - тут-же драйвер EMJOY вырабатывает коды в 'старом протоколе' - т.е возвращает коды 0,1,2 (а значит и не позволяет узнать об одновременном перемещении и нажатии кнопок). Для того, чтобы это 'поиметь' факт перемещения теперь 'выдается' старшим битом, т.е возвращается код не 0, а 80 или 81 или 82. Это и позволяет иметь одновременную информацию о перемещении и кнопках. На EMJOY это невозможно. Однако при использовании в качестве кнопки при РК86-клавиатуре клавиши РУС/ЛАТ не входящей в основную матрицу или 'прямом' чтении порта клавиатуры это будет возможно в последующей вeрсии драйвера EMJOY. Т.е учтите, что ниже описано отличающаяся версия драйвера GRI, а данная версия возвращает 0, при перемещении и FF при отсутствии перемещения и нажатия (так было проще для реализации, т.к функция F81B возвращает FF). ROM-BIOS не имеет векторов и допускает загрузку только одного драйвера - драйвера GRI. Этот драйвер пишет сам пользователь, причем программа должна быть перемещаемой (без использования адресных переходов, т.е только JR). Максимальный размер его - 256 байт. Он возвращает управление командой RET, результаты в регистрах. Если это мышь то буферизование 'ввода' этот драйвер должен делать сам (если нужно буферизование). Драйвер должен возвращать регистр A=FFh, если ничего не вводится. Если было нажатие или перемещение, то возвращается: регистр A равный 1 или 2 если было нажатие на левую или правую кнопки. Если обнаруживается перемещение GRI то возвращается А на 80h больший (т.е 80,81,82) и тогда в регистре C возвращается код направления RRR (показывающий направление). После загрузки пользовательского драйвера GRI функция QGRI начинает использовать эту п/п драйвера (перегружая регистры A и C процессора в регистры связи R1 и R2 (F3D8,F3D9). Работа с GRI из БЭЙСИКА имеет особенность. Вызов функций MVGRK1 необходимо (но не обязательно) вести в режиме полностью 'отключенной' клавиатуры, т.е когда перестают функционировать функции CONIN и CONOUT и интерфейс с клавиатурой и экраном возможен только через вход F000h. Тогда, после выполнения команды CONSOF, связь функции CONIN с ее исполнительной частью полностью разрывается (глушится) Это надо по двум причинам. Во-первых, - с отключенной клавиатурой можно иметь устройство EMJOY - эмулятор джойстика на курсорных клавишах, который работает даже в интерпретаторе. Если п/п клавиатуры не отключить, то функция STA-TUS обнаруживает нажатие клавиши. А так как БЭЙСИК интерпретатор после исполнения каждой строки программы проверяет клавиатуру (чтобы обнаружить CONTROL/C), то это фатально тормозит перемещение GRI по экрану и получается разница в работе компиллятора и интерпретатора (а 'визуально' в программе это проявляется, как 'писк' при работе JOY или EMJOY - ведь они используют клавиатуру). И при работе всех графических процедур написанных на БЭЙСИКЕ полезно по этим же причинам отключать клавиатуру (это ускоряет программы). Внимание! Однако если ваша программа, выполнив CONSOF, по ошибке после этого не исполнит CONSON и сразу перейдет на ввод с клавиатуры, то программа полностью зависнет и прервать ее будет никак нельзя, если не включена функция BREAK ON. При инициализации, для ускорения работы включен режим BREAK OFF и поэтому на время отладки непроверенных программ надо специально включать режим BREAK ON. Процедура клавиатурного BREAK подключается к программному прерыванию срабатывающему от часов. Эта функция SOFT INT предназначена для загрузки специального драйвера пультового режима (аналогично машинам DEC, где пультовый режим прямо встроен в микропроцессор (за счет двойного дублирования всех регистров и наличия входа для апп.запроса пультового режима). Пультовый режим это в терминах МИНИ-ЭВМ - так называемый СУ-ПЕРВИЗОР, т.е специальная программа в которую можно выйти из любой программы для целей отладки или устранения программной 'аварии'. Однако сам драйвер пультового режима не встроен в данную версию ПЗУ (из-за нехватки места). Точнее, как Вы видели этот драйвер там пока просто простой монитор для ОЗУ, работающий в маленьком окошке на 32 символа. Драйвер должен загружаться при загрузке ДОС. Без этого, в случае ошибочного 'улета' программы в режим CONSOLE OFF и только (!) при условии, что функция BREAK включена и используется РК86-клавиатура (не МС7007 даже по схеме 12.1991), то одновременное нажатие клавиш УС/СС/Z вызовет звук XERSND и выполнит ф-цию CONSOLE ON. Использование сочетания клавиш УС/СС/C тут невозможно, т.к такое сочетание встроено в МОНИТОР-3 и вызывает JMP F800 (т.е уход из 'улетевших' программ через СБРОС). Еще в этом столетии я планирую закончить драйвер пультового режима, который должен позволять полное управление ресурсами ЭВМ из любой программы, удобную установку даты, времени, будильника, управление режимами принтера с возможностью загрузки собственных шрифтов (эмуляция в граф.режиме), фоновую печать по принципу известной программы DESPOOL CP/M, печать содержимого экрана на принтер (в граф.виде), просмотр и модификацию ячеек памяти а также контроль в виде LIST программы на БЭЙСИКЕ интерпретаторе с возможностью модификации констант. Из перечня параметров для регистров не совсем понятна работа и назначение самой важной функции графического интерфейса MVGRK1 (что мнемонически кодирует строку: EXE MOVING GRK). Особо следует заметить, что ГРК (граф.курсор) обязательно должен быть предварительно включен (иначе его просто не будет видно). Для включения ГРК надо выполнить один раз функцию позиционирования (если задать неверные параметры, то курсор автоматически сам установится в центре экрана). Обработка функции ГРК происходит так. Эта подпрограмма использует драйвер GRI и перемещает ГРК по экрану до тех пор пока не будет обнаружено отсутствие ввода или нажатие одной из двух кнопок GRI. Если из п/п драйвера получаются данные о перемещении (т.е
сдвиг устройства мышь или нажатие ручки джойстика), то не
происходит выхода из п/п MVGRK1 до тех пор пока не прекратится ввод (ручка в нейтральном состоянии, или мышь неподвижна) или будут получены данные о нажатии на кнопки. В
результате эта функция перемещает по экрану курсор, без дополнительных затрат программиста и программиста даже не волнует какой конкретно тип устройства GRI имеется в данной
ЭВМ, как оно работает и устроено. При инициализации в качестве драйвера GRI загружен встроенный в XBIOS универсальный эмулятор джойстика на клавиатуре. Этот др-р EMJOY чтобы
мог работать на любой клавиатуре использует ф.F81B. Поэтому
им пользоваться значительно менее удобно, чем джойстиком. Эти клавиши <ПРОБЕЛ> и <ВК> имитируют кнопки мыши. Так у джойстика только одна кнопка, то для получения кода 2 драйвер джойстика не сразу возвращает управление, а ждет полсекунды второго нажатия кнопки. То есть при двойном нажатии джойстика возвращается код 2. У ЭВМ Apple MACINTOSH тоже на 'мыше' только одна кнопка, но этого уже вполне достаточно. Однако при нажатии на 'кнопки' (или кл.ПРОБЕЛ,ВК при EMJOY) программе возвращается не только один 'код' нажатой кнопки, но и позиция ГРАФ.КУРСОРА на экране (в рег.R6-R7). Причем не в графических, а в символьных координатах (0-59,0-24). Но это только в том случае, если нажимают на 'кнопку', т.е если в рег.R1 содержится 1 или 2 (в иных случаях координаты не пересчитываются и в рег.R2,R3 будут случайные величины). Это весьма удобно для того чтобы сразу-же по выходу из функций CLICK или MVGRK вызвать крайне удобную функцию TSTOBJ. Учтите, что при отсутствии тикера часы ходят 'программно' и поэтому скорость их хода сильно зависит от конкретного ПЗУ F800, примененного в Вашей ЭВМ. Константы пожобраны для МОНИТОРА V3.6, причем для РК86-клавиатуры и при реальном так- те ОРИОНА в 4.25 МГЦ (141% ТУРБО с WAIT и еще 20% ускорения за счет замены кварца 10 МГЦ на 12 МГЦ). С другим МОНИТОРОМ (особенно МС7007) и с другими реальными тактами в Вашей ЭВМ часы будут ходить иначе (например на ОРИОНЕ 2.5 МГЦ часы будут ходить в 1.7 раза медленнее, а при клавиатуре МС7007- еще медленнее). PS: Имеется огромное количество версий драйвера и ROM-BIOS
на его базе. Причем коды команд в промежуточных версиях существенно менялись. Но большинство версий, имеющих функцию
INFO совместимы по вышеприведенным кодам (хотя имеют и отличия и у промежуточных версий нет части перечисленных функций, но номера соответствуют, - для отсутствующих функций
выполняется RET; чем больше номер версии, тем больше реализовано функций). Тут приведены не все коды - есть и другие.
Для поточечной работы можно пользоваться графич.ESC-кодами,
которые кстати можно уже считать 'устаревшими'- они есть во
всех, даже очень ранних версиях и поэтому видимо уже не будут исключены, но для большинства случаев более удобно
пользоваться командами PSET/PRESET, т.к они для ускорения
выполнены в линейном стиле, без подпрограмм и удобно, что
они не меняют регистры R1,R2,R3 где указывается координата, ПРИЛОЖЕНИЕ 1. СИСТЕМНЫЕ ЯЧЕЙКИ ORION-DOS И КОММЕНТАРИЙ.EFFA DB MSKSTROB битовая маска строба принтера Комментарий для умелых юзеров ORION-DOS V3.02Если по адресу CONIN BUFFER (т.е адресу из ячейки EFF5)
записать число (меньшее 78), то функция CONIN будет воспринимать байты по адресу BUFFER+1...BUFFER+79 как буферисованный ввод и с функции CONIN будет возвращено ровно столько
байтов, сколько записано в ячейку CONIN BUFFER. То есть при
каждом вызове функции CONIN сначала проверяется - не 0-ли в
ячейке CONIN BUFFER и ежели там не 0, то следующий байт берется и возвращается как результат CONIN из буфера (число
по адресу CONIN BUFEER уменьшается на 1 и все 80 байтов в
буфере сдвигаются вниз). Так функционирует буферизованный
ввод. На этом основана обработка AUTOEXEC.BAT файла, ввод
ключевых команд и тимплет CCP. В данной версии всего две
ключевых команды (т.к жалко ОЗУ). Зато они не по 12 байтов,
а по 80. Адрес PDMTBL (т.наз.таблица подмены) дает возможнось заменить как код подмены, так и 'строку подмены'. Идея
заложенная в функционировании ключевых команд функции CONIN
заключается в следующем. Это функция не BDOS и не ROM-BIOS,
а функция CP/M-BIOS. Это как-бы 'вирус' прицепленный на функцию CONIN CP/M-BIOS. По адресу из ячейки EFEDh (PDMTBL)
(а также по адресу на 80 большему) берется байт (и второй)
и проверяется на соответствие введенному с CONIN коду. И
если будет обнаружено соответствие, то вместо введенного с
клавиатуры кода в программу поступает не 1 байт (но может и
даже 1 единственный байт), а целая строка символов - ключевая строка подмены (до 80 символов в этой версии). Это достигается тем, что при обнаружении совпадения кода, вся строка просто перегружается в буфер п/программы CONIN. После
чего до считывания всей этой строки опрос клавиатуры блоки- При наличии МОНИТОРА-3 можно было бы использовать неиспользуемые коды 'псевдографики' (80h-BFh). Но МОНИТОР-3 загублени затравлен безумным стандартизатором и хозяином ОРИОНА. Поэтому можно считать, что с клавиатуры можно получить только коды 0-7F. Из всех кодов не используемых ни в BDOS, ни в программах CP/M рекомендуется использовать коды ^Z и ^F. Загрузив эти коды и соответствующие строки в PDMTBL вы будете иметь по нажатии на клавиатуре сочетания клавиш CONTROL/Z и CONTROL/F вывод нужных Вам строк (или нескольких строк, важно чтобы общая длина была менее 79). Таким образом ORION-DOS имеет встроенную функцию программы SL.COM Сама программа SL.COM от ACP/M 1992, которая также являлась 'вирусом' вешаемым на CONIN и позволяла иметь любое количество подменяемых кодов, в ORION-DOS естественно не работает (т.к она использовала буфер в банке 0, т.е конфликтует по ОЗУ). Но SL.COM имела существенный недостаток, т.к как и всякий вирус она могла грузиться лишь однократно (при повторной загрузке - завис). На практике обычно не надо более двух командных строк и более важна возможность загружать новые ключевые строки. Я написал простенькую программку на БЭЙСИКЕ, которая позволяет формировать и загружать ключевые строки для кодов ^Z и ^F. Эту возможность удобно использовать при программировании на ассемблере и БЭЙСИКЕ. Для ассемблера, например так. ^CSAVE "TMP<ВК>SYSTEM<ВК>SED TMP.BAS<ВК> Вот и все. Загрузив эти две строки в PDMTBL, Вы получаете
возможность в любой момент времени переходить одним нажатием клавиши из БЭЙСИКА в более удобный текстовый редактор. т.е ^[ - EXIT). При использовании WORD MASTER вторая строка будет такой: ^[E<ВК>MBASIC<ВК>LOAD "TMP<ВК>. Как видите тут идея также проста, как апельсин. На этом-же принципе можно получить 'временный режим' вызова ХЭЛПА из любой программы.Т.е например, программируя на БЭЙСИКЕ, Вы вдруг забыли как работает какая-либо из команд. Тогда нажав комбинацию клавиш, Вы выходите в любой "вьювер" текстов и просматриваете соответствующий ХЭЛП-файл. Если Вы еще не 'вьхали' в идею, то намекаю - сначала выдается ^C - чтобы можно было выйти в режим в любом месте, даже из программы на БЭЙСИКЕ, затем програма на БЭЙСИКЕ 'сливается' во временный файл и вызывается редактор для редактирования его. Все то-же самое, как будто это Вы сами вводили эти команды. Только тут все это делается быстро, а при использовании эл.диска переход из БЭЙСИКА в текст.редактор и обратно происходит мгновенно, т.е и получается (ну совершенно) незначительными усилиями - ТУРБО-среда для программирования. Написав себе простенькие вспомогательные программки (на чем угодно, на БЭЙСИКЕ, на СИ, ПАСКАЛЕ, ассемблере или даже в маш.кодах вручную) Вы можете активно использовать эту возможность ORION-DOS. Итак запомните: берете адрес PDMTBL. Сразу по этому адресу хранится первый ИСКОМЫЙ код. А через 80 байтов - второй ИСКОМЫЙ код. Вслед за каждым из этих 'разыскиваемых' кодов следуют до 79 символов, которые выводятся при поступлении с клавиатуры ИСКОМОГО кода. Стоп-байт - FFh (или конец по 79- му символу, т.е используется вся длина буфера PDMTBL). Таким образом, теперь Вы представляете как устроена подмена. Адрес 'КАРТЫ ЭЛ.ДИСКА' также знать очень полезно. Номера треков идут подряд от начала карты (первый нулевой трек, где хранится каталог эл.диска). Каждый трек описывается тремя байтами: N банки ОЗУ и нач.адрес. Треки записываются естественно не подряд - байт к байту, а логическими секторами по 128 байт. Поэтому эл.диск на физическом уровне надо читать 'не внаглую', что бесполезно, а функциями READ/WRITE CP/M-BIOS. Но пересчитать номер блока CP/M в номер сектора немного неудобно, т.к в треке не 32 сектора, а только 31. Поэтому хоть и на трек уходит 4 Кб ОЗУ, а блоки в ORION-DOS по 2 Кб, тем не менее нет удобного соответствия между номером блока и номером трека (т.е в каждом треке не ровно два блока, а на 1 лог.сектор меньше). Это вызвано тем, что надо хранить контр.суммы каждого лог.сектора. Поэтому и работать с ОЗУ 'внаглую' просто неудобно. В то-же время функциями READ/WRITE работать вполне удобно, покрайней мере гораздо удобнее, чем 'возиться' с данными по 1 байту. Каталог эл. диска занимает первый блок эл.диска, т.е сектора 1-16 в треке 0 и имеет размер в 2 Кб. Даже если Ваша программа не будет использовать ОЗУ эл.диска полезно проанализировать КАРТУ, чтобы знать какие куски ОЗУ расположены в начале эл. диска, какие в конце. Заметьте, что последний кусок эл.диска расположен прямо в экране C000 банки 0. То есть по сбросу он повреждается. Этого можно избежать загрузить 'стартовый хук', перехватывающий управление по сбросу. Но опятьтаки этого механизма нет в убогом МОНИТОРЕ-2, а есть только в МОНИТОРЕ-3. Там при старте проверяется сумма байтов в ячейках F3C0/C1... и при равенстве нулю делается JMP по адресу из ячеек F3C1/C2. Но это позволяет избежать очистки экрана C000, только при МОНИТОРЕ-3, причем т.к расположение процедуры очистки экрана в разных версиях ПЗУ разное, то такой 'стартовый хук' оказывается неуниверсален даже для разных версий МОНИТОРА-3 (а их было в 1992 году сделано множество). Поэтому сам я имею такой 'стартовый хук' для того ПЗУ F800, что использую сам. Но всем остальным юзерам не могу сделать версии для всех других МОНИТОРОВ-3. Поэтому в данной версии ORION-DOS последние треки эл.диска форматируются всегда - и при холодном старте и при перезагрузке ДОС, после сброса. То есть если уровень файлов в Вашем эл. диске превысит 80К, то файлы занимающие самые дальние треки 'исказятся' (в них будет E5 после нажатия на сброс). То есть у меня эл.диск имеет больший размер и не портится по сбросу, а у Вас это не так - у Вас портится при сбросе последний трек. Если Вас это не устраивает, то измените параметры эл.диска (адрес узнается по DPB эл.диска А:). Так сделано специально, т.к я решил, что Вам будет лучше иметь эл.диск максимального размера (тем более, что из-за того что в ORION-DOS 16К теряется на сам ROM-BIOS загружаемый в ОЗУ (т.к ПЗУ в ОРИОНЕ нет) и еще 32К теряется для буферов графических процедур (открытых окон) - от этого эл.диск в ORION-DOS становится исключительно маленького размера 84К при 256К, и 144К при 320К ОЗУ в ОРИОНЕ. Номера версий ДОС и EXTENDED ROM-BIOS -десятичные. FREE MEMORY - это кусок куда удобно подгружать маленькие п/программы в маш.кодах из программ на БЭЙСИКЕ. Это предназначено для загрузки Ваших драйверов принтера. ORION-DOS не имеет векторов для загрузки драйверов (это нонсенс, если есть вектора на входе BIOS) Если Ваш принтер не совместим с моим (например не параллельный, а последовательный), то грузите JMP на вектора принтерных функций CP/M-BIOS и кусок кода драйвера в это ОЗУ. Не забудьте при этом изменить ячейки FREE MEMORY. При использовании параллельного принтер по любой схеме проще заменить два байта (маски битов) в моем драйвере принтера, чем иметь свой другой драйвер. Естественно в качестве ОЗУ можно использовать то ОЗУ, где сидит мой драйвер LST сейчас (посмотрите отладчиком где это 'место'). В итоге Ваш драйвер принтера может состоять из 3 команд ассемблера (это заменить байты 'битовых масок' в моем драйвере принтера). Впрочем еще проще не грузить драйвер, а просто 'поковырять' отладчиком в самом коде ORION-DOS и заменить (если надо адреса порта 580ВВ55 и битовую маску для битов STROB и BUSY для порта PC). В данной версии это допустимо, т.к код DOS-BIOS не контроллируется на неизменность кода. Это можно сделать, откорректировав, как файл инсталлятора ДОС, так и в самом коде ДОС на 'бутовых' треках дискеты или в ROM-диске, если DOS грузится из ПЗУ ROM-диска. Узнать о том HD, HD/DD или HD/VD (винчестер IDE 40 Мб) можно только загрузив версию ORION-DOS без драйвера и посотрев стартовое сообщение. Так как при наличие в системе XBIOS стартовое сообщение блокируется и не выводится. Если у Вас клавиатура МС7007 и Вы используете МОНИТОР-3 с драйвером А.Мостового (1991), который рассчитан на свопинг цифровых клавиш, то Вы можете включить в файл CONFIG.SYS одну строчку - SWAP. Это вызовет в процессе обработки CONFIG.SYS 'разблокирование' свопинга. После этого при работе п/программы CONIN будет выполняться коррекция цифровых клавиш (смена верхнего и нижнего регистров у клавиш с цифрами). Для ПЗУ F800 где регистры клавиатуры не перепутаны (например РК86) это делать не требуется, но и не повредит (а только перепутаются регистры клавиш). Адрес порта принтера при инициализации соответствует адресу порта F600. Но на всякий случай при инициализации программируется и порт F600 и F500. Специально, чтобы сменить этот адрес порта в CONFIG.SYS имеется команда LST F500. Она просто подставляет в эту ячейку адрес F500. Точно также, если Вы сами напишете крошечный драйвер из трех команд - LD HL,0F???h : LD (0EFFBh),HL : RET :, то драйвер принтера будет использовать порт F???, а не F600 (биты как у меня). Но в ORION-DOS V3.02/02 есть и возможность в небольших пределах изменить схему адаптера принтера. Речь идет только о изменении разряда STROB в порту PC. Для адаптера используется порт ВВ55. При этом PA - это всегда вывод (данные). А PC используются для чтения сигнала BUSY и записи сигнала STROB. При этом PC программируется так, что младшие 4 бита PC запрограммированы на ввод, а старшие 4 бита PC запрограммированы на вывод (упр.слово 8Ah). Таким образом в качестве BUSY может быть использован D4,D5,D6 или D7. Но используется только разряд D7. Это не меняетя и не настраивается. А для сигнала STROB могут соответственно быть использованы разряды D0,D1,D2 и D3 порта PC. И выбор этого разряда доступен весьма просто. Для этого и служит ячейка EFFAh. Здесь должна быть подставлена битовая маска разряда STROB. Это может быть любое число от 0 до 15. По всем битам, где 1 при работе драйвера будет выдаваться строб. Если подставить 15 (0Fh), то строб 'пойдет' по всем 4 разрядам D0-D3 PC. То есть будет совместимость с адаптером принтера ОРИОН-СЕРВИС (у них это кажется разряд D3). Впрочем корректнее подставить для адаптера с сигналом STROB по биту D3 число 8. Тогда другие разряды этого порта можно использовать еще для других целей (светодиоды, доп.адреса для переключения 'кусков' ROM-диска, биты управляющие включением телевизора или включение автопоилки для Вашей любимой коровы или домашнего бегемота). Однако настройка этой 'маски' - это Ваше личное дело. Спец.команды для этого в CONFIG.SYS нет. Проще всего взять любой отладчик и изменить ячейку .... в файле SG.COM. Или можно написать драйвер в 2 команды записывающий яч.EFEA Не забывайте, что драйвера в ОРИОН-ДОС - это вовсе не COM- файлы и грузятся они автоматически и в банку 0, с того адреса, что Вы укажете. Временные 'драйверки' меняющие 1-2 байта можно грузить в экран с 8000h или грузить их в область графического буфера 100-4000h в банке 0 (в ходе загрузки ДОС эта область не используется). Ниже для примера привожу вид 'карты' эл.диска: KARTA: DEFB 3 ; номер банки ПРИЛОЖЕНИЕ 2. По эл.диску ORION-DOS для особо матерыхКак пересчитать номер блока в номер трека и сектора в эл. диске ОРИОН-ДОС (или дискеты). Для эл.диска параметр PARM - число логич.секторов в физ.треке равно 31. В каждом блоке - 16 логических секторов (2К). Итак, - из каталога мы узнали номер блока, где хранятся интересующие нас данные (или где свободное от файлов ОЗУ). Сначала узнаем порядковый номер логического сектора. Это 16 умножить на номер блока. Теперь делим этот номер на 31 (число секторов в наших треках). Целое число - это номер трека, а остаток от деления - номер лог.сектора. По этим данным, воспользовавшись 'КАРТОЙ' размещения треков эл.диска по памяти ЭВМ, мы легко узнаем место в ОЗУ где начинается данный блок в эл.диске. Таким образом мы всегда можем узнать свободно-ли данное ОЗУ от файлов хранимых в эл.диске. То есть можно-ли по наглому попортить это ОЗУ без всяких последствий для системы. Алгоритм действий тогда такой. Из КАРТЫ эл.диска (а можно и DPB диска) узнаем число треков эл.диска. Из этого, умножив это на 31 узнаем число лог.секторов (по 128 байт). Затем, поделив это на 16 узнаем число CP/M-блоков в эл.диске. Затем считываем в память TPA 2 кило каталога (т.е выполняем функцию READ для 16 лог.секторов трека 0). Затем начинаем просматривать этот каталог просто внаглую. Имена файлов, номера областей и номера экстентов файлов нас не интересуют. Поэтому будем просматривать с шагом в 32 байта, с начальным отступом в 16 байт, куски по 16 байт разыскивая ненулевые байты. Эти ненулевые байты и показывают занятые файлом блоки. Если просмотрев все 2 кило каталога мы не найдем в каталоговых записях нужного номера блока, то значит этот блок свободен и можно использовать это ОЗУ даже для прямого хранения промежуточных данных. Причем, самое смешное, что так как это место эл.диска не используется файлом, то и восстанавливать его (т.е форматировать) не требуется. Эти лог.сектора просто никто не будет считывать, а при записи в них новой информации (при записи в эл.диск новых дисковых файлов) данные этих секторов полностью перезапишутся новой информацией. Естественно, если мы запустим функцию TEST POWER-а, то получим солидный список дохлых секторов. Но кого это волнует, если мы знаем, что сами попортили эл.диск. Таким образом, в случае, если нам вдруг 'приспичило' заняться наглым доступом ко всему ОЗУ (как это практикуют узколобые в своих убогих системах ORDOS или рэтро-CP/M ОРИОНА), то самый простой вариант для этого - просто сначала удалить все файлы из эл. диска средствами функций BDOS CP/M, а затем можно крушить все ОЗУ эл.диска кроме 2К каталога - как угодно. И даже после этого не заботиться о восстановлении эл.диска (хотя вызвать функцию WRITE столько раз сколько лог.секторов в диске - совсем не трудно). Таким образом оказывается, что при грамотном подходе эл.диск в ОРИОНЕ вовсе не является препятствием для 'наглых' программ, которые 'пожирают' ОЗУ километрами и ради которых В.Сугоняко придумал свой ОРИОН-ПРО и сильно 'выступал против' такого использования ОЗУ ОРИОНА, которое предлагал ему я и что реализовано в ORION-DOS V3.0. Заметим, что для эл.диска процедура форматирования и просто записи данных - это одно и то же. При старте ДОС эл.диск действительно форматируется, т.е во все байты записываются коды E5, как и принято для форматирования дискет. В действительности такая процедура необходима лишь только для области каталога эл.диска. Все остальные сектора эл.диска при начальной инициализации можно было бы не менять, а лишь пересчитывать и подставлять контрольные суммы этих секторов. Тогда например при 'слете' программы, Вы могли бы перезагрузившись 'взять' уцелевшие куски Ваших файлов, переписав содержимое треков эл.диска в файлы на дискетах. Но по времени запись байта в эл.диск или считывание занимают одинаковое время, да и система не должна 'слетать'. Поэтому так я не сделал. Хорошим стилем разработки программ для ORION- DOS я считаю следующее. Программы удобнее делать маленькими полностью независимыми кусочками, как практиковали некоторые папуасы. Но они использовали в качестве 'менеджера памяти' ORDOS. То есть куски их программ были маленькими файлами, которые по мере необходимости функциями ORDOS считывались в ОЗУ банки 0. Так как эл.диск полностью снимает проблему обьема файлов программ, т.к с эл.диска файл размером в 16-30 килобайт грузится очень быстро, то выгодно такие модули (или оверлеи) делать на ЯВУ, например на БЭЙСИКЕ Это увеличивает эффективность труда программиста на порядок или два. При том-же самом 'визуальном' результате. Таким образом эл.диск эквивалентен расширению ОЗУ и увеличению скорости процессора, что подтверждает старинную аксиому, что скорость работы может быть компенсирована ростом обьема памяти (в известных пределах). Так например, при программировании линейно, без использования подпрограмм растет скорость, но увеличивается 'память'. Для передачи параметров из оверлея в оверлей можно использовать файлы на эл.диске или даже просто запись на низком уровне (п/п BDOS WRITE) данных в треки VDISK-а. При старте программа должна распаковаться и 'сбросить' на VDISK все свои оверлеи и модули. При этом, если не хватает места VDISK-а, то имеющиеся на VDISK-е файлы программа должна скопировать на дискету, освободив себе место. Это особенно важно для программ, где много графики или картинок. Например DBASE-II имеющий обьем кода в 180К с оверлеями при работе с дискеты производит удручающее впечатление, т.к оверлеи грузятся медленно. Также наример текстовый редактор SED при редактировании файла в 7000 строчек при хранении SPILL-файла на дискете убивает своей неторопливостью при 'перемещениях' по файлу. В то время, как с эл.диском это ускоряется. Поэтому VDISK - это средство, чтобы делать программы на ЯВУ. При такой концепции ОЗУ ЭВМ входящее в эл.диск оказывается поддержаным ЯВУ, а концепция В.Сугоняко, когда все ОЗУ ЭВМ отдается на нужды программ и для его управления требуются специальные менеджеры памяти - нонсенс. При этом и от улучшения архитектуры ОРИОН-ПРО в виде диспетчера памяти не получается никакого толка. Это не поддерживается ЯВУ и поэтому ОРИОН-ПРО лишенный и нормального системного ПО и поддержки энтузиастов обречен. Это мертворожденный монстр, который уже давно 'труп' Все что следует сделать с платой ОРИОН-ПРО - это скорейшая переделка в нормальный, причем скоростной ОРИОН-128, имеющий к тому-же и ОЗУ - "как грязи". К сожалению данная версия ДОС поддерживает только 256/320К. От поддержки версии на 192К я пока отказался (т.к имеется только один юзер с ОЗУ в 192К, да и можно использовать версию на 256К, имея только 192 - тогда нельзя записывать более 20К файлов в эл. диск). То есть, данная версия ORION-DOS не универсальна по VDISK-у. Но эта версия ДОС и не имеет такой задачи. Это 'вводная' версия, к тому-же с TIME LIMIT блоком, которая естественно вполне коммерческая, если известен пароль. Но в первую очередь эта версия ORION-DOS рассчитана на 'экономных' юзеров ОРИОНА-128 предпочитающих 'сидеть' с паршивым антикварным ПО ОРИОНА, чтобы не 'рисковать' с покупкой нового ПО для ОРИОНА-128. В других версиях у меня имеется полная автонастройка на размер эл.диска (сами понимаете, что это сводится к проверке физического наличия в ЭВМ ОЗУ и и смене двух байтов при инициализации ДОС - т.е мне без разницы по 'труду' - поддерживает ли встроенный драйвер эл. диска внутреннее ОЗУ до 4 мегабайтов или до 256 байт - все это сводится к замене одного байта). С лета 1996 я больше не поддерживаю файлы CP/M в ROM-диске ОРИОНА. Это вызвано тем, что при файлах в ROM-диске, удобно чтобы в каждом треке было число секторов кратное 16. Но при этом впустую теряется много ОЗУ ЭВМ. Это вызвано тем, что первый трек ПЗУ- части VDISK-а должен 'попадать' на начало блока. Кроме того проблематично понятно обьяснить юзерам технологию подготовки данных файлов для зашивки в ПЗУ ROM-диска. А с учетом того, что ПЗУ 27256 не КМОП ныне дефицит, а КМОП в моем не сложном программаторе (на двух диодах марки КД522) не прошиваются, то поддержка файлов в ROM-диске пока проблематична. Проще иметь AUTOEXEC.BAT файл копирующий нужные файлы с дискеты в VDISK при загрузке ДОС. 192238, Санкт-Петербург, А/Я 175 Чистяков Владимир (1997)
Купить платы, наборы микросхем на Орион-128, Орион ПРО, Орион Восточный Экспресс 512, Куплю z80а 80аММЕ к1818вг93 Au в позолоте, куплю микросхемы, микросхемы серии к1533, кр1533, кр1531
На предыдущую страницу На главную страницу На следующую страницу
|
||