Контроллер псевдодиска на SD-карте для ДВК/ УКНЦ / PDP-11 original + Ethernet

[AFZ]

Но здесь есть и подводный камень - в многозадачном окружении контроллер должен запоминать фазу терминального обмена на время выполнения блочного обмена. Иначе когда (например) фоновая задача дефрагментирует какой-то диск, смонтировать новый образ в какой-то свободный привод не получится.

У меня, похоже, не получится совместить терминальный и блочный режимы. Переключиться - без вопросов, а совместить не выходит. Поэтому, если запускать это дело под многозадачкой, то ее сначала лучше, наверное, остановить. То есть задача, в которой запускается настройка контроллера, должна перейти в монопольный режим, все остальные задачи должны быть приостановлены.

В принципе, это элементарно сделать, если ввести дополнительный вызов .SPFUN, ну, или его эквивалент в других ОС. Как я понимаю, во всех ОС запросы ввода-вывода к одному контроллеру исполняются строго последовательно, для чего ведется их очередь, и пока очередной запрос не выполнится, следующий не запустится. Поэтому выдаем .SPFUN (или его эквивалент в других ОС) с запросом переключения в терминальный режим. Получив этот запрос, драйвер переключит контроллер в терминальный режим и выйдет назад в ОС в состоянии "операция запущена, ждем прерывания с сигналом об окончании", остальные запросы (от других задач) будут ждать в очереди. Когда терминальная программа отработает, она должна переключить контроллер назад в блочный режим, пойдет сигнал прерывания, который просигналит драйверу, что длинная .SPFUN, наконец, закончилась, и очередь двинется дальше.

Естественно, запрос .SPFUN должен выдаваться в варианте без ожидания.

Кстати, ИМХО, эти дела актуальны и для устройства HD с программой MNT. Вот, программа MNT, запущенная под TSX, начала программировать чтение блока 0. Переслала номер устройства, номер блока, тут подоспел квант времени другой задачи, а она взяла, да и запустила на HD какую-то свою операцию ввода-вывода. И все, чтение блока 0 программой MNT сорвано. Или я ошибаюсь?

................................................

В общем, если не будет существенной критики, я потихоньку начну сочинять эту часть программы контроллера. Да, я для начала, так сказать, "тренируюсь на кошках" - отлаживать эти дела в реальном контроллере не очень удобно, так я сначала отлаживаю модель этого дела на китайской пробной платке с тем же МК на борту, потом аккуратно переношу отлаженные куски в боевую программу контроллера. Так вот, сейчас мне нужно взаимодействие с ДВК. Я бы хотел воспользоваться эмулятором, но нужна связь, пока устроит обычный USART.

Поэтому внимание, вопрос: как в эмуляторе подключить к 176560 реальный компорт?

[Advertiser]

[Patron]

Кстати, ИМХО, эти дела актуальны и для устройства HD с программой MNT. Вот, программа MNT, запущенная под TSX, начала программировать чтение блока 0. Переслала номер устройства, номер блока, тут подоспел квант времени другой задачи, а она взяла, да и запустила на HD какую-то свою операцию ввода-вывода. И все, чтение блока 0 программой MNT сорвано. Или я ошибаюсь?

Да, проблема есть - о полной совместимости процесса монтирования с многозадачным окружением я не думал.

как в эмуляторе подключить к 176560 реальный компорт?

Добавки в любой конфиг, эмулирующий обычную ДВК, следующие:

[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