1

Тема: Резервные байты у Track/Sector List

Вы наверное знаете что в первом (или единственном, если он один) TSL находятся 9 резервных байт.
Они почти всегда нули, но некоторые программы их используют по своему. Школьница там размер файлов иногда хранит, для К-файлов точка загрузки, ещё mousegraf использует их как размер ФРГ-файлов в пикселях.
Копировщики (напр ИКП) переносят резервные байты при копировании файла. Это в Агатстве......

А вот на Apple вроде бы, кажется, но я не уверен, эта резервная область не использовалась.

Может быть кто-то знает или натыкался ни инфу: зачем вообще Возняк решил зарезервировать эти байты? Ведь даже популярные копировщики эпловские не переносят эти байты при копировании. Может быть это как-то завязано на файлы типа R (Перемещаемый = Reallocate)?

2

Re: Резервные байты у Track/Sector List

Вроде, 8 байт: $00, $03-$04, $07-$0B.

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

Что имел в виду Возняк я не знаю, но можно предположить, что структуры VTOC и TSL в процессе разработки DOS несколько раз менялись (никто ведь не видел 1 и 2 версий DOS). Собственнно, во VTOC есть специальное поле, указывающее, сколько пар трек/сектор содержит TSL, поэтому можно даже наверняка сказать, что это количество менялось.

Ну и дальше эти резервные байты почему-то остались. Возможно потому, что DOS выпускалась в спешке и эти места просто не успели почистить. А потом уже не стали трогать, чтобы не сломать совместимость.

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

Еще я где-то читал, что в ProDOS структуры, описывающие подкаталоги, изначально должны были хранить ключи для шифрования подкаталогов. Если предположить, что в DOS хотели сделать шифрование файлов и в байтах $07-$0B должен был храниться ключ, то не удивительно, что он не копируется.

Ну и наконец, можно предположить, что это был какой-то механизм защиты от копирования, поддерживаемый DOS.

3 Отредактировано LeoN (15-08-2018 07:54)

Re: Резервные байты у Track/Sector List

Apple II The DOS Manual.pdf, стр. 128. И ещё по DOS 3.2.

Турбо АГАТ-9/16 (65C802 CPU, 2.8 Маха), MSX2 Yamaha YIS503IIIR.

4 Отредактировано Voldemar0 (15-08-2018 08:29)

Re: Резервные байты у Track/Sector List

Где -то читал, что 3.2 - это и есть первая версия ДОС. Чистый маркетинг, ничего личного - выше номер версии - больше доверие клиентов.

Хотя вот в DOS 3.2 Instructional and Reference Manual.pdf как раз в начале пишут: "Это руководство не относится к версиям 3.0 и 3.1". Т.е., возможно, они всё таки существовали, но про 1.x и 2.x слышать не доводилось.

5 Отредактировано avivanov76 (15-08-2018 14:38)

Re: Резервные байты у Track/Sector List

Да нет, это не маркетинг, это стечение обстоятельств. Тот же Microsoft не побоялся выпустить PC-DOS 1.0. Да и клиенты на тот момент были только потенциальные - первый выпуск же.

Возняк ведь сделал не весь DOS, а только набор утилит для чтения и записи данных и собственно контроллер. Ему Джобс просто времени больше не дал - они хотели работающий дисковод с DOS-ом показать на выставке Consumer Electronics Show 1978 года.

Поскольку Возняк зашивался, Apple обратилась к другой компании, Shepardson Microsystems. Её работник Пол Лоутон (Paul Laughton) собственно и делал всё остальное: файловый менеджер, интерпретатор команд, интерфейс с Бейсиком. Номера версий он вёл очень просто: при каждом ребилде номер версии увеличивался на 0.1. Он отдал Apple исходники версии 2.8 (то есть, 28 билд).

Дальше Apple действительно заморочилась с номером версии - они не хотели, чтобы новый продукт имел версию 2.8, и изменили версию на 3.0. Но это была бета-версия, она не продавалась, а скорее всего раздавалась среди знакомых программистов с целью поискать баги. Первая официальная версия уже имела номер 3.1 (но билд это уже был номер 63).

Весь базар отсюда https://apple2history.org/history/ah14/#DOS31
А тут хронология операционок https://apple2history.org/history/ah15/

6 Отредактировано garnizon (27-09-2018 13:09)

Re: Резервные байты у Track/Sector List

0 not used

1 Link: track number where continuation of the track/sector list may be found.

2 Link: sector number where continuation of the track/sector list may be found.
( if both bytes of Link=0, no Link.)

3 through 4  not used

5-6 Sector base number (counts groups of 122 sectors) (У DOS 3.2 :  5-6 not used)

7 through B  not used

C Track number of first file sector
D Sector   "    "         "    "

E Track number of second file sector
F Sector   "    "         "    "

10 Track number of third file sector
11 Sector   "    "         "    "
.
.
.
FE Track number of 122nd file sector
FF Sector   "    "         "    "

0 в списке резервных вообще не понятно почему. С точки зрения удобства, чаще проще использовать непрерывной большой кусок, чем этот один байт в начале.
Все структуры диска имеют байты 1 2 именно как ссылку на своё продолжение (VTOC-> каталог1->каталог2, тсл1 -> тсл2....), вероятно, нулевой байт оставляли для какой-то возможной надобности в расширении адресации. Ну, типа, может планировали там номер стороны сохранять или что-то ещё подобное.
Интересно, что в икп-шных дисках (или 840ках вообще ?) этот нулевой байт во VTOC иногда содержит не-ноль. Но случайно или специально и на что это влияет - не знаю. Может просто баг в каком-то популярном форматере.

* * *

Выходит что отличие 3.3  от 3.2 использованием 5-6 байта. Похоже это порядковый номер TSL.

С одной стороны: мне почему-то кажется, что в какой-то агатовской структуре упоминалось , что байты 3-4 тоже вроде как указывают на предыдущий тсл.
И вот если так (т.е. есть ссылка на следующий, есть на предыдущий и есть счётчик) то это очень удобная структура для свободного перемещения по файлу назад-вперёд.

Надо бы подождать когда Володя из отпуска вернется и глянет исходники dos33c2 - там как раз байты 3-4 (а может как раз 5-6...) с какой-то версии появились. Без них что-то не работало, но очень редко.


С другой стороны: в агатстве было два крупных шага по сдаче всего этого цветмета в утиль:

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

2) И потом, уже при выпуске ИКП (к тому времени Кривцов наверняка уже расковырял и знал почти всё, что нужно), не только опять не документировали всё, что нужно, но ещё и сломали механизм внешних вызовов к файловому менеджеру. Т.е. само ядро дос его использует, конечно (через него все load/bload/save/bsave/.... работают), а вот снаружи вызвать каким-то универсальным способом, без извращений, уже нельзя.

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

P.s. Вот смотрю сейчас MouseGraf: он размер (в пикселях) для формата "РИС" и "ФРГ" нагло хранит в 6 и 7  байтах первого TSL.....
А К-файлы все красиво хранят в 8-B байтах первого TSL.

7

Re: Резервные байты у Track/Sector List

Вот этот кусок кода из dos33c2:

      ( PWord (
        @( tTSLSector( Mass[tl, sl] ).data[5] )
      )) ^ := sz div $100

Значит здесь написано (где-то около 2012 года, а может раньше) : в байты смещения 5-6 записывается количество уже записанных секторов (sz - количество записанных байт, / 256 - получается количество секторов). Причем записывается это только начиная со второго TSL. Первый TSL создаётся из данных, которые хранятся в FIL. Второй очищается и туда заносится эти данные. Это было сделано немного костыльно (иначе бы Володя завёл в структуру tTSLSector соответствующее поле), а значит, много лет dos33c2 этого не делала (и не делала бывшая dos33.exe). Бага вылезла в момент копирования каких-то здоровых игрушек. Проявлялась бага вроде бы в том, что dos33 семёрки (а может и икп-шная) ни в какую не хотели читать сектора из второго ТСЛ. Т.е. не видя этого счётчика, они считали что файл по любому закончился на первом ТСЛ.

И еще, копировщик (тот же икп, я проверял) однозначно переносит все резервный байты первого тсл, из диска оригинала в диск копию, в том числе байты 5 и 6 - а по эпловским описаниям получается что ОС сама должна их править при копировании..... выходит что-то может испортиться? или как этот механизм действует, сперва переносится с диска копии а потом поверх ос вносит свои изменения в соответствии с картой образа? Это наверное только пробовать или копать его исходники, пробовать видимо быстрее.

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

Хотя на практике - ну много ли народу порисовав в маусграфе, потом это всё копировали ИКП-шным или каким-то совсем другим копировщиком?
Тут же понятно: все кто копался хоть чуть-чуть в форматах знали, что в первом ТСЛ все байты резервные. Т.е. их К - в первую очередь использует. Ну и , скорее всего, первый ТСЛ переносился как есть. Что там со вторым и последующими - не знаю, но они для К-, ФРГ- и не особо важны, более того, таких здоровых ни К ни ФРГ просто не было - чисто по ограничению формата и карт памяти Школьницы. Это только в dos33 (ну и ИКП) можно зачитать одним куском такой здоровый файл (в смысле - есть свободная память). Проставляет ли ИКП 5-6 байты во вторых ТСЛ - скорее всего да, но это только предположение. Сохраняет ли остальные байты в них - хрен его знает.

Остается выяснить список Агатовских структур, в которых байты 3-4 указывают на предыдущий тсл (Цикоза?).
Тут вся закавыка в том, что если следовать логике заполнения этих полей, то в первом ТСЛ они нули. И - соответственно - так как любая дос очищает первый ТСЛ при создании файла, то вроде как бы всё правильно.
А проявляются проблемы именно на файлах со вторым ТСЛ - т.е. которые больше примерно $7A секторов (122).