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

[AFZ]

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

Вообще-то, приличная многозадачка просто не пустит эту программу к странице ввода/вывода, и правильно сделает, ибо не фиг.

Неприличная многозадачка, вроде RT-11FB/XM (ну, может быть, кроме каких-нибудь АСУТП), работает в многозадачном режиме крайне редко. Лично я пользовал эту многозадачность в единственном случае - для распечатки больших листингов программой QUEUE - она печатает, а я занимаюсь чем-то другим. Так вот, здесь, чтобы порулить дисками, можно просто остановить (или не запускать) оперативные задачи.

Проблему разрушенного содержания накопителя при внезапном снятии питания обычно решают приделыванием достаточно большого конденсатора на связку "контроллер-накопитель"

Мы вообще прикидывали зацепить туда ионистор, это позволит даже сделать кэш отложенной записи. Возможно. Если хватит оперативки. Но пока не до этого, так, что этот вопрос отложен.

- - - Добавлено - - -

А для "больших" многозадачек я, по-простому, опубликую исходник, и пусть любители этих операционок сочиняют сами. Впрочем, для TSX, может быть, я и сам что-то сочиню.

[Advertiser]

[SuperMax]

Проблему разрушенного содержания накопителя при внезапном снятии питания обычно решают приделыванием достаточно большого конденсатора на связку "контроллер-накопитель", и детектирования понижения входных +5в. до, например, +4.5 в.
В самой минимальной конфе такой аддон будет содержать сам электролит ( например ~~2200 мкф 6.3 в. ), несколько диодов Шоттки , участок измерения питающих +5в. и софтовую поддержку этого в ОЭВМ.
Для более сложного варианта можно приделать и 8-выв. DC-DC ИС, обеспечивающую стабильные +5в. 0.1 сек после снятия основного +5в.

в нашем случае всё проще - надо стабильные 3.3В и только
соответственно заряженный конденсатор -> стабилизатор 3.3В и всё

[AFZ]

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

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

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

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

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

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

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

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

[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

[AFZ]

Спасибо! А по поводу моего подхода к многозадачному монтированию (приостановке) особых замечаний нет, можно делать?

[Patron]

А по поводу моего подхода к многозадачному монтированию (приостановке) особых замечаний нет, можно делать?

Если включение терминального режима будет наглухо блокировать дисковый обмен - даже программа монтирования не сможет обращаться к диску после перехода в терминальный режим. Это не очень круто. Без совмещения дискового и терминального обмена нормальной работы в многозадачной среде не будет. При правильном подходе - для запоминания фазы терминального обмена не надо много ресурсов, но зато блочные запросы смогут вклиниваться в любом месте не разрушая терминальный обмен.

[AFZ]

Если включение терминального режима будет наглухо блокировать дисковый обмен - даже программа монтирования не сможет обращаться к диску после перехода в терминальный режим.

А ей-то это зачем? Её задача - выполнить переназначение, а не читать/писать файлы псевдодисков, которые, к тому же, могут быть ею же перемонтированы.

При правильном подходе - для запоминания фазы терминального обмена не надо много ресурсов

Тут проблема в том, что я собираюсь сделать эти назначения в духе Командира Нортона - чтобы юзер, вместо набора команд, мог выбрать клавишами управления курсором что-то из предложенного на экране и одним-двумя нажатиями отправить выбранное на исполнение (в оглавление - войти, файл-образ - смонтировать). В стиле Командира Нортона, увы, не выйдет - не на всех компьютерах есть терминалы, поддерживающие, хотя бы, VT100, а возможностей VT52, совместимость с которыми есть у всех терминалов ДВК/УКНЦ, для этого недостаточно.

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

Да, конечно, юзер будет предупреждён, что не стоит держать слишком много файлов в одном оглавлении, тем не менее...

[AFZ]

Пошли первые вопросы от владельцев ДВК, купивших этот контроллер. Решение вопроса, который в барахолке задал DATAsoft, в общем-то, не так очевидно. Дело в том, что драйверов для КЖД существует несколько штук и все они имеют название файла DW.SYS, какой из них стоит на конкретной машинке мы, естественно, знать не можем. И не факт, что находящийся на наших псевдодисках DW.SYS окажется совместимым с тем, который стоит у вас на ДВК. Поэтому проще всего загрузить ДВК с этого DW, инициализировать VM: скопировать на этот VM: свой драйвер DW.SYS, потом, не выключая компьютер, перезагрузиться с AZ: (дважды нажать кнопку ОСТ и набрать 177226G) и скопировать с VM на SY актуальный драйвер DW, для чего последовательно подать четыре команды

DEAS - в некоторых из псевдодисков сразу при загрузке DK назначается
         на какой-то из приводов LD, DEAS отменяет все назначения
REM DW - это чтобы убрать имеющийся на AZ драйвер DW из таблиц системы
UNPRO DW.SYS - драйвер DW.SYS может оказаться защищенным от удаления
COP/SY VM:DW.SYS SY: - и, наконец-то, копируем драйвер.

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

[DATAsoft]

Добрался сегодня до своего ДВК-3М. гружусь с AZ0 (177224G). После загрузки пишу SET DW INFORM и получаю:

DIR DW0: дает тот же результат.

При этом загрузка с HDD работает штатно.


Вопрос. Как настроить драйвер записанный на диске AZ0:?

p.s. По предыдущей инструкции пытался скопировать свой dw.sys - не заработало... Пишет ошибку как на первой картинке..

[SKcorp.]

Добрался сегодня до своего ДВК-3М. гружусь с AZ0 (177224G). После загрузки пишу SET DW INFORM и получаю:

DIR DW0: дает тот же результат.

При этом загрузка с HDD работает штатно.


Вопрос. Как настроить драйвер записанный на диске AZ0:?

p.s. По предыдущей инструкции пытался скопировать свой dw.sys - не заработало... Пишет ошибку как на первой картинке..

Раз "заголовка" драйвера при загрузке нет - значит он HDD не видит.
Видимо что-то регистры DW перекрывает.

PS: Плата AZ стоит последней?