≡ Передовица » Hardware » ДЗУ » Исследование КНГМД 840 » Немного лирики и истории
 |
|
|---|
Немного лирики и истории
В конце 90-х я уже свободно ориентировался в архитектуре Агата, писал довольно сложные программы, но всё ещё большой загадкой для меня оставался дисковод 140 кб. Скудная документация, не раскрывающая многих подробностей об использовании этого устройства. Дизассемблированные примеры драйверов, некоторые особенности которых можно было повторить, но без понимания - так не интересно. Попытки разобраться в электронной схеме контроллера тоже были безрезультатными. Всё вокруг было понятно, было ясно как включается двигатель, как управляется головка, но вопрос был именно в обработке данных. Существенным препятствием было то, что в схеме стояла ПЗУ 556рт5, прочитать её было можно, но для этого бы пришлось собрать простейшую читалку, выпаять микруху... А у меня уже были драйвера 140-ки в исходниках, так что изучение могло продолжаться только ради интереса.
Наступили 2000-е, у меня появился контроллер 840-ки. В него я не стремился залезть, было ясно, что её схема не проще 140-ки.
Не помню, что или кто натолкнул меня на книжку Jim Sather, где подробно описывался эпловский Disk ][, но это было Открытие! Архитектура Disk ][ оказалась совершенно удивительной - мне бы в голову не пришло так решить подобную задачу. Стало понятно, почему я не мог в ней разобраться: когда изучаешь чужую схему, всегда стремишся разделить её на знакомые участки, но здесь их не было. Это было около 2010 года и уже к маю 2013 я закончил большую статью про конструкцию 140-ки, ведь концептуально 140-ка повторяла Disk ][.
Успех был велик и я даже подумал, что теперь-то разобрать работу 840-ки большого труда не составит. И, однако, это растянулось на несколько лет. В 2014 году я уже хорошо понимал, что авторы 840-ки использовали тот же подход к построению канала чтения/записи, что и в 140-ке, но только слегка его усложнили. Но именно это слово - "слегка" - оказалось не менее удивительным, чем сама 140-ка. Дело в том, что всего на десятке неспециализированных микросхем Андрей Филлипов (разработчик 840-ки) построил полный MFM-кодер и декодер, к тому же ещё и с цифровым трехзонным предкомпенсатором записи.
Схема получилась очень нетривиальная в анализе и чтобы понять причины, нужно немного рассказать об архитектуре контроллера 140-ки. Помимо микросхем, которые управляют движением головки и включением дисковода, в контроллере 140-ки реализовано устройство под названием "секвенсор".
Оно состоит из микросхемы ПЗУ, которая содержит некую "программу" и набор регисторов-защёлок. Часть выходных линий данных ПЗУ входит в защёлки, а часть выходов защёлок подключена к адресным входам ПЗУ. Защёлки по сигналу синхронизации запоминают состояние на входе и выдают его на свой выход. Таким образом, если, например, в ПЗУ записаны числа 1 2 3 4 0, а в регистрах-защёлках хранится число 0, то на адресном входе ПЗУ будет число 0, а на выходе данных число 1. После синхроимпульса число 1 попадёт на адресные входы ПЗУ, а на выходе ПЗУ мы получим число 2. Таким образом мы получим счётчик от 0 до 4. Это будут шаги "программы". На другие выходы ПЗУ мы можем выводить какие нибудь команды для любых исполнительных устройств. На другие входы ПЗУ мы можем подавать какие-то ещё сигналы (например, данные с головки дисковода) и, в зависимости от получившегося итогового адреса, ПЗУ будет выдавать различные команды для исполнительных устройств. Это и есть задача секвенсора - по сути, небольшого микроконтроллера с простой программой.
Но единственное исполнительное устройство 140-ки - это сдвиговый регистр, именно в нём накапливается читаемый байт и из него же выдаётся байт для записи. Секвенсор реагирует только на значение старшего бита этого регистра, на режим работы контроллера (чтение/запись), на данные с головки дисковода. Есть ещё кое что, но тоже не сложное.
В 840-ке же входные сигналы секвенсора заметно более сложные. Например, есть вход от счётчика обработанных бит.
Но сам счётчик тоже управляется секвенсором! Более того, он исполняет три различных команды: инкремент, сброс
в 0, сброс в 8. Мало того, секвенсор управляет отдельным автоматом кодирования и предкомпенсации записи. Секвенсор
управляет ещё одним накопительным регистром. И это ещё не всё: часть данных секвенсор выдаёт с выхода ПЗУ, а часть
- с выходов регистров-защёлок. Так как для некоторых исполнительных устройств имеется несколько входных сигналов,
было очень непросто разобраться с фазировкой: какой сигнал прибежит достаточно рано, до сигнала синхронизации,
кто позднее, а кто задержится до следующего синхроимпульса. Достаточно сказать, что в системе действуют
два синхросигнала: 4 МГц тактовой частоты секвенсора и сигнал Fs - его вырабатывает секвенсор и это означает
что-то вроде "ок, переходим к следующему биту" - каждый из этих сигналов связан с тремя исполнительными
устройствами-микросхемами. Ну и, конечно, там есть сигнал "следующий байт". Причем во время чтения он возникает
при обработке 8-го бита, а при записи - вот же сюрприз - при обработке 4-го бита очередного байта.
Итак, в 2014-м я написал первую версию "дизассемблера" программы секвенсора 840-ки. Ничего умного не получилось и я отложил эту работу. Затем несколько раз возвращался, перерыл кучу статей по MFM-формату, но это пока был путь в гору - когда объём знаний по решаемой задаче только возрастает, но проблемы не решаются. Где-то в конце 2017-го, при очередном подходе, я ещё раз перечитал имеющиеся доки по контроллеру и решил перерисовать электронную схему. Впервые в жизни я попробовал использовать цветные маркеры для отметки того, кто из микросхем с кем связан. Не отдельные линии, а глобальные связи. Обозначил источники синхронизации цветом. Также я выкинул из схемы всё, что не относилось непосредственно к потоку данных. Выкинул 580вв55 и всё управление дисководом. Кое что стало проясняться. Точнее так: ещё ничего не стало понятнее, но я заметил, что несколько микросхем, по которым информация передаётся перед записью, почти не имеет связи с секвенсором. Секвенсор только выдаёт сигнал сдвига данных в регистр, хранящих ещё не кодированные биты, а также сигнал параллельной загрузки в последний, перед головкой дисковода, счётчик. Это была хоть какая-то ниточка.
Среди этих микросхем есть небольшая ПЗУ 556рт4. Я решил начать с расшифровки её содержимого.
Где-то неделя ушла на то, чтобы понять логику таблицы, хранимой этой микросхемой. Но когда она стала проясняться
- это был не просто свет в конце тоннеля - это был прожектор в лоб! Стало ясно: 1) Надо даже не исправлять ошибки
в моём "дизассемблере", а вообще переписывать его. 2) Этот блок, который я так старательно ковырял - это и есть
автомат кодирования MFM и предкомпенсации записи. Ему для нормальной работы вообще не нужен секвенсор,
секвенсор используется только для введения в запись т.н. "синхросбоя" и Fs-тактирования. Но как вносится
синхросбой - я ещё не понимал. И - однако - именно тогда появились первые наброски статей для сайта.
Был переписан "дизассемблер". Ещё раз - уже сбился со счёту сколько раз это случалось - я перепроверил все
условия работы микросхем, составляющих секвенсор. Проверял это по отечественым справочникам (хотя бы по паре
разных) + pdf-ки по импортным аналогам. Было важно, по фронтам или спадам срабатывают счётчики и регистры. Инверсные
или прямые сигналы управления режимами. Что означает сдвиг вправо или влево: какой вывод будет правым, а какой
- левым. Сколько времени выдаётся "перенос" - только пока активен тактовый сигнал или до следующего тактового
фронта. Уже был печальный опыт с разбором 140-ки, когда оказалось, что ир13 во многих справочниках описана
не совсем правильно. В 840-ке это всё очень важно, так как почти всё управление поступает от секвенсора,
а он работает по программе, в правильности расшифровки которой я вовсе не был уверен.
Теперь я вновь вернулся к расшифровке программы секвенсора. Это была середина 2018 года. Теперь я знал как работает блок записи, по аналогии со 140-кой я предполагал, что программа записи будет проще программы чтения. Это было почти так, но когда я уже думал, что всё понял, настал черёд подключить к реальному флопику логический анализатор и проверить мои выкладки. К тому времени я уже перечитал на пару раз статью Oleksandrа Kapitanenko, но, в очередной раз всё оказалось не так, как я ожидал. Вновь вылезло моё неверное понимание работы некоторых блоков. Например, команда инкремента счётчика бит всё таки оказалась состоящей из двух частей (я надеялся, что мне мерещится, что не могли разработчики так усложнить себе жизнь): сперва в программе появляеся команда Fs "следующий бит", а уже на следующем шаге (не обязательно, что он будет на следующем адресе программы!) выдаётся инфорамация о том, какое действие должны предпринять исполнительные механизмы. Без Fs действия выполнены не будут. Вновь пришлось подправлять дизассемблер и заного анализировать его результат. Мне хотелось не просто знать Как выглядит формат записи Агата, но и Как он синтезируется и что прочитает драйвер из контроллера, если на дискете встретиться что-то необычное.
Как вы думаете: если нужно записать специальную последовательность бит для синхронизации контроллера
(синхросбой), инженер будет делать специальный блок, который сформирует эту последовательность?
Ну я так думал. И опять не угадал. В 840-ке запись синхросбоя происходит как запись обычного байта.
Просто в середину этого байта докидывается маленький скромный ноль. Суть в том, что при чтении этот
ноль ничего не значит для декодера, он валидный. Невалидным (синхроубитым) получаются совсем другие биты,
следующие заметно позднее этого нуля. Я долго смотрел на сигналограммы реальной агатовской дискеты, пока до меня это дошло.
Понимаете: событие "сбой синхронизации" в режиме записи происходит НЕ В ТОМ МЕСТЕ, где оно произойдёт при чтении!
Они сдвинуты почти на 8 RAW-бит.
Но к концу сентября 2018 задача уже во всю катилась под гору. Я взялся за программу чтения. Каждая программа состоит из шагов, 64x4 для записи, 64x2 для программы чтения. Такое сокращение связано с тем, что программа чтения не анализирует сигнал "конец байта". Т.е. команды счётчику бит выдаются, счётчик выдаёт сигнал "конец байта" в пограничную 580вв55, но сам алгоритм декодирования на краях байт не меняется.
Но и 64x2 шага - довольно непросто для анализа, когда каждый шаг может быть ветвлением :). Если в программе записи основная задача секвенсора - выдавать
команду перехода к очередному биту через равные промежутки времени (ну и формирование синхросбоя записи, но это только изредка, по команде
драйвера), то программа чтения должна подстраиваться под период входного потока, да ещё проверять саму
последовательность бит - выявляя корректные и некорректные сочетания, находя синхросбои и выдавая дешифрованный
поток. Собственно, скорость работы 840-ки и плотность данных - заслуга именного этой программы.
Ну блока записи, тоже.
Я пытался по разному расшифровать эту программу. Нужно было как -то объединить группы команд, работающие
с одним и тем же таймслотом, найти какое-то графическое или формульное представление того, что там может
происходить.
Было несколько рисунков, штук пять. К очередной версии применялись реально имеющиеся последовательности данных,
очередной раз было непонятно, как получившееся упрощение может их обработать, опять выявлялись какие-то
мелкие неучтённости в работе секвенсора. Ручка, цветные маркеры, бумажные черновики. Это всё напоминает
попытку математика сократить форумулу. Или попытки физика выявнить те параметры математической модели, которые не
будут вносить существенный вклад в результат и, таким образом, могут быть исключены из неё.
Наконец, к ноябрю 2018, после очередной перерисовки диаграммы, вдруг удалось чётко обозначить блоки, расшифровывающие кодированный ноль и кодированную единицу, исключить часть "нерабочих" переходов (goto, которые не должны исполняться при корректном потоке данных) и - вау! - на диаграме почти ничего не осталось, кроме ветки, задерживающей работу при синхросбое. Это было завершение. Теперь можно было спокойно считать, что основная часть работы выполнена.
В отличие от 140-ки я не делал тестовых прог, специально формирующих какую-то последовательность бит (они и там понадобились, в первую очередь, в процессе разработки Моста). Да, здесь могут ещё быть какие-то ошибки. Но:
- Я добитно разгрёб разницу между форматом 1818вг93 и Агатом.
- Я стал понимать, для чего нужны и как используются байты ¤A4 / ¤FF, которые, согласно документации, нужно отправлять контроллеру при записи синхросбоя. Я понял, где и как они будут прочитаны.
- Я могу попытаться предсказать поведение контроллера для любых входных данных.
Конечно, кой что из этого неплохо бы проверить. Но я всё же начал писать этот текст, так как писать нужно, пока хорошо всё помнишь - это закрепляет знания. Если я всё же проведу тесты, то подправить текст никогда не поздно.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *