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

[LeoN65816]

Здесь Игорь озвучил мысль о реальной необходимости современного и мобильного средства снятия образов АГАТовских дисков.
Почитал о FM-, MFM-кодировании - "перевариваю".
"Нарисовался" такой вариант: флоппик без контроллера цепляем к девайсу на МК, читаем 4-5 раз каждую дорожку в сыром виде (RAW-битпоток) с привязкой к индексу и "выплевываем" через UART на COM-USB в PC. А можно извратиться и писать сразу на SD. Уже на PC анализ синхросбоев, бит-байт преобразование, анализ достоверности.

Советы/хотелки/критика/подсказки/обмен опытом приветствуются.

[Advertiser]

[GARNIZON]

О! Сейчашние мосты читают в EIM, обработка потом, это жутко удобно.

EIM-файлы - поток сырых данных, получаемых из регистра чтения реального дисковода. В поток органично вплетаются символы синхросбоя, метки индекса (сигнал от датчика индексного отверстия) и все байты, которые контроллер возвращает через регистр чтения. EIM создаётся только программами обслуживания моста, а читается только программой RawEdit. Размеры этих образов не фиксированы и составляют 1-10 Мб, причем могут содержать несколько экземпляров (проходов) чтения каждой дорожки (обычно от 2 до 6 вариантов). Каждая копия каждой дорожки читается 220 мс, т.е. содержит примерно 110 % данных (десятая часть повторяется дважды для возможности точной склейки кольца, если таковая потребуется). Размер дорожек не фиксирован.

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

У Володи не получилось зарегится здесь, тогда бы он уточнил хотелки. Что-то я запутался как тут зарегится. Сейчас попробую спросить "смотрящих".

Очень хотелось бы, если будут варианты такого устройства, понимать сколько это (каждый из вариантов) будет стоить. Т.е. я скорее в хотелки запишу SD, но затяну пояса.

[LeoN65816]

Очень хотелось бы, если будут варианты такого устройства, понимать сколько это (каждый из вариантов) будет стоить.

Навскидку: PIC24EP256GP204, LCD 20x4, SD-shield, кварц, стабилизатор, кнопки, разъемы.

[dk_spb]

Не-не-не. Читать в сырые данные, а обработка потом - это совсем плохо. Проходили.
Надо сразу анализировать формат, считать контрольные суммы, и, если есть сбои - пробовать читать еще раз.
Пробовал на том же KryoFlux - читаем диск в сырое, а потом этом же программой переводим в условно .dsk - программа даёт полно ошибок, образ кривой.
Делаем то же сразу на лету - видно и слышно как некоторые дорожки перечитываются - получаем годный образ без ошибок.
У нас же не идеальные дискеты.....

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

[GARNIZON]

Навскидку: PIC24EP256GP204, LCD 20x4, SD-shield, кварц, стабилизатор, кнопки, разъемы.

Это само собой, я про работу имел в виду. Или сперва надо определится с хотелками?

Мне вот что пока приходит в голову (целиком все мысли попробую оформить через пару дней):
Пишу только про свои хотелки, надеюсь заинтересованные включатся в обсуждение:

1) Когда я еду дампить диски, ноут всегда со мной, на нем вероятней удобней наблюдать за процессом чем на
автономке с СД картой. Видимо с СД я погорячился, а может и нет.... пока запутался.

2) 99 процентов дисков - 840, и если 140 не будет вписываться в проект то можно вероятно и пережить.

3) Очень важно: больше всего доставляет проблем, особенно когда в другом городе или на коленке дампиш,
сортировка! Т.е. многие агатовцы свои диски частично переформатили на PC, или как чаше бывает просто кучей от
разных компов отдают - типа разбирайтесь сами. Т.е. необязательно чтоб и другие MFM форматы умела читать -
достаточно подать знак типа такого "с большой долей вероятности этот диск не от агата".

Надеюсь, форумчане напишут свое видение ситуации.

[dk_spb]

Если делать "автономное", хватит ли 32К и на "сырое" и на "готовое"?
Если неавтономное - там проще - считали дорожку, отдали "сырое" на комп, там проанализировали и при необходимости попробовали считать еще раз. При этом должен быть механизм "сбора" дорожки из разных кусков с разных попыток (например, первый раз не считался первый сектор, второй раз -3; уже за эти две попытки можно собрать годную дорожку).

[GARNIZON]

Не-не-не. Читать в сырые данные, а обработка потом - это совсем плохо. Проходили.

И мы проходили http://agatcomp.ru/Soft/agat.shtml

И поэтому Володя написал прекрасный софт для изучения RAW и работы с RAW.
И вот уже 12 лет именно в сырье.

KryoFlux не показатель. И как он там dsk из сырья делает тоже вопрос.

Ручной анализ EIM-файлов позволяет в некоторых случаях восстановить сбойные блоки дискет, в том числе обнаруживать и исправлять довольно неприятную ошибку "двойных" секторов (в случае неуверенного чтения поля адреса стандартный драйвер иногда "путает" поля данных разных секторов, не имея эффективной возможности обнаружить ошибку). Програмное обеспечение работает под MS-DOS-совместимой системой, за исключением полноэкранного редактора EIM-файлов - он сделан под FreeBSD с использованием библиотеки ncurses.

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

При этом должен быть механизм "сбора" дорожки из разных кусков с разных попыток (например, первый раз не считался первый сектор, второй раз -3; уже за эти две попытки можно собрать годную дорожку).

Это все есть и даже больше в сейчашних мостах, которыми я пользуюсь - въедливый когда надо, ожидает всяких подлянок и т.д.
Но они LPT и так далее про неудобства.

[dk_spb]

Как скажете. Если есть уверенность что в raw с первого раза прочиталось без ошибок (не попала никакая пылинка, микрокусочек покрытия дискеты и т.д.) - можно сразу однократно в raw.
А потом дома кусать локти если после долгого изучения raw потвердилось что пылинка таки была, да еще и протащилась на пару секторов....

и потом, мы под raw понимаем абсолютно разное: то что Вы называете raw (байты из регистра контроллера, то есть видимо уже засинхронизированный поток записанных битов) - это совсем не raw. raw - это либо семплирование с частотой минимум в 4 раза больше реального потока битов, или хранение таймингов "перепадов" (типа на такой-то наносекунде после сигнала индекс произошел первый перепад из 0 в 1, следующий - на такой-то, следующий - на такой-то). Или я неправ?

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

Это все есть и даже больше в сейчашних мостах

А это тут причем? Мы вроде будущий продукт обсуждаем и какие в нем фичи нужны. Или я спутал тему? Если обсуждаем что где УЖЕ есть - беру свои слова назад ;-)

[GARNIZON]

можно сразу однократно в raw.

Поечему однократно? вот пример про 140, прошу прочитать со всей внимательностью (там в конце видео есть интересное):
http://agatcomp.ru/Reading/fl140k_selfmade.shtml

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

А это тут причем?

Этими наработками можно воспользоваться

[dk_spb]

Еще раз - мы разные raw обсуждаем.

>Этими наработками можно воспользоваться
Я бы не мешал всё в одну кучу. Сначала, обычно, обсуждают желаемый функционал, а уже потом смотрят есть ли под этот функционал наработки.
А то для меня непонятно: я пишу "надо бы такую вот фичу", а мне "да это уже там-то и там-то есть". Может показаться что мне возражают и эта фича в конкретно обсуждаемом новом продукте не нужна, раз она уже где-то есть.

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

Я Вас совсем перестал понимать.
Вот по ссылке "(на плохих дискетах приходится перечитывать до 800 раз)"
То есть Вы предалагаете 800 раз записать на SD "сырье" без всякого анализа? А потом (когда дискета уже недоступна) выбирать из этого годные сектора?
Или сразу проанализировать "сырье" (то есть получить из него битовый поток данных, проверить нет ли сбоев кодирования, посчитать CRC) выбрать правильные куски и сохранить битовый поток данных?