1 Тема от Voldemar0 Отредактировано Voldemar0 (14-02-2024 08:10)

  • Voldemar0
  • Voldemar0
  • Участник
  • Неактивен

Тема: Форматы дисков различных архитектур, кроме Агата

Привет!

По импортным системам эта информация собирается в википедии:
https://en.wikipedia.org/wiki/List_of_f … sk_formats

Предлагаю тут составить список с чуть более подробной технической информацией.


PC-совместимые по контроллеру:

Apricot PC-AT / IBM-PC Compatible, ОС - MS-DOS; НГМД - 40 x 2 x 9 x 512.

Robotron 1715, ОС - SCP (CP/M clone); НГМД - 80 x 2 x 5 x 1024.

Wang prof computer / IBM-PC Compatible, ОС - MS-DOS; НГМД - 40 x 2 x 9 x 512.

Wang VS MultiStation, ОС - своя; НГМД - 40 x 2 x 9 x 512.

Башкирия-2м, ОС - CP/M; 80 x 2 x 5 x ?
    !! нужно будет добавить поддержку инверсии головок в simple_image_decoder, возможно там сектор 1024 байта
    и, возможно, она где-то в чём-то спектрум или корвет- совместимая

БК0010-01, ОС - ANDOS [FAT12], MK-DOS; НГМД - 80 x 2 x 10 x 512.

ДВК-MY, ОС - rt11; НГМД - 80 x 2 x 10 x 512.
    Возможны варианты: 80 или 40 цилиндров, 1 или 2 стороны, 10 секторов на трек.
    Для чтения этого формата на PC под MS-DOS существует программа
    RT11.EXE. Кроме того, она также может читать диски
    формата DZ (ЭВМ "Электроника 85" / PRO-350 фирмы DEC).
    Автор RT11.EXE - Станислав О. Мясников.

Ириша, ОС - ???; НГМД - 40 x 2 x 9 x 512.

Корвет, ОС - CP/M; НГМД - 80 x 2 x 5 x 1024.

Спектрум, ОС - TR-DOS; НГМД - 80 x 2 x ???

Yamaha MSX, ОС - MSX DOS (подобна CP/M, но формат файловой системы - FAT12); НГМД - ???


PC-совместимые по контроллеру, но с нетипичной геометрией сторон (80c x 1h - мост3 определяет такие диски, но не умеет правильно создавать DSK - !! требуется доработка софта):

DEC PRO-380, ОС - rt11; НГМД - 80 x 1 x 10 x 512.

DEC Rainbow 100, ОС - Dial CPU: CP/M, MSDOS, CP/M-86; НГМД - 80 x 1 x 9 x 512.

TRS-80 Model III, ОС - TRSDOS; НГМД - 80 x 1 x 18 x 256.

Электроника МС 0585 / Dec Pro-350 / Электроника 85, ОС - rt11; НГМД - 80 x 1 x 10 x 512.
    Упоминается о сдвиге на одну дорожку, но не ясно почему (аппаратно или программно) и невозможности форматирования
    дисков (возможно, контроллер НГМД имел в своём составе вспомогательный контроллер, прошивка которого вносила эти особенности).


PC-несовместимые по контроллеру:

ДВК-MX, ОС - rt11; НГМД - 80 x 2 x 11 x 256 или 40 x 2 x 11 x 256.
    Подробности ниже, в отдельном сообщении.
    TAO, единственное синхрополе на трек.

Commodore, ОС - Commodore DOS; НГМД - 35 x 1 x <VR> x 256, но могут быть также и варианты с 2 сторонами.
    Количество секторов переменное, начиная от 21 на внешних дорожках и до 17 на внутренних.
    Также некоторые пакеты в некоторых случаях могли форматировать больше 35 дорожек, если это позволяло железо.
    Подробности ниже, в отдельном сообщении.

Amiga; НГМД - 80 x 2 x 11 x 512 или 80 x 2 x 22 x 512.
    Формат записи MFM, синхронизация по байту как на PC, но, кроме того, есть ещё один слой кодирования,
    оптимизирующий синтез MFM на железе Амиги: чётные и нечётные биты размазываются по сектору.
    TAO, но каждый сектор имеет своё синхрополе.

Микроша
    Очень подробное описание в журнале Радио, номера 1 и 2 за 1993 год.
    FM-кодирование всего потока, контроль синхронизации, геометрия 80 x 2 x 5 x 512,
    но размер сектора задаётся явно в поле данных и встречаются сектора меньшего 512 байт.
    В результате DSK-формат тут не подходит, эмули используют что-то вроде NIB-формата агата/эпла.
    CRC - арифметическая 16-битная сумма всех байт.
    Формат навеян агатом/эплом (названия структур файловой системы (VTOC, TSL...), адресация TS, а не CHS и т.д.),
    но в чём-то улучшен (CRC, например, более эффективная), в чём-то (FM вместо MFM/GCR) упрощён.

<последние 4 попозже опишу>

Дополняйте, кто что ещё знает.

2 Ответ от Voldemar0 Отредактировано Voldemar0 (19-12-2023 09:41)

  • Voldemar0
  • Voldemar0
  • Участник
  • Неактивен

Re: Форматы дисков различных архитектур, кроме Агата

Формат ДВК-MX

Основная статья с деталями тут:
https://zx-pk.ru/threads/20541-kontroll … rammy.html

Далее - выжимка из неё:

Данные пишутся 16-битными словами, начиная от старшего бита к младшему. Всё завернуто в FM-кодировку.

Синхро: нулевые байты (несколько) и затем слово 0363 (до этого контроллер не пропускает данные на вход, после этого пропускает всё подряд).

00 000 000 000 000 000 000 000 011 110 011
    1   2   3   4   5   6   7   8   9  10

0000 0000 0000 0000 0000 0000 1111 0011
(0x0000 00F3)

Выполняет ли контроллер синхронизацию только однажды или всегда (при встрече этого слова) - неизвестно.
Вероятно, запись начинается от сигнала индекса.
Тогда, возможно, что и распознавание сигнатуры при чтении тоже выполняется после сигнала индекса только однажды.
Иначе любая последовательность бит внутри полей данных вновь сбрасывала бы контроллер.
Вопрос лишь в том, какого размера требуется эта сигнатура (сколько нулей перед 0363)...

Формат адресного поля трека:
1) 00 00 000 00 00 0 000  0363
2) слово с номером дорожки
3) 11 секторов без GAP:
3.1) 128 слов данных
3.2) одно слово арифметической суммы слов из 3.1

До и после этого блока могут быть GAP (в зависимости от версии формата):
Версия 1) До вводной сигнатуры: 30 нулевых слов. После последней контрольной суммы: два слова 0101401 и затем 0177777 до сигнала INDEX.
Версия 2) До вводной сигнатуры: 8 нулевых слов. После последней контрольной суммы: три слова 0101400 + ( номер дорожки*2 + номер стороны ).

Вводные нули, очевидно, используются для того, чтобы контроллер мог синхронизоваться по биту (т.е. отличить синхробит от бита данных). Синхронизуется ли контроллер по биту после синхронизации по слову (после нахождения 0363) - неизвестно (т.е. что он будет делать в случае срыва синхро ?).

Важно: получается, что номер дорожки тут не включает в себя номер стороны.
Номер стороны пишется только в конце дорожки в варианте формата 2.

--

формате файла ххх.DSK , то его формат такой :
( нулевое ( начальное ) ) слово 16 бит - начальное слово файла х.DSK, младший байт следует первым, старший - вторым, и т.д.
Расположение информации в файле .DSK соответствует именно логическому следованию блоков от 000000 ( первого ) блока до ( хххххх ) ( последнего ) блока.
Т.е. фактор привязки блоков ( в файле .DSK ) к трекам и секторам отсуствует и является одинаковым для дисков, электродисков и винчестеров. Привязку контента файла .DSK к аппаратуре должен выполнять драйвер устройства в соответствии со своими аппаратными ( программными ) особенностями - см. ТО на дисковод.
( Например, сектора в МФМ треке винчестера тусуются в непоследовательном порядке ).

--

На каждую сторону дорожки диска MX пишется 5.5 логических блоков по 512 байт ( 11 секторов по 256 байт ), поэтому на двустроннюю дорожку MX пишется 11 блоков по 512 байт.

0 блок образа пишется в 1 и 2 сектора 0 дорожки с нижней ( 0 ) стороны диска;
4 блок пишется в 9 и 10 сектора нижней стороны 0 дорожки;
5 блок пишется в 11 сектор нижней стороны 0 дорожки и 1 сектор верхней стороны 0 дорожки;
6 блок пишется в 2 и 3 сектора верхней стороны 0 дорожки;
10 блок пишется в 10 и 11 сектора верхней стороны 0 дорожки;
11 блок пишется в 1 и 2 сектора нижней стороны 1 дорожки;

--

Помимо MX [FM] и MY [MFM, PC-совместимый по контроллеру] были также DX

3 Ответ от garnizon Отредактировано garnizon (20-12-2023 16:38)

  • garnizon
  • garnizon
  • Участник
  • Неактивен

Re: Форматы дисков различных архитектур, кроме Агата

Liberty Drive http://agatcomp.ru/Pravetz/Hard/LibertyDrive.shtml

ОС модифицированная Pro-Dos

Реально попавшийся нам формат 400кб, 40 дорожек, 2 стороны, 10 секторов x 512 байт.

Но поддерживаются другие варианты:
формат 400 и 800 кб для 5,25" дисков
формат 800 и 1400 кб для 3,5" дисков

4 Ответ от avivanov76

  • avivanov76
  • Участник
  • Неактивен

Re: Форматы дисков различных архитектур, кроме Агата

Была такая машина Изот-1080 (клон VAX-11/780). Там была интересная особенность: микрокод процессора хранился на 5-дюймовой дискете. То есть, для загрузки надо было сначала запустить консольный процессор, с его помощью прочитать микрокод с дискеты и загрузить его в память основной машины. Только после этого она могла выполнять инструкции и ее можно было запускать.
Какой там формат диска вообще не представляю, знаю только, что дисковод 80 дорожечный.

Форматы дисков CP/M - это отдельная песня. На youtube было какое-то видео, так там говорилось, что форматов дисков было около 200. То есть, стандартов там не было, каждый производитель придумывал свой формат и в результате сочетаний числа и размеров секторов видимо-невидимо.

5 Ответ от Voldemar0 Отредактировано Voldemar0 (23-12-2023 08:35)

  • Voldemar0
  • Voldemar0
  • Участник
  • Неактивен

Re: Форматы дисков различных архитектур, кроме Агата

Формат Commodore

Очень подробное описание есть в книге "INSIDE Commodore DOS" by Richard Immers, Ph.D. and Gerald G. Neufeld, Ph.D., 1984.
Там две главы на эту тему: chapter 3 and chapter 7.

Дальше выжимки оттуда и из других источников:

compatibles employed four different data rates depending upon track
position (see zone bit recording).

Tracks                in book        in real (not worth trusting)
 1 to 17 had 21 sectors,    3.25 mks    0-16    3.1
18 to 24 had 19,        3.50        17-23    3.4
25 to 30 had 18,        3.75        24-29    3.7
31 to 35 had 17,        4.00        30-34 - 4.0

for a disk capacity of 174848 bytes (170.75 KB, 175 decimal kB).
256 bytes per sector x 683 sectors.
17*21 + 7*19 + 6*18 + 5*17 = 683
683 * 256 = 174848

Синхро: единичные биты. Хотя бы 10, но обычно 40 (5 байт 0xFF без GCR-кодирования)
Число 5 тут не случайно: фактически, это ровно 4 некодированных байта.
Зачем нужно 4: аппаратный детектор сработает на любые 10 бит, но записывали 40
чтобы сигнал синхронизации слов продержался достаточно для программного его обнаружения.
Когда контроллер обнаруживает такой поток единиц, он сбрасывает счётчик бит и ждёт появления нуля.
Первый же найденный ноль и следующие за ним биты вкатывается в конвеер GCR-декодера.

{
  У контроллера есть некая замороченность (вероятно даже, это проблема его firmware), связанная с тем, что найдя одно синхрополе и его завершение (нолик), он не умеет отскакивать обратно по алгоритму, если вдруг встретил следующее. В результате синхрополе, начавшись, ни в коем разе не должно прерываться. Это привело к тому, что при минорной смене формата между разными версиями контроллеров, юзеры словили интересную несовместимость: диски разных версий могут читаться любым контроллером, но при попытке записи на "чужой" формат поле данных ломается так замысловато, что его невозможно найти ни на одной версии контроллера :)
Т.е. по сути, GAP между полем адреса и полем данных у них получается не совсем GAP (в смысле "любой, не слишком длинный, мусор"), а должен строго соответствовать определённому формату.
  { Декодеру Моста3 это пофигу: он должен декодировать даже такие сломанные сектора. Но проверить не на чём :( }
}

GCR-код ( в отличие от Disk][ ) тут покрывает всю запись кроме синхропоследовательности.
Но GCR тут гораздо проще, чем на эппле: каждым 5 битам на поверхности диска сопоставляются
по таблице 4 декодированных бита. Т.е. 10 бит с поверхности - это один байт на выходе декодера. Дальше всё просто: обычные
поля адреса и данных, традиционно предваряемые синхрополями:

AF:
SYNC 0x08 CRC sec tr id2 id1 0x0f 0x0f gap

CRC = tr ^ sec ^ id1 ^ id2;
sec - нумеруется от 0
tr - нумеруется от 1 !!
id2 - фактически, метка тома, иногда называется ID HI;
id1 - по сути, тоже метка тома, иногда называется ID LO;
0x0f - что-то вроде GAP, анализировать их при чтении не нужно;
gap - 8-9 байт 0x55.

DF:
SYNC 0x07 data CRC 0x00 0x00 gap

data - 256 data bytes, но могут заменяться ссылкой на другой сектор !
CRC - xor от всех data;
0x00 - нулевые байты, никак не используются;
gap - может быть от 4 до 12 и даже до 100 байт со значением 0x55.


Links:

Тут о некоем vorpal:
https://luigidifraia.wordpress.com/2021 … ocumented/

И тут ещё несколько поясняющих деталей о железе контроллера:
https://luigidifraia.wordpress.com/2020 … rive-work/

https://en.wikipedia.org/wiki/Floppy_disk_variants

Основная информация по формату тут (начиная с раздела 17.3):
https://vice-emu.sourceforge.io/vice_17.html
на самом деле тут о форматах образов. Очень подробно, но нам сейчас ни к чему.

Тут есть про скорости записи:
https://www.pagetable.com/?p=1070

Ну и тут чуть-чуть:
https://en.wikipedia.org/wiki/Commodore_1541
https://www.c64-wiki.com/wiki/Commodore_1541

Книжка Inside Commodore DOS:
https://www.devili.iki.fi/pub/Commodore … OS_OCR.pdf


Проблема с коммодором в том, что дисковод у него - это закрытая система.
У дисковода свой процессор, свое ПЗУ и общается он с компом по
последовательному интерфейсу специальными запросами. В результате комп
ничего не знает про файловую систему и кодирование данных на диске.
Официальной документации, насколько я понимаю, нет. Это типа "секрет
фирмы", в отличие от Apple. Вся информация, которая есть - это то, что
любители смогли самостоятельно накопать.

6 Ответ от Voldemar0 Отредактировано Voldemar0 (14-02-2024 08:26)

  • Voldemar0
  • Voldemar0
  • Участник
  • Неактивен

Re: Форматы дисков различных архитектур, кроме Агата

Формат Amiga

Очень хорошее описание есть тут: http://lclevy.free.fr/adflib/adf_info.html
Ни убавить, ни прибавить.
Немного необычно то, что здесь описание формата сектора даётся от уровня сырых бит, т.е. до MFM-декодирования.
Это, вероятно, связано с тем, что тут синтез и декодирование MFM оптимизировано под железо Амиги и содержит дополнительные битовые перестановки, выполняемые немного по разному в разных зонах сектора.

Основное по формату:

Sync: 0x4489
Paula will search two synchronization words, and then read 0x1900 words of data.
Each sector starts with 2 synchronization words. The synchronization value is 0x4489.

Double density (DD) disks have 11 sectors per MFM track, High density (HD) disks have 22 sectors.

Per-track Organization: Nulls written as a gap, then 11 or 22 sectors of data. No gaps written between sectors.

Далее порядок бит после sync: takt , data.