ODS1 FILES-11 DECFILES11A reader

[anasana]

ods1reader - разбор образов дисков с FILES11-структурой: https://www.dropbox.com/s/f0ewfhrvhw...ods1reader.zip v.1.05 (03-04-2020)
Нужна изредка, но пусть будет отдельной темой, т.к. ODS-1 (On Disk Structure Level 1) — формат файловой системы использовался на разных машинках с корнями от d|i|g|i|t|a|l.
Может быть полезна для просмотра образов с RSX/Micro-RSX, P/OS и ПРОС. Идентификатор DECFILE11A или DFCFILE11A.
У файлов может оказаться по несколько разных имен (как они описаны в директории-родителе, и личной инфе). Подсвечиваются болдом при несовпадении (правый клик мыши покажет альтернативное имя).
Извлекает все файлы, в т.ч. удалённые, из дампа диска общей кучей в один каталог C:\OUT\
В исходные дампы никакие изменения никогда не вносятся, для них жестко задан режим только чтение.
При извлечении дополнительно разворачиваются текстовые файлы со строчным кодированием (f.rtyp == R_VAR), добавляя к имени файла-оригинала ".txt".
"c:\out\zzlog.txt" - полный лог парсинга. "c:\out\zzcut.dat" - "форк-минусовка" (копия дампа в которой незанулены только те сектора которые оказались недоступны через дерево файловой системы данного диска).
По моему личному предпочтению, на данный момент:
.DSK и .DZ - это образ дискеты в формате DZ (409'600 байт).
.IMG - это образ такой же дискеты, только сектора идут уже нормально последовательно - бут блок самый первый и т.д.
.RD - образ жесткого диска у которого бут блок чуть сдвинут, а в начале идёт пустой сектор.
Длина файла .img в общем-то может быть любой, так как и .dsk/.dz и .rd в итоге сводятся к .img, который есть LBN.
Внутреннее предперекодирование секторов происходит опираясь только на расширение выбранного файла-образа, зададите неправильно - могут быть чудеса.
P.S. Чудеса зависят от разных факторов. Поэтому если не открывается то, что должно открываться - прошу в личку, скайп или на мыло.

При извлечении (в C:\OUT) файлов с одним именем, расширением и номером ревизии, но из разных директорий образа, они перезапишутся друг поверх друга по мере встречи, но это можно отключить галочкой. Выбрать принудительное сохранение нужного можно из контекстного меню.

[Advertiser]

[form]

Умеет вытаскивать правильно? (с учетом структуры FILES-11)?
Особенно ксается файлов текстовых и бинарных (OBJ, STB) - должны при вытаскивании конвертиться в формат RT-11.

[anasana]

Так для миграции используется FLX. А я сохраняю содержимое 1-в-1 как записано на диске(те), что бы, максимально, в человеческом виде.
Если предварительно обработать FLX-ом, то оно тогда будет извлечено уже готовым к переносу с учетом его соглашения о форматировании.
Помнишь ты мне сбрасывал специально для тестов ttdrv.stb. Там всё это хорошо было видно по служебным полям.
З.Ы. Есть ли необходимость переписать FLX под винду/консоль? Тогда файлики смогут красиво копироваться дальше в TC-плагине Patron'а.


/*
Из аттача с образом RX50 (не прошным).
В нем в [1,1] лежат TTDRVRSX.STB - родной RSXовский STB файл и TTDRVRT.STB - он же, скопированный FLX'ом в RT-11 и вытащенный оттуда в IMAGE mode.
Вроде в описании утилиты FLX написано что делается при конвертации таких файлов.
Примерно так - когда копируется за пределы FILES-11, в начало каждой записи добавляется ее длина, а в конец - контрольная сумма.
*/

Исходник (плюс его текстовая колбаса):
Filename: [87,1] ttdrvrsx .stb;1 ;0 # № 8, LBN: (11)
f_rtyp R_VAR - text
f_ratt FD_NONE - save content as is
f_rsiz - used Record Size value in bytes: 122 (p.6.3.1) == HEX: 7A 00

А вот так он выгружается при экспорте:
Filename: [87,1] ttdrvrt .stb;1 ;0 # № 7, LBN: (3)
f_rtyp R_FIX - fixed binary or stream
f_ratt FD_CR - use Normal slew: LF before line data, CR after
f_rsiz - used Record Size value in bytes: 512 (p.6.3.1)

[AFZ]

.DSK - это образ дискеты в формате DZ (409'600 байт).
.IMG - это образ такой же дискеты, только сектора идут уже нормально последовательно - бут блок самый первый и т.д.

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

Для образа дискеты DZ следовало бы выбрать какое-то другое расширение - например, .DZ, подобно тому, как Патрон сделал .DW для ДВК-шного винчестера. Пока еще не сильно поздно, стоило бы переиграть. И в Хомере, кстати, тоже.

[AFZ]

dw и dz добавил

Стоп-стоп! .DW зарезервировано за ДВК, для Э-85 положено .RD. Если не в курсе, у ДВК сначала делением вычисляют C-H-R, потом инкрементируют R по модулю 16, а у 85-й инкрементируют номер блока, потом делением получают C-H-R. В итоге у Э-85 на один сектор сдвинут весь диск, а у ДВК на один сектор сдвинута дорожка, а блоки 15, 31, 47, 63... оказываются в нулевом секторе соответствующей дорожки.

[Patron]

у ДВК на один сектор сдвинута дорожка, а блоки 15, 31, 47, 63... оказываются в нулевом секторе соответствующей дорожки.

Так было и на всех советских Э-85 с RT-11 - "заворот дорожки" DW в RT-11 исправлен только с V05.03, а на советских Э-85 стояла V05.01

[hobot]

Да, согласен, - это хорошая идея. Посижу, пострадаю немного локально в размышлениях - dw и dz добавил, а dsk пока ещё не отдал, т.к. слишком много переименовывать сейчас не готов.

Уточни пожалуйста ещё разок, что там с расширениями в итоге, .DSK - должны быть RT-шки, как тут описано

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

- - - Добавлено - - -
Попытка запуска в XP sp3

[AFZ]

Так было и на всех советских Э-85 с RT-11 - "заворот дорожки" DW в RT-11 исправлен только с V05.03, а на советских Э-85 стояла V05.01

Не-а! Это было всегда. Собственно, эта глупость была затеяна из-за того, что БИОС ПРОхи, а, следовательно и 85-й, в процессе запуска, производит какую-то тестовую запись на винчестере, для чего ему пожертвовали дорожку 0-0-0, а остальной диск сдвинули. Не сделай они этого изначально, диск DW, в точности, как и RK, начинался бы с 0-0-0.

А наши ДВК-шники (Зеленоград), не въехав в суть этого дела и, вероятно, не зная RK, зато насмотревшись на дискеты и поразглядывав винт от 85-й, решили, что загрузочный сектор всегда должен быть 0-0-1, остальное интерпретировали по-своему. Исправили они эту ошибку, или нет, точно не знаю. Я видел в поставке с ДВК только ФОДОС, который был сделан из 5.1. Контора, в которой я тогда работал, получила в 1994-м кучку ДВК, они были с тем же ФОДОСом. Подозреваю, это была вообще одна из последних поставок ДВК с Кванта. То есть, конечно, они еще пытались продавать свой АДОС, не знаю, ни разу не пытался его ставить и понятия не имею, какой там DW, но подозреваю, что DW для ДВК, совместимый по расположению дорожек с Э-85 - чья-то самодеятельность, есть у меня где-то и такой, причем, действительно, не то с 5.3, не то с 5.4. DEC'овского же DW для ДВК не было и не могло быть, поскольку таких контроллеров для Q-Bus у них никогда не было, это целиком наша (зеленоградская) самодеятельность.

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

Да, вспомнил. Я все-таки загружал АДОС, с дискеты. И этот АДОС вполне нормально видел мой винчестер, который "с заворотом". Так, что ни разу Зеленоград этот "заворот" не убирал. Оно и понятно: допустим, купил кто-то у них этот АДОС, ставит его на свой винт, где был ФОДОС, и обнаруживает, что содержимое винта пошло лесом. Да он же пойдет бить им морды!..

А ходившие в народе ДВК-шные драйвера DW с 85-м порядком секторов - чей-то самопал, точно.

[Patron]

Не-а! Это было всегда.

Всегда - на ДВК. Но речь про Э-85 и про то, что вплоть до RT-11 V05.03 - на Pro350 ( а значит - и на Э-85 ) был точно такой же "заворот дорожки" DW.

Дековцы исправили "заворот дорожки" только в родном драйвере DW для RT-11 V05.03. До того момента - винчестеры с RT-11 во всём мире ( включая все Pro350 и все Э-85 ) были в точности с таким же "заворотом дорожки", как у ДВК.

[AFZ]

Всегда - на ДВК. Но речь про Э-85 и про то, что вплоть до RT-11 V05.03 - на Pro350 ( а значит - и на Э-85 ) был точно такой же "заворот дорожки" DW.

Поглядел - точно. Блин, и на хрена они это сделали? Глядя на других? Так ведь у них контроллер уникальный, у других нулевого сектора просто не было - они начинались с 1 и где как - на простых MFM - до 17, на RRL - поболее, помнятся цифры 22, 28, 39, еще что-то, но нулевого сектора нигде не было. А тут 0-15, на хрена, спрашивается, было извращаться? Чтобы делать ошибки в драйверах?