Образы дискет

[dk_spb]

ZA191 .LST начинается с 295 блока. 295*512 - 151040 или 24E00 по утверждению calc из Windows

Нет, Вы, как и многие, почему-то считаете что в образе том начинается со смещения 0x0.
Реально (по-крайней мере на дискетах) так не всегда. И плагин Patron'а это понимает.
Если скопировать плагином этот файл (или открыть его для просмотра), то видно что файл начинается с ".CPT otwety na woprosy". Поиск этого в образе даёт смещение 0x25800.

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

И вот с этим вопрос:
># number of 512 byte blocks on volume
>BlockCount=501
501*512 = 256512

А дискета-то всего 77*26*128=256256, то есть на 256 байт меньше.

[Advertiser]

[Hunta]

Нет, Вы, как и многие, почему-то считаете что в образе том начинается со смещения 0x0.

Вот только нужно учитывать, что DX - он с интерлейсом. И моя программа это учитывает. Но показывает она логические блоки, а не смещение внутри файла.

Да, согласен, для DX это даст не правильное смещение - но учитывая, что в DX блоки по 128 байт и интерлейсятся они, а не логические блоки - блок 295 файла - он размазан по чётырём кускам, которые не идут друг за другом.

Так что пока что в моей программе, что, похоже, в плагине (он показывает стартовое смещение или для всех физических блоков?) информация о смещении бесполезна.

Надо будет сделать вывода инфы как о логических блоках, так и для физических блоков - если образ с интерлейсом.

[dk_spb]

И про:
># File 0,00 "ZAY3.LST".
> No prefix.
> Data 2560 = 0x2560 bytes, start block 14 @ 0x1C00.
Плагин Patron'а под TC считает что этот файл начинается с ".LIN0 sleduet znatx, ~to redaktiru`}ie klawi{i uprawlq`t"

А по смещению 0x1c00 вообще сплошные 0x58

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

Да, согласен, для DX это даст не правильное смещение - но учитывая, что в DX блоки по 128 байт и интерлейсятся они, а не логические блоки - блок 295 файла - он размазан по чётырём кускам, которые не идут друг за другом.

Мне очень важна информация на какие физические сектора попадает конкретный файл (а лучше листинг/карту сразу по всем файлам).
Иначе очень усложняется процесс понимания нужно ли искать способы считать сбойные сектора или на них можно забить.

[Hunta]

И вот с этим вопрос

Последствия того, что 256256 на 512 нацело не делится. Сейчас не помню, но почему то решил сделать округление в большую сторону до целого
Технически ни на что влиять не должно - даже если создавать образ для RT-11 - в описании стоит - использовать 494 блока и по идее - образ создаться на 256256 байт, но вот это проверить надо

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

Плагин Patron'а под TC считает что этот файл начинается с ".LIN0 sleduet znatx, ~to redaktiru`}ie klawi{i uprawlq`t"

Результат распаковки, файл zay3.lst

.LIN
delo  zakl`~aetsq  w  tom,  ~to  bolx{instwo  |wm - cifrowye
ma{iny,  ih  ~asto  dave  nazywa`t  cwm ( cifrowaq

Как программой, так и эмулятором PDP-11 от Патрона

> Data 2560 = 0x2560 bytes, start block 14 @ 0x1C00.

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

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

Мне очень важна информация на какие физические сектора попадает конкретный файл

Я это понимаю. Но образы с интерлейсом - это относительная экзотика - и при написании кода не была учтена У меня то цель была несколько другая - распаковка/запаковка
Как я уже написал - принял к сведению, будет реализовано

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

а лучше листинг/карту сразу по всем файлам

Я похожее сделал для ODS-1 - там выводится список (логических) блоков с указанием - какому файлу принадлежит. Надо будет сделать и на уровне физических блоков и не только для ODS-1

[dk_spb]

Результат распаковки, файл zay3.lst

Прошу проверить что это ZAY3, а не ZA3

># File 0,00 "ZAY3.LST".

А то мы так далеко не уедем :-(

[Hunta]

Прошу проверить что это ZAY3, а не ZA3

Пардон, ошибся, ZAY3.LST:

.LIN0
sleduet  znatx,  ~to  redaktiru`}ie  klawi{i  uprawlq`t
poloveniem  kursora  w  stroke,  no  sami  kody  redaktiru`}ih
klawi{  w  pamqti  ne  zapisywa`tsq.  kody  klawi{
.SWT0
               ,    ,    ,   ,   ,   ,
.BLN