Форматы дисков, имеющие FAT

хх.хх.1999 - Журнальная редакция в формате 32 символа в строке. Описаны MS-DOS, iS-DOS, AGAT, DOS 2.9 - РАДИО-86РК, SP-DOS -ОРИОН-128, AO-DOS 2.02 (и совместимые с ней MicroDOS, NORD, NORTON, MK-DOS ) - BK-11M, CP/M (MICRODOS) - КОРВЕТ, РОБОТРОН, ОРИОН-128, PROFI, ATM-TURBO, ASM (ASC SOUND MASTER), RT11 (РАФОС,ФОДОС, ОС ДВК) - УКНЦ, СМ, ДВК, "Электроника-60М", NEWDOS - письмецо из Нета.

01.06.2000 - Свободно распространяемая версия, 64 символа в строке. Добавлено описание AN-DOS (БК-11М). Всего 11 систем.

01.09.2000 - Переформатировано в редакторе Слово и Дело v6.40. Добавлено описание Profi DOS, VFAT (расширение FAT) - длинные имена в Windows. Журнальная версия, кажется, вскоре тоже увидит свет.

14.10.2001 - Журнальная версия вышла в свет. Добавлено описание CP/M 2.3 by Michael Markowsky, 1995, CP/M и MX-DOS для компьютера Специалист-МХ, диски программы Realtime Audio Player, 2000, 2001, Halloween and Triumph.
Ред.: Описание MB02 см. в Adventurer #13. Описание ZXVGS - в Inferno#4. Описание CacheVox - в IG#5. У меня также имеется документация по DISCiPLE/+D на английском, она, возможно, будет опубликована в следующем номере.

18.06.2005 (Alone Coder) - Добавлен новый формат каталогов iS-DOS, исправлены многие опечатки. Справочник разбит на 4 части.

MS-DOS

Начнем с того, что все параметры диска хранятся в 0-ом секторе 0-ой дорожки. Только дело в том, что количество параметров наращивалось вместе с версиями MS-DOS, и только в 4-ой версии можно всё узнать о диске. Но поскольку форматер FLOPPY FORMAT Ивана Рощина записывает в этот так называемый BOOT-сектор то же, что и сама MS-DOS, то забудем об этой проблеме и вернёмся к содержанию этого сектора, в чём поможет таблица.

Что же обозначают эти цифры...

Я старательно буду умалчивать о работе с винчестером. Это не потому, что я по каким-либо соображениям хочу это утаить. Наоборот, ситуация с винчестером весьма поучительна для установки его под другие системы, но и гораздо более сложна для того, чтобы описывать её в обзоре дискетных форматов: там ведь тебе и проблемы наращивания объема, и главный загрузочный раздел с возможностью размещения нескольких операционных систем, и куча форматов при работе с уплотненным диском... А я рассказ веду о дискетах. Ред.: Статья ZET-9 в этом номере дополняет информацию Nuts'а как раз по вопросу о файловой системе на винчестерах.

Для начала немного теории. Операционные системы в большинстве своём оперируют не с секторами и дорожками, а со смещениями в абсолютных секторах. Т.е. понятие "дорожка" практически не употребляется, а существует куча секторов, начиная с нулевого и до какого-то конечного, может быть, стотысячного. Если, скажем, на диске 10 секторов на одной логической дорожке, считая с нулевого, то на нулевой логической дорожке будут находится сектора с 0-го по 9-ый, на 1-ой логической дорожке - с 10-го по 19-ый, и так далее. Более того, чтобы ограничить количество бит, задающих номер абсолютного сектора, весь диск разделяется на блоки по несколько секторов. Причем нулевой блок может находиться и не в начале диска - может начинаться с какого-либо абсолютного сектора. Первые сектора как раз и являются загрузочными и информационными.

В MS-DOS такие блоки называются кластерами. Количество секторов, приходящихся на один кластер, можно узнать из загрузочного сектора. Номер логического сектора, на котором располагается нулевой кластер, приходится подсчитывать на основе данных из загрузочного сектора, но об этом позже. Такая хитрая разбивка служит для того, чтобы всегда знать свободные места на диске, и разные куски одного файла записывать в различные области диска, куда только возможно, и собирать его, даже если он не находится на последовательных секторах. Поэтому можно долго не заботиться об очистке диска от удалённых файлов. Чтобы знать место расположения каждого куска файла, служит таблица FAT. Каждый её элемент, начиная с первого, содержит ссылку на тот элемент этой таблицы, где продолжается файл, номер кластера которого соответствует этому элементу таблицы. То есть, если мы узнали, что начало файла находится, скажем, на пятом кластере, то мы загружаем его и смотрим на пятый элемент таблицы FAT. А там значится, положим, число 25. Ну тогда мы спокойно читаем 25-ый кластер. И смотрим 25-ый элемент таблицы. А он указывает на номер следующего кластера - он же номер следующего элемента в таблице или число, означающее, что этот кластер является последним для этого файла и больше ничего читать не надо. Он также может указывать, что данный сектор свободен или помечен как дефектный. Проблема лишь в том, что на дискетах размер одного элемента равен 12 битам, и половинки каждого второго байта относятся одна к предыдущему байту, а другая - к следующему. Для определения содержимого элемента таблицы нужно:

1. Умножить данный номер кластера на 1.5, получим смещение до пары байтов в таблице, которая содержит номер следующего кластера;
2. Если предыдущий кластер имел нечётный номер (определяется по нулевому биту в номере кластера),то надо использовать 12 младших битов этой пары, иначе - 12 старших.
Если полученное значение равно 0, то этот кластер свободен. Если #FF8 - #FFF, то это последний кластер файла. #FF0 - #FF7 - зарезервированные сектора, в том числе: #FF7 - сбойный кластер. Только 0-ой элемент этой таблицы является исключением. Он содержит копию байта-описателя данного диска. Например, для дисков, которые можно прочитать на Спектруме (Ред.: имеется в виду, на Спектруме без доработки для чтения HD-дисков):

Но такие байты имеют и многие другие диски, в том числе и не со стандартной разбивкой.
На самом деле в этих байтах-описателях типа используются только младшие 3 бита, а старшие биты всегда равны единице.

В этом байте...
0-ой бит: 1 - двухсторонний;
0 - односторонний.
1-ый бит: 1 - 8 секторов на дорожке;
0 - не 8.
2-ой бит: 1 - постоянный диск;
0 - сменный диск.

Для определения начала FAT в загрузочном секторе указывается число зарезервированных и загрузочных секторов. Там же можно найти и количество таблиц FAT - для надежности делают несколько копий. После них идет корневой каталог, размер которого можно высчитать из количества файлов в нем. Корневой каталог всегда присутствует на диске. В нем содержится информация о файлах и подкаталогах 1-го уровня. Последние представляют из себя обыкновенные файлы, но с нулевой длиной, их размер определяется по таблице FAT, и они могут быть сегментированы - разбросаны по всему диску. В начале каждого подкаталога есть описатели двух файлов: "." и ".." .

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

Описатель любого файла или каталога занимает 32 байта:

Вот и всё, что надо для работы с диском. Для перехода от номера кластера к абсолютным секторам нужно отнять 2 от номера кластера, умножить на количество секторов в кластере и прибавить смещение до второго кластера в абсолютных секторах. Затем полученное число нужно поделить на количество секторов на дорожке. В результате получим логическую дорожку, где находится кластер, а в остатке - сектор.
Замечу, что в большинстве виденной мною литературы предлагалось считать корневой каталог, т. е. несколько самых первых кластеров,- вроде бы и не кластерами. Взамен вводилось понятие начала данных: следующий после каталога второй кластер считается вроде как нулевым, ну, и, соответственно, все номера кластеров считаются от него, при помощи приплюсования-минусования размера каталога. Словом, только лишние вычисления. На мой взгляд, если каталог лежит в нулевом кластере, то его и нужно считать за начало данных, а не за что-то особенное. Так сделано, например, в CP/M-80.

Но на самом деле корневой каталог не считается первыми двумя кластерами, а именно особой областью диска, размер которой не кратен размеру кластера. Именно поэтому данные начинаются со второго кластера и смещение до него определяется суммой абсолютного начала корневого каталога и его размера. И приходится производить вычисления.

Со времени появления расширений данной файловой системы, используемых в Windows 9X, появилась ещё одна проблема - длинные имена. Старая добрая MS-DOS справляется с подобной напастью - и, хотя имена файлов выглядят не совсем обычно, тем не менее, никакого мусора между ними не возникает, чего нельзя сказать о многочисленных конвертерах и читалках. Если вкратце, то глюки эти происходят оттого, что в некорректно написанных программах не отлавливаются заголовки, у которых в байте флагов установлен третий бит.

Но мне было уж очень интересно, как же всё-таки хранятся длинные имена. Самое интересное, что вопрос этот оказался довольно недокументированным (малопопулярным?) (Ред.: закрытым. Научно-техническая информация, по законам западного рынка,- объект торговли). Гипотезы я слышал самые фантастические, но точный ответ дала мне документация для ОС Linux, которая поддерживает несколько файловых систем (в основном редкостных и малозадокументированных),в том числе VFAT (на которую как раз документашка оказалась).

Описание это носит название:

NOTES ON THE STRUCTURE OF THE VFAT FILESYSTEM

(This documentation was provided by Galen C. Hunt <gchunt#cs. rochester.edu> and lightly annotated by Gordon Chaffee).

Привожу неточный и не дословный перевод:

Данный документ содержит очень упрощенный технический обзор исследований расширенной файловой системы FAT, используемой в Windows NT 3.5 and Windows 95. Никакой гарантии относительно корректности информации не дается.

Extended FAT file system почти идентична FAT file system, применяемой в более ранних версиях MS-DOS. Наиболее важным отличием является поддержка имен длиной до 255 символов, включая пробелы, большие и малые буквы.
Далее следует описание традиционного хедера для Windows 95:

Байт регистра указывает - должны ли быть заглавными буквы имени и/или расширения. Он имеет несколько разные значения в Windows 95 и Windows NT. Имя файла в стандарте 8.3, записанное в Windows NT маленькими буквами, будет показано в Windows 95 большими буквами.
Всё это распространенная и доступная информация. Вместе с extended FAT system Microsoft добавляет дополнительные заголовки в каталоги (если оно не укладывается в стандарт 8.3), может даже и по нескольку для каждого файла - в зависимости от длины имени. Далее эти дополнительные заголовки будут называться слотами. Упрощенно, слот есть специальный элемент каталога, содержащий до 13 символов расширенного имени. Их можно представить как дополнительные метки к заголовку соответствующего файла. Microsoft предпочитает представлять стандартный заголовок 8.3 файла как сокращенное имя (alias), а дополнительные слоты - как имя файла.
Структура слота такова.

Такая разбивка слотов выглядит несколько иррационально, потому что Microsoft пыталась обеспечить совместимость с более старыми версиями своего программного обеспечения. Для этого используются следующие приёмы:

1) Байт атрибутов в слоте равен #0F. Это означает, что данный файл является меткой, спрятанным, системным, защищённым от записи, чтобы он игнорировался этим старым ПО как метка диска, хотя, на самом деле, у метки установлен только один бит;

2) Начальный кластер установлен в 0, что невозможно для ДОС'овского файла.
Для того, чтобы старое ПО могло работать с каталогами, а новое - определить, к какому alias относятся расширенные слоты, применяются следующие методы:

1) Размещение. Слоты файла всегда связаны со своим alias. Вдобавок, у каждого слота есть идентификатор id, который показывает порядок этого слота в расширенном имени. Ниже следует пример файла "My Big File.Extension which is long", с порядком следования хедеров:

<слот #3, id = 0x43, символы = "h is long">
<слот #2, id = 0x02, символы = "xtension whic">
<слот #1, id = 0x01, символы = "My Big File.E">
<нормальный хедер, имя = "MYBIGFIL.EXT">

Это означает, идут с последнего по первый. Слоты пронумерованы с 1 до N. К N'ому слоту добавлено число 64=#40, что означает, что этот слот последний.

2) Контрольная сумма. Каждый слот содержит контрольную сумму своего alias'а 8.3, вычисленного по следующему алгоритму:

for (sum = i = 0; i < 11; i++) {sum = (((sum&1)<<7)|((sum&0xfe)>>1)) + name[i]}

Что означает примерно следующее (для всех 11 символов): у контрольной суммы оставить 0-й и 7-й биты, поменять их местами и добавить код данного символа.

Все расширенные имена хранятся в коде Unicode, по ДВА байта на ОДИН символ. Конец имени - два нуля, а остаток заполняется байтом #FF.

Такой вот перевод. Добавлю, что, форматируя диски в Масдае95, я получил диск, у которого был сброшен 4-й бит медиадескриптора (см. выше). Это, очевидно, и является признаком расширенной файловой системы FAT.

ASC SOUND MASTER

Это вообще-то музыкальный редактор, но вспомнил я, что с некоторых версий он вообще-то обладает ещё и своим, известным только автору, дисковым форматом. В редакторе было упоминание о некой версии CP/M того же автора. Системы этой я и в жизнь не видел, но я не нашел причины, чтобы на ASM 'овских дисках полазать. Собственно говоря, мне нужды до такого дела нетуть .Да вот компилировать музоны не всегда нужно под адрес 49152. Мудрые кодеры, надо думать, написали бы свой компилятор - ведь немало их под ST понаписали. А вот лазить по хитрому диску никто не захотел - написали рекомпилер под другой адрес.

Я тоже особо возиться не стал, так что, может, в нижеследующем описании что не так - не проверял пока особо-то.
Короче говоря, разбивка диска такая. Нулевая дорожка совсем хитрая:
Первые 8 секторов - по 512 байт;
Последний - на 1024 байта.
Остальные дорожки - нормально, 10 секторов по 512 байт.
На нулевой дорожке располагается каталог. Сколько секторов он может занимать, я не знаю, и при мне последний сектор всегда пустовал.
На запись в каталоге приходится по 16 байт. Нулевая запись -первые 16 байт диска - особые. Там содержится строка: "ADS 1.00"+ +" (C) ASC" - по ней легко определить принадлежность диска к отряду "музыкальных".
В остальных записях о файлах:

Теперь пару слов о сегментации. Структура диска удивительно похожа на диск MS-DOS. Куски файла могут занимать произвольное место на диске, а в записи о файле указывается ссылка на первый кусок. Только на данном формате диска размер куска равен одному сектору, и поэтому его номер можно называть номером кластера, номером блока или смещением до абсолютного сектора. Нахождение разбросанных по диску таких вот кусков осуществляется при помощи таблицы, аналогичной FAT-12. Две копии этой таблицы, размером по 5 секторов каждая, занимают всю первую дорожку.

Когда нужно прочитать файл,номер первого куска которого записан в каталоге, читают вначале этот первый кусок, а затем определяют в таблице, что содержится в ячейке с номером, равным номеру первого куска файла. А там содержится номер второго куска.
Теперь его читают и повторяют процесс с третьим. И так до тех пор, пока в таблице будет не номер следующего куска, а признак конца файла.
При записи в таблице ищут ячейки, содержащие признак незанятого места на диске, и записывают в туда номер следующего найденного пустого места, а на сектор соответствующего номеру ячейки таблицы записывают нужную часть файла.
Проблема в том, что ячейки имеют размер 12 бит = 1.5 байта, поэтому приходится извлекать нужную половинку из трех байт командами сдвига.
Первая ячейка таблицы всегда содержит число #AC - медиадескриптор для MS-DOS:
#000 - признак пустого места на диске;
#FFF - признак конца файла - последняя ячейка, которая содержит номер куска данного файла - последнего куска.
Словом, объяснить на словах это трудно. Ежели кому надо разбираться - изучайте на практике, а краткое описание я закончил.

Profi DOS

Продолжая разговор о дисках, в которых структура FAT аналогична MS-DOS, упомяну и про эту систему. Диски для неё полностью копируют структуру MS-DOS. Системные (загрузочные) файлы хранятся на строго фиксированных местах. Упоминавшиеся в документашках USER области пока замечены не были, а посему не могу сказать, где в хедере файла хранится номер области, если он хранится вообще.

iS-DOS

Как свидетельствует программа FLOPPY FORMAT Ивана Рощина, эта DOS поддерживает восемь разбивок диска, которые могут очень даже сильно отличаться друг от друга, т. к. размер сектора может быть как 256, так и 1024 байта (у запускаемых дисков). Количество секторов при этом будет 16 или 5 соответственно. Диск при этом может быть как односторонним, так и двухсторонним. Внимания заслуживает порядок секторов на дорожке. Поскольку диск может быть автозапускаемым, то, хотя на нём и находится по 5 секторов на дорожке, последний из них имеет номер 9.

Теперь рассмотрим структуру диска. Её описание находится на диске с ассемблером iS-DOS. Но оно рассчитано на программиста, работающего непосредственно в этой DOS. Здесь же я изложу основные факты из этого описания.
"Внутри" iS-DOS абсолютно ВСЕ устройства хранения информации представляются набором блоков, по 256 байт каждый, с номерами от 0 до некого максимального. Положение любого файла и вообще любого нужного места на диске задается смещением относительно начала диска - 0-го блока. И измеряется это смещение в этих же блоках по 256 байт. Т. е. не так важен размер сектора. Для определения дорожки и сектора можно воспользоваться формулами:
ДОР. = INT(СМЕЩ./ 5120) (или /4096)
СЕКТ. = INT((СМ.-ДОР.*5120)/1024) (или /4096)

А остаток от разности между смещением до сектора и смещением до нужного блока даст нам смещение внутри 1024-байтного сектора. 0-ой блок - это 0-ой сектор 0-ой дорожки. В нём содержится:

1-ый блок содержит бит-карту устройства: каждый её бит соответствует своему блоку на устройстве. 1 бит/блок: 0 - свободен, 1 - занят.
Подобная таблица - битовая карта диска, часто применяется в различных операционных системах.
Теперь поговорим о файлах и каталогах. Мы уже знаем, где находится главный каталог. Полезно вспомнить, что файлы в iS-DOS бывают не только сегментированными, как в MS-DOS, но и непрерывны ми, как в TR-DOS.

Т. е. файл может быть разбросан кусками-сегментами по всему диску, будет долго грузиться, и восстановить его после того, как запись в каталоге о нем будет испорчена, крайне затруднительно. Но забот о чистке диска от удалённых файлов почти не станет. Также файл может быть непрерывным, грузиться будет быстро, но проблемы с командой MOVE или, точнее, SQUEEZE (так она называется в HOBET'е на ПЦ) знакомы всем спектрумщикам (если они не работают под эмулятором). Правда, по некоторым сведениям, эта проблема разрешима (см. ниже),но как - пока неизвестно. Большинство (ВСЕ?) конверторы IBM<>ZX работают по принципу условной последовательности секторов файла, а если писать свой конвертер IS<>TR, то можно сделать этот файл и несегментированным, но для полноты картины надо рассказать, каким образом система iS-DOS собирает сегменты своих файлов с диска. Так вот, в каталоге описатель такого файла содержит ссылку не на начальный блок файла как такового, а ссылку на особый блок
- Таблицу Размещения Секторов Файла или, как его называют в фирменном описании, Блок Описателя Сегментов Файла. 0-ой его байт содержит количество сегментов файла - на сколько частей он разбит. Остальные 255 байт содержат 85 3-байтовых записей, каждая из которых описывает свой сегмент файла. Первые два байта каждой содержат номер нулевого блока этого сегмента, а третий - число блоков в сегменте.

И для чтения нужного файла нужно сначала определить начало этого Описателя, затем считать его. Потом организуется цикл по количеству сегментов. По первым двум байтам каждой тройки определяется начало конкретного сегмента и обыкновенным образом считывается последовательность секторов, содержащих блоки этого сегмента. При необходимости нужно позаботиться об исключении ненужных остатков первого и последнего секторов. Для последнего блока это можно сделать простой манипуляцией с адресом загрузки следующего сегмента. А вот с первым сложнее. Придется делать перемещения командой LDIR или читать сектора в промежуточный буфер. Но в любом случае размер 1024 байт придется учитывать.
Для сохранения файлов придется также побеспокоить битовую карту диска. Нужно искать незанятые блоки - соответствующий им бит будет сброшен. Его нужно установить, затем заполнить нужную запись в Блоке Описателя или добавить блоков к старой записи. Делать эти операции лучше в ОЗУ. Каталоги, как ни странно, представляют из себя почти обычные файлы, но у них два описателя: внешний - в каталоге-родителе и внутренний - в нем самом. У главного каталога только внутренний описатель - его 0-ой файл. Именно во внутреннем описателе содержится информация количестве файлов и уровне вложенности.
Кроме того, запись о файле/каталоге содержит определяющую метку, показывающую принадлежность файла к определенной группе (см. ниже). Следует также помнить об ограничениях: кол-во файлов в каталоге - до 128, уровень вложенности - до 6. Каталог тоже может быть сегментированным или несегментированным.
Теперь подробнее о структуре описателя файла. Замечу, что в описании структуры записи внутреннего описателя каталога мне не всё стало ясно.

Дата и время кодируются, как в MS-DOS. Контрольная сумма, возможно, тоже. Вот что известно про описатель внутреннего каталога:

Ред.: Структура каталогов на дисках iS-DOS поздних версий (к ним относятся "Open Letters" ) несколько изменилась. Плагин xISD HalfElf'а к Far'у понимает "новый" iS-DOS (2000) и позволяет копировать с/на него файлы. Дополнение по исходникам xISD:

|23 |1 |levelChic (уровень вложенности каталогов до 32)|
|24 |6 |Резерв. |
|30 |2 |Дата. |

Цитата из А. Леонтьева: "24.12.96 уровень вложенности каталога перенесен из 16-го байта описателя файла в 23-ий,т.к.16-ый байт, строго говоря, является старшим байтом длины файла и, хотя каталоги и не бывают длиной более 16 блоков, но при отладке программ бывали случаи, когда это совмещение изрядно вредило. <...> в старой системе через открытый как файл каталог становятся доступны для чтения и, что самое страшное, для записи блоки, находящиеся далеко за пределами каталога!"

CP/M (MICRODOS)

В том или ином виде эта система использовалась на огромном количестве компьютеров. Многие зарубежные и отечественные производители ПК пытались использовать эту систему на своих компьютерах. Пытались делать это и на СПЕКТРУМ'е. Но тогда были чудесные времена, когда формат MS-DOS, а равно и её возможности, был лишь сладкой мечтой. Сама фирма IBM использовала эту систему при помощи восьмидюймовых дисководов.
Тем не менее, старая восьмиразрядная система, казалось бы, должна прекрасно подходить для многих простых компьютеров. В некотором роде, это правильно. Но правильнее сказать, что её возможности по осовместимливанию разных компьютеров весьма скромны.

Система эта создавалась для работы с текстовыми терминалами. У неё нет средств работы с графикой! Да и с большим количеством памяти могут возникнуть проблемы.

Осталось только элементарная совместимость по общей памяти, тексту и формату диска. Но и тут совместимость мизерная. На СПЕКТРУМ'е весьма затруднительно вывести 80 символов в строке. Но самым интересным оказался вопрос дискового формата. Всё дело в том, что на восьмидюймовых дисках было 77 дорожек и на каждой размещались 26 секторов по 128 байт. Вроде бы, проблема разрешима, и диски можно прочитать. Однако почитаем соответствующую литературу.

Весьма часто можно видеть ссылку на такую книгу:

Уейт М. Ангермейер Дж. Операционная система CP/M. Пер. с англ. М: Радио и связь, 1986.

Но при детальном осмотре оказалось, что это явно пособие в работе, но не по программированию в этой системе.
Такой же оказалась книга:

Н. В. Макарова и др. Работаем на персональном компьютере РОБОТРОН 1715 Л: Машиностроение, 1989.

Похоже, что эта книга писалась во времена, когда под словом КОМПЬЮТЕР понималась: Большая, Очень Умная, Дорогая и Сложная Машина с Большим Экраном Типа Калькулятора Для Бухгалтера. Еще можно упомянуть подробную и научную, но устарелую и удалённую от практики книгу:

Дейтел Г. М. Введение в операционные системы. Пер. с англ. под ред. В.С. Штаркмана. М: Мир, 1987 В 2 т.

Несколько устарелая, на мой взгляд, но весьма полезная для создателей ОС книга. Но описываемые там методы весьма сложны, и на практике описывается как раз старая CP/M под восьмидюймовик. В результате становится понятно, что в этой системе разные машины используют практически любой возможный формат разбивки диска.

Только на РОБОТРОН'е стандартно их три. Немного отличаются методы сегментации. В результате существуют две модели компьютера КОРВЕТ, не совместимые между собой (когда-то мне об этом поведала учительница информатики из нашей школы).Но с КОРВЕТ'ом как со школьным компьютером и так почти покончено, ибо существует масса несовместимых между собой школьных агрегатов. А ведь постановка CP/M на КОРВЕТ называлась одной из самых удачных. Называлась теми, кто её присобачивал к компьютеру ОРИОН-128, на котором не только дисков, но и контроллеров с портами существует пяток версий.

То же самое можно сказать и о других компьютерах. Поэтому трудновато будет запустить на РОБОТРОН'е и даже на КОРВЕТ'e игру от PROFI или ATM-TURBO.

Но оказывается, что некоторая совместимость есть, формат дисков, описываемый ниже, хотя и является наиболее применительным для КОРВЕТ'а, вполне читаем и на других компах, несмотря на то, что их операционки называются, вроде бы, по разному: CP/M (-80) и MICRODOS, к тому же разных версий. Стало понятно, что читать диски от разных компов можно, но как их различать - неизвестно. Вот и приходится с трудом разбираться, что к чему.

Про КОРВЕТ и ОРИОН немало говорилось в журналах РАДИО и РАДИОЛЮБИТЕЛЬ. Я также пытался изучить диск от PROFI, но с ним у меня получилась печальная история. Я попросил сделать копию этого единственного диска при помощи NEXTCOPY. В результате исходный диск испортился, а на мой диск скопировались пара дорожек, содержащих каталог. И при помощи его я и узнал общие принципы хранения информации на таком диске.

Разбивка была, как и на КОРВЕТ'е и других машинах, на 5 секторов по 1024 байта. И такой формат следует признать общим. Описатели каталога состояли из 32 байтов, из которых 16 последних явно описывали блоки, на которых были расположены байты.
И только много позже я узнал некоторые подробности. К этой поре я уже походил в библиотеку и уже поставил себе эмулятор этой системы: MYZ80 v 1.0 by Simeon Cran. Он, правда, использовал виртуальный диск, который не совсем похож на реальные. Но некоторые интересные вещи я оттуда извлек. Потом я подробно изучил документацию к КОРВЕТ'у и ещё много чего выяснил.

Все осложняет наличие самых разнообразных единиц измерения:

от записей по 128 байт до экстентов и блоков по 32(16) Кб и 4(2) Кб. И похоже, что все размеры отличаются в зависимости от версии.
Но общие принципы не меняются. Где-то на диске расположен каталог: у PROFI на второй дорожке, у РОБОТРОН'а на третьей.

На файл уделяется по 32 байта, но в старых системах было и по 33. Описатель содержит в себе цепочку байтов - последовательность блоков, в которых помещается файл. Таким образом, на диске эмулятора можно было создавать файлы до 32768(16384) байт длиной. Но для систем с жесткими дисками максимальная длина упоминаемая длина достигала 8Мб. Также ограничивается и размер диска: около 256Мб. Но и эту проблему можно преодолеть увеличением размера блоков. Также упоминается возможность создавать цепочки из нескольких описателей для одного файла, всего до 16. А отдельные куски больших файлов получили название экстентов. На следующий описатель раньше указывал 33-ий байт. Позже за это стал отвечать байт с другим номером.

Каталоги в этой системе не поддерживаются. Но существует одна примечательная возможность. Дело в том, что раньше на одну машину приходилось по множеству пользователей. А даже гибких, не то что жестких, дисков было мало. Надо было решать вопрос о разделении данных на дисках. Поэтому было решено разбить диск на несколько USER-областей, всего до 16, но теоретически до 255. Каталог был общим, но в описателе каждого файла содержалась пометка принадлежности файла к определенной области. Таким образом, на одном жестком диске существовало несколько логических, как и в MS-DOS. Но диск при этом рассматривался как единое целое, и процедуры загрузки, записи и удаления файлов, а также чистящие утилиты, не определяли принадлежность файла к определенной области, и разделение было чисто внешним.

Теперь можно рассмотреть описатель файла более подробно:

Остаток сектора может быть заполнен кодом #E5.
В принципе, данной информации уже достаточно и для чтения, и для записи файлов. Тем не менее, в старых системах на диске также размещалась битовая карта на 243 байта. Каждый её бит отвечал за кластер из 8 секторов (8*128=1024). При записи файла устанавливался первый найденный сброшенный бит, и в описатель заносился номер соответствующего блока.

Однако для записи нового файла достаточно просканировать каталог, хотя эту операцию не совсем удобно реализовать программно, к тому же надо пропускать удалённые файлы. Лучше сначала создать таблицу свободных блоков в памяти и сделать это при первом же прочтении диска, а затем, используя и корректируя её в памяти, перезаписывать только изменённый каталог. Поэтому я не нашел больше никакого упоминания об подобной таблице размещения в более поздних моделях компьютеров.

Тем не менее, нельзя не сказать, что данная система использует самый оригинальный способ сегментирования. Прочие системы размещают информацию о сегментах либо в общей таблице, и тогда каталог так или иначе ссылается на один из её пунктов. Другие содержат её на отдельных секторах для каждого файла, и в каталоге делается ссылка на такие сектора. Но при копировании разумно было бы рассматривать такие сектора как сегменты файла. iS-DOS в этом смысле весьма оригинальна - использует и таблицу, и сектора, а также позволяет создавать вообще несегментированные файлы. Её авторы, по-видимому, изучали CP/M, но принятый на ней способ сегментации так и оказался уникальным.

В документации на КОРВЕТ стандартным также являлся самый первый сектор на диске - его 128 байт содержат размеры всех областей на диске: размер секторов в байтах, количество их на дорожках - и если эта информация вместе с форматом каталога является более-менее стандартной, то можно постараться и написать универсальную читалку-писалку на диски всех систем, претендующих на CP/M совместимость.
В этом секторе содержится:

Осталось невыясненным, где хранится BLS - размер блока данных (2048/4096) как таковой. Но его можно рассчитать из 19-го байта - маски блока данных.

Прошло время, и у меня появились также диски от других CP/M / MICRODOS -совместимых систем: Вектор-06Ц, АТМ и Скорпион. Под Вектор-06Ц у меня был эмулятор с внешней программой MST, работающей с егошними дисками. Но, к сожалению, наиболее глючно она работает в процессе форматирования дисков - много везде плохих дорожек, а в других системах диск форматируется нормально. Посему точно ничего сказать не берусь, но каталог, вроде бы, стандартный. Потом накачал ещё кучу софта и даже отформатировал диск.
Но никаких существенных признаков при этом не проявилось, да софта полезного было очень мало, так что пока вопрос остается открытым.

Под АТМ диски я форматировал Honey Commander'ом v1.0, каковая версия ещё работала на любом 128'ом. Диск - как в TR-DOS: 16 секторов по 256 байт, блоки вроде по 4096, но НИКАКОГО признака для их определения, кроме байтов #E5 в начальных секторах. Работать с ними, в общем, возможно. Установленные седьмые биты первых двух букв расширения файла соответствуют атрибутам READ ONLY и SYSTEM, что для вышеупомянутого коммандера означает HIDDEN: файл с таким битом просто так в каталоге уже не показывается. Так же, как и в КОРВЕТ'е, используются байты 12 и 15 описателя файла.
Под Скорп CP/M адаптировал г-н MOA аж в 1992. Плохо это или нет, да только образчик такого диска у меня пока один, под названием типа SEXDEMO - есть на нем какие-то картинки и музоны, пара исполняемых файлов... Только вот Скорпа -то у меня нетуть, под эмулем прут какие-то READING ERRORS 8-!, а при детальном осмотре файлов в них обнаружились то ли разрывы, то ли дырки, забитые нулями. Да и структура каталога заметно отличалась от стандартной: в табличке описания местонахождения блоков файла на диске было заметно, что на каждый блок уделяется не по паре байт, а по одному байту. Это и понято: при размере блока 4096 байт на диске их поместится около 150. Но эти разрывы в каталоге, заполненные нулями, заставляют меня подождать других образцов или информации.

Чуть позже я достал прогу TT 3.02, в кою была встроена возможность читать CP/M -овские диски. И, как оказалось, читает она их неплохо, несмотря на разрывы. При небольшом взломе оказалось, что процедура чтения довольно хитра. Детально я разбираться не стал, потому как стал сильно сомневаться в достоинствах этой системы.
Снова диски CP/M PROFI появились у меня благодаря г-ну Melted'у Snow, за что ему большой thanks. Были это диски от профийной якобы SP-DOS with Concurent BIOS (или что-то там такое - в общем, всё та же CP/M ). При их рассмотрении выяснилось ниже-следущее.

Во-первых, каталог находится на первых четырех секторах нулевой дорожки. Формат оного каталога соответствует стандарту.
Во-вторых, размер блока - 2048 байт, то бишь, каталог занимает первые два блока: нулевой и первый.

В-третьих, стандартная разбивка,- вроде бы, пять секторов по 1024 байта. Но на нулевой дорожке последний сектор всегда имеет нумер девять. Ясно, что вышепоименованный сектор служит для автостарта из под TR-DOS - на ЗАГРУЖАЕМЫХ дисках там всегда сидит файл BOOTK (или что-то в этом духе). А на незагружаемых дисках там может размещаться любой файл, что создает некоторую трудность при его чтении - приходится делать корректировки.
Но достоинством такого диска (он, похоже, был отформатирован не стандартным, в смысле, не системным форматером) было чередование секторов 1:1 и без всяких смещений. У загрузочного диска (он уже, скорее, был отформатирован стандартно) было смещение -1 (или 6 - на первой дорожке 1,2,3,4,5; на второй 2,3,4,5,1 ).Я дописал программку для SOFTCOPY - первый диск читался гораздо быстрее второго. Конечно, когда пишешь какой нибудь хитрый автоподстраивающийся лоадер, сей факт не имеет никакого значения, но факт остаётся фактом.

Далее у меня появились эмуляторы и диски от ОРИОН'а. Как оказалось, их структура полностью идентична дискам КОРВЕТ'а, только в загрузочном секторе прописан другой адрес для загрузки системы и, соответственно, изменилась контрольная сумма; как считать её - всё так же неизвестно.

Кроме того, от Capry/STALL получены диски и информация о Спектрум-совместимом ПК "Кворум". Как оказалось, эти диски тоже совместимы по формату с КОРВЕТ 'овскими, естественно, со своим клоном операционной системы.

Аналогичная ситуация и с версией CP/M для компьютера Специалист-МХ. Образец диска можно взять по адресу:
[http://avshsoftware.by.ru/download/bst_cpm0.zip]
Но у него есть ещё и собственная ДОС (см. ниже).
Другое дело CP/M 2.3 by Michael Markowsky (KLUG), 1995. На Klug BBS можно найти документацию на переработку Пентагона под эту систему и образ диска с системой и утилитами. Содержимое этой BBS можно найти в Интернете по адресу: [ftp://osin.iasnet.ru/klug/]

Там в подкаталоге SINCLAIR есть файлы: ZXCPM. LZH, SYSZXCPM.LZH и ZXCPM.ZIP, в них - всё необходимое.
Опознать дискету можно, например, по стрингу "CP/M BIOS "+ "Ver 2.3, Michael Markowsky (C) 1995", находящемуся по смещеню #297=663, в нулевом секторе нулевой дорожки. Экстенты начинаются с 4-ой дорожки, 0-го сектора - там
находится каталог. Размер каталога - 2 экстента. Размер экстентов - 2 сектора, т.е., как обычно, - 2 Кб.
Какой же из всего этого следует вывод?

CP/M -совместимость компьютера абсолютно ничего не говорит о разбивке его диска. Но в целом приведенной информации должно хватить для работы хотя бы со стандартными КОРВЕТ 'овскими дисками.

А точнее, для работы с CP/M придется написать настроечный модуль, определяющий или запрашивающий подвид системы и настраивающий системные переменные. А уж потом универсальная программа при помощи этих переменных будет работать практически с любым CP/M диском.

Примером такой программы может служить писишная 22Disk by Sydex, inc. Она, в частности может работать с CP/M компьютеров Spectrum +3 и Amstrad. Есть также и конфигурация для PROFI. Но, как известно, PC is...

Realtime Audio Player a project by PSB^Halloween vizualize by blade^triumph 2000, 2001, Halloween and Triumph

Этот плейер работает с дисками своего формата, и записана на них музыка в WAVE-виде. Описание - непосредственно из документации к программе.
Дорожек 80, стороны 2 (обязательно), сектора такие:

+----------+-----+
|физ.номер |длина|
+----------+-----+
| 0 | 128 |
| 1 |1024 |
| 2 |1024 |
| 3 |1024 |
| 4 |1024 |
| 5 |1024 |
+----------+-----+

Т. е. на диске 800 k под данные (беззнаковый wav,8 bit,mono) и на 0-й дороге 0-й сектор - информационный. На остальных треках его создавать не обязательно. Кстати, 0-й - это, в смысле, на самом деле (физически) нулевой, т.е. если пользоваться #3D13, то его надо указывать как -1 (#FF). Формат info-сектора такой:

Номер диска задаётся числом от 0 до 20 (всего 21 диск), а количество дисков определяется количеством байт, не равных #FF, по смещению +61. Таким образом, info-сектора каждого из дисков одного и того же музона отличаются только номером (+15).

Таким образом, определить диск этот можно, но не по 0-му сектору нулевой дорожки, как это можно сделать со всеми другими системами, а специально читая #FF-ый сектор.

DOS ПК "АГАТ"

Все данные о нём я почерпнул в книге:
Мымрин М.П. Конструкция, применение, программирование и ремонт ПЭВМ "АГАТ". М.:Машиностроение, 1990 г.
Книга эта весьма подробная и содержит полную информацию об этом ПК, включая схему и разные доработки, а также тексты кое-каких программ.

Формат диска: 35 дорожек (а может быть, физически-то и все 40 ),на каждой по 10 секторов по 256 байт. И, скорее всего, одна сторона.

Из этих дорожек нулевую, первую и вторую занимает ДОС, а каталог находится в самой середине диска - на 17-ой дорожке. Причем всё указывает на то, что секторы его идут в обратном порядке: начинается он на 15-ом секторе и, если он помещается на одной дорожке, оканчивается на 0-ом. В начале сектора расположены три важных байта. 1-ый - признак продолжения каталога: если он равен нулю, то процесс считывания секторов каталога можно прекращать. Иначе во втором и третьем байтах содержатся дорожка и сектор продолжения каталога. И вот, если каталог находится только на одной дорожке, то на всех секторах второй байт ссылается на 17-ую дорожку, а третий байт более старшего сектора - на более младший: 2-ой байт 15-го сектора равен 14, указывая, что следующий сектор каталога находится на 14-ом секторе. Аналогичным образом 14-ый сектор ссылается на 13-ый, 13-ый на 12-ый и т.д., а вот 0-ой сектор ссылается на 15-ый, будто бы каталог закольцован. (Но я надеюсь, что первый его байт равен нулю.) Иначе второй и третий байты нулевого сектора содержат дорожку и сектор продолжения каталога.
После этих трех байт идут 8 зарезервированных байт, а затем поле описателей файлов.
На каждый файл отводится по 36 байт, а именно:

Только вот неизвестно: то ли один описатель файла может находиться на разных секторах, то ли остаются свободные байты.
И насчет сегментации. Каталог явно может быть сегментированным. Но вот файлы... В вышеупомянутой книге содержится не совсем понятное объяснение. Первые два байта описателя могут содержать ссылку на ссылку размещения файла. Т. е. они указывают на расположение (дорожку и номер) того сектора, в байтах 13-ом и 14-ом какового содержатся дорожка и сектор, где начинаются или продолжаются данные. Но тогда как это различить? Как определить занятость секторов при записи нового файла, и вообще почему 13-ый и 14-ый байты сектора, отведенные
по данные файла, используются для других целей? Может быть это особые сектора, содержащие только ссылки, или на это используются пропавшие байты в секторах каталога? Впрочем, вопрос о сегментации файлов, хотя и является самым сложным, является также наименее освещённым в литературе. Как показали дальнейшие исследования дисков от APPLE 2, их формат действительно совместим или совпадает с вышеприведённым. Кодировка текста в каталоге (и не только): большие буквы ASCII + + 128.

DOS 2.6 (РАДИО-86РК)

Основным достоинством РАДИО-86РК является подробное описание в массовом радиожурнале. И описание его ДОС найдено там же: РАДИО 93 г., номер 1, стр. 13-16.

Ну так вот... 80 дорожек: чётные (0, 2, 4...) - сверху, нёчетные - снизу. Пять секторов по 512 байт - FM метод записи. Порядок секторов: 0,3,1,4,2.

Карта и каталог диска находится на 32-ой дорожке. Карта - на 0-ом её секторе. Это 160 байт, описывающих занятость секторов на соответствующей дорожке. Каждый из пяти младших битов отвечает за свой сектор.
Например, первой дорожке соответствует первый байт этого сектора. Пусть значение нулевого байта равно #1E (11110 bin).

Это означает, что заняты сектора 1,2,3,4, но не 0. Значение #1F (11111 bin) означает, что все сектора заняты. #0B (01011 bin) -сектора 0,1,3 и т.д.
Затем идёт каталог диска. На каждый файл выделяется 28 байт:

T/S LIST или, точнее, TRACKS/SECTORS LIST - список дорожек и секторов, на которых содержится нужный файл. Первые два байта этого сектора содержат ссылку на продолжение этого списка, иначе это нули. Далее идет некоторое количество пар байт (а точнее, это количество содержится в описателе файла). Каждая пара содержит дорожку и номер очередного сектора файла. Ну, а признаком окончания списка служат два нуля. Не могу только сказать, как располагаются описатели файлов по секторам: то ли впритык, и тогда один описатель может быть на двух разных секторах, или же в каждом секторе каталога остаются неиспользованные байты. Однако в любом случае каталог оставляет немало байт для всякого секретного использования.

SPDOS (ОРИОН-128)

Описание из журнала РАДИО № 2/93.

Система эта предназначалась для быстрой дискофикации ОРИОН'а, при совместимости со старым ПО. В дальнейшем она была заменена на более распространенную систему CP/M. Но вопрос о её профессиональности, совместимости и прогрессивности слишком отдалён от темы и в дальнейшем может быть изложен лишь касательно формата диска. А пока речь пойдет про её предшественницу. Две стороны, 80 дорожек. Пять секторов по 1024 байта. Все счисление ведется в блоках - секторах по 1024 байта,- и положение на диске задается смещением в этих блоках. Вся нулевая дорожка зарезервирована: блоки 0-9 не используются. На первой находятся два каталога вместе с картой диска (по 2 Кб): резервный на секторах 1 и 2 (блоки 10 и 11) и основной на секторах 6 и 7 (блоки 15 и 16). И на дорожках с 2-ой по 79-ю (блоки 20 - 799) размещается область данных - 780 Кб. В каталоге находится до 78 описателей файлов, по 16 байт в каждом, а именно:

Замечу, что 78*16=1248. Это означает, что в каталоге осталось ещё 800 байт места. И вот 780 из них используются для размещения таблицы размещения файлов.
Если её байты условно пронумеровать от 20 до 799, получим прямое соответствие между каждым байтом и блоком на диске. Если значение какого либо байта равно #E5, то соответствующий ему блок свободен, а если его значение - #FF, то он дефектный. Иначе его значение будет от 1 до 78, в соответствии с тем, какому файлу этот блок принадлежит, или, точнее, номеру позиции этого файла в каталоге.
Таким образом, совсем не нужно записывать положение первого сектора (блока) файла или создавать таблицу расположения секторов каждого файла. Для чтения файла нужно определить его порядковый номер в каталоге, если он неизвестен, а затем сканировать таблицу расположения файлов, и, найдя искомый номер, загрузить блок, соответствующий смещению от начала таблицы, не забыв прибавить 20. И продолжать такое сканирование-считывание, пока весь файл не будет загружен.

А для записи нового файла нужно в этой таблице искать свободные блоки, соответствующий им байт будет равен #E5. Естественно, надо пропускать занятые и дефектные блоки. И при верификации записанного файла можно даже параллельно помечать обнаруженные дефектные сектора!

Примечательна возможность создания фиктивного файла - только в каталоге. Но этот бит обязательно нужно учитывать, дабы не искать блоки, принадлежащие несуществующему файлу. Также надо не забыть о большом количестве свободного места на начальных дорожках. Свободное место можно с толком использовать для различных защит и даже вирусов, хотя, к сожалению, максимально возможный размер секторов не позволяет форматировать секторы, изменяющие какие либо данные в памяти скрыто от чужих глаз.

В итоге можно только сказать: зачем использовать старую систему CP/M, если эта система совместима со старыми наработками и её развитие могло бы привести к лучшим результатам? Это я к тому, что на СПЕККИ такая же ситуация с операционками, и если уж кто хочет сделать новую, то пусть учтет подобную ситуацию.

MX-DOS

Эта ДОС предназначена для компьютера Специалист-МХ. Образец эмулятора этого компьютера можно взять по адресу: [http://avshsoftware.by.ru/download/spmx_v42.zip]
А образец диска (один диск в двух частях): [http://avshsoftware.by.ru/download/bst_mx0_0.zip]
[http://avshsoftware.by.ru/download/bst_mx0_1.zip]
Разбивка диска стандартная: 162 дорожки с двух сторон, 5 секторов, по 1024 байта каждый.
Опознать диск можно по стрингу "Dos_MX V3.6", который находится по смещению 5, в нулевом секторе нулевой дорожки.
Файловая структура дисков весьма необычная: файл позиционируются с точностью до байта. Дело в том, что файловая система основывается на структуре ROMDISK'а для этого компьютера.

Структура заголовка файла:

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

RT-11 (Рафос, Фодос)

Прежде всего попались мне в руки диски от ДВК. Но они были совершенно нечитаемые, несмотря на то, что об их совместимости со стандартными форматами разбивки упоминалось не раз. Чуть больше повезло мне с дисками от УКНЦ. Читались они просто прекрасно, углядывалось имя диска, загрузчик... Но не было никакого намека на присутствие каталога. В дальнейшем у меня появился доступ к этим машинам и специалист по ним. Но в документах на них я не нашёл никакой пользительной информации на нужную тему и, даже отформатировав диск и записав на него известные файлы с известным каталогом, я не нашёл его на диске как таковой. Была только какая-то таблица, структурой напоминавшая то ли каталог, то ли таблицу размещения файлов, которой, кстати, быть не должно, т. к., по полученной информации, структура диска напоминает СПЕКТРУМ 'овский. Потом у меня завёлся эмулятор ОС RT-11, совместимой с форматом FODOS на УКНЦ, да ещё и конвертилка с дисков такого формата. Но опять же ни доки, ни каталога, а только чушь всякая. В общем, вопрос тут остался открытым, и пока имелись ещё кое-какие надежды.

Целый год я надеждами этими жил, а потом опять пошёл в библиотеку. Перерыл целую кучу книжек. Вначале выяснилось, что, в общем-то, все идет от этой самой RT-11, а от неё "откопировались" всякие там РАФОС, РАФОС 2, ФОДОС, ФОДОС 2, ОС ДВК и чего-то там ещё - в общем, всё то, что использовалось на старых машинах СМ и серии "Электроника". На них, как, впрочем, и на MS-DOS, и на CP/M, более важной казалась программная совместимость. В результате - опять секреты, а может - стыдно кому за содранное с иностранных образцов.

Словом, про диски от сих совместимых ОС сказано мало. Самую подробную информацию я отыскал в справочнике:
Операционная система СМ ЭВМ РАФОС Составители: А.И. Валиков, Г.В. Вигородчик, А.Ю. Воробьев, А.А. Лукин под общ. ред. В.П. Семина. М:Финансы и статистика, 1984 г. - 207 с.

Оказывается, система РАФОС может ещё работать с дисками ДОС СМ и ЕС ЭВМ. Скорее всего, это тоже влияет на хитрый формат каталога. Почему его нигде не видно? Да дело в том, что все символьные строки упакованы в хитрый (и, похоже, старющий) такой код - RADIX-50. Практически это небольшая компрессия: три буквы - в два байта. Но набор букв, между прочим, состоит не из 32 символов (по пять бит на букву, да ещё бит в паре байт остается, а раскодируется всё простым тебе сдвигом - для каталога вроде достаточно). Но нет, тут используется набор из 40 символов: букв, цифр и три спецзнака. Вроде, нужно 6 бит на символ - в два байта не втиснуться. Но это - если работать сдвигами, а если умножением - то получится:

40*40*40 = 64 000 - вполне двухбайтное число.
И получаем:
Код_Первой_Буквы*1600 +
+Код_Второй_Буквы*40 +
+Код_Третьей_Буквы = Более #FFFF никак не получится, если код буквы лежит в диапазоне от 0 до 39 !
У "пробела" код - ноль, у букв A-Z - коды от 1 до 26. Далее идут спецсимволы: "точка в кружочке", по-нашему "$" - код 27, "точка" - код 28, "/" - код 29 - этим символом замещают символы, не имеющие аналогов в коде RADIX-50. Ну, а цифры "0"-"9" - коды 30-39.

Кодирование и декодирование осуществляется операциями умножения и деления. Дальше - проще.
Весь диск разбит на блоки по 512 байт, на УКНЦ это - размер сектора, и нумеруются эти блоки от нуля и до некоторого максимума - общего числа блоков. Число это зависит от количества дорожек и секторов на них: 10 или 9.
Блок 0 - загрузочный сектор. Начинается он с кода #A0, есть и другие примечательные байты, но как по ним определять количество сторон, дорожек и секторов - пока неизвестно.

Блок 1 - содержит: в конце - имя пользователя, диска и операционной системы, а в начале - таблица замещения дефектных блоков. Как в ней кодируются эти плохие блоки - нигде не написано, кроме того, там присутствуют кое-какие всегда постоянные байты.

Блоки 2-5 - сама система или пусто, если диск не загрузочный. Начиная с блока 6 находится каталог. Он состоит из одного или нескольких сегментов - каждый по 1024 байта - 2 блока. Количество сегментов может задаваться при инициализации диска. Принято, что вся информация в каталоге двухбайтная - всего 512 слов (пар байт) в сегменте.
Первые 5 слов - служебные:

Могут быть и дополнительные байты. Положение файла на диске приходится определять сложением длин файлов, начиная с первого файла данного сегмента и по файл, идущий перед заданным, плюс 5-ое слово данного сегмента. Похоже на мотание ленты в магнитофоне по счётчику; впрочем, данная ОС ведёт своё летоисчисление с ленточных времен. Напоследок добавлю, что в ОС РАФОС возможны виртуальные дисководы - файлы, структура которых повторяет разбивку диска.
Это только подтвердилось, когда я немного ознакомился с БК-11М, на котором тоже можно запустить эту систему. Но пока это только небольшие обмолвки в документации на другие системы. Посему не известны ни подробности функционирования системы на БК, ни форматы первых блоков системы.

АО-ДОС версии 2.02

Формат её каталога совместим с MicroDOS, NORTON, NORD, MK-DOS - имеются в виду другие БК 'шные системы. Диск может быть 40/80 -дорожечным, 1/2 -сторонним. 10 или 9 секторов по 512 байт. Проблема заключается в существовании двух вариантов дисковых форматов: расширенного и стандартного. Последний формат как раз и исследовался, и похоже, что при этом используется только определённая разбивка: 10 секторов.

Ещё одной проблемой было то, что для БК основной системой счисления является восьмеричная, каждый раз на это нужно обращать внимание.
Положение на диске задается в смещениях в блоках по 512 байт.
Пересчёт ведётся по формулам:
ДОРОЖКА = INT(СМЕЩЕНИЕ/10)
СЕКТОР = СМЕЩЕНИЕ-ДОРОЖКА*10
Впрочем, положение на диске легко определяется "на глаз": первые две цифры десятичного числа - дорожка, а последняя - сектор. На нулевом блоке (0 дор. 0 сект.) размещается системная информация и начало каталога. Первые 4 байта используются только для загрузочного диска, у него:

Структура его весьма оригинальна. Несмотря на то, что в системе могут создаваться каталоги с уровнем вложенности как минимум до 128, все записи о всех файлах на диске находятся в едином каталоге. Каждый подкаталог, вне зависимости от уровня вложенности, имеет свой индивидуальный номер, записанный в описателе данного каталога. И каждый файл или подкаталог имеет ссылку на свой родительский каталог.

На запись в каталоге отводится 24 байта:

Как видим, нет никаких признаков, что файлы и каталоги могут быть сегментированными. Да и в её описании говорится: "Система использует алгоритм записи файла, позволяющий оптимально использовать дисковое пространство, не прибегая к помощи утилит сжатия, и снимающий необходимость контроля за состоянием каталога диска". Тайна этого алгоритма мною не раскрыта. На диске нет ничего похожего на карту диска. Возможно, система пытается записать новый файл на место удалённого, подходящего по размерам, и какая-то часть диска пропадает зря.
И действительно, стирая и записывая файлы, я убедился, что меньшие по размеру файлы записываются на место уже удалённых, больших их по размеру. Если же файл не помещался, запись происходила на новые сектора, уменьшая свободное дисковое пространство, и запись добавлялась в конец каталога. А если записывались маленькие файлы, то их описатель занимал место удалённого, и, если после этой операции оставалось место от удалённого файла, то запись о поместившемся новом файле добавлялась после старой. Таким образом, файлы шли в последовательности положения их относительно начала диска. Оставшаяся от удалённого файла "дырка" между блоками могла использоваться для записи помещающихся в неё файлов, хотя в каталоге о ней записи не было. Кроме того, в конце каталога был найден эдакий конечный файл. Первые два байта его были равны #FF. Байты 16 и 17 у его описателя содержали номер первого свободного блока, а байты 18 и 19 - количество свободных блоков. Эту информацию можно использовать для работы с диском.

Осталось только сказать, что система автоматически создаёт полную копию нулевой дорожки, которая располагается на дорожке номер 1. Причём на обоих последний сектор, похоже, не используется, поскольку он заполнен байтом #00, тогда как неиспользуемое место в каталоге заполнено байтом #F6.

NEWDOS

Привожу одно письмо. В нём предлагается новый формат диска для Спектрума.

"Привет All !

Я тут pазpаботал новый фоpмат хpанения имени файлов на диске и хочу, чтоб вы его посмотpели и оценили все возможные недостатки. Может быть, что добавить или убpать нужно, как на Ваш взгляд Hа диске может находиться либо 64 файла, либо 64 диpектоpии по 16 файлов в каждой, итого максимум 1024 файла на один диск. Может быть и pазбpос файл-диpектоpия, т. е. не что-нибудь одно, а всё вместе. В созданной уже диpектоpии создать ещё одну нельзя, а можно записать 16 файлов. Эти огpаничения сделаны для облегчения pаботы в последующем пpи написании какого-либо софта под этот фоpмат, а также для уменьшения занимаемого дискового пpостpанства.
За счёт этого фоpмата мы теpяем ещё 9 доpожек, т. е. first track на диске будет 10.
Тепеpь опишу фоpмат названия диpектоpии и файла:

DIRECTORY;

+#00 - file mask:
#00 - end of catalog or directory;
#01 - deleted file or directory;
#02 - directory;
#03 - file don't delete;
#04 - hidden file or directory.

+#01-#14 - directory name of 20 symbols;
+#15-#17 - type of 3 symbols;
+#18-#1A - create date DD-MM-YY;
+#1B - not used; !!!
+#1C - files in directory;
+#1D - directory length of sectors;
+#1E - first sector;
+#1F - first track.

FILES:

+#00 - file mask:
#00 - end of catalog or directory;
#01 - deleted file or directory;
#02 - directory;
#03 - file don't delete;
#04 - hidden file or directory.

+#01-#14 - file name of 20 symbols;
+#15-#17 - type of 3 symbols;

+#15= 'B'-'BAS' for basic file
'C'-'COM' for code file
'D'-'DAT' for data file

+#18-#19 - start address file;
+#1A-#1B - bytes length file;
+#1C - number directory for this file;
+#1D - lenght of sectors;
+#1E - first sector;
+#1F - first track.

То бишь, тепеpь имеем 20 символов имени, 3 символа тип и кучу файлов на диске.
Как вы на это смотpите? Лично я завтpа начинаю писать пеpвоначальную пpогpаммную поддеpжку, котоpая впоследствии станет одной из доpаботок нового DOS'a, а Phantom Ltd начнет писать COMMANDER под этот фоpмат."

А вот и ответ на это письмо:

"Я бы на твоём месте сделал бы следующее: 512 байт на сектор, 10 секторов на дорожке, формат диска MS-DOS. Это сразу решит вопрос переносимости файлов между всеми остальными досами. Кроме того, нет ограничений на количество файлов на диске - ограничено только количество файлов/директорий в корневом каталоге.
Подумай о пользователях HDD - им опять резать винт на ломтики по 640 Кб?
Теперь насчёт формата каталога. Берётся оригинальный формат MS-DOS, и в него вносятся следующие исправления: вместо времени создания файла записываем стартовый адрес (такой вариант давно и успешно применялся на БК). Кроме того, в MS-DOS в записи о файле пустует ещё 10 байт, так что развернуться можно.

IK> Эти огpаничения сделаны для облегчения pаботы в последую IK> щем пpи написании какого-либо софта под этот фоpмат, Софт нужно писать под операционку, а не "под формат".

IK> +#15= 'B'-'BAS' for basic file
IK> 'C'-'COM' for code file
IK> 'D'-'DAT' for data file

Планируется ли использование нового доса как замены TR-DOS? Если нет, то про бейсик можно сразу забыть.

IK> +#1E - first sector;
IK> +#1F - first track.
Зачем повторять чужие ошибки? Линейное расположение файлов сейчас не актуально.
__
__/ / Powered [pepsi inside]
\_\/ by MOTOROLA [smoking suxx]"

Надеюсь, тут суть понятна без особых комментариев, но всё-таки, поддерживать эти форматы или не поддерживать???
Как заметил Time Keeper, письмо это взято из конференции REAL. SPECCY, и подобных писем там немало. Как по его личному мнению, так и по мнению множества других людей, самый лучший формат для винчестера - это MS-DOS FAT, т.к. будет большая совместимость с ПЦ - можно легко переносить информацию в виде ОБРАЗОВ ДИСКОВ и подключать их к операционной системе тем или иным образом (напрямую, через RAM-Disk).

Сделаю и я небольшую заметку: винчестер режут на ломтики как раз на БК, каждый ломтик - образ диска - именуется своей буквой, большой или маленькой. И вообще, если работать с винтом, то надо и на ломтики делить (для старых систем, и программы поддержки контроллеров винта на Спеке делают примерно так же) и новый формат диска придумывать - для новых операционок. А уж будут ли ломтики эти в виде файлов или раздельчиков - вопрос к разработчику, уже сейчас реализован и тот, и другой вариант. Таким образом, описание файловой системы, предлагаемой выше, можно рассматривать и как предмет дискуссии, так и призыв к действию. Здесь он присутствует как практический пример и пособие - на тот случай, если кто-то этот формат вздумал поддерживать. Но самое интересное: автор этого опуса откликнулся, и его личность установлена: Himik's ZxZ.

AN-DOS

Самое время вспомнить опять о БК. AN-DOS и есть та система на БК, о которой вспоминали чуть выше. Она действительно использует систему размещения файлов при помощи FAT, как у MS-DOS (и ASC SOUND MASTER ).
В структуре диска произошли лишь незначительные изменения. В загрузочном секторе для команды перехода на загрузчик используются не 3, а 4 байта: #A0, #00, #1E, #01, и далее идёт стринг "ANDOS". Затем всё как обычно, включая метку диска и признак "FAT12". Только разброс параметров: всегда по две FAT, размером по 1200 байт (424 кластера по 4 сектора),размер каталога - 7 секторов.
Кроме того, используется только корневой каталог. Подкаталоги кодируются в стандартной для БК системе. У каждого каталога и подкаталога есть свой индивидуальный номер. А у каждого подкаталога и файла есть ссылка на номер их каталога-прародителя (в котором они находятся). Поэтому произошли небольшие изменения в структуре каталога:

Структура FAT системы аналогична MS-DOS, а структура подкаталогов похожа на AO-DOS. Т.е. НА ДИСКЕ имеется один-единственный каталог. У каждого подкаталога в нём есть свой порядковый номер в резервируемой области хедера, промаркирован он как метка диска, и MS-DOS его не кажет. А у каждого файла в хедере хранится номер подкаталога, где он находится. Разбивка эта является чисто визуальной: если система пишет файл и ищет - нет ли уже файла с таким же именем,- то она сканирует все файлы, не глядя на подкаталоги.

ЭПИЛОГ

На этом я пока заканчиваю своё повествование. В разное время я имел доступ к дискам и компьютерам самых разных систем ,а также к эмуляторам. И здесь изложены, пожалуй, далеко не все известные мне форматы дисков.
Многое я узнал при помощи эмуляторов на IBM ПЦ. Надо сказать, при их помощи можно изучить такие системы, которые мало кто видел вживую, или такие, чьи носители информации не способствуют их изучению на СПЕКТРУМ'е.

Например, в компьютере COMMODORE 64 используется хитрый дисковод, подключенный к специальной шине компьютера шестью проводами. Оригинальны и форматы диска: на дорожках 1-17 располагается 21 сектор по 256 байт, 18-24 - 19 секторов, 25-30 - 18, и на остальных по 17, причем дорожки 36-40 - нестандартные. Поэтому там используются виртуальные диски и файлы - в виде файлов формата MS-DOS. Эмулятор имитирует работу настоящих дисководов, картриджей и кассет, используя информацию из этих файлов. Но при этом возможно подключение настоящих дисководов и кассет при помощи принтерного порта. Существуют даже специальные программные оболочки, которые позволяют объединять стандартные и нестандартные устройства под общим интерфейсом и производить удобный перенос информации между ними. А ещё существуют и совместимые дисководы, винчестер и даже конверторы из/в MS-DOS, но, насколько я понял, они гораздо более редкие.

Поэтому только стандартными просмотрщиками MS-DOS можно изучать виртуальные диски.

Хотя, например, компьютеры MSX используют диски, весьма похожие на MS-DOS 'овские, да и автор ОС обоих систем, вроде, общий, несмотря на то, что MSX 'ная, вроде бы, называется CP/M. Виртуальные же диски не всегда являются полной копией реальных и, может быть, мне захочется копаться на реальных при помощи СПЕКТРУМ'а.
А форматы кассет и картриджей вообще не поддаются нормальным исследованиям. Правда, кому нужно старьё 1980-1984 годов? Ещё попадался мне компутер такой - ATARI XE 130. Был при нём и дисковод, и дискеты, и даже кое-какая русскоязычная документация. Но дисковод был внешний, соединительные кабели куда-то делись. Дискеты читались с трудом, а кроме того, они использовались как две односторонние. Короче, чего я там на них ни прочитал, но каталога нигде не нашёл. А в документации вот как раз про него - ни слова. В общем, если найдется какой специалист, то продолжим об этом разговор. А то, что я уже начал писать по сию тачку, к сожалению, стёрлось. Как показали копания в эмуляторских образцах - каталог содержится где-то в середине диска и имеет довольно простую структуру. Имеются образцы и немного документации про диски SAM Coupe' и DiSCIPLE Plus. Их особенностью является порядок следования логических дорожек: дорожки 0-79 находятся на одной стороне диска, а дорожки 80-159 - на другой. Но малое количество документации не стимулирует детальное их исследование.
Для Opus Discovery нет даже образцов, а только несколько утилит с краткой документашкой и дизассамблер ПЗУ. И опять же - ненаю, стоит ли с ними возится.

И ещё, читал я хорошее описание старинного такого компа: ИСКРА 224 называется. Кое-кто говаривал, что работал с ним. И стоило бы о нём рассказать, хотя бы из принципа о необходимости распространения полезной (ли) информации. Да вот только я даже не знаю, подключаются ли к нему FDD 5'25", и насколько он сейчас распространён, чтобы им кто-либо заинтересовался, хотя бы из праздного интереса.

То же, впрочем, можно и сказать о всех вышеперечисленных тачках. Но я могу с уверенностью сказать, что кто-нибудь каким-либо образом имеет к ним доступ, а о других подобных машинах не знает или не хочет знать, несмотря на то, что популярность некоторых из них даже на текущий момент может быть весьма велика в определённых слоях. И доступность свежего программного обеспечения к ним, а также подробная информация о них и кооперирование с более мощными и современными системами помогут продлить интерес к ним, особенно если переход на вышеупомянутые мощные системы по каким-либо причинам невозможен.

И информацией можно и нужно делиться про все платформы, и кооперированию их как раз и помогают различные описания всевозможных стандартов и форматов. Особо важно, по-моему, рассказать про ПЦ 'шные форматы. Но дело в том, что такие интересные вещи зачастую остаются без внимания теми, у кого они есть, но их долго ищут те, которым они нужны. А те, кто может что-то сказать по поводу дисков от вышеперечисленных, а также и других компьютеров, могут писать об этом мне, NUTS 'у. Я с удовольствием приму все дополнения, добавления, поправки, исправления и критику. Ред.: Не забудьте и мне чиркнуть письмецо, в редакцию. Было бы очень полезно издать справочник по разного рода форматам в бумажном виде. Уже сейчас я собрал более 300k ZX-публикаций на эту тему.

Благодарности

Как уже внесшим вклад в это пользительное дело, хочется сказать большое спасибо:
Unbeliever'у - за его CD-R, содержавший, в частности, разный эмуляторный софт и, соответственно, авторам этого софта;
Ивану Рощину - за его форматер;
Евдокимову Алексею - за его программу 'AFRODITA 3.0'; и всем тем, кто помогал мне форматировать диски в разных
системах, а в частности:
Melted Snow (сотоварищи) - Profi CP/M (Concurent BIOS);
Ice'DI'Griz/3umph (сотоварищи) - Profi DOS (когда-то не продававшаяся);
Capry/STALL - информация о CP/M для Спектрум-совместимого ПК "Кворум".

Wanted !!!!

Информация о дисках всех систем и платформ, особенно на БК и ДВК (CSI, RT-11, ОС ДВК) и ZX Spectrum (D80, Opus Discovery). С целью апгрейда данного справочника обращайтесь к распространителям или по адресу:
606015, Нижегородская обл. г. Дзержинск пр. Ленина д.6 кв.8 Полякову Алексею
mailto: nuts@pochtamt.ru
Естественно, апгрейдеры будут тут упомянуты. Можно такое дело делать и по музакам, архивам и пр.

Nuts, 1998-14.10.2001 гг. Дата последней редакции: 18.07.2005 (Alone Coder)

Купить платы, наборы микросхем на Орион-128, КР565РУ5В, КР565ру7В, к565ру5г AU, к565ру7г Au в позолоте, куплю микросхемы

Полезные и интересные статьи

На предыдущую страницу На главную страницу На следующую страницу