Arduino Floppy Disk Reader

Эти примеры выше - HD, т.е. 3.5" 1.44Мб диски. То есть "излишне" точные тайминги для нужд спека (2/3/4мкс).
Для сравнения - как выглядят обычные DD 640Кб 5.25" спектрумовские диски (4/6/8мкс):

http://volutar.eu5.org/fddscan5.png

Третий - для примера, 3.5" IBM 1.44Mb диск. Справа - 5.25", тоже PC-шный, но он какой-то странный. Почему-то 5 полос.

И, как я уже упоминал выше, что бывают диски с плавающей скоростью.

http://volutar.eu5.org/fddscan6f.png
0я,1я, 80я (пустая) дорожка.

Он судя по всему пустой, и с коцами на первых дорожках, но сам факт, что такие диски бывают. И скорость вращения при форматировании, судя по всему, у него была в целом медленнее чем 300об/с, где-то 240, наверное (с замедлением в на двух противоположных участках).

А на 80й дорожке забавный "размытый облик" дорожки - видимо дотягивается намагниченность от соседней, 79й дорожки.

Занялся выработкой стратегии чтения.
Дампить за один оборот - плохой вариант (но один диск считывается за 70 секунд)
Во-первых, индексное отверстие могло быть не в нужном месте во время записи/чтения (имеются такие диски), и заголовочные части секторов могут оказаться до индекса. Потому ZX Disk Studio, кстати, и очень чувствителен к расположению датчика, и вынуждает людей шаманить с этим, ибо умеет читать только от индекса до индекса. При чтении в два оборота надобности в этом уже нет, т.к. на втором обороте все эти сдвинутые данные так или иначе читаются целыми.

Можно конечно заморочиться, и читать диск вообще не синхронизируясь с индексным отверстием, а просто грузить объем чуть больше двух оборотов, и уже в данных разбирать где там начало, а где конец. Читал, что на каких-то ретроплатформах он в принципе игнорировался, и потому трек всегда начинался в случайном месте. При этом, конечно, желательно сам индексный импульс все-таки в пересылаемые данные как-то впихивать, чтоб алгоритму проще было потом после чтения ориентироваться.

А дампить трек в "красивом" виде со всеми таймингами (как в скринах выше), думаю, нет смысла - это ничего толком не даёт. Разве что чтобы убедиться, что диск действительно покоцан, и читать нет смысла, и статистического не детального графика хватит (который зелёным). Он-то, конечно, пригодится и для подстройки под скорость, и просто инспекции. Ведь в большинстве случаев все эти красивые графики, которые рисует Kryoflux, также бесполезны. Ну, видно что там мусор - читать его так или иначе бесполезно; ну, видно что "пограничные биты" - за три оборота обычного чтения это и при обычной пороговой дифференциации будет понятно. Начал считать, что этот точный захват потока - скорее фетиш. Вот реально, кому оно нужно, хранить 720кб диск как 40мб raw данные магнитного потока? Единственное - это для анализа какой-нибудь фендипуперной защиты, которая возможно даже и не в FM/MFM, а MFM2 или с ещё более хитрым методом кодирования. Но это едва ли относится к нашим стандартным ретроплатформам.

От автора FlashFloppy, очевидно хорошего специалиста по STM32, буквально пару недель как начал проект читалки/писалки на STM32F103 blue pill. Для этого дела видимо лучше отдельный топик открывать. Лично я до STM пока не добирался. Понятно, что там намного больше и памяти, и скорости, и DMA имеется, и программирование USB (а не через USB-USART модуль).

https://github.com/keirf/Greaseweazl...re-Connections

На хосте через питон, пишет scp образы.

Открыл отдельный топик:https://zx-pk.ru/threads/31038-greas...ov-flopov.html

Состояние дел:
Понемногу вникаю в скриптование на питоне, пишу конвертер из MFM потока в UDI.

Попутно обратил внимание, что ZX Disk Studio делает кривые HFE файлы (потратил часть времени на разбирательство с этим). То есть, надеяться на него вообще не стоит. Придётся, видимо, делать так же и свой конвертер в HFE (поскольку UDI не поддерживается FlashFloppy, и даже нельзя сконвертировать с помощью утилиты HxC).

На текущий момент особо показывать нечего. С Greaseweazle есть некоторые проблемы - чувствительности к вольтажу, из-за чего шаговый двигатель на 5.25" не работает без доп.схематики, неумение работать с неустойчивым оптическим датчиком index, из-за чего SCP захватываются криво.

Планы:
- Дописать конвертер HFEv1 в UDI 1.0 (в ходе конвертации отображать информацию о каких-то нестандартных моментах, и ошибках CRC).
- Дополнить конвертер возможностью преобразовывать образы из UDI 1.0 в HFEv1.
- Дополнить конвертер возможностью сохранения TRD образов (с warning'ом, если в формате есть нестандартности).
- Написать капчурилку с ардуины, которая в ходе чтения будет показывать физическую структуру дорожки, порядок секторов, CRC, возможные защиты, и давать многократно перечитывать не очень качественные дорожки.
- Приделать ардуиновую к сделанным на предыдущих этапах конверторам (чтение-сохранение HFE/UDI/TRD)
- Научить утилиту выводить логический каталог диска (TRD).
- .. Возможно дополнить конвертер импортом SCP (хотя по сути он нафиг не нужен, ужасно огромный, плюс из него HxC прекрасно в HFE умеет конвертировать). Но смысл всё-таки есть, поскольку существуют разные способы дешифровки и интерпретации уже имеющихся высокоточных образов.
- .... Возможно добавить в конвертер форматы образов других платформ.

Утилиту "захвата" на питоне имеет смысл сделать по типу консольной. Т.е. не через пачку параметров строки, а через вводимые инструкции (как в ftp, nslookup, fdisk/diskpart), потому как перечитывание сложных мест лучше делать отдельно, плюс лучше иметь возможность загрузки имеющихся образов и их корректировки без полного перечитывания всего диска. Т.е. имеется необходимость в интерактивности.

Пока доделал набросок конвертера HFE->UDI.
Работает не сверх-быстро, но что ж поделать - питон все-таки далёк от скорости нативного кода, но в реальном времени это делать не нужно, поэтому, думаю, простительно. К тому же он позволит быстро накидать любые другие форматы вывода, и подкорректировать в случае чего.
Подсчёт кривого UDIшного CRC делается вручную, потому в конце слегка будто подвисает.
Вложение 70720

Dexus, опробовал конвертер в udi, все шикарно работает и очень быстро плюс на выводе видно где дырки если они были при чтении. Спасибо!

SoftLight, благодарю за отзыв.

Вообще, парсинг структуры доржки я сделал с заделом на будущее. Помимо распознавания амижных секторов (которые идут с двойным A1, а не с тройным), ещё пытаюсь восстанавливать межсекторную структуру, синхронизируя GAP коды (0x4E) и 12 ноликов перед A1A1A1 (обычно синхронизируют байты ПОСЛЕ A1, а не до). UDIшки, которые создаются с живых дисков (а не конвертацией с логических образов типа SCL/TRD/FDI), грешат отсутствием синхронизации межсекторного пространства. В принципе оно и не требуется - на то они и межсекторные. Но всё-таки при просмотре содержимого дорожек в самом файле (или через какой-нибудь браузер образов, тот же ZXDS) лучше когда все поля чёткие. Возвращаемый этим парсером каталог секторов имеет отсылки на начало каждого сектора внутри дорожки, так что будет совсем несложно собрать из них любой логический формат (тот же TRD, FDI, ADF, IMG).

Когда доделаю UDI->HFE, можно будет UDIшки на физический носитель записывать (если HFE->SCP преобразовать через HxC, а SCP записать через тот же greaseweazle). Раньше, помню, такой путь был просто невозможен.

Сейчас при загрузке HFE, сектора с ошибкой CRC помечаются восклицательными знаками, обрезанные сектора - обратным слешем и количество байт в квадратных скобках (обрезанные сектора могут быть в конце диска, или с какими-то хитрыми защитами типа sector in sector). Пока они достаточно быстро проскакивают, можно пропустить и не заметить. Потому планирую сделать "терминальный" интерактивный режим при импорте-экспорте, с возможностью сохранения списка нестандартных треков и возможностью просматривать их структуру вербозно. В перспективе - подтягивать отдельные дорожки с "железа" (это когда уже взаимодействие с железом будет).

По правде говоря, у меня очень скромная база специфических образов дисков с защитой, на которых можно было бы все это дело отлаживать. Поэтому если попадётся что-то нестандартное, нераспознаваемое, будет интересно его пощупать и подфиксить тулзу.

Если я правильно помню, scp позволяет хранить в себе несколько разных попыток считать сектор. Мне вот стало интересно, какую попытку сохраняет конвертер француза в hfe. Выбора там никакого нет. Я просто сейчас вижу, что в файле после считывания диска на 53 дорожке только три сектора и это явно не защита, а просто дырка при чтении. Конвертер hfe2udi все сделал верно, а вот что происходило при конвертации из scp в hfe непонятно.

С большой вероятностью конвертируется первый оборот. Вообще по моему опыту эти несколько оборотов не помогут прочитать данные. Они лишь помогут увдеть насколько там все плохо. Посмотри в этой французской утилите саму поверхность (нижняя кнопка). Там обороты можно перематывать насколько я помню.

--добавлено--
Нет, французская утилита от HxC вообще бесполезна в этом смысле. Используй другую французскую утилиту - Aufit (https://info-coach.fr/atari/software...ects/Aufit.php)

Как успехи? Есть куча дисков c защитой и в нестандартных форматах, ожидающих прочтения.