ПЭВМ АГАТ: У Агата был странный дисковод

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

А всё просто, одни видели Агат с ранним типом дисковода (временно позаимствованным от Apple), а другие общались уже с родным Агатовским, который появился позднее. И те, и другие, могли не знать о существовании иного типа дисковода, отсюда такие разные мнения. А характеристики у них действительно несравнимо разные.

Иногда неочевидно, что для АГАТа существовало два разных дисковода (контроллеры у них тоже разные). Они вообще никак не совместимы между собой кроме физического размера дискет!

- Ранний тип. 140 кб. Так называемый "килобайтник" (на фото с красной дискетой).
- Поздний тип. 840 кб. Так называемый "мегабайтник" (с синей дискетой).

Поскольку в серийное производство контроллер 840 пошел одновременно с Агат-9, имеем такую таблицу:

	1 х 140	1 х 840	840+140
Агат-7	штатно до 1988 г*	штатно с 1988 г	модификация на заказ
Агат-9	не бывает	штатно с 1988 г	модификация на заказ

Таким образом, с 1988 года, контроллер 140 стал только опцией, для совместимости с дисками от раннего АГАТа, а также с дисками от Apple и Правец. Т.е. либо запустить что-то, написанное конкретно под 140К дисковод, либо просто перенести данные на 840.

* * *

Ранний тип.

Физический привод - такой же, как устанавливался в Правец 8, болгарский ЕС 5088. Это почти точная копия привода DISK II от ЭВМ Apple II. Собственно такие аппараты применялись только в Apple/Правец/Агат.

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

Вообще, DISK][ и его копии весьма своенравные супчики: скорость плавает, таРрРрахтит...
Куплет частушки, сочиненный детьми на одной из ЛШЮП, иллюстрирующий характер этого флопа:

У Пегги вредный был Агат
Он портил диски всем подряд
Ах, до чего же гад Агат
Спляшем Пегги, спляшем!

Однако вины самого Агата нет, болгарские пользователи Правца "плясали" не меньше. Похожие пляски, хоть и менее дикие, устраивали американские пользователи Apple.

* * *

Поздний тип.

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

Кому приходилось видеть, как Агат с этим контроллером шустро общается с диском, интересуются, откуда такая проворность. Причин несколько:

- Самая ёмкая из разметок, применяемых для дисководов DS/DD.
- Диск размечается без привязки к индексному отверстию, драйвер его не ждет, а сам учитывает прошедшее время.
- Благодаря широким возможностям программной оптимизации, в т.ч. "ленивый" режим.

Для объяснения принципа последнего, нам придется немного добавить технических подробностей и уйти от обзорной прогулки. На тот момент это было Агатовское ноу-хау, и является отечественной фишкой. В Apple вы такого не встретите, как и где-либо еще, кроме некоторых ХДД WD (уже в середине 90-х). Но эта компания и не скрывала, что пользовалась "русской идеей".

Секрет в том, что на уровне софта реализовано буферизация операций обмена (кеширование команд). Т.е. файловая система может делать два вида запросов к драйверу диска:

- с мгновенной доставкой данных (ну, скажем, если ей нужен заголовок файловой структуры или блок данных каталога).

- с возможностью отложенного выполнения (когда собственно ведётся обмен с содержимым файла). Реализовано это так: создан специальный массив (всего 21 байт) по элементу на каждый сектор трека. В каждом элементе указывается тип операции над данным сектором (0 - ничего не делать, 1 - читать, 2 - писать , 3 - проверять (сравнивать)) и указатели адреса - куда читать или откуда писать. Когда файловая система шлёт запросы с флагом возможности отложенного выполнения, то эти операции просто помещаются в соответствующий элемент массива, а реально ничего не выполняется, пока не случится либо запрос без возможности отложенной операции (обычно последний блок запроса) или не случится переход на другую дорожку.

Вот тут и начинается самое интересное, происходит обработка всех отложенных заданий. Драйвер просто отлавливает заголовки секторов, которые проходят в данный момент мимо головки и по номеру смотрит на задания указанные в массиве. Если ничего не надо делать -- просто пропускает, сказано прочитать -- прочитает, сказано записать -- запишет, после выполнения операций флаг скидывается на 0, причём для записи было сделано так, что устанавливался не 0, а 3 и на следующем обороте выполнялась проверка записанного. Когда после обработки очередного сектора оказывалось, что заданий нет -- начиналась работа по новому заданию.

Что это даёт? А две простые вещи:

- массовое чтение выполняется строго за один оборот (плюс максимум один сектор).

- запись выполнялась с отличной проверкой (СЛИЧЕНИЕ ДАННЫХ), причём на это требовалось всего два оборота (можно вспомнить, что на PC если включить запись с проверкой всё начинало плестись со скоростью аж по 15/18 оборотов на дорожку для 1,2/1,44 МБ).

... Эту же логику потом добавили и в драйвер 140кб. Но, правда, там дорожка всё равно требует два оборота или больше - драйвер налету вынужден выполнять сложное декодирование, получается: один сектор читаем, один пропускаем (пока декодируем предыдущий).

* * *

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *