Посмотрим вечером.
Вид для печати
Пашет.
Заглянул в драйвер...
Несколько слов.
Системная библиотека уже содержит макрокоманду .ADDR которая обладает весьма большим функционалом (кроме того что использован здесь). Вряд-ли есть смысл дублировать. Хотя на самом деле в данном драйвере она вообще не нужна (см ниже).Код:.Macro .ADDR x
Mov PC, R0
Add x -., R0
.EndM
Макрокоманда нигде не используется ниже. В XM/ZM работать не будет (если вдруг возникнет желание сделать поддержку для). В системной библиотеке есть замечательная макрокоманда .MTPS для таких целей.Код:.Macro MTPS xx
Mov xx, -(SP)
Mov PC, -(SP)
Add #6, (SP)
RtI
.EndM
Повторение того, что и так делается автоматом. Определение же вручную этих настроек здесь ломает возможность использования драйвера в стандартной процедуре SYSGEN.Код:.IIF NDF RTE$M, RTE$M =: 0
.IIF NDF MMG$T, MMG$T =: 0
.IIF NDF ERL$G, ERL$G =: 0
.IIF NDF TIM$IT, TIM$IT =: 0
Ничего полезного кроме несовместимости с RT-11 V5.0 на уровне исходников не дает: UMRы нам не нужны, error logging не поддерживается, а больше нигде от этих команд пользы нет. Ну разьве что сторонние утилиты могут посмотреть в эти таблицы (система их никак не использует). Зачем нужен .DRPTR без параметров даже придумать не могу.Код:.DrPtr
.DrSpF <373>
Не очень хорошая идея вписываться в докементированные (со времен как минимум 4.0) области заголовка драйвера.Код:. = 116
HXMES:
.ASCIZ <CR><LF>"HX DSK/TTY multiplexer v1.0 2012"<CR><LF>
Если совместимость с самыми древними мониторами не нужна (а в том виде как есть ее и так нет), то можноКод:. = 200 ; DATA DEVICE Installation check
Return
. = 202 ; SYSTEM DEVICE Installation check
воспользоваться макросом .DRINS который предназначен для определения точки инсталяции.
Думаю проще JSR R0 и строка текста после :)Код:.ADDR #HXMES
Кстати, тут как я понимаю готовился .PRINT изначально, мешался драйверу?
Бессмысленный функционал. Драйвер работает с буфером программы и следовательно требует специальной работы с ним для XM. Непонятно зачем испольхуется значение - можно же было сделать [NO]KEY.Код:.DrSet MMGT, 2, O.GEN, NUM
CLC лишний - никто бит C не взводил, да и первая же команда его чистит в явном виде.Код:O.GEN:
Tst R0 ; Arg = 0 ?
BEq 30$
BiS R3, HX.GEN ; Set SYSGEN bit.
Br 31$
30$:
BiC R3, HX.GEN ; Clear SYSGEN bit.
31$:
ClC
Return
В системной библиотеке есть замечательная макрокоманда для этогоКод:.IIF GT .-1000 .ERROR
.ASSUME . LE 1000,MESSAGE=<;SET area overflow>
В начале драйвера есть намек на разные CSRы. Тогда проще сделать поддержку SET HX CSR=xxxxxx.Код:Mov @#TPS, TPSRes
CLR будет короче :)Код:BiC #100, @#TPS
Попутно стоит отметить, что подобное не сработает в многотерминальных системах. Можно добавить проверку и .ERROR (на случай сборки родным SYSGEN) или проверку в подпрограмме инсталяции.
Дальше углубляться не стал. Добавлю еще, что для сборки драйвера неплохо бы LINK/NOBITMAP использовать (что согласно документации в принципе требуется).
Вопрос на засыпку - как проще всего удостовериться, что терминал подключен через HX?
То есть SET команды переделки mapped драйвера в unmapped и наоборот не должно быть в принципе (для I/O устройства это слишком сложно - проще как и положено иметь два драйвера), а для XM надо пользоваться подпрограммами маппинга буфера.
Ругаться же смысла нет поскольку XMу вообще нет никакого дела до файлов xx.SYS, а если усер переименовал его в xxX.SYS, то это его проблемы :)
Я о программном способе - к примеру из загрузчика. Хотя думаю самое простое - просто счетчик попыток ожидания готовности на прием :)
Запустил XM с HX...
DIR, загруженный в верхнюю память, показывает каталог.
Драйвер не оптимизировал, так, попинал слегка от нефиг делать :)
Перечисленное выше не имеет никакого смысла и в нормальном драйвере ничем не поможет. Причина проста: эти директивы всего лишь добавляют лишний код в драйвер, тем самым просто отодвигая дальше вектор системных подпрограмм. Это спасет драйвер от перезаписи его кода значениями этого самого вектора, но никак не поможет драйверу попасть в правильные точки вызова (к примеру в системе с поддержкой device timeout, $INPTR, вызываемый .DRASTом находится на одно слово дальше, а драйвер, скомпиленный без поддержки по прежнему будет вызывать подпрограмму по привычному смещению и тем самым вызовет @$TIMIT вместо @$INPTR).Код:.IIF EQ MMG$T .BlkW 5
.IIF EQ ERL$G .BlkW 1
.IIF EQ TIM$IT .BlkW 1
Данный конкретный драйвер для unmapped системы будет работать и с таким довеском - он просто ничего не вызывает из этого вектора. С mapped драйвером сложнее - там нам нужны вызовы из системного вектора, а если драйвер собран без поддержки таймаута, значение, предназначенное для $TIMIT как раз впишется в точки вызова XMных подпрограмм. Можно правда плюнуть на это так как XM без поддержки device timeout вроде не бывает в принципе.
Правильный метод - использовать .DREND или .DRBOT с FORCE (это правда не решит проблеммы с точками вызовов которые лежат после $TIMIT и $ERLG, но пофиксит в нашем случае XMный драйвер), но к сожалению .DRBOT только в V5.6 научился это делать. Что впрочем не мешает нам собрать драйвер в 5.7 и использовать его потом где угодно :)
Из серии "дурацкая идея": можно засунуть стартовый код в котором будет обычная программа синхронизации с монитором - она спросит файл монитора, прочитает оттуда sysgen слово, пропишет в драйвер и подправит вызовы подпрограмм из вектора, и никаких сетов ;)
Другая дурацкая идея - вызывать все вручную. Какой-то драйвер вроде делал так.
Кстати, SETы переделал на [NO] варианты. Проверять лень было :)
PS. SPFUN я там не переделывал для XM. Принцип тот же, только $PTWRD...
$GTxxx/$PTxxx подпрограммы требуют чтобы R4 смотрел на Q.BLKN.
Подпрограммы упдатят Q.BUFF.
---------- Post added at 18:23 ---------- Previous post was at 18:23 ----------
Сейчас выложу дорайвер в котором SPFUN в XM тоже работает.
---------- Post added at 18:27 ---------- Previous post was at 18:23 ----------
Загрузка получается одна из 10-30 попыток. Если загрузилось - дальше работает. Где-то видимо вылезает разница между полноценным и USBшным COM портом.