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

[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

[Advertiser]

[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

[dk_spb]

Да, вот теперь мы об одном файле говорим ;-)

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

И эти строки в образе с 0x3100.
То есть с указанными 0x1C00 разница больше чем в дорожку. Разве интерлив может нас так "радовать"?
upd: а, ну да, может в пределах двух дорожек.

[Hunta]

Ну, названия похожие, не внимательно посмотрел
Так что распаковка работает норм, инфа (с учётом неправильного префикса 0x в длине) вывозится тоже правильная, но - для интерлейсных дисков - оказалась бесполезной
Не обещаю быстро - я пока ещё и в проверках результатов массовых рефакторингов, но эта доработка на первых местах. Закончу кусок возни с ODS-1 - и займусь этим косяком

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

Разве интерлив может нас так "радовать"?

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

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

upd: а, ну да, может в пределах двух дорожек.

Тогда не буду париться с выводм таблицы Или всё таки вывести?

[dk_spb]

Или всё таки вывести?

Информация лишней не бывает ;-)
Заранее спасибо!

[Hunta]

Ок, сейчас постараюсь сделать

[gid]

Тогда странно что gid пишет про два битых сектора....

Я посчитал 128 нулевых байтов в конце файла тоже битым сектором. Потому что плагин Patrona при извлечении файла обрезает не нужные нулевые байты в конце. А у этого почему-то не обрезал.

[Hunta]

Информация лишней не бывает

https://zx-pk.ru/threads/34713-image...=1#post1164713
Сделал для DX и DY

[dk_spb]

https://zx-pk.ru/threads/34713-image...=1#post1164713
Сделал для DX и DY

> 0 0x00000 26 0x00D00
> 1 0x00080 28 0x00E00
> 2 0x00100 30 0x00F00
Я правильно понял что самый первый физ сектор (если с нуля считать - то 0) попадает даже не на первую дорожку?
Это такой интерлейс? А в чем его смысл?

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

Я да, есть ли к этому "чуду" формула?