Еще не понятно, нужно ли создавать образы, т.е. если образа с нужным номером нет, то можно при попытке чтения выдавать ошибку (0221?), а запись разрешать. Таким образом получатся динамически расширяемые тома, не знаю как на такое отреагирует RT-11. Или вообще забить и создавать образы только на ПК?
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Забить и создавать образы только на ПК.Сообщение от Jarik65535
Размер подключенного образа не должен изменяться после подключения.
Вообще-то, ИМХО, вполне необременительно можно создать дополнительный функционал работы с файл-образами. Смонтировать файл-образ на виртуальный привод, создать новый файл-образ заданного размера, то есть смонтировать на какой-то виртуальный привод новый пустой диск, как вспомогательное средство - просмотреть оглавление хостовой файловой системы для выбора файл-образа, который следует смонтировать. Это во-первых.
Во-вторых, надо решить вопрос с "хвостами" сейчас. Большинство дисковых устройств аппаратно дописывают хвосты нулями, что упомянутые DEC-овские RK, DM, да и наш MY. Драйвер, в общем-то, о блоках не знает, передает нужное число слов, и вперед, а контроллер сам разбрасывает их по секторам, начиная с полученного при начале операции адреса и подчищая "хвост" в конце.
Но есть контроллеры, которые так не умеют и вся возня с блоками ложится на драйвер. Тот же MX, да и, кажется, DW. Так вот, надо решить, каким быть этому контроллеру.
Мне кажется, что лучше будет, если с блоками будет разбираться драйвер. Поясню. Тут Патрон уже несколько раз предлагал фрагменты программы передачи данных, и все они имеют значительное число проверок. То есть, главный цикл передачи данных оказывается довольно громоздким, и, соответственно, медленным. Несмотря на то, что сама передача данных в уфер или из буфера достаточно быстрая. Таким образом, если драйвер будет знать про блоки, то прямой смысл все проверки сделать до начала передачи данных, а саму передачу блока делать коротким циклом из двух-трех команд без всяких проверок.
Тогда запись будет выглядеть примерно так:
1. Проверяем готовность контроллера.
2. Даем предварительную команду записи
3. Посылаем номер блока двумя словами.
4. Счетчик слов не нужен - он всегда 256.
5. Проверяем, не вызвала ли ошибок эта команда.
6. Без проверок высылаем 256 слов в короткньком цикле - очередной блок данных. Если он последний и счетчик слов кончится раньше 256, чистим "хвост"
7. Даем команду GO.
8. Ждем окончания операции
9. Проверяем, нет ли ошибок и идем на запись следующего блока.
Чтение - аналогично, только команда GO выдается вместе с командой чтения, а пересылка считанных данных будет в конце, после всех проверок на ошибки. Заодно, если считанный блок последний и нужен не весь, остаток можно просто бросить, контроллер, получив следующую команду, о нем забудет.
Таким образом мы, путем небольшого усложнения драйвера, значительно ускорим обмен с устройством - нет нужды проверять состояние контроллера и флаги ошибок для передачи каждого из 256 слов (псевдо)сектора, достаточно выполнить эти проверки для всего сектора целиком.
- - - Добавлено - - -
Да, из дополнительного функционала забыл "демонтировать заданный виртуальный привод".
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Это если у контроллера есть внутренний буфер на 256 слов. Тогда контроллер успеет принимать/передавать слова со скоростью шины ДВК ( на самом деле ДВК перед запросом каждого слова ещё и считывает из ОЗУ команду, осуществляющую это чтение ). Но если контроллер "прожигает" каждое записываемое слово во флешке отдельно, сразу после его получения - без чтения бита READY не обойтись.
В целом идея работы фиксированными кусками по 256 слов позволяет упростить программу контроллера за счёт усложнения программы драйвера. При таком подходе исчезает ситуация EOF - когда передаётся меньше слов, чем заказал драйвер, а значит - не нужен код ошибки IE_EOF ( 0031 ).
Это не требуется, потому что запись 256-го слова в буфер контроллера автоматически запускает "прожиг" блока.
Если "прожиг" буфера из 256 слов требует у контроллера в 256 раз больше времени, чем прожиг одного слова без буферизации - это ожидание убьёт весь предыдущий выигрыш в скорости.
- - - Добавлено - - -
На мой взгляд - нужно монтировать в приводы только те файлы на флешке, у которых в самом конце имени файла есть расширение типа ".nnn" ( или префикс типа "nnn." в самом начале ), где nnn - число от 000 до 255, задающее номер тома для подключения. Тогда пользователь сам сможет решать, какие из файлов на флешке в какие приводы подключать, а флешка будет определять это, перебрав список файлов после включения питания.
Затевать бодягу с управлением монтированием только через регистры контроллера - значит требовать наличия программы монтирования в каждой операционной системе, для которой есть драйвер. Если контроллер может сам переименовывать файлы на флешке, добавляя/удаляя ".nnn" в конце ( или в начале ) имени файла при подключении/отключении образа - эту затею можно реализовать тогда, когда всё остальное будет успешно работать.
Последний раз редактировалось Patron; 02.08.2017 в 22:02.
Так с этого все и началось. Предыдущий вариант - на шине ПП УКНЦ - работал именно "на лету", причем успевал без всяких готовностей выполнить цикл обмена за время исполнения одной команды, задержав выдачу СИПа. Но это на ПП, он помедленней, а на ЦП такой вариант не прошел, тайм-аут шины ЦП меньше времени передачи одного слова. Мы с Ярославом пообсуждали и решили делать нечто, в какой-то степени напоминающее DW - в программном режиме быстро заливаем буфер, потом отключаемся от шины, единственный аппаратный регистр сигналит "Думаю, прошу не мешать" (с), а контроллер занимается обменом с флешью.
Не знаю, так это, или нет, но время на запись/чтение блока по-любому требуется и это не обойти, а терять его еще и на передаче, ИМХО, не стоит.
Я не настаиваю. Это, в общем-то, заявка на программу-максимум.
Мы, среди прочего, обсуждали вариант когда после включения с карты, вместо ОС, грузится вторичный загрузчик. Вот он может делать все назначения, переключения и т.п., главное - не вынимать карту и не бежать с ней к писюку. А ддля основной ОС - для УКНЦ это RT-11 - эту программу не грех и сочинить.
Впрочем, все это разговоры на очень дальнее "потом". Сейчас надо запустить это дело в минимальной конфигурации, а дальше видно будет.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
На счет списка образов:
А запоминать примонтированные образы где, опять файл создавать? Все-таки жесткие диски это как бы стационарные устройства, ими не нужно часто жонглировать.
И как реализовывать этот дополнительный функционал? В текущей версии контроллера на шину ПП список файлов выводится кусками по 512 байт, начиная с указанного по номеру файла, не очень удобно его получать, и где-то закралась ошибка, что Хобот до сих пор в ярости. Может другие варианты есть? И естественно, без сортировки, на нее может не хватить памяти ни на УКНЦ, ни у кортекса.
Можно принять соглашения о именах, типа nnn.img, где nnn — номер образа с незначащими нулями, и выдавать в каком-нибудь запакованном виде список, типа "с 000 по 012 присутствуют и 015 еще".
Я бы порекомендовал делать именно драйвер максимально небольшим и простым - и в частности всякой дописывание нулей переложить на контроллер. Всё таки 64 к (а то и меньше) доступной памяти
Буфер есть, даже килобайт наберется. Можно еще предусмотреть перевод контроллера в исходное состояние, например записью какого-нибудь значение в 176560 перед каждой операцией или когда бит DONE не установлен, полезно когда буфер был передан не полностью. Тем более туда уже пишется 4 для полной инициализации.
Поскольку буфер больше блока и меньше максимального запроса - есть смысл выделить буфер на 256 слов и вести чтение и запись кусками не больше блока ( от одного до 256 слов ). При записи меньше 256 слов - контроллер сам добивает буфер нулями.
Всегда передавать только по 256 слов вряд ли имеет смысл, потому что RT-11 иногда читает по 1 слову и тогда принимать от контроллера 256 слов ради одного первого слова - слишком накладно.
Тогда бит DONE не нужен, потому что при любой ошибке контроллер завершает работу, а количества передаваемых слов у контроллера и драйвера всегда совпадают.
Значит - бит 0200 в регистре 176566 можно отдать флагу ошибки.
Тогда коды состояний контроллера в младшем байте регистра 176566 могут быть такими:
IS_SUC = 0000; // нет ошибки
IE_VER = 0210; // неустранимая ошибка (например, внутренняя ошибка контроллера)
IE_OFL = 0220; // устройство offline (образ не подключен)
IE_BLK = 0230; // выход за пределы устройства
IE_WLK = 0240; // попытка записи на защищённое устройство
IE_IFC = 0250; // неверная команда
IE_RD = 0260; // ошибка чтения флешки
IE_WR = 0270; // ошибка записи флешки
Алгоритм работы следующий:
1. ожидаем готовности в 176560 и проверяем бит ошибки в 176566 на каждом шаге.
2. в регистр данных заносим код операции. Если код операции ошибочный - контроллер установит 250 ( если запись невозможна - 240 ) и завершит работу.
3. номер тома. Если к указанному тому не подключен образ - контроллер установит 220 и завершит работу.
4. номер блока в томе (мл.слово)
5. номер блока в томе (ст.слово, 0 для RT-11). Если номер блока больше размера образа - контроллер установит 230 и завершит работу.
6. кол-во слов ( от 1 до 256 ). Если 0 или больше 256 - контроллер установит 210 и завершит работу
7. пишем данные без ожидания готовности и потом ждём готовности и проверяем отсутствие ошибки записи 270 или
ждём готовности, проверяем отсутствие ошибки чтения 260 и затем читаем данные без ожидания готовности.
Последний раз редактировалось Patron; 03.08.2017 в 00:19.
Jarik65535, ау! Как успехи?
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
