Virtual Worlds #01 31 декабря 1999

Программирование

Техпомощь - Dos Review 2: материал по формату дисковых операционных систем ПК "АГАТ", Радио-86РК, SP-DOS, БК-0011М.

 ┌────────────────────────────┐
 │ ░▒▓▓█ DOS REVIEW #01 █▓▓▒░ │
 └────────────────────────────┘

  Но    на   этом   разговор   о
нетрадиционных операционных сис-
темах  далеко не кончается. Дело
в  том,  что в последнее время я
очень  полюбил  изучать  форматы
разных  дисков при помощи диско-
вых докторов, эмуляторов и глав-
ное  -  литературы.  Я изучал и,
надеюсь,  буду  дальше  изучать,
форматы    разных    дисков.   В
частности это: CP/M на ПК PROFI,
"КОРВЕТ",  ROBOTRON-1715  и др.,
ОС   ПК   "АГАТ",  "РАДИО-86РК",
"ОРИОН-128", БК-0011М, УКНЦ.

  Надо сказать, нашел немало об-
щего и интересного. Но не всегда
информация  была окончательной и
подробной,  а  чаще  наоборот  -
крайне        невразумительной и
противоречивой, как и с IS-DOS.

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

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


           ПК "АГАТ"

  Все данные о нем я почерпнул в
книге:

    Мымрин М.П. Конструкция,
 применение, программирование и
      ремонт ПЭВМ "АГАТ".
   М:Машиностроение, 1990 г.

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

  Его  отличительными особеннос-
тями являются:

  1)    Построен,    несмотря на
отечественное  происхождение, на
импортном проце 6502. Тем не ме-
нее,   его  совместимость  с  ПК
APPLE-][,  по моему, практически
нулевая.

  2)  Контроллер  дисковода  его
программно  -  аппаратный. Схема
только читает отдельные байты, а
дешифруется все программно - лю-
бая защита - не проблема; Железо
только считывает текущий байт, а
всякие  там  метки,  сектора, FM
или MFM разбираются уже програм-
мным драйвером.

  3)    Оригинальная    графика:
256*256  моно, 128*128 - 16 цве-
тов  (8  КБ),  64*64  (!!!) - 16
цветов   (!!!)   (2   КБ   !!!).
Примечательно,  что  в  комплект
прилагается  цветной монитор, но
он  отображает только 8 (восемь)
цветов.

  4)  Память  его расширяется до
768 КБ

  Казалось  бы,  его  контроллер
дисковода  позволяет  копировать
любые  защищенные  диски. Что ж,
может  быть и так, только сперва
надо  бы  подключить современные
дисководы,  да  еще не известно,
справятся ли с ними аппаратура и
успеет   ли   процессор  считать
плотный   поток   данных.   Ведь
реально   поддерживается   такой
формат диска: 35 дорожек ( а мо-
жет   быть   физически-то  и все
40  ),  на каждой по 10 секторов
по  256  байт.  И, скорей всего,
одна сторона.

  Ну  вот, а из этих дорожек ну-
левую,  первую и вторую занимает
ДОС, а каталог находится в самой
середине диска - на 17-ой дорож-
ке. Причем, все указывает на то,
что  секторы его идут в обратном
порядке:  начинается он на 15-ом
секторе и, если он помещается на
одной  дорожке,  оканчивается на
0-ом.

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

  После  этих  трех  байт идут 8
зарезервированных  байт, а затем
идет поле описателей файлов.

  На каждый файл отводится по 36
байт, а именно:

  1  байт  -  номер  дорожки и 1
байт  - номер сектора размещения
файла.

  Кроме того, 1-ый байт описате-
ля удаленного файла увеличивает-
ся   на   160  и  данные  о  нем
сохраняются.  Отсюда  видно, что
теоретически  можно использовать
и  дисководы  на 80 дорожек, или
двухсторонние   на   40,  но  не
80TR/DS,  или  уж файлы при этом
удаляются по-другому.

  1  байт - тип файла:
     2 (1-ый бит) - Бейсик
     4 (2-ой бит) - двоичный
     0 - текстовый
     7-ой бит - защита от записи

  30 байт - имя файла

  2 байта - длина файла в секто-
рах.

  1 байт - резерв

  Только  вот  неизвестно: то ли
один   описатель   файла   может
находится на разных секторах, то
ли остаются свободные байты.

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


           Радио-86РК

  Продолжим  рассмотрение диско-
вых  систем.  Теперь речь пойдет
об весьма простой и довольно по-
дробно описанной системе DOS 2.6
от  старого, почти ровесника ZX,
компьютера  РАДИО-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 байт:

┌────────┬─────────────────────────────────────────────────────┐
│СМЕЩЕНИЕ│ЗНАЧЕНИЕ                                             │
├────────┼─────────────────────────────────────────────────────┤
│0       │дорожка                                              │
├────────┼─────────────────────────────────────────────────────┤
│1       │сектор следующего сектора каталога Если 0-ой байт    │
│        │равен нулю, то это значит, что продолжения не будет  │
├────────┼─────────────────────────────────────────────────────┤
│2-5     │Резерв, заполнен #00                                 │
├────────┼─────────────────────────────────────────────────────┤
│7-16    │Имя файла, остаток заполнен #00                      │
├────────┼─────────────────────────────────────────────────────┤
│17      │Т.н. нулевой файл - если файл удален, то первый байт │
│        │его имени равен #FF, а сюда записывается первая буква│
│        │его имени.                                           │
├────────┼─────────────────────────────────────────────────────┤
│18-20   │Расширение файла                                     │
├────────┼─────────────────────────────────────────────────────┤
│21,22   │Дорожка и сектор размещения т.н. T/S LIST (см. ниже) │
├────────┼─────────────────────────────────────────────────────┤
│23,24   │Адрес загрузки                                       │
├────────┼─────────────────────────────────────────────────────┤
│25,26   │Длина в секторах                                     │
├────────┼─────────────────────────────────────────────────────┤
│27      │Атрибуты файла                                       │
└────────┴─────────────────────────────────────────────────────┘


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

  Не  могу  только  сказать, как
располагаются  описатели  файлов
по  секторам:  то  ли впритык, и
тогда  один описатель может быть
на  двух разных секторах, или же
в  каждом  секторе  каталога ос-
таются  неиспользованные  байты.
Однако,  в  любом случае каталог
оставляет немало байт для всяко-
го секретного использования.


             SP-DOS

  И еще одна подробно описанная,
но  весьма экзотичная система из
журнала   РАДИО.  Это  SPDOS для
компьютера  ОРИОН-128.  Про  нее
рассказывается  в  номере  2  за
1993 год.

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

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

  В  каталоге  находится  до  78
описателей  файлов  по 16 байт в
каждом, а именно:

  Байты  0-7:  Имя  файла,  если
первый  его  байт  равен #E5, то
этот  файл удален, а если - #00,
то значит каталог окончился.

  Байты  8,  9:  Адрес  загрузки
файла.

  Байты  10,  11: Размер файла в
байтах.

  Байт 12: Атрибуты файла:
 7-ой бит - защищен от записи
 4-ый бит - файл создан фиктивно
- только в каталоге.

  Байты 13, 14 и 15 зарезервиро-
ваны.

  Замечу,  что  78*16=1248.  Это
означает,  что  в каталоге оста-
лось  еще 800 байт места. И вот,
780   из   них  используются для
размещения   таблицы  размещения
файлов.

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

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

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

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

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




            БК-0011М


  Теперь  приступим  к компьюте-
рам, которые я изучал при помощи
эмуляторов на IBM ПЦ. Особо при-
мечательным является то, что они
существуют  и  для отечественных
компьютеров.

  Таковыми являются и компьютеры
серии  БК.  Кое  кто  называл их
первоисточником  демок  и  элек-
тронных  газет. Что касается ме-
ня,  то я изучал эмулятор самого
мощного  ПК  из этой серии, име-
нуемого БК-0011М ( v0.7 (C) 1995
by  Vicious ) . Не знаю, как там
на  счет  газет и винчестера, но
почти  все демки в его комплекте
переданы  со  СПЕКТРУМА, если не
полностью,  как  LIRA ][, то, по
крайней мере, идея и музыка.

  Вот  примеры того, что было на
этом диске:

"NEWN2M" ,
"MAXAMIZZ" ,
"DYNA BLASTER" ,
"NO LIMIT"
"POPCORN"

все COPYRIGHT XPEHSOFT и FUXOFT,
после каждого было:

SONG COMPILER COPYRIGHT (C)
RDC SOFTWARE 1993y...

  Интересно  посмотреть ЛИРУ или
поиграть  в CYBERNOID 2, в четы-
рех цветах, но из палитры в 16 и
каждая точка своим цветом.

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

  На  БК,  как  оказывается, су-
ществует  немало операционок, но
они   совместимы   между  собой.
Приводится  приложенное к эмуля-
тору  описание  дисковой системы
АО-ДОС версии 2.02.

  Формат ее каталога совместим с
MicroDOS, NORTON, NORD, MK-DOS -
имеются  в  виду  другие БК'шные
системы.

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

  Еще  одной  проблемой было то,
что  для  БК  основной  системой
является  восьмеричная  и каждый
раз на это нужно обращать внима-
ние.

  Положение  на диске задается в
смещениях  в блоках по 512 байт.
Пересчет ведется по формулам:

ДОРОЖКА=INT(СМЕЩЕНИЕ/10)
СЕКТОР=СМЕЩЕНИЕ-ДОРОЖКА*10

  Впрочем,  положение  на  диске
легко  определяется  "на  глаз":
первые   две  цифры  десятичного
числа  -  дорожка, а последняя -
сектор.

  На  нулевом  блоке  ( 0 дор. 0
сект.  )  размещается  системная
информация  и  начало  каталога.
Первые четыре байта используются
только для загрузочного диска, у
него: 0-ой байт - код 160, байты
2 и 3 - коды команды перехода на
загрузчик.

  4-ый  байт определяет тип фор-
мата:  если  там  26,  то формат
расширенный, а на изучаемом мною
диске там было число 32.

  Поэтому  расскажу об отличиях.
Как  свидетельствует  документа-
ция,  при расширенном формате 5-
ый  байт описывает разбивку дис-
ка. Там содержится размер дорож-
ки  диска в секторах, плюс уста-
новлен   7-ой   бит,  если  диск
односторонний.  Байты  6 и 7 при
этом  содержит  размер сектора в
байтах.  Байт 8 - количество до-
рожек     и    10-ый    зачем-то
зарезервирован.

  В моем варианте формата я уви-
дел  на  месте  этих байт стринг
"AO-DOS".

  Далее  соответствие восстанав-
ливается.  Начиная  с  байта  12
размещается   имя   диска  (  12
байт   ),  которое  показывается
оболочкой  DOS  SHELL  для  этой
системы.  Байт  со  смещением 24
содержит  количество  записей  в
каталоге,  Байты 26 и 27 - номер
первого свободного блока на дис-
ке.

  Примечательны  байты со смеще-
нием  256 и 257 на том же блоке.
Там содержится байты #2E и #A7 -
число 123456 в восьмеричной сис-
теме.   Это  признак  данной ОС.
Также  обнаружена недокументиро-
ванная  пара  байт  со смещением
310  - количество свободных бло-
ков на диске.

  Ну  и начиная с 320-го байта и
далее находится каталог.

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

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

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

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

  На практике оказалось, что при
удалении  файлов  оба  эти байта
принимают значение #FF.

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

  Байты  16  и 17 содержат номер
первого  занимаемого файлом бло-
ка.  Для  подкаталога это всегда
число #14.

  Байты  18  и 19 содержат коли-
чество   блоков,  расходуемых на
файл. Для подкаталогов оно всег-
да равно нулю.

  Байты  20  и 21 содержат адрес
загрузки,     который     всегда
уменьшается до четного числа.

  И,  наконец, байты 22 и 23 со-
держат   длину   файла,  которая
должна быть меньше 32768.

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

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

  Кроме  того,  в конце каталога
был найден эдакий конечный файл.
Первые  два байта его были равны
#FF.  Байты 16 и 17 у его описа-
теля   содержали  номер  первого
свободного  блока,  а байты 18 и
19  -  количество свободных бло-
ков.  Эту  информацию  можно ис-
пользовать для работы с диском.

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