Мои 160 образов дискет (публикую впервые)

[Error404]

Лирическое отступление.
До какой-то поры SteinBlume, открывая образ с dph/dpb как у Корвета, всецело доверялась данным из dph, dpb. С Корветовскими дисками особых проблем не помню. А вот с Орионовскими и, по-моему, Векторовскими была следующая трабла. Авторы этих реализации CP/M, честно стырив ее с Корвета, на некоторые вещи решили положить. Их диски часто бывают отформатированы на >80 цилиндров, при этом в dph (Барсику ужасно не нравится, когда я так называю) по-прежнему записано 80(!). В итоге при открытии таких дисков, появлялись проблемы с файлами за пределами 80 цилиндра (утилита-то предполагала, что их 80). Пришлось прицепить костыль. Если образ больше, чем должен быть (исходя из данных dph), то количество дорог пересчитывалось. Это позволяло нормально открывать 82-цилиндровые образа с 80 в dph.
Но в данном случае, это выходит боком. SteinBlume, пересчитав число дорожек, пытается определить количество блоков на диске (а значит и то, 1-байтная карта блоков в директории или 2-байтная). И в данном случае определяет неправильно (так как думает, что цилиндров 80). Отсюда и абсолютно некорректная обработка карты.
А если откусить от образа первые 400кг, то все (как я думаю) приходит в норму.
Как-то так.

Фигня какая-то. А как тогда работала сама CP/M с такими дисками? Формат более 80 дорожек на Орионе в лениградских CP/M использовался часто, логических ошибок на экстра-треках у CP/M не возникало.
Не припоминаю так странно размеченных дисков на Орионе (чтобы в одном месте DPB было одно количество дорожек а видимо количество групп под другое количество дорог). Чьи образы использовались (чтобы косвенно понять - чем оно так чуднО форматировалось)? Может опять руками правленное?

[Advertiser]

[Black Cat / Era CG]

Ну, на эмуляторах, эти два проблемных (40x2-дорожечных) образа (007-Gelas-Bel-Krum и 009-ndr-2) и без "обрезания" работают, я это еще в начале темы писал. И все игры запускаются. Я думаю, эмуляторы просто игнорируют вторые 400 кб образа, ориентируясь только по информации из cp/m (нулевого сектора).

Да. Логично. Так и должно быть. Просто моя утилитка по некоторым причинам (я там писал выше) не может в этом случае верить информации из 0 трека

Фигня какая-то. А как тогда работала сама CP/M с такими дисками? Формат более 80 дорожек на Орионе в лениградских CP/M использовался часто, логических ошибок на экстра-треках у CP/M не возникало.
Не припоминаю так странно размеченных дисков на Орионе (чтобы в одном месте DPB было одно количество дорожек а видимо количество групп под другое количество дорог).

Орионовских подобных дисков (где в DPH дорог 80, а на деле больше) на вскидку не нашел. Может я и наврал.
Могу пока только сослаться на

Число треков в большинстве реализаций не используется (развитые реализации CP/M, зная, что дисковод на 80 треков, а дискета на 40, начинают читать 40-ка дорожечные дискеты на 80-ти дорожечном флопе, делая 2 шага на дорожку).

Нашел таких дисков для Вектора несколько штук.

Формат более 80 дорожек на Орионе в лениградских CP/M использовался часто, логических ошибок на экстра-треках у CP/M не возникало.

Подкиньте пару-тройку таких образов. Может мы о разном говорим.

[Error404]

Подкиньте пару-тройку таких образов. Может мы о разном говорим.

Пары-тройки у меня нет, я такие не храню: их ведь не только открывать надо, но и записывать чем-то, а утилиты физической записи обычно всё же на 80 дорожек (ибо не знают про ВИЗ, а пишут некий абстрактный трек - не обязательно CPM-овский, что в-общем то и верно). Надобность в них как в более ёмких чем 800к тоже отпала после перехода на HDD и образы HDD.
Для примера вот такой образ (храню сугубо себе для образца):
https://drive.google.com/file/d/0B3S...ew?usp=sharing

А вот в былые времена когда я на реальном Орионе и реальном дисководе работал, то не только ежедневно пользовался в CP/M "нестандарными" форматами (7-8 килобайтных секторов на трек, 83-85 дорожек), но и сам писал CP/M-овский форматировщик дискет под такие форматы (причем это на момент 1995 года уже не было что-то оригинальное или какое-то новшество: делал вприглядку в уже существующие, просто я сделал себе универсальный вариант вместо кучи F82/F83/F84.com).

[Black Cat / Era CG]

А если этот образ открыть?
007-Gelas-Bel-Krum_.zip
Тогда rescue.com извлекается, как у тебя?

[marinovsoft]

Все-таки у меня есть косяк.

AL numbers can either be 8-bit (if there are fewer than 256 blocks on the
disc) or 16-bit (stored low byte first).

Значит скоро будет фикс

[Black Cat / Era CG]

AL numbers can either be 8-bit (if there are fewer than 256 blocks on the
disc) or 16-bit (stored low byte first).

Вот поэтому у меня образ 800кг и его половина (400кг) открываются по-разному.
Давай сравним crc32 RESCUE.COM

[Black Cat / Era CG]

Serebriakov, если будете перечитывать 40-дорожечные дискеты, сравните результат со старым вариантом. По сути-то ведь должна получится просто половина "старого" образа.

[Serebriakov]

Хм. Попробовал перечитать одну из таких дискет (009-ndr-2). Выходит такой же образ (800кб), как и в первый раз (контрольные суммы совпадают). Что со сканированием секторов в ZXDStudio, что без. Что логично, т.к. там в настройках по-умолчанию стоит читать 160 дорог. ZXDStudio, судя по всему, смотрит только на наличие физических секторов и ему глубоко фиолетово, что там в параметрах cp/m.

Старый MST от 2014 вообще отказывается эти дискеты читать. Новый MST от 2017 читает тот же самый образ.

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

В общем, странные какие-то дискеты. В заголовке 40 на 2 стороны дорожек, а по факту вторая половина за пределами 40×2 читается и там даже что-то есть.

Сейчас попробую вручную задать настройки ZDX по дорожкам и поглядеть что выйдет.

Позже: Ну логично, если вручную указать читать первые 40×2, то читаются первые 400 кб того же самого образа.

Короче говоря, я так и не понял можно ли просто так взять и выкинуть вторые 400кб этих образов.

[DDp]

А если откусить от образа первые 400кг, то все (как я думаю) приходит в норму.

можно ли просто так взять и выкинуть вторые 400кб этих образов.

IMHO, вы активно_замедляетесь_в_нев� �рном_направлении.
Надо вырезать чётные цилиндры, работать только с нечётными (случай: 40-дорожечная дискета в 80-дорожечном дисководе).

[Serebriakov]

Надо вырезать чётные цилиндры, работать только с нечётными (случай: 40-дорожечная дискета в 80-дорожечном дисководе).

Конечно-же, я предполагал и такой вариант. Это бы значило, скорее всего, что запись ведётся только на одну сторону дискеты.
Но очень сомневаюсь, что форматирование в 40 дорожек × 2 стороны ведётся описанным вами способом. В образе на каждом чётном цилиндре были бы дыры (NULL или т.п.) А здесь данные идут последовательно и очень похоже, что каждый следующий цилиндр - это продолжение предыдущего (видно, например, по hex'ам на секции имен файлов).

Ага есть. А возможен такой вариант, что диски были РАНЕЕ отформачены на 80 треков, а уже ПОТОМ на 40?

Могу предположить, что это остатки от предыдущего форматирования, но хочется чьего-нибудь экспертного мнения.