МС1201.2018

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

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

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

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

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

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

Цитата:

---

Сообщение от AlexG

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

---

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

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

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

Цитата:

---

Сообщение от AlexG

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

---

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

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

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

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

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

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

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

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

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

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

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

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

Цитата:

---

Сообщение от Alex

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

---

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