1 Отредактировано Voldemar0 (14-06-2025 10:14)

Тема: Микрухи, совместимые или похожие на ВГ93

Привет!

ВГ93 умеет два режима: FM и MFM.
Я сейчас столкнулся со странным форматом, который как будто похож на FM-режим ВГ93, но не совсем:
у вг93 есть несколько специальных байт-сигнатур, которые обозначают начала адресных полей и полей данных.
Такие сигнатуры позволяют найти нужное поле, а заодно синхронизовать контроллер по байту и биту.

Для FM-режима предлагается несколько значений сигнатур: F8-FB и FE.
Обычно (по рекомендациям доков) FE используется для поля адреса, а FB - для поля данных.

Но мне попались диски, где с FE проблем нет: чистый FM, даже CRC адресных полей совпадает.
Но сигнатура поля данных как будто бы FD. И это странно, потому что у ВГ93 этот байт пишется с обычной синхронизацией (т.е. не отличим от обычного байта FD в любом другом месте). Однако на этих дисках получается, что FD пишется с необычной синхронизацией (C7).

Причем, даже если я принимаю такую комбинацию, у меня не совпадает CRC поля данных.

Есть два варианта: или у меня ошибки (буду ещё искать) или тут использовалась какая-то микруха, которая была по формату похожей на ВГ93, но имела небольшие отличия.

1) Я собираю список близких контроллеров: FD1793, FD1773, WD1772, чтобы порыться по их докам, может быть где-то будет подсказка. Какие ещё могли быть ?

2) На одном из дисков была пометка "PDP-11 DY0:" Есть ли какая-то информация по этому контроллеру ?

2

Re: Микрухи, совместимые или похожие на ВГ93

Я поскреб интернет насчет формата DY: и нашел упоминание, что он создается контроллером PDP-11 RXV21.
Беглый взгляд на описание формата говорит, что видимо это оно и есть (в смысле метка FD для данных) https://www.avitech.com.au/mm-files/sca … manual.pdf

К сожалению (или не к сожалению) этот контроллер сделан без микрух от Western Digital. На 10-й странице есть рисунок печатной платы и видно, что он собран на неких микросхемах 2901. Фотки именно такого контроллера я не нашел, но нашлось фото какого-то совместимого контроллера от другой фирмы https://avitech.com.au/?page_id=847
На фото видно, что микрухи от AMD (AMD2901). Это секционированный процессор (у нас известный как К1804ВС1). Так что формат записи он поддерживает программно и может там крутить байтами как захочет, совершенно независимо от того, как работает с диском ВГ93.

3 Отредактировано Voldemar0 (14-06-2025 08:38)

Re: Микрухи, совместимые или похожие на ВГ93

Спасибо!

Тут ещё появилась подсказка, что в этом формате может быть так, что поле адреса пишется в типичном для ВГ93  FM, а затем контроллер переключается то ли в типичный, то ли атипичный MFM. Пока плохо понимаю эту игру: если там реально был какой-то проц со своим кодом, то, возможно, это была попытка внедрить MFM, но почему столь половинчато ?

Есть инфа о существовании компа с операционкой BOS-1810, которая при форматировании диска нулевую дорожку лепила в FM, а остальные - в MFM. Но тут понятен вероятный смысл: совместимость. Если контроллер поддерживает только FM, то прочитали нулевую дорожку, выяснили что за диск и какой дальше формат и можем сообщить пользователю, что на этом контроллере этот диск не прочитается. Даже, может быть, можно каталог показать.

А отдельно иметь возможность читать адресные поля и не читать данные - ну как бы так себе идея...
Или это специфика ПО контроллера: "Так, давайте FM реализуем. Процедура чтения адресного поля, процедура чтения поля данных. А теперь добавим MFM. Процедура чтения адресного поля у нас уже есть... сойдёт и такая. Надо только процедуру чтения поля данных сделать, но с MFM..."

ЗЫ В доке на WD1772 нашел, наконец, название этого формата (который я нызваю "вг93"): IBM 3740 or System 34 formats.

4 Отредактировано Voldemar0 (14-06-2025 11:08)

Re: Микрухи, совместимые или похожие на ВГ93

Читаю описание на rxv21 - да, оч похоже на то, что я вижу на диске.

--

Я как вижу эти цепочки битовые, мысли разбегаются по всем знакомым контроллерам, и мне тут идея пришла в голову:
ведь агатовская 140ка / Disk ][ , если отбросить вопросы чтения диска, фактически не выполняет какого либо кодирования данных при записи. Она тупо побитно фигачит на диск то, что ей прислал ЦП. Т.е. теоретически, нет ограничений на то, чтобы заранее сформировать хоть целиком дорожку нужного формата, например, хотя бы IBM 3740 FM.

Интересно, PC-шные биосы из 90-х single density поддерживали ?

5

Re: Микрухи, совместимые или похожие на ВГ93

Voldemar0 пишет:

Тут ещё появилась подсказка, что в этом формате может быть так, что поле адреса пишется в типичном для ВГ93  FM, а затем контроллер переключается то ли в типичный, то ли атипичный MFM. Пока плохо понимаю эту игру: если там реально был какой-то проц со своим кодом, то, возможно, это была попытка внедрить MFM, но почему столь половинчато ?

В википедии пишут, что так и есть - используются и FM и MFM на одном треке.
Вообще, у DEC было два формата:
1) FM-формат RX01 с емкостью 243 КБ на диск, полностью совместимый с IBM
2) гибридный FM/MFM формат RX02 с емкостью 487 КБ на диск, который не совместим ни с чем
Контроллер RXV21 работает с обоими. То есть, есть выбор - можно использовать универсальный формат, а можно фирменный, высокой плотности. Возможно, они так сделали потому что IBM стала использовать MFM на 8-дюймовых дисках с 1976 года, а DEC сделала RX02 в 1978-м, и на тот момент еще не было явного лидера, непонятно было, какой формат победит.
А может, дело в лицензировании. Думаю, что IBM-овский MFM был защищен патентами и DEC пришлось бы платить за его использование (и финансировать конкурента). А так - сделали свой формат и сэкономили.

Voldemar0 пишет:

ведь агатовская 140ка / Disk ][ , если отбросить вопросы чтения диска, фактически не выполняет какого либо кодирования данных при записи. Она тупо побитно фигачит на диск то, что ей прислал ЦП. Т.е. теоретически, нет ограничений на то, чтобы заранее сформировать хоть целиком дорожку нужного формата, например, хотя бы IBM 3740 FM.

Собственно, контроллер 140К и так пишет адресные поля в FM (к вопросу о совмещении разных форматов). Так что нет проблем весь диск им записать в FM. Только плотность записи упадет. Будет не 140 КБ, а что-то типа 109 КБ на диск. И именно под эту емкость дисководы и проектировались. Но видимо даже для конца 70-х такой емкости было мало, поэтому каждый пытался выдумать свой формат.

6 Отредактировано Voldemar0 (16-06-2025 07:59)

Re: Микрухи, совместимые или похожие на ВГ93

Я почитал внимательно документ, там пишут что всё просто: всё крутится вокруг FM, но если контроллер находит пролог MFM-поля данных, то следующие за прологом 258 байт (256+CRC16) должны быть декодированы как MFM.
Очевидно, после этого контроллер опять соскакивает в FM. Причём размер сектора тут описывается как константа и, вероятно, не предполагает других вариантов.

Всё выглядит как будто просто, но есть две мысли:

1) Вводили ли они предкомпенсацию фазовых сдвигов записи для MFM ? Может быть это есть в документе, но я поке не встретил. MFM имеет более близко расположенные спектральные линии, чем FM, фазовый сдвиг больше пакостит.

2) У меня стек декодеров определённо не был расчитан на то, что на одной дорожке будут два варианта сборки байт из потока интервалов времени от дисковода. Когда у Агат-140 контроллер работает с дорожкой, где сочетается FM и GCR - это сочетание разбирает уже ЦП, у контроллера режим не меняется. GCR, фактически, касается только строго пользовательских данных, даже CRC он не покрывает. А вот это сочетание FM+MFM - это уже разная работа сборщика байт. И я в глубокой задумчивости, как это скрестить не ломая архитектуру кода.

--

Че-то торкнуло щас: я понял почему на 140ке чаще чем на 840ке встречается проблема с версиями секторов при неуверенном чтении. Т.е. когда диск очень плохо, но долго читается, получается несколько вариантов одного сектора с правильными CRC.

Я -то как -то думал о том, что как в 140 так и в 840 CRC - это байт. А сейчас понял что это не так: в 840ке это байт, т.е. 8 бит. А у 140ки, фактически, только 6 бит. Поскольку CRC там считается после первого табличного преобразования байт, когда из 8 бит, прочитанных с диска, драйвер выжимает "сухой остаток" - 6 бит. Вот по ним и считается CRC, т.е. она не может выйти за пределы [$00..$3F]. Потом уже, из каждых 4 байт по 6 бит GCR- декодер собирает 3 байта по 8 бит.

--

> Собственно, контроллер 140К и так пишет адресные поля в FM (к вопросу о совмещении разных форматов).

Я про другое думал: как можно бы было в 80-е перетащить данные с Агата на PC без аппаратных доработок, пайки кабелей и т.д. Если PC-шка понимает всё таки FM-запись, то это мог бы быть вполне рабочий вариант.

Может быть такой софт существовал для Apple ][ ?

{ Либо ещё вариант: низкочастотный MFM. Стандартный MFM - это интервалы 4, 6, 8 мкс, агатовский контроллер же имеет дискретность только 4 мкс. На нём можно было бы сделать MFM c интервалами 8, 12, 16 мкс. Но PC-шное железо такой низкий битрейт не поймёт. Да и не ясно, что прочитается с флопика на такой низкой частоте. }

7

Re: Микрухи, совместимые или похожие на ВГ93

Voldemar0 пишет:

Вводили ли они предкомпенсацию фазовых сдвигов записи для MFM ?

Страница 12, раздел 2.1.4 Write Precompensation. Правда, я не пойму, а что это для чтения меняет? Была там предкомпенсация, не было ее - все равно результат записи не исправить и придется читать то, что записалось.

Voldemar0 пишет:

Вот по ним и считается CRC, т.е. она не может выйти за пределы [$00..$3F]

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

За пределы $00..$3F КС выходит, потому что используются закодированные значения в диапазоне $9F..$FF, а не исходные 6-битовые слова.

Но в общем, да. Если бы подсчитывалась КС исходных байтов, то надежность была бы выше.

***

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

IBM не просто так использовала на дисках циклическую контрольную сумму вместо обычной КС. CRC во-первых ловит четные ошибки, которые продольная четность просто не видит. А во-вторых, длина КС тоже имеет значение. Например, 8-битная CRC может ловить двойные ошибки в блоке данных не больше 255 бит. В любом стандартном секторе данных больше. Поэтому на дискетах и используется CRC-16.

Voldemar0 пишет:

Я про другое думал: как можно бы было в 80-е перетащить данные с Агата на PC без аппаратных доработок, пайки кабелей и т.д. Если PC-шка понимает всё таки FM-запись, то это мог бы быть вполне рабочий вариант.

Я понял, но никаких упоминаний про поддержку Single Density на PC я не нашел. Разве что какие-то CP/M совместимые компы ее использовали.

8

Re: Микрухи, совместимые или похожие на ВГ93

> Страница 12, раздел 2.1.4 Write Precompensation. Правда, я не пойму, а что это для чтения меняет?

Для чтения вроде бы ничего. Хотя, если её не было при записи, можно было бы попробовать ввести её же при чтении.
Но меня больше интересовало, использовалась ли она? MFM на дисках появился не так давно, могло быть так, что первые поколения контроллеров не использовали предкомпенсацию.


> За пределы $00..$3F КС выходит, потому что используются закодированные значения в диапазоне $9F..$FF, а не исходные 6-битовые слова.

Код, который у меня в rawedit, её считает уже после преобразования. А я его взял из какого-то драйвера.
Либо взял неправильно либо были разные варианты драйверов.
Преобразование для корректных данных однозначное, так что EOR будет одинакого работать.

9 Отредактировано avivanov76 (18-06-2025 01:38)

Re: Микрухи, совместимые или похожие на ВГ93

Voldemar0 пишет:

Код, который у меня в rawedit, её считает уже после преобразования. А я его взял из какого-то драйвера.

Блин, я смотрел в код, но все равно все переврал :( Да, верно, сумма считается после преобразования. И если ошибок чтения нет, то действительно используются значения из диапазона $00..$3F.

Spoiler

http://forum.agatcomp.ru//misc.php?action=pun_attachment&item=1346&download=1

Но у преобразования есть особенность.
Оно делается по таблице. Индексом к таблице является значение, считанное из регистра данных контроллера. Поскольку признаком готовности байта является установленный старший бит, то это значение всегда будет лежать в пределах $80..$FF.
В таблице значения, отвечающие правилам кодирования не всегда идут подряд.
Что же лежит в промежутках? Там лежат значения, возрастающие от $96 до $FF.
То есть, если будет прочитан байт с нарушениями кодирования, то в результате преобразования получится значение $96..$FF, и контрольная сумма выйдет за пределы $00..$3F.

***

В связи с этим есть вот какой забавный момент. Я не настолько хорошо знаю как работает секвенсор контроллера 140К, поэтому не уверен, может ли контроллер вернуть байт в диапазоне $80..$95. Но если может, то получается выход за пределы таблицы.
Таблица преобразования для чтения начинается с адреса $XX96. Байты $XX80..$XX95 в разных версиях драйверов заняты разными данными. У Apple там какой-то код, у Агата там окончание таблицы перекодировки для записи. То есть, в случае ошибок, контрольные суммы будут получаться другими.

Post's attachments

Attachment icon Apple_Read16.png 54.28 kb, 88 downloads since 2025-06-17 

10 Отредактировано Voldemar0 (20-06-2025 19:24)

Re: Микрухи, совместимые или похожие на ВГ93

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

В софте Мостов я всегда мониторил эти ситуации. Т.е. если входящее число выходит за пределы таблицы либо попадает на незаполненные ячейки таблицы (есть там такие), то поднимается флаг "Ошибка GCR-кодирования" и сектор считается сбойным независимо от CRC.