Параметры дискеты

[litwr]

Обнаружил, что при обращении к диску Корвет каждый раз считывает информацию с системной дорожки. Как понимаю, это позволяет Корвету работать с разными форматами дискет. Ищу информацию о том, что именно и откуда считывается.

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

Похоже нашёл методом тыка. Параметры идут со смещением 4 на начальной дорожке и занимают 20 байт. Но полной уверенности нет... Интересно, сможет ли Корвет использовать диски только с одним зарезервированным треком?

Но скорее лучше брать сразу первые 32 байта...

[specorg]

Вот в этой статье (https://zxpress.ru/article.php?id=8564) упоминается структура первого сектора диска у Корвета.


В документации на КОРВЕТ стандартным также являлся самый пер─
вый сектор на диске - его 128 байт содержат размеры всех облас─
тей на диске: размер секторов в байтах, количество их на до─
рожках - и если эта информация вместе с форматом каталога яв─
ляется более-менее стандартной, то можно постараться и написать
универсальную читалку-писалку на диски всех систем, претендую─
щих на CP/M совместимость.
В этом секторе содержится:
┌───────┬───────� �───────┬────────� ��──────────────── ────────────┐
│Байты │Стандартно │Назначение │
├───────┼───────� �───────┼────────� ��──────────────── ────────────┤
│0-1 │0 или #BE80 │Адрес загрузки ОС │
│2-3 │0 или #BF00 │Адрес запуска ОС │
│4-5 │0 или #0D │Количество секторов под ОС │
│6 │0 │Код диаметра НГМД (133 мм) │
│8 │0 │96 дорожек на дюйм (=1 для 48 дор.) │
│9 │1 │Данные вектора перевода секторов │
│ │ │(0 - не используется) │
│10 │3 │Размер сектора: │
│ │ │(0 - 128 байт │
│ │ │ 1 - 256 │
│ │ │ 2 - 512 │
│ │ │ 3 - 1024) │
│11 │1 │Двухсторонний НГМД (четные дорожки │
│ │ │сверху, 0 - односторонний) │
│12-13 │5 │Количество секторов на дорожке │
│14-16 │0080 │Количество дорожек на одной стороне │
│ │ │(TPD, TPD'=2TPD) │
│16-17 │40 │Количество логических записей по 128 │
│ │ │байт на дорожке (SPT) │
│18 │4 │Фактор сдвига ( =LOG2(BLS/128) ) │
│19 │15 │Маска расположения блока данных │
│ │ │( =BLS/128-1 ) │
│20 │0 │Маска размера блока │
│ │ │( =BLS/1024-1-DSM/256 ) │
│21-22 │#187 │Количество блоков данных на диске │
│ │ │( DSM=SPT*(TPD'-OFF)*128/BLS-1 ) │
│23-24 │#7F │Число элементов оглавления минус 1 │
│ │ │( DRM ) │
│25-26 │2 │Количество блоков под оглавление │
│ │ │( =32*DRM/BLS) │
│27-28 │#0020 │Размер вектора контроля оглавления │
│ │ │(Контрольная сумма каталога?) │
│29-30 │3 │Количество дорожек под операционную │
│ │ │систему, включая нулевую (OFF) │
│31 │#E7(#F1) │Контрольная сумма этого сектора │
│32-128 │0 │Резерв для вектора перевода секторов │
└───────┴───────� �───────┴────────� ��──────────────── ────────────┘
Осталось невыясненным, где хранится BLS - размер блока дан─
ных (2048/4096) как таковой. Но его можно рассчитать из 19-го
байта - маски блока данных.

[Black Cat / Era CG]

На самом деле инфа известная. Думал, кто-нибудь вместо меня закинет подробности. Ну. Не ошибся.

[litwr]

Благодарю за подсказки. Попробовал сделать незагрузочный формат с одним системным треком - сработало, получаем на 4 КБ больше, чем с типовым cpm-диском, и на 10 КБ больше, чем с типовым микродос-диском.

https://s1.hostingkartinok.com/uploads/images/2022/03/34f55ffe314629b67e535e4e719c1da8.png

SteinBlume с этим форматом тоже справляется. Прикрепляю образ в этом формате. Он сделан в z88dk (https://github.com/litwr2/z88dk/tree/corvette) - - можно тестировать. Например, готовим файл hello.c и компилируем его командой

zcc +cpm -clib=8080 -subtype=corvette hello.c -create-app

получаются исполнимый файл A.COM и образ диска A.DSK с этим файлом.
77111

[Black Cat / Era CG]

SteinBlume с этим форматом тоже справляется.Так она первым делом проверяет КС этих самых параметров, и если все нормально, то оттуда параметры и берет :)

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


образ диска A.DSK с этим файлом.лучше сменить расширение на KDI, так заведено.