Arduino Floppy Disk Reader

[SoftLight]

Существует такой интересный проект: "Arduino Amiga Floppy Disk Reader (Writer)" от Роба Смита.

По сути, это сверхбюжетный аналог kryoflux. Он позволяет считать на дисководе всю инфу с дискеты на уровне контроллера, записать все сырые данные в файл и потом преобразовать в adf. Соотв., можно считывать всякий защищенный софт, нестандартные форматы и т.п.

Но он заточен исключительно на Амигу. Поэтому, родилось два вопроса:

1) Собрал ли кто-нибудь это устройство и опробовал?
2) Все исходники автором открыты. Насколько реально их переписать для поддержки дисков ZX, для считывания и последующей конвертации, например, в формат fdi или udi?

[Advertiser]

[Shadow Maker]

Для спека такое вот есть https://github.com/psbhlw/floppy-disk-ripper
Я тестировал, у меня нормально всё ограбляет.

[SoftLight]

Shadow Maker, я тестировал в свое время, игрушки с защитой типа ЗН, UFO-2 сдампились с массой ошибок и потом не работали. Возможно, это проблема дисковода.

[Shadow Maker]

Shadow Maker, я тестировал в свое время, игрушки с защитой типа ЗН, UFO-2 сдампились с массой ошибок и потом не работали. Возможно, это проблема дисковода.

Я пока из защищенных смог протестировать только ZX Format 8, вечером может за исдосами съезжу. Формат сконвертился в уди и запустился без каких-либо телодвижений.

[Dexus]

Отвечаю тут, ибо там оффтоп.

Ардуинко будет использовать скетч отсюда, только надо подправить константы чтобы она читала MFM формат в расчете на 300rpm. А нее - посмотрел скетч, даже править ничего ненада.

Посмотрел внимательно (пару дней изучал вопрос). Проблема в том, что скорости ардуинки нередко может не хватать, чтобы качественно опознавать MFM поток. У автора (Роба Смита), всю дорогу постоянно происходит борьба со сбоями, и читается с нескольких попыток. Длина raw трека 6250 байт, это 50кбит.
Если на PC сливать поток в форме расстояний между импульсами (переходами фазы), типа, промежутки между единичками, надо определиться с какой дискретизацией это передавать. Допустим, байт на расстояние. В самом плотном случае MFM даёт 1 смену потока на 1 бит (или 1.5 или 2). То есть это 50кбайт потока на один оборот, или 250кбайт в секунду. 2мбита в секунду вообще устройство-то потянет? В общем, слегка сомнительный проект получится.
Хотя, наверное, можно читать по сектору за оборот, и хранить в буфере (вроде у ардуины 2кб?), но цельный трек тогда уже не загрузишь, особенно если секторы с размером больше 256 байт.

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

Для спека такое вот есть https://github.com/psbhlw/floppy-disk-ripper

Дороговато, покупать целый дорогой спек ради чтения дисков (на фоне стоимости ардуины-то).
Так-то можно обычным спеком начитывать, и в тап перевести, если кому хочется спек задействовать (все защиты все равно используют стандартное raw-чтение ВГшки). И вообще не вижу связи с топиком.

[Shadow Maker]

Дороговато, покупать целый дорогой спек ради чтения дисков (на фоне стоимости ардуины-то).
Так-то можно обычным спеком начитывать, и в тап перевести, если кому хочется спек задействовать (все защиты все равно используют стандартное raw-чтение ВГшки). И вообще не вижу связи с топиком.

Не получится у тебя рав образ считать спеком, он же переврет всё. Связь с топиком только в том, что есть вариант для тех, у кого нет желания покупать ардуину, но есть Эва.

[Dexus]

Защита для спектрофона была на чтении рава и проверки межсекторной области (за 16м сектором). Так что если и перевирает, то не все.
Да и в большинстве случаев рав и не нужен. Обычное посекторное копирование, и через тап можно в трд загнать.

[Dexus]

Ардуиновские исходники (скетч) от Роба Смита в принципе пойдёт и для ZX, единственное - это увеличить количество доступных дорожек (у него захардкодено максимально дорожка 80). Софт для общения с устройством через UART может быть даже консольным (у Криофлюкса он и есть консольный). Красивая морда ни к чему.

Проблемы этих программ (той же ZX Disk Studio), что ими нельзя "задрачивать" какой-то отдельный трек при том что весь остальной диск считался за раз. Бывает же - немного размагнитилось, домены размылись, и идёт CRC Error. Как победить? Прочитать 50 раз кривую дорожку, проанализировать импульсы, подвигать туда-сюда в сомнительных местах, и скорее всего получится восстановить. Т.е. софт обязательно должна уметь брать уже загруженный образ (с ошибками), и дочитать в него только недостающие треки. Ну или работать в двухпроходном режиме, за первый проход считывать все как есть, помечая кривые треки, а за второй проход уже насиловать конкретные кривые дорожки.

UDI в принципе нормальный формат для защищённых дисков (где нет хитростей). Но по-идее HFE более универсальный.

[Dexus]

Накапчурил разных дисков лог.анализатором, на частоте 4МГц, и могу сказать, что задача в целом нетривиальная. Если это _хороший_ диск с постоянной скоростью - все более менее ОК, и то тайминги в 4/6/8мс могут варьироваться. Но диски у которых скорость неравномерна в течение одного оборота - просто нераспознаваемы такими вот константными значениями, которые захардкодены у Роба Смита.
Есть 2 варианта:

- добавить первый проход в ходе которого определять статистику по таймингам (есть диск на котором вместо 4мс пик значений гуляют от 3 до 5мс), и выстроить скоростной "график" для захвата. А потом уже читать поток с учётом плавающих скоростей. Проблемы бы не было если бы оперативной памяти хватало на оборот (хотя бы в уплотнённом виде). 50 тысяч для DD плотности и 100 тысяч доменов для HD. 2Кб оперативной памяти хватит только для статистики или скоростных параметров. RAW данные таймингов отдавать потоком невозможно даже через скоростной режим UART (даже 2мбита едва ли хватит). 4 бита на значение - недостаточно для качественной постобработки - но это уже 1мбит по UART для обычного DD диска. 6 бит - уже более-менее норм, но это полтора мегабита, и про процент ошибок при пересылке не надо забывать. И HD диски такое вообще не потянет.

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

Вот ещё сел заморочился. http://cowlark.com/fluxengine/index.html

[HardWareMan]

А что если внешний сепаратор прикрутить?