Увы, оно работает только под последними версиями RT-11. С какой версии начали передавать остаток командной строки с адреса 510 ? С 5.04, да? В общем, моя любимая RT-11DS (SJ) V5.01 в их число не попадает...
Ладно, буду думать.
Увы, оно работает только под последними версиями RT-11. С какой версии начали передавать остаток командной строки с адреса 510 ? С 5.04, да? В общем, моя любимая RT-11DS (SJ) V5.01 в их число не попадает...
Ладно, буду думать.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Все о БК ДВК УКНЦ VAX Alpha
Архив ПО для ретрокомпьютеров
предоставляю бесплатный хостинг на PDP-11.RU для проектов о ретрокомпьютерах
Проблема, правда, возникнет, когда ДВК-шик вырубят внезапно. При плановом выключении (получив низкий на К ПИТН В) можно попытаться снять все эти атрибуты со смонтированных файлов, обещанных 10 мс от снятия К ПИТН В до снятия К ПОСТН В и отключения питания должно хватить. А вот внезапное вырубание всяких самодельных источников (которые сделаны из АТХ) - это ой!
Те файлы, которые прописаны в AZ.INI можно, конечно, смонтировать, игнорируя эти флаги (и потом поставить их, как надо). А вот с файлами, смонтированными на ходу, будут сложности...
- - - Добавлено - - -
Не факт. Я подаю команду BO AZ2:, и? А для того, чтобы не перемонтировать системный диск (любая ОС от такого, скорее всего, упадёт), в программе надо дополнительно контролировать это дело. Но это, скорее всего, можно будет обойти и как-то по-другому.
Тоже верно. В принципе, мне, по всей видимости, будет не особенно трудно проверить файл по списку монтирования. Ладно, это надо обдумать.
Мне казалось, что лучше было бы принять строку CSI и, если в ней указан какой-то файл, использовать его, как источник команд. Если же строки нет, то принимать последовательность команд через .GTLIN и отрабатывать их, зациклив программу. Через .GTLIN - это чтобы можно было править строку посредством SL. В общем, тоже надо обдумать.
- - - Добавлено - - -
И вообще, тут вот СуперМакс высказал предложение: сделать все эти дела внутри контроллера. Переключить контроллер в некоторое подобие терминала и общаться с юзером через терминал ДВК. Тогда программа в ДВК будет совсем маленькой, ее спокойно можно вписать в программу начальной загрузки, которую я пересылаю в ДВК при запуске. И это дело будет работать на голом железе, до загрузки любой ОС. В принципе, продублировать этот кусочек в виде отдельной программы под любую ОС, и можно будет рулить этими делами и на ходу, а не только при запуске.
Так, что информации к размышлению - море! Буду думать...
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Да, переключить контроллер в терминальный режим и принимать/передавать потоки байтов через родной регистр данных контроллера. Тогда программа в ДВК должна просто "коммутировать" эти потоки с системным терминалом, а всё остальное будет делать контроллер - рисовать промпт, выводить HELP, разбирать и выполнять команды. Это самый крутой способ, максимально совместимый со всеми возможными применениями контроллера.
- - - Добавлено - - -
Но здесь есть и подводный камень - в многозадачном окружении контроллер должен запоминать фазу терминального обмена на время выполнения блочного обмена. Иначе когда (например) фоновая задача дефрагментирует какой-то диск, смонтировать новый образ в какой-то свободный привод не получится.
- - - Добавлено - - -
И как тогда в многозадачном окружении программа терминального обмена с контроллером должна сообщить контроллеру о готовности продолжить потоковый обмен, прерванный блочным обменом фоновой задачи? Ведь терминальная программа в многозадачной операционке вообще не знает, когда её выполнение прерывается операционкой. Если блокировать контроллер на всё время потокового обмена, то при замене кванта потоковой программы квантом блочной программы - блочная программа зависнет на всё время терминального обмена. В итоге байтовый обмен с контроллером лучше вести по одному терминальному байту за одну команду "прочитать терминальный байт" или "записать терминальный байт".
Таким образом "терминальный агент" оказывается более сложным - перед чтением или записью каждого потокового байта агент должен выдавать в контроллер специальную команду "прочитать терминальный байт" или "записать терминальный байт". В таком случае всё будет работать и в многозадачном окружении.
Последний раз редактировалось Patron; 18.06.2019 в 14:31.
У меня, похоже, не получится совместить терминальный и блочный режимы. Переключиться - без вопросов, а совместить не выходит. Поэтому, если запускать это дело под многозадачкой, то ее сначала лучше, наверное, остановить. То есть задача, в которой запускается настройка контроллера, должна перейти в монопольный режим, все остальные задачи должны быть приостановлены.
В принципе, это элементарно сделать, если ввести дополнительный вызов .SPFUN, ну, или его эквивалент в других ОС. Как я понимаю, во всех ОС запросы ввода-вывода к одному контроллеру исполняются строго последовательно, для чего ведется их очередь, и пока очередной запрос не выполнится, следующий не запустится. Поэтому выдаем .SPFUN (или его эквивалент в других ОС) с запросом переключения в терминальный режим. Получив этот запрос, драйвер переключит контроллер в терминальный режим и выйдет назад в ОС в состоянии "операция запущена, ждем прерывания с сигналом об окончании", остальные запросы (от других задач) будут ждать в очереди. Когда терминальная программа отработает, она должна переключить контроллер назад в блочный режим, пойдет сигнал прерывания, который просигналит драйверу, что длинная .SPFUN, наконец, закончилась, и очередь двинется дальше.
Естественно, запрос .SPFUN должен выдаваться в варианте без ожидания.
Кстати, ИМХО, эти дела актуальны и для устройства HD с программой MNT. Вот, программа MNT, запущенная под TSX, начала программировать чтение блока 0. Переслала номер устройства, номер блока, тут подоспел квант времени другой задачи, а она взяла, да и запустила на HD какую-то свою операцию ввода-вывода. И все, чтение блока 0 программой MNT сорвано. Или я ошибаюсь?
................................................
В общем, если не будет существенной критики, я потихоньку начну сочинять эту часть программы контроллера. Да, я для начала, так сказать, "тренируюсь на кошках" - отлаживать эти дела в реальном контроллере не очень удобно, так я сначала отлаживаю модель этого дела на китайской пробной платке с тем же МК на борту, потом аккуратно переношу отлаженные куски в боевую программу контроллера. Так вот, сейчас мне нужно взаимодействие с ДВК. Я бы хотел воспользоваться эмулятором, но нужна связь, пока устроит обычный USART.
Поэтому внимание, вопрос: как в эмуляторе подключить к 176560 реальный компорт?
Последний раз редактировалось AFZ; 20.06.2019 в 05:56.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Да, проблема есть - о полной совместимости процесса монтирования с многозадачным окружением я не думал.
Добавки в любой конфиг, эмулирующий обычную ДВК, следующие:
Код:[objects] ComPort_Adapter = Ядро:Terminal_ComPort_Adapter TerminalPort2 = Port_module:DL11-W [links] bus & TerminalPort2 TerminalPort2 <=> ComPort_Adapter [ComPort_Adapter.ini] PortName="COM5" MinimalBreakTime_MKS=3000 [TerminalPort2.ini] BaseIO_Address = 0176560 BaseVectorsAddress = 0360 DL11W_LineClock_ComponentDisabled = 1 DL11W_TerminalPort_BitsPerByte = 10 DL11W_TerminalPort_BaudRate = 9600
Последний раз редактировалось Patron; 20.06.2019 в 18:53.
Нужно переделать ввод командной строки:
Вызов .GTLIN при отсутствии командной строки рисует приглашение программы, а при наличии - переставляет две части введённой строки местами, помещая между ними символ "=" (и если не ошибаюсь - заменяя пробелы на запятые). Нужно написать обратное преобразование (когда-то давно для ввода командной строки в ранних версиях RT-11 я уже такое делал) и тогда единственным отличием станет появление приглашения программы при вызове программы без аргументов.Код:;************************************************************************ ;* * ;* Подпрограмма GETLIN * ;* * ;* - Назначение Ввод командной строки вызова программы * ;* в буфер с адресом в R0. * ;* * ;* При пустой командной строке возвращает * ;* SeC * ;* * ;************************************************************************ .Procedure GETLIN Mov R0, R1 Mov #510, R2 Mov (R2)+, R3 BEq 1$ Dec R3 BEq 1$ .GTLIN ; Нужно убрать командную строку из буфера KMON 2$: MovB (R2)+, (R1)+ SOB R3, 2$ ClrB (R1) Tst (PC)+ 1$: SeC Return .End.
- - - Добавлено - - -
Помечать загрузочный диск есть смысл только в том случае, когда предусмотрена автоматическая загрузка с ненулевого привода. Нужность такой опции (а значит - и всех связанных с её реализацией заморочек) представляется довольно сомнительной.
- - - Добавлено - - -
Использование флажков, как быстрого способа отличить смонтированный образ от обычного - хорошая идея только в том случае, когда контроллер не успевает фильтровать выдаваемый в ДВК список файлов на флешке по своему списку монтирования. Ведь флажок не может заменить список монтирования, а значит он имеет смысл только тогда, когда сильно экономит какие-то ресурсы (например - сильно упрощает написание алгоритма формирования списка доступных для монтирования файлов).
Последний раз редактировалось Patron; 18.06.2019 в 10:18.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)