Вид для печати
Не могу понять, почему вам так принципиально читать всю дорожку целиком... ведь можно это делать посекторно, или часть дорожки, потом еще часть и т.д., да скорость чтения будет медленнее, но зато не нужны большие объемы памяти, считал килобайт, закинул на флешку и читай дальше...
есть трековые форматы, например, MX для ДВК.Цитата:
Сообщение от EvgenRU
Можно. Но смысл? Ни одну защиту это не возьмет. Плюс бывают сектора 4к размером. Плюс один фиг надо продумывать способ адаптации к плавающим скоростям, не в постобработке на ПК, а «налету».Цитата:
Сообщение от EvgenRU
Каким образом «продолжить чтение», если там расстояния постоянно плавают, и невозможно точно попасть в то же место на другом обороте? Да и сами импульсы бывает есть, а бывает нет (хоть это и не часто, но это помешает найти ту же позицию для сшивания).Цитата:
Сообщение от EvgenRU
Продумай стабильный алгоритм такой безглючной многопроходной склейки, вперед.
Добавлено: 2кб оперативы дадут возможность впихнуть лишь ~250 байт ноликов (по байту на расстояние). каждый нолик (или 0xff) - это восемь 4мкс импульсов. Неотличимых импульсов. Каким образом можно склеить неотличимые "поезда" ноликов? Ответ - никаким. Ты можешь ЛЮБОЙ кусок взять за продолжение, и совершенно нет никакой гарантии что ты попадешь в нужный, CRC - собъётся. Если была бы гарантия что каждые 250 байт (не 256, т.к. там меньше 2048 свободного) будет хоть что-то кроме ноликов - тогда это возможно. Но даже на спектрумовских дисках постоянно эти пустоты идут. Даже за 1000 оборотов ты не сможешь гарантированно сосканировать дорожку с секторами длиннее 128 байт. Когда 256 байт ноликов (пустой сектор) - ты будешь постоянно попадать то на начало, то на конец, то очень редко на середину (без начала и конца), но чтобы посчитать точно сколько там этих 4мкс импульсов - тебе нужно застать И начало И конец (т.е. хоть какие-то импульсы помимо 4мкс).
Есть кое-какие успехи в ковырянии ардуины (а именно 16МГц атмеги 328р, 8МГц лучше даже не пытаться использовать).
Взял за базу робсмитовский скетч и перелопатил его (ибо там неприемлемый жёсткий хардкод пороговых значений). Всё что связано с записью тоже конечно вырезал.
Только с асмовскими вставками смог добиться того, чтобы дотянуться до скорости, достаточной для чтения HD дисков (поток в 2 раза плотнее - не 4/6/8мкс, а 2/3/4мкс, это например 1.44Мб).
2Кб оперативы 328й явно недостаточно чтобы сохранять тайминги каждого импульса, и пиковой скорости в 2Мбита которые дает UART недостаточно чтобы в реальном времени дампить длительности импульсов (как это делает kryoflux).
Потому поступил иначе.
Сделал функцию сканирования дорожки - тайминги каждых 512 импульсов (это 64-128 байт raw данных) аккумулируются и выдаются друг за другом в виде статистики. То есть дорожка диска двойной плотности состоит где-то из 70-90 фрагментов. Эту инфу можно визуализировать, чтобы посмотреть что там за нечитаемый мусор (плавающая скорость и сектора с размагниченными фрагментами хорошо видны, как и неформатированные дорожки), а главное - чтобы использовать эту статистику для нормализации скорости записи, сделанной с неравномерной скоростью вращения. Включать этот режим "нормализации" и сканировать статистику наверное уже нужно только когда дефолтовые пороговые значения плохо сработали (т.е. если ошибки CRC). В большинстве случаев надобности в этой статистике нет, и дамп должен идти достаточно быстро.
К хостовому софту пока даже не приступал.
Думаю, проще будет сохранять результаты в hfe/udi образы (они вроде простые, и универсальные). Читалке без разницы что там за формат внутри - спектрумовский или атаревский.
Вот попытался визуализировать. Сверху - то что сосканировано лог.анализатором с частотой в 4Мгц, внизу - тот самый результат, который капчурит ардуин (одна и та же дорожка, но разные итерации чтения, поэтому "сбойные" импульсы не совсем совпадают).
http://volutar.eu5.org/fddscan1.png
Посреди 4го сектора некое "размытие" - там тайминги уплывают от 4мс в плюс-минус (компенсируя общую длительность). Из ардуинового скана такой момент не виден, но видно что впринципе равномерно, и достаточно плотно размазано.
Верхняя полоса - это 4мс импульсы.
Дорожка - пустая (поэтому 16 однополосчатых "пустот"). Штука в том что это 3.5", который прежде долго был HD диском (с таймингами 2/3/4мкс). Поэтому при перезаписи с двойной плотностью (4/6/8мкс) в длинных доменах проскакивает остаточное намагничивание предыдущих "коротких". И это остаточное намагничивание околопороговое, проскакивает не всегда. А что это за "размытие" на 4м секторе - ХЗ.
Младшая ардуинка (8мгц) в принципе думаю справится, в притык, только DD дисками. А 16мгц и с hd дисками. С процессом статистического сбора можно подбирать пороговые значения так что прочитается все что может прочитаться. Автоматического или даже ручного подбора (если надо такую опцию можно предусмотреть). Но это конечно это не сверхдетальный дамп как в kryoflux. Но ИМХО детализация криофлюкса избыточна. Зачем эта 40мгц с 25нс точность?
А вообще я тут прикинул, может и относительно детальный дамп получиться, если дампить по 6 бит на импульс — для выборки 8мгц хватит для DD диска, со значениями 24—87 (стандарт 32/48/64). На 2мбитовом UART в пиковом режиме скорость — 4мкс на 8 бит, или 3мкс на 6 бит. То есть варианты есть. И на сверхбюджетной ардуине получится лучше чем позволяет обычный FDC. Можно даже по 2кб читать отдельные фрагменты для детальной инспекции интересующих кусков, включая тайминги вплоть до 1мкс.
Кстати еще нашел вот: https://nickslabor.niteto.de/projekte/adf-copy-english/
Читалка на Teensy3.2
Не совсем бюджетный вариант. 2 тысячи стоит платка микроконтроллера. 72Мгц и 64К оперативы. Не густо для такой цены. При том что у ESP за 250р - 160МГц и 512К оперативы.
Сделал примитивную дампилку - 1.44Мб диски высокой плотности читает вполне надёжно и с одного оборота. А 640Кб спектрумовские, надо думать, будет читать и подавно. Просто саму хостовую программу нужно бы сделать нормальной. Не уверен насчёт консольности.
По-доброму у нее должно быть несколько режимов.
1. Quick, с предварительным анализом одной дорожки, вытащить общее пороговое значения для MFM декодирования всех дорожек.
2. Adaptive, с предварительным анализом каждой дорожки перед чтением, для составления и установки профиля изменения пороговых значений (для дорожек с плавающей скоростью).
3. Slow-partial, с чтением "точных" значений каждого импульса определенного куска дорожки (там где сбои CRC). Бывают сектора, в которых биты плавают не потому что там защита, а потому что происходит размагничивание и диффузия доменов (или "просвечивание" предыдущих доменов). Теоретически можно было бы сделать многопроходное чтение необходимых фрагментов, их "склеивание" со статистическим усреднением и "перебором". Весь диск в таком виде дампить совершенно бессмысленно, это избыточная информация, и нужна только для отдельных кусков.
Каждый вариант чтения по-доброму должен работать не для всего диска, а только для нужных дорожек. То есть грузить имеющийся образ, и обновлять в нём "особые" дорожки.
То есть сначала идёт чтение в режиме quick, если где-то проскакивает ошибка CRC - переключается для таких дорожек на adaptive. Если Adaptive не помогает - переключаться на slow-partial. Есть два варианта - Slow-partial режим включать в ходе основного прохода по дорожкам, но лучше ИМХО - после чтения диска. Пишется журнал результатов где помечаются дорожки-сектора с ошибками, и по ним идёт второй проход для коррекции этих особых случаев.
Стандартный HFE формат к сожалению не поддерживает плавающих импульсов. HFEv3 поддерживает, но его формат слишком мудрёный. UDI не поддерживает.
С целью более универсального использования предпочтительно наверное сохранять в HFE формате (а не в каком-то спектрумовском), но как быть с защищёнными-плавающими?.. Какие ещё есть универсальные, распространенные, и не слишком сложные?
- - - Добавлено - - -
Что-то форуму совсем нездоровится. Невозможно отправить сообщение без каких-то глюков и двойного постинга.
Начал экспериментировать с чтением фрагментов в режиме точного тайминга.
http://volutar.eu5.org/fddscan2.png
Точки с голубым оттенком наверху - места "склейки". HD дорожка прочиталась за ~40 оборотов встык. То есть ещё без умного склеивания, при котором нужно идти внахлёст и находить правильные границы (что не всегда возможно, но когда это невозможно - это как правило однородные участки которые даже если спутать - в принципе ничего страшного). Но читать таким макаром дорожку за 8 секунд - мало удовольствия. Это для "особых случаев". На скрине кстати такой особый случай хорошо виден (и в зелёной "статистике" и после кусочного чтения).
Попутно выяснилось, что даже с минимальным таймингом имеется неприятная дискретность в 3 clk при наблюдении за RDATA.
Так что точность на этой ардуине получается всё равно не 16MHz, а ~5MHz, то есть где-то 0.2мкс. Неприятно, но как бы и так хватает.Код:sbic 0x09, 4 ;1
rjmp .-4 ;2
Идея этого slow-partial в том, чтобы сначала загрузить дорогу в обычном MFM режиме, с 2 битами на импульс, и потом использовать его как "скелет", ориентир для загрузки более точных таймингов. Придётся мудрить с неточным сравнением и толерантностью (хорошо хоть что окно поиска небольшое).
Кстати, неформатированная дорожка в ардуиновой читалке выглядит примерно так:
http://volutar.eu5.org/fddscan3.png
- - - Добавлено - - -
Нифига не добавлено. Это форум уже притомил двойными постингами.
Избавился от дискретности в 3clk, поменяв способ подсчета таймингов (пришлось изменить распиновку, чтобы использовать ногу ICP1 для RDATA).
Значения получаются в разы более чёткие, чем прежде, можно сравнить графики с постом №30 (выше).
http://volutar.eu5.org/fddscan2b.png
В общем, при таком способе измерения таймингов может получится очень даже неплохо. Во всяком случае лучше, чем прежде кто-то на ардуине делал.
ЗЫ: Стал использовать counter1 в режиме Input capture mode (по фронту спада). То что он 16битный меня вообще никак не волнует - главное, что он умеет сам детектить фронт. Ну и заодно избавился от необходимости сбрасывать значение счетчика (вместо этого смотрю дельту). В общем сейчас от проекта Роба Смита мало что осталось, даже распиновка немного другая.