Чтение дисков без АГАТа

[dk_spb]

Ну как-то всё сильно в "терминах" Агатовского железа.
На самом деле raw-bit нужен как раз для того, чтобы "вытягивать" raw_byte. В том числе программной ФАПЧ.
Видел сорцы как раз конвертилки raw-bit в raw-byte от kryoflux - так там даже методы ФАПЧ можно менять.

Про противопоставление EIM-DSK вообще ничего не понял. Железка+софт должны уметь писать все (raw-bit; raw-byte=EIM; dsk).

И мне лично крайне не нравятся все эти дискуссии про всякие atmeg'и. Ну давайте еще на 155 серии сделаем ;-)
Я думал сделать такой проект (не только для Агата) в виде дочки к BBB, точнее к BBG (BareBone Black Green). При этом от дочки нужны практически только разъемы и пару м/c "адаптеров" сигналов логики 3,5V-5V. И тогда получается чисто софтовый проект. Сейчас у меня такое железо (не моей разработки софт и "дочка") работает универсальной читалкой HDD MFM. То есть нужно, в некотором роде, "задаунгрейдить" софт и добавить анализатор агатовского формата. За 35 евро на борту и SD и USB и Ethernet. Внутри Linux с компилятором C. Для realtime обработки данных с дисковода- встроенный спецпроцессор. Дискетный битрейт - почти из пушки по воробьям. Но времени совсем нет :-(

- - - Добавлено - - -

Принципиальное отличие тут только в том, что в 140ке частичная синхронизация происходит на каждом байте (байт записывается как 10 бит, два последних - нули), а в MFM- только на поле синхросбоя.

Я не специалист в кодировании и передаче информации, но, насколько я понимаю, синхросбой нужен для синхронизации начала потока информации. Грубо для того чтобы в MFM потоке типа 10101010 понять с какого бита начинается байт. То есть в предлагаемых терминах это уже работа с raw_byte.
Еще нужно получить поток MFM типа 101010 из такого сигнала ----____----____----___, который по факту может быть и ------__----__-_----___ . И вот именно для этого и нужен raw-bit, который обрабатывается программно.

- - - Добавлено - - -

Контроллеры, что 140, что 840 - уже имеют на борту соответствующий аппаратный анализатор.
Он же есть и в мосту-140. Я не вижу возможности его как-то улучшить за счёт программной
обработке на PC или

В том-то и дело что в железке, которую планируется сделать, его нет (хотя бы потому что желзки еще нет). И тут и возникает вопрос: делать "соответствующий аппаратный анализатор" или делать это программно. Для меня в данном случае программно - значит с большими вариантами и возможностями спасти плохочитаемую информацию.
Хотя опять же была мысль сделать два канала: читать чистый сигнал с дисковода и, параллельно уже после какого-нибудь сепаратора с ФАПЧ (например, WD92C32). А потом сравнить. Но аппаратные сепараторы я видел только для FM/MFM. Для GRC не видел.

- - - Добавлено - - -

Ведь повреждение записи - это проблемы поверхности.

А вот тут уже категорически нет. Есть еще куча причин, например, размагничивание от времени, неточная юстировка головки при записи и т.д.