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

[AFZ]

Делать .SPFUN я уже передумал - не вижу смысла кодировать это все для передачи в .SPFUN, потом декодировать назад, да еще и занимать место в драйвере, которое, в отличие от управляющей программы, будет сидеть в памяти всегда. Тем более, что .SPFUN - это только для RT-11. Так, что сейчас я клепаю программу, которая будет выполнять переназначения, обращаясь прямо к регистрам кондуктора. Да, конечно, TSX к регистрам не пустит, да и на здоровье - оно же запускается из RT-11, там и конфигурируйте...

Технология полностью описана здесь: HMount.

Блин, а я уже сделал по-своему. Вспомнить бы вовремя, так я бы подогнал это дело под программу MNT...

[Patron]

Блин, а я уже сделал по-своему. Вспомнить бы вовремя, так я бы подогнал это дело под программу MNT...

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

[AFZ]

Подумаю. И посовещаемся. Тут беда в том, что мне недоступна концепция безразмерного блока, 512 байт, и всё. Поэтому, может быть, разбить это дело на блоки, а манипуляции с часами РВ вынести в отдельное устройство? Это ведь, так сказать, "свободный" ресурс - в большинстве реальных контроллеров номер устройства - 3-6 бит, а у нас доступны все 16...

[Patron]

Тут беда в том, что мне недоступна концепция безразмерного блока, 512 байт, и всё. Поэтому, может быть, разбить это дело на блоки

В HMount такое предусмотрено - там можно или пихать всё в один блок #0, или отдавать строку монтирования для каждой точки монтирования отдельным блоком - тогда в блоке #2 должен быть список точек монтирования, а затем должно идти столько же отдельных блоков, сколько есть точек монтирования, а в каждом блоке - строка монтирования для данной точки. В MNT.SAV реализована работа только по первому варианту, но добавить второй не сложно.

Интерфейс предусматривает, что контроллер может сам решать, как отдавать список монтирования. Если общий объём списка меньше размера блока #0 - контроллер может отдавать список монтирования обоими способами (так проще начинать отлаживать, потому что MNT.SAV будет проще заставить работать), а если список не лезет в нулевой блок, тогда при чтении нулевого блока контроллер должен отдавать пустой результат и получив такой результат программа уже должна пробовать получить список монтирования более сложным способом - прочитать блок #2, сосчитать точки монтирования и затем прочитать все блоки со строками монтирования для каждой из точек.

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

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

Тогда переделки MNT.SAV окажутся вообще минимальными и можно будет не морочиться со вторым способом отдачи списка монтирования (этот способ сейчас даже в эмуляторе ДВК не реализован).

Как и положено крутым протоколам - HMount реализует просмотр списка файлов каталога SD-карты так, чтобы можно было передать в ДВК даже бесконечный список файлов. Для этого предусмотрен особый протокол, наиболее близкий концепции 512-байтовых блоков. Там каждое следующее имя из списка файлов передаётся при каждом следующем чтении блока #1.

[AFZ]

А каким образом это все делается? Ведь RT-11 передает номер устройства одним байтом, так как передать номер 282 ? Напрямую в регистры контроллера, минуя драйвер?

[Patron]

А каким образом это все делается? Ведь RT-11 передает номер устройства одним байтом, так как передать номер 282 ? Напрямую в регистры контроллера, минуя драйвер?

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

Подключен ли "волшебный привод" к контроллеру - в программе MNT.SAV проверяется так:

	Mov	#MNT.Unit, (R2)		; Номер привода HMount ( 432 )
	Mov	#SetUni,   (R1)		; Задать номер привода.

	Tst	(R1)			; Привод HMount подключен к контроллеру HD ?
	BMi	4$			; Нет - сообщить об ошибке.

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

В принципе, для имитации "безразмерных блоков" можно обойтись без передачи размера данных в начале первого отдаваемого блока. По сути это полезно только в одном месте - при извлечении полного содержимого блока #0. Но если принять соглашение, что программа повторяет чтение блока #0, пока не получит ошибку чтения (и в этот момент контроллер сбрасывает фазу чтения блока #0 в исходное состояние) - то результат будет не хуже, чем с передачей размера данных, а мороки меньше.

Таким образом общий "безразмерный подход" может быть таким:

1. Чтения блока #0 повторяются вплоть до ошибки чтения ( там список монтирования в виде текста ASCII, содержащего по одной команде монтирования/размонтирования для каждой точки монтирования ).
2. Чтения блока #1 повторяются вплоть до ошибки чтения ( там список файлов, находящихся в текущем каталоге флешки, отдаваемый по одному имени файла в каждом прочитанном блоке ).

Блок #2 и последующие блоки не поддерживаются.

Запись в блок #0 передаёт новый список монтирования. Не упомянутые в этом списке точки монтирования не затрагиваются. Размер списка - не больше одного блока. Чтобы изменить больше точек монтирования, чем влезает в один блок - нужно создать несколько не пересекающихся списков монтирования и передать их по одному, записывая по отдельности в блок #0.

Запись в блок #1 (если поддерживается) изменяет текущий каталог флешки.

Уже смонтированные файлы не должны показываться в списке файлов на флешке, чтобы исключить двойное монтирование.

[Advertiser]

[AFZ]

Понятно. Я начал делать что-то подобное, но мне до окончания, как до Луны пешком. Только вот у меня и CSR другой, и команды не совсем совпадают (частично совпадают, но тем не менее...) Поэтому, ИМХО, надо будет сочинить какой-то промежуточный интерфейсный модуль, который будет приводить эти дела к общему знаменателю.

1. Чтения блока #0 повторяются вплоть до ошибки чтения ( там список монтирования в виде текста ASCII, содержащего по одной команде монтирования/размонтирования для каждой точки монтирования ).

Здесь, как раз, ограничений нет, читать можно сколько угодно. У меня по аналогичной команде - "передать таблицу назначений" передаются 560 слов - таблица назначений во внутреннем формате, для всех восьми дисков. Только не чтениЯ, а чтениЕ. То есть счетчик слов я задаю не 256, а 560, и всё прилетает. Ну, и вместо чтения какого-то блока, я принимаю несколько команд, одна из них специальная, остальные - общего назначения: запросить передачу таблицы назначений, читать из памяти контроллера и цикл чтения регистра данных без ожидания, по счетчику, который в этом случае начинается с 560.

2. Чтения блока #1 повторяются вплоть до ошибки чтения ( там список файлов, находящихся в текущем каталоге флешки, отдаваемый по одному имени файла в каждом прочитанном блоке ).

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

------------------------------------------------

В общем, для того, чтобы пользовать одну программу для двух разных устройств, необходима "прослойка" между железом и программой. Вопрос, как ее прицепить. Навскидку, возможно, имеет смысл сделать драйвер, у которого тот же CSR, что и у основного устройства, а средства ввода-вывода повторяют NL: плюс единственная SPFUN, которая возвратит адрес таблицы вызовов. Тогда делаем .FETCH этому драйверу, вызываем эту SPFUN, запоминаем возвращенный адрес и вызываем нужные функции по таблице. Ну, или, вариант, собрать её, как .REL и сделать свой загрузчик для нее (списать из системы).

Запись в блок #1 (если поддерживается) изменяет текущий каталог флешки.

У меня не поддерживается относительная адресация - строку текущего оглавления надо будет держать у себя.

Уже смонтированные файлы не должны показываться в списке файлов на флешке, чтобы исключить двойное монтирование.

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

[Patron]

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

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

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

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

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

[AFZ]

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

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

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

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

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

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

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

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

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

[Patron]

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

Зачем такие сложности. В комплекте поставки MNT.SAV есть исходник. Нужно просто взять его и исправить на свой лад.