МС1201.2018

[Alex]

Любая, которая файл заданного размера на диске может создать.
Можно готовый(е) том(а) для системы с файлами для PDP-11 использовать.
Потом форматируется флэшкарта... И файлики копируются или создаются...
Потом, например, WinHex(там возможностей много), смотрится номера стартовых секторов.
Если носитель пустой, то системой отводится место в начале носителя непрерывным куском.
На следующий файл будет отведено место в начале свободной области. И так далее...
В общем надо просто облегчить жизнь мозгам :-)
Как вариант, таблицу параметров может держать и драйвер со стороны PDP-11. С контроллера только тупо прочти сектор да запиши сектор :-)
Были драйвера DW которые на одном винчестере несколько томов держали и даже несколько операционок позволяли запускать, как по номеру поверхности, так по номеру трека...
Тут достаточно номера стартового сектора да размера тома

[AlexG]

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

[Hunta]

Не, слишком замороченно, неудобно в использовании и не дай бог файл грохнешь-создашь...
А для загрузки по номеру устройства (ZF0 ZF1 и т.д.) это ещё и в ПЗУ надо писать номера секторов... То есть, учитывая доступность (будущую) текстов ПЗУ, если кто захочет - флаг в руки, я точно не буду делать

Пока склоняюсь к варианту - разбиение CF на куски определённого размера, схему которого знает и ПЗУ. Возможно, несколько таких схем (ZF0/0 ZF0/1).
Пока окончательно не отбросил вариант создания аналога таблицы разделов - в первом или последнем секторе карты. Плюс программа, которая умеет собирать-разбирать образ или работать непосредственно с флешкой (придётся только разобраться, как пишется код для работы с физ устройством). Вариант MBR - точно не нравится.

По любому, заморачиваться ну работа с файловой структурой от PC не буду - драйвер под PDP будет слишком тяжеловесный, а специализированный проц под это дела на полуплате - насколько я понимаю - не в этой редакции полуплаты

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

крайне рекомендуется (при таком "дизайне") иметь утилиту (под виндами), которая будет создавать нужный образ на флешке из набора файлов для пдп

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

То, что крутится в голове сейчас - 4 фиксированных схемы:
0 - вся карты - куски по 32 мб (но с ходу RT увидит только первые 8 или 64)
1 - вся карта - куски по 256 мб (под RSX)
2 - 64 куска по 32 мб, остаток кусками по 256 мб (на карте как RT, так и RSX)
3 - вся карта целиком (под RSX)

[AlexG]

для проверки железа / идей 0 вариант
в идеале мбр(таблицу - разные куски , в разном порядке итд)

[Hunta]

для проверки железа / идей 0 вариант
в идеале мбр(таблицу - разные куски , в разном порядке итд)

В силу того, что под WQ был уже практически написан драйвер под RSX - первым будет писаться он и под варианты 3 и 1. Таблица MBR - под очень большим вопросом.

И ещё раз. Исходники ПЗУ и драйвером будут доступны - хотящие странного могут реализовать свои самые странные хотелки. Сами.

[Alex]

FAT на флэшкарте нужен чисто для того, чтобы на PC без великой головной боли можно было обменятся данными со стороны РС.
Единственный минус FAT, это то, что она отъест какое-то место карты, но с современными размерами я в этом большой беды не вижу :-)
Для того, чтобы всякие оптимизаторы не лезли своими грязными лапами - можно карту забить полностью файлами, так чтобы свободного места не осталось и размер кластера сделать максимально возможным, чтобы FAT менее места занимала.
Данные об фвйлах-томах можно держать в первом файле, коий служит чисто для этой структуры.. И ни в каком ПЗУ держать структуру не надо. Достаточно только адрес первого сектора структуры и всё. Формат данных-простейший - пара четырёхбайтовых целых чисел(указатель на первый и последний сектора тома, либо на первый плюс длина в блоках), как пошли нули, значит томов более нет ... Увсё :-)
В ПЗУ сделать только выбор номеров тома на устройстве с какого грузить. Одного сектора хватит на 64 тома :-)
Или, если с местом в ПЗУ напряг, загрузить более одного сектора и передать управление... Там хоть менюшку пиши с выбором и информацией и томов сколько хош ;-)

[Advertiser]

[Hunta]

С фиксированным разбиением CF по 32 мб - нет проблем с написанием драйвера (в том числе блока начального загрузчика - в RT он сидит в драйвере и копируется в нулевой сектор диск, когда делаешь диск загружаемым аппаратно) в RT

С отдачей всей CF под один диск - нет проблем написания драйвера (и начального загрузчика - в RSX он сидит в SAV.TSK) в RSX

Всё остальное создаёт определённые проблемы - ибо структуру нефиксированного разбиения должен прочитать ПЗУ (меньшая проблема) и её нужно передать в драйвера RT и RSX (большая проблема). Это навскидку - пока не доберусь до написания кода.

В целом - у меня пока сильного интереса решать проблемы данных подходов - нет, ибо свободного времени мало, а своих интересов - много. То, что точно будет реализовано - 32 мб-тные куски CF - диски для RT и вся карта CF - для RSX, потому что это проще всего и может быть реализовано максимально быстро. Что будет реализовано в последующих версиях драйверов - покажет время.

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

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

А, да, забыл. Ещё будет написана прога вытаскивания кусков из образа (если повезёт - непосредственно с CF) и заливку их в образ (если повезёт - непосредственно в CF)

[Hunta]

ААААААААА!!!!!! Выпущено таможней! Дня через три четыре будет у меня

[Alex]

Как данные передать драйверу? Считало ПЗУ данные, или "предпервичный загрузчик" да и передало первичному загрузчику адрес стартового сектора тома.
Я вот не помню, как именно :-( , но там есть какое-то соглашение о передаче данных при начальной загрузке первичному загрузчику. Я этот момент подробно не разбирал, так единственные драйвера физических устройств, которые переписывал DW от RT11 V5.2, для ДВК, убрал заморочки с получением адреса и вектора, и поменял таблицу геометрии винчестеров, да МY, там возни было более, исходника не было, дизассемблировал. Делалось это для того, чтобы XM-монитор запустить и посмотреть. А с МY ковырялся ещё для того, чтобы читать дискеты с PC. Увы, не допилил... :-( Написал логический драйвер IB, который должен был перенаправлять запрос на ввод/выод на МY. Даже добился выдачи корневого каталога по команде DIR IB: :-)
Громоздкий получился, по этому вынес всё по работе с FAT12 в отдельный драйвер...
Правда дискета с PC должна была быть на 800 кб на FAT12. Ну плюс отдельные утилитки были, опять же для чтения каталогов дискет PC. Они выдавали геометрию размер и корневой каталог дискеты PС, которую мог прочитать дисковод на MY. Достаточно было прочитать первый трек. Точнее первые 8 секторов МY. Возможно, что утилитки и работали бы на других контроллерах поддерживающих двойную плотность, но не проверял...
На том мои успехи кончились :-(
Ввод-вывод с файлами я не сделал :-(
У других было проще, работали с оболочкой по типа нортона, читали и писали программой.

[Hunta]

но там есть какое-то соглашение о передаче данных при начальной загрузке первичному загрузчику

Минимальный вариант - адрес РКС и всё, теоретически (понятно, что не для всех устройств) по регистрам можно раскрутить остальное. Ещё зависит от операционки, скажем в RSX много чего зашивается в нулевой сектор при его записи. Но в последних версиях RSX по крайне мере которые плюс - стал работать и с дисками с разделами от PC - тут надо смотреть - как оно передаёт. С учётом того, что во времена PDP-11 от DEC такой вопрос особо не стоял - не уверен, что DEC выработало какой то стандарт.
Драйвер WQ для RT, скажем, принимает от начального загрузчика РКС, primary или slave и номер раздела (ака номер устройства) плюс непонятная константа 100200(8) в R5, смысл которой для меня пока не понятен