≡ Передовица » Hardware » ДЗУ » Исследование КНГМД 840 » Формат MFM
 |
|
|---|
Формат MFM
Формат MFM подробно описан на куче сайтов в интернете, но не всегда эти описания хороши и я решил составить собственное, особо разжёвывая те моменты, которые мне были сперва непонятны. Кстати, на мой взгляд, лучшее описание формата - в википедии. Но попробую сделать ещё лучше :)
Главное правило (и два термина впридачу)
Итак, главное: если в 140-ке мы говорим о всяких ограничениях на значения бит и всячески их тасуем, чтобы соответствовать этим ограничениям, то в 840-ке используется формат MFM с совсем иным подходом: мы можем записывать любые значения, никак их не меняя, но кроме самих значений (будем называть их "данные" или "data" или "d") будем записывать дополнительные биты, называемые "синхронизация" (или "sync" или "s"). Причем биты синхронизации просто будем записывать между битами данных. Пример:
data: 1 0 0 1 0 1 +
sync:0 0 1 0 0 0 0 = sync = 1 при условии, что предыдущий и последующий биты данных = 0
результат:0100100100010
Значения бит синхронизации вычисляются очень просто: если два соседних бита данных равны нулю, то бит синхронизации между ними делаем единицей. В противном случае (один или оба соседа-данных есть единицы) бит синхронизации равен нулю.
Название "бит синхронизации" весьма спорно. Оно не отражает основного назначения этого бита и возникло из названия события "сбой синхронизации", ведущего свои корни из официальной агатовской документации. Именно ошибка в значении "бита синхронизации" приводит к "сбою синхронизации". Другие названия: тактовый бит или clock bit.
Особенности потока бит
Договорившись о названиях и правилах формирования потока бит попробуем изучить его особенности.
- Расположенные рядом либо бит синхронизации либо бит данных всегда равны нулю. Таким образом в результирующем потоке никогда не бывает двух соседних единиц. Это важно. Это взаимосвязано с полосой частот, которую может записать и воспроизвести дисковод, но это важно и для некоторых частей автомата кодирования и программы декодирования MFM потока.
- Максимум в потоке может быть три, подряд идущих, нуля. Они возникают, если в потоке данных была комбинация бит 101 - один нолик данных и два нолика синхронизации дают три нолика в выходном потоке. Большее число нулей потребовало бы расширения полосы частот дисковода, а она не бесконечна.
- Попробуйте расшифровать такой поток: 01010101010101010101 ? Он корректный ? Конечно. А что им было закодировано ? Как тут найти начало байта ?
Попробуем зашифровать поток нулей:
data: 0 0 0 0 0 0 0 0 0
sync:x 1 1 1 1 1 1 1 1
результат: x01010101010101010
А теперь поток единиц:
data: 1 1 1 1 1 1 1 1 1
sync:0 0 0 0 0 0 0 0 0
результат: 010101010101010101
Таким образом поток нулей, так же как и поток единиц, в результате кодирования становится одинаковым чередованием нулей и единиц. Можно проверить и результат кодирования таких данных: 001001001001001. Он даст в результате поток вида 01001001001001001001001001001. Он тоже может быть расшифрован начиная с любого бита. Чтобы при декодировании различить бит синхронизации и бит данных нужно найти какую либо, заранее известную, комбинацию бит - сигнатуру. Она же укажет на начало очередного байта.
Синхросбой
Волшебство начинается на входном потоке вида 10001. Как было сказано выше, он образуется при записи комбинации бит данных 101:
data: 1 0 1
sync: 0 0
результат: 10001
В "результате" первый бит данных, затем синхронизация. Но предположим, декодер потока сбился и пытается расшифровать наоборот: считая первую единицу битом синхронизации:
результат: 10001
data: 0 0
sync: 1 0 1
Упс ! Получается, что вокруг двух нулей данных бит синхронизации тоже ноль ??? Но ведь входные данные вроде бы корректны, мы не нарушаем правил (нет соседних единиц, нет больше трёх нулей подряд). И всё же оказывается, что эту комбинацию бит можно расшифровать только одним способом.
И это важно: встретив такую комбинацию, дешифратор может действовать двумя путями:
- Если комбинация начнётся в тот момент, когда дешифратор ожидал бит данных - он просто корректно её раскодирует и затем будет ожидать бит синхронизации.
- Если комбинация начнётся в тот момент, когда дешифратор ожидал бит синхронизации, то: бит1 - sync, бит2 - data, бит3 - sync. И прочитав 4-й бит как данные дешифратор поймёт, что ошибся. Теперь ему требуется и 5-й бит прочитать как бит данных. Прочитав его, он будет ожидать бит синхронизации, как и в первом случае.
Как видно, эта комбинация бит даёт возможность умному дешифратору отличить биты данных от бит синхронизации. Дело остаётся за малым: как найти начало какого нибудь байта ?
Это проще, чем кажется. Достаточно записать ещё одну комбинацию 10001, причем "неправильно" по отношению к предыдущей и всё получится. На первой комбинации дешифратор гарантированно настроится на определённую фазировку и, таким образом, гарантированно сменит фазировку на второй комбинации:
входной поток: 100010010010010001010
дешифратор, вар 1: dsdsdsdsdsdsdsds!dsds
дешифратор, вар 2: sds!dsdsdsdsdsds!dsds
Здесь буквами "d" и "s" обозначено то, как воспринимает дешифратор очередной бит: как бит данных или как бит синхронизации. Ну а "!" - момент, когда дешифратор распознаёт ситуацию, в которой текущий и предыдущий биты данных и бит синхронизации между ними равны нулю. Что является ошибкой для корректного потока. И дешифратор меняет фазу.
Такой входной поток называется, в терминологии контроллера 840-кб, "синхросбой". Как видите, если каждый "!" считать началом байта и ожидать после него, например, старший бит данных, то после последнего "!" мы отчётливо видим две единички будущего прочитанного байта: 11xx..и что-то там будет дальше. Первый, считанный после синхросбоя, байт контроллер не отдаёт: драйвер начинает получать данные от следующего байта (просто небольшая экономия на деталях, никакой алгебры).
Синхросбой "по PC-шному"
В контроллере 1818вг93, его предках (в описании программы Floppy Disk Analyser говорится, что это было в IBM System 34) и потомках механизм синхросбоя действует почти также. В качестве синхросбоя записывается специальный "синхроубитый" байт со значением ¤A1:
data: 1 0 1 0 0 0 0 1 ¤A1-sync
sync:0 0 0 0 1 x 1 0 x - выбитый бит синхронизации, должен быть равен единице,
результат:0100010010x01001 но специально устанавливается в ноль
Всё также: две комбинации 10001, одна из которых не может быть корректно раскодирована. Данные начинают отдаваться драйверу после чтения этого байта.
Главный вопрос жизни, вселенной и всего такого
Интересно, что сделает агатовский контроллер с PC-шным синхросбоем? Скорость потока там почти такая же (если говорить о форматах до 800-кб PC), порядок бит такой же (старший бит идёт первым, младший - последним).
sDsDsDsDsDsDsD sDsDsDsDsDxDsDsD
10101010101010 0100010010001001 Это байты FF A1(sync), закатанные в MFM-формат PC-шкой
фаза 0: -0-0-0-0-0-0-0 -1-0-1-0-0-!1-0-...... Это два варианта раскодирования потока агатовским контроллером
фаза 1: 1-1-1-1-1-1-1- 0-0-!1-0-0-!1-0-...... Тире - удалённые биты синхронизации
Проблемы две:
- Байтовый сдвиг. Агатовский контроллер считает синхросбой началом следующего байта, PC-шный же записывает ещё несколько бит. Ладно, это бы можно было сдвинуть в драйвере.
- Битовый сдвиг. Агатовский контроллер считает в синхросбое 10001 последний бит битом данных. А у PC это бит синхронизации. И это - большая проблема.
Нам ведь интересно прочитать PC-шный диск. Но биты данных, которые записывает PC, агатовский контроллер будет считать битами синхронизации и отбрасывать их. И это будет продолжаться до тех пор, пока где нибудь в потоке не появится последовательность 10001, которая ещё раз развернёт фазу работы дешифратора.
Я не проверял это предположение и сделал его только из диаграмы работы автомата декодирования. Если у вас есть информация о том, что это не так - напишите мне.
Можно ли восстановить из бит синхронизации биты данных ? На первый взгляд они жестко взаимосвязаны. Но мне не удалось придумать подходящий алгоритм.
Другие описания MFM
В некоторых описаниях MFM вы можете прочитать что нибудь вроде "единица сдвигается по фазе". Это тот же MFM, но описанный немного по другому. Так как двух соседних единиц нет, то можно считать, что в комбинации 10 единица стоит на своём месте, а в комбинации 01 - сдвинута на половину такта (если тактом считать два бита). Это всё лишь вопрос определений.
Ещё один вариант: считать единицу - началом условного интервала, а число следующих за ней нулей - размером интервала. Тогда можно говорить, что 10 - единичный интервал, 100 - двойной интервал, 1000 - тройной. И оперировать именно такими терминами.
Мне показалось, что вариант, в котором каждый бит данных и бит синхронизации упомянуты явно и не двигаются со своих мест - удобнее для понимания.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *