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

[Patron]

В общем, для того, чтобы пользовать одну программу для двух разных устройств, необходима "прослойка" между железом и программой.

Зачем такие сложности - сделать две разные программы и всего делов.

С этим пока сложности...

Без этого при достаточно большом количестве образов пользователь будет регулярно пытаться смонтировать один и тот же образ дважды. Простое решение - в момент монтирования переименовывать монтируемый образ, добавляя к нему расширение с номером привода. Типа SYSTEM.DSK -> SYSTEM.DSK.001

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

[Advertiser]

[AFZ]

момент монтирования переименовывать монтируемый образ, добавляя к нему расширение с номером привода. Типа SYSTEM.DSK -> SYSTEM.DSK.001

Увы, мне недоступны длинные имена, только 8+3. И так оперативки маловато, а разреши я длинные имена, и ее вообще не хватит.

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

Зачем такие сложности - сделать две разные программы и всего делов.

Угу, так еще проще.

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

В общем, как я понимаю, с меня объектный модуль, который будет выполнять взаимодействие с моим кондуктором. Так? Осталось согласовать интерфейс.

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

В смысле, отдельно транслируемый исходник, подключение на этапе линковки.

[AFZ]

Без этого при достаточно большом количестве образов пользователь будет регулярно пытаться смонтировать один и тот же образ дважды. Простое решение - в момент монтирования переименовывать монтируемый образ, добавляя к нему расширение с номером привода. Типа SYSTEM.DSK -> SYSTEM.DSK.001

В принципе, у файлов еще есть атрибуты. Причем флажки Hidden и System у нас не используются. Можно заюзать их. Смонтированному диску ставить HIDDEN, а тому, с которого загрузились, дополнительно - System. Для этого добавить в устройство команду "пометить диск, как загрузочный", а в первичном драйвере выдать ее.

[AFZ]

Посмотрел. Круто. Снимаю шляпу!

А как его транслировать и собирать? Там довольно сложные манипуляции с секциями, расположением и пр. Сходу не въедешь. Батничек... Ой, пардон, com-файлик не сохранился?

[Patron]

А как его транслировать и собирать?

Просто компилировать MNT.MAC - там включается HEAD00.MAC, который уже подтягивает всё остальное.

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

Там довольно сложные манипуляции с секциями, расположением и пр. Сходу не въедешь.

Это исполняющая система, которая всё делает сама. Использована концепция "библиотеки исходников", потому что только при включении всех исходников в один "корневой" можно создавать переменные не в виде нулевых слов в коде, а в виде смещений от конца кода.

[AFZ]

Увы, оно работает только под последними версиями RT-11. С какой версии начали передавать остаток командной строки с адреса 510 ? С 5.04, да? В общем, моя любимая RT-11DS (SJ) V5.01 в их число не попадает...

Ладно, буду думать.

[SuperMax]

Увы, оно работает только под последними версиями RT-11. С какой версии начали передавать остаток командной строки с адреса 510 ? С 5.04, да? В общем, моя любимая RT-11DS (SJ) V5.01 в их число не попадает...
Ладно, буду думать.

да, надо предусматривать совместимость со старыми версиями - дабы ADOS работал

[AFZ]

Проблема, правда, возникнет, когда ДВК-шик вырубят внезапно. При плановом выключении (получив низкий на К ПИТН В) можно попытаться снять все эти атрибуты со смонтированных файлов, обещанных 10 мс от снятия К ПИТН В до снятия К ПОСТН В и отключения питания должно хватить. А вот внезапное вырубание всяких самодельных источников (которые сделаны из АТХ) - это ой!

Те файлы, которые прописаны в AZ.INI можно, конечно, смонтировать, игнорируя эти флаги (и потом поставить их, как надо). А вот с файлами, смонтированными на ходу, будут сложности...

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

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

Не факт. Я подаю команду BO AZ2:, и? А для того, чтобы не перемонтировать системный диск (любая ОС от такого, скорее всего, упадёт), в программе надо дополнительно контролировать это дело. Но это, скорее всего, можно будет обойти и как-то по-другому.

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

Тоже верно. В принципе, мне, по всей видимости, будет не особенно трудно проверить файл по списку монтирования. Ладно, это надо обдумать.

Вызов .GTLIN при отсутствии командной строки рисует приглашение программы, а при наличии - переставляет две части введённой строки местами, помещая между ними символ "=" (и если не ошибаюсь - заменяя пробелы на запятые). Нужно написать обратное преобразование

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

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

И вообще, тут вот СуперМакс высказал предложение: сделать все эти дела внутри контроллера. Переключить контроллер в некоторое подобие терминала и общаться с юзером через терминал ДВК. Тогда программа в ДВК будет совсем маленькой, ее спокойно можно вписать в программу начальной загрузки, которую я пересылаю в ДВК при запуске. И это дело будет работать на голом железе, до загрузки любой ОС. В принципе, продублировать этот кусочек в виде отдельной программы под любую ОС, и можно будет рулить этими делами и на ходу, а не только при запуске.

Так, что информации к размышлению - море! Буду думать...

[Patron]

И вообще, тут вот СуперМакс высказал предложение: сделать все эти дела внутри контроллера. Переключить контроллер в некоторое подобие терминала и общаться с юзером через терминал ДВК.

Да, переключить контроллер в терминальный режим и принимать/передавать потоки байтов через родной регистр данных контроллера. Тогда программа в ДВК должна просто "коммутировать" эти потоки с системным терминалом, а всё остальное будет делать контроллер - рисовать промпт, выводить HELP, разбирать и выполнять команды. Это самый крутой способ, максимально совместимый со всеми возможными применениями контроллера.

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

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

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

И как тогда в многозадачном окружении программа терминального обмена с контроллером должна сообщить контроллеру о готовности продолжить потоковый обмен, прерванный блочным обменом фоновой задачи? Ведь терминальная программа в многозадачной операционке вообще не знает, когда её выполнение прерывается операционкой. Если блокировать контроллер на всё время потокового обмена, то при замене кванта потоковой программы квантом блочной программы - блочная программа зависнет на всё время терминального обмена. В итоге байтовый обмен с контроллером лучше вести по одному терминальному байту за одну команду "прочитать терминальный байт" или "записать терминальный байт".

Таким образом "терминальный агент" оказывается более сложным - перед чтением или записью каждого потокового байта агент должен выдавать в контроллер специальную команду "прочитать терминальный байт" или "записать терминальный байт". В таком случае всё будет работать и в многозадачном окружении.

[AFZ]

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

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

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

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

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

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

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

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