В 176560 определен только бит 0200, в старшем байте возвращается 1 - номер станции, но только когда контроллер не занят и только при обращении непосредственно к адресу 176561. УКНЦшный загрузчик делает именно так.
176560 и 176564 - аппаратные, но только по чтению, причем это один регистр просто на двух адресах для эмуляции сетевого адаптера. Эти регистры видны всегда.
Я думаю вопрос с хвостами нужно решать в драйвере, т.к. ухудшить всегда можно.
Можно передавать текущее состояние контроллера в регистре 176566.
Тогда перед чтением каждого слова из регистра данных 176562 - нужно сначала ожидать 200 в 176560, а потом проверять младший байт 176566 на биты DONE ( 200 ) и ERROR ( 001 ).
В старшем байте 176566 всегда читается номер тома последней/текущей операции.
Тогда коды ошибок в младшем байте 176566 могут выглядеть так:
IS_OK = 0000; // нет ошибки ( передача данных продолжается )
IS_SUC = 0200; // нет ошибки ( контроллер готов к приёму команды )
IE_VER = 0211; // неустранимая ошибка (например, внутренняя ошибка контроллера)
IE_OFL = 0221; // устройство offline (образ не подключен)
IE_EOF = 0031; // выход за пределы устройства до EOF ( передача данных продолжается )
IE_BLK = 0231; // выход за пределы устройства после EOF ( передача данных завершена )
IE_WLK = 0241; // попытка записи на защищённое устройство
IE_IFC = 0251; // неверная команда
Еще не понятно, нужно ли создавать образы, т.е. если образа с нужным номером нет, то можно при попытке чтения выдавать ошибку (0221?), а запись разрешать. Таким образом получатся динамически расширяемые тома, не знаю как на такое отреагирует RT-11. Или вообще забить и создавать образы только на ПК?
Забить и создавать образы только на ПК.Цитата:
Сообщение от Jarik65535
Размер подключенного образа не должен изменяться после подключения.
Вообще-то, ИМХО, вполне необременительно можно создать дополнительный функционал работы с файл-образами. Смонтировать файл-образ на виртуальный привод, создать новый файл-образ заданного размера, то есть смонтировать на какой-то виртуальный привод новый пустой диск, как вспомогательное средство - просмотреть оглавление хостовой файловой системы для выбора файл-образа, который следует смонтировать. Это во-первых.
Во-вторых, надо решить вопрос с "хвостами" сейчас. Большинство дисковых устройств аппаратно дописывают хвосты нулями, что упомянутые DEC-овские RK, DM, да и наш MY. Драйвер, в общем-то, о блоках не знает, передает нужное число слов, и вперед, а контроллер сам разбрасывает их по секторам, начиная с полученного при начале операции адреса и подчищая "хвост" в конце.
Но есть контроллеры, которые так не умеют и вся возня с блоками ложится на драйвер. Тот же MX, да и, кажется, DW. Так вот, надо решить, каким быть этому контроллеру.
Мне кажется, что лучше будет, если с блоками будет разбираться драйвер. Поясню. Тут Патрон уже несколько раз предлагал фрагменты программы передачи данных, и все они имеют значительное число проверок. То есть, главный цикл передачи данных оказывается довольно громоздким, и, соответственно, медленным. Несмотря на то, что сама передача данных в уфер или из буфера достаточно быстрая. Таким образом, если драйвер будет знать про блоки, то прямой смысл все проверки сделать до начала передачи данных, а саму передачу блока делать коротким циклом из двух-трех команд без всяких проверок.
Тогда запись будет выглядеть примерно так:
1. Проверяем готовность контроллера.
2. Даем предварительную команду записи
3. Посылаем номер блока двумя словами.
4. Счетчик слов не нужен - он всегда 256.
5. Проверяем, не вызвала ли ошибок эта команда.
6. Без проверок высылаем 256 слов в короткньком цикле - очередной блок данных. Если он последний и счетчик слов кончится раньше 256, чистим "хвост"
7. Даем команду GO.
8. Ждем окончания операции
9. Проверяем, нет ли ошибок и идем на запись следующего блока.
Чтение - аналогично, только команда GO выдается вместе с командой чтения, а пересылка считанных данных будет в конце, после всех проверок на ошибки. Заодно, если считанный блок последний и нужен не весь, остаток можно просто бросить, контроллер, получив следующую команду, о нем забудет.
Таким образом мы, путем небольшого усложнения драйвера, значительно ускорим обмен с устройством - нет нужды проверять состояние контроллера и флаги ошибок для передачи каждого из 256 слов (псевдо)сектора, достаточно выполнить эти проверки для всего сектора целиком.
- - - Добавлено - - -
Да, из дополнительного функционала забыл "демонтировать заданный виртуальный привод".
На счет списка образов:
А запоминать примонтированные образы где, опять файл создавать? Все-таки жесткие диски это как бы стационарные устройства, ими не нужно часто жонглировать.
И как реализовывать этот дополнительный функционал? В текущей версии контроллера на шину ПП список файлов выводится кусками по 512 байт, начиная с указанного по номеру файла, не очень удобно его получать, и где-то закралась ошибка, что Хобот до сих пор в ярости. Может другие варианты есть? И естественно, без сортировки, на нее может не хватить памяти ни на УКНЦ, ни у кортекса.
Можно принять соглашения о именах, типа nnn.img, где nnn — номер образа с незначащими нулями, и выдавать в каком-нибудь запакованном виде список, типа "с 000 по 012 присутствуют и 015 еще".
Я бы порекомендовал делать именно драйвер максимально небольшим и простым - и в частности всякой дописывание нулей переложить на контроллер. Всё таки 64 к (а то и меньше) доступной памяти
Это если у контроллера есть внутренний буфер на 256 слов. Тогда контроллер успеет принимать/передавать слова со скоростью шины ДВК ( на самом деле ДВК перед запросом каждого слова ещё и считывает из ОЗУ команду, осуществляющую это чтение ). Но если контроллер "прожигает" каждое записываемое слово во флешке отдельно, сразу после его получения - без чтения бита READY не обойтись.Цитата:
Сообщение от AFZ
В целом идея работы фиксированными кусками по 256 слов позволяет упростить программу контроллера за счёт усложнения программы драйвера. При таком подходе исчезает ситуация EOF - когда передаётся меньше слов, чем заказал драйвер, а значит - не нужен код ошибки IE_EOF ( 0031 ).
Это не требуется, потому что запись 256-го слова в буфер контроллера автоматически запускает "прожиг" блока.Цитата:
Сообщение от AFZ
Если "прожиг" буфера из 256 слов требует у контроллера в 256 раз больше времени, чем прожиг одного слова без буферизации - это ожидание убьёт весь предыдущий выигрыш в скорости.Цитата:
Сообщение от AFZ
- - - Добавлено - - -
На мой взгляд - нужно монтировать в приводы только те файлы на флешке, у которых в самом конце имени файла есть расширение типа ".nnn" ( или префикс типа "nnn." в самом начале ), где nnn - число от 000 до 255, задающее номер тома для подключения. Тогда пользователь сам сможет решать, какие из файлов на флешке в какие приводы подключать, а флешка будет определять это, перебрав список файлов после включения питания.Цитата:
Сообщение от Jarik65535
Затевать бодягу с управлением монтированием только через регистры контроллера - значит требовать наличия программы монтирования в каждой операционной системе, для которой есть драйвер. Если контроллер может сам переименовывать файлы на флешке, добавляя/удаляя ".nnn" в конце ( или в начале ) имени файла при подключении/отключении образа - эту затею можно реализовать тогда, когда всё остальное будет успешно работать.
Буфер есть, даже килобайт наберется. Можно еще предусмотреть перевод контроллера в исходное состояние, например записью какого-нибудь значение в 176560 перед каждой операцией или когда бит DONE не установлен, полезно когда буфер был передан не полностью. Тем более туда уже пишется 4 для полной инициализации.
Поскольку буфер больше блока и меньше максимального запроса - есть смысл выделить буфер на 256 слов и вести чтение и запись кусками не больше блока ( от одного до 256 слов ). При записи меньше 256 слов - контроллер сам добивает буфер нулями.Цитата:
Сообщение от Jarik65535
Всегда передавать только по 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 и затем читаем данные без ожидания готовности.