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

[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 не видел.

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

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

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

[Advertiser]

[LeoN65816]

http://yadi.sk/d/e46aIhNZ8qFTQ - что то я совсем запутался...

[GARNIZON]

Володя:

"

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

А польза от чередования разных алгоритмов есть?
Есть ли алгоритмы, использующие, например, статистический анализ дорожки или сектора? Или всё сводится только к состоянию последних 2-4 бит?

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

Был выше спор о том, кто что проходил и что надо сразу писать в DSK (при считывании диска).

И мне лично крайне не нравятся все эти дискуссии про всякие atmeg'и. Ну давайте еще на 155 серии сделаем ;-)

Я больше скажу - у нас ещё и 531 серия используется на мостах. А в чём проблема -то?
Задачу они решают, стоят копейки.

Но времени совсем нет :-(

Так если нет времени - зачем мы тогда здесь собрались?
Игорь сказал, что тут есть те, кто хочет сейчас и здесь сделать реальное устройство, но не имеет некоторых данных, по форматам и ещё чему-то.

Для меня в данном случае программно - значит с большими вариантами и возможностями спасти плохочитаемую информацию.

Программно надо делать либо если есть избыточные вычислительные мощности либо если есть идеи по модификации этой программы во время отладки.
У меня нет ни того ни другого. Я разбирал логику 140го секвенсора и экспериментировал с прогой от разработчиков агата и от Возняка - разница есть, но не очень значительная.
Поэтому, возможно, если разобрав логику 840го секвенсора я увижу в ней какие-то возможности для расширения, тогда сделаю так же как сделано в 140ке: несколько
разных программ в ПЗУ секвенсора и чередование их в случае неуспеха. Но сохранять в файлы RAW-bit мне кажется уже перебором. Просто из практики работы с агатовскими дисками.

Если найдется какой-то явно лучший способ RAW-bit -> RAW-byte конвертации, чем анализ последних пары бит - я им заинтересуюсь.

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

Я под повреждениями имел ввиду не только физические, но любые. Независимо от своей природы они вряд ли коснутся единственного бита.

"

[dk_spb]

Так если нет времени - зачем мы тогда здесь собрались?

Хороший и своевременный вопрос.
У меня вот один из ответов такой "для того чтобы поспорить есть ли польза от ФАПЧ при чтении дисков". Хотя, насколько я себе представляю этот вопрос уже давно решен гораздо более светлыми умами, чем наши.

[LeoN65816]

Про пресловутый "desync A1" - http://vak.ru/doku.php/proj/megadrive/mfm?do=export_raw.