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 (20-08-2018 11:14)

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 байте TSL.....