Просмотр полной версии : Arduino Floppy Disk Reader
SoftLight
17.07.2019, 16:08
Существует такой интересный проект: "Arduino Amiga Floppy Disk Reader (Writer) (http://amiga.robsmithdev.co.uk)" от Роба Смита.
По сути, это сверхбюжетный аналог kryoflux. Он позволяет считать на дисководе всю инфу с дискеты на уровне контроллера, записать все сырые данные в файл и потом преобразовать в adf. Соотв., можно считывать всякий защищенный софт, нестандартные форматы и т.п.
Но он заточен исключительно на Амигу. Поэтому, родилось два вопроса:
1) Собрал ли кто-нибудь это устройство и опробовал?
2) Все исходники автором открыты. Насколько реально их переписать для поддержки дисков ZX, для считывания и последующей конвертации, например, в формат fdi или udi?
Shadow Maker
17.07.2019, 16:10
Для спека такое вот есть https://github.com/psbhlw/floppy-disk-ripper
Я тестировал, у меня нормально всё ограбляет.
SoftLight
17.07.2019, 16:17
Shadow Maker, я тестировал в свое время, игрушки с защитой типа ЗН, UFO-2 сдампились с массой ошибок и потом не работали. Возможно, это проблема дисковода.
Shadow Maker
17.07.2019, 16:24
Shadow Maker, я тестировал в свое время, игрушки с защитой типа ЗН, UFO-2 сдампились с массой ошибок и потом не работали. Возможно, это проблема дисковода.
Я пока из защищенных смог протестировать только ZX Format 8, вечером может за исдосами съезжу. Формат сконвертился в уди и запустился без каких-либо телодвижений.
Отвечаю тут, ибо там (https://zx-pk.ru/threads/12842-zx-disk-studio-programma-dlya-raboty-s-obrazami-diskov/page20.html) оффтоп.
Ардуинко будет использовать скетч (https://github.com/RobSmithDev/ArduinoFloppyDiskReader/blob/master/FloppyDriveController.sketch/FloppyDriveController.sketch.ino) отсюда (https://github.com/RobSmithDev/ArduinoFloppyDiskReader), только надо подправить константы чтобы она читала 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
11.08.2019, 17:27
Дороговато, покупать целый дорогой спек ради чтения дисков (на фоне стоимости ардуины-то).
Так-то можно обычным спеком начитывать, и в тап перевести, если кому хочется спек задействовать (все защиты все равно используют стандартное raw-чтение ВГшки). И вообще не вижу связи с топиком.
Не получится у тебя рав образ считать спеком, он же переврет всё. Связь с топиком только в том, что есть вариант для тех, у кого нет желания покупать ардуину, но есть Эва.
Защита для спектрофона была на чтении рава и проверки межсекторной области (за 16м сектором). Так что если и перевирает, то не все.
Да и в большинстве случаев рав и не нужен. Обычное посекторное копирование, и через тап можно в трд загнать.
Ардуиновские исходники (скетч) от Роба Смита в принципе пойдёт и для ZX, единственное - это увеличить количество доступных дорожек (у него захардкодено максимально дорожка 80). Софт для общения с устройством через UART может быть даже консольным (у Криофлюкса он и есть консольный). Красивая морда ни к чему.
Проблемы этих программ (той же ZX Disk Studio), что ими нельзя "задрачивать" какой-то отдельный трек при том что весь остальной диск считался за раз. Бывает же - немного размагнитилось, домены размылись, и идёт CRC Error. Как победить? Прочитать 50 раз кривую дорожку, проанализировать импульсы, подвигать туда-сюда в сомнительных местах, и скорее всего получится восстановить. Т.е. софт обязательно должна уметь брать уже загруженный образ (с ошибками), и дочитать в него только недостающие треки. Ну или работать в двухпроходном режиме, за первый проход считывать все как есть, помечая кривые треки, а за второй проход уже насиловать конкретные кривые дорожки.
UDI в принципе нормальный формат для защищённых дисков (где нет хитростей). Но по-идее HFE более универсальный.
Накапчурил разных дисков лог.анализатором, на частоте 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
05.10.2019, 20:19
А что если внешний сепаратор прикрутить?
А что если Arduino Mega 2560 (https://arduinomaster.ru/platy-arduino/plata-arduino-mega-2560/) прикрутить?
Памяти то побольше?
8кб, а не 2кб? При том, что цена в 1.5 раз дороже чем на esp32 (с учетом даже конвертеров уровней 3.3-5v). На буфер чтения не хватит в любом случае. И 20кб smt32f103 не хватит. Эти варианты (atmeg’и и stm’ки) - разве что для ограниченного капчуринга. Для большинства случаев, конечно, может и хватить. Но за один проход читать не всегда способны (см выше про плавающую скорость при записи). Дороговата эта мега2560, для своих параметров.
Печально что внешних spi/sram модулей нет. Только недешевые и при этом небольшие 32кб fram, и отдельные чипы sram, которые еще вмонтаживать нетривиально (уж явно сложнее чем на монтажной breadboard с десятком проводков и одним сопротивлением).
Esp32 мне видится более подходящим и недорогим кандидатом для качественной работы с любыми дисками на уровне kryoflux. А для ограниченного double density и ардуины хватит. Даже в принципе плавающие биты можно захватывать. Как раз для UDI. Жаль что flashfloppy его не поддерживает. А hfe(по крайней мере первый) не поддерживает плавающие биты.
В качестве бредовой идеи - STM32 и к нему цветной LCD дисплей по вкусу, с доступным чтением из памяти LCD.
1. объем недостаточен.
2. задержки.
Вообще есть проекты в которых из-за бомжовских объемах ОЗУ использовался бы экран с мусором?
Конечно, на бредовые идеи тратить время никто не запрещает. Вперед.
1. объем недостаточен.
2. задержки.
Вообще есть проекты в которых из-за бомжовских объемах ОЗУ использовался бы экран с мусором?
Конечно, на бредовые идеи тратить время никто не запрещает. Вперед.
Объема на одну дорожку должно бы хватить с запасом. Задержки, при использовании быстрого процессора с быстрым SPI, тоже не будут проблемой.
Бредовости же в использовании экранной памяти не больше, чем колхозить FRAM или, прости господи, статику. В свое время я подобный велосипед делал на DRAM.
Бредовость все же в разы больше чем колхозить dram. А spi fram модули для подобного куда более к месту чем _экран_, наглядно заполняемый мусором.
А памяти для свободного размещения дорожки HD диска нужно под 128кб. ED диска - 256кб. 512 кб - чтобы уровня Kryoflux достичь. С ESP32 за 250₽ в принципе все это достижимо без извращений в форме использования экрана как RAM буфера.
Вариант "на каждый расшифрованный MFM байт - один байт ОЗУ" - только для идеального случая. Для такого РобСмиттовский вариант пойдёт. А что-то посерьезнее, с нормализацией плавающей скорости, дампом произвольного flux потока хотя бы с частотой 8МГц, и распознаванием HD дисков (1.44Mb) - необходимо как минимум 128кб. Вообще смешные объемы для 2019г. Но микроконтроллеры с 8кб уже считаются "огого" по сравнению с ардуинским копеечным мусором с 2кб оперативы.. Не смешно?
ESP32 за 250₽
ну на esp32 - так на esp. почемуу бы и нет. Если стока много надо памяти
Но микроконтроллеры с 8кб уже считаются "огого" по сравнению с ардуинским копеечным мусором с 2кб оперативы.. Не смешно?
Ну как бы все относительно. Когда-то, в стародавние времена, 256кБ оперативы и 40 Мб винта хватало за глаза, сейчас 240Гб SSD ещё хватает, а вот 40 Гб памяти - уже нет(
Я считаю, что имеет смысл два варианта проработать. Самый дешевый, через ардуино, который сам будет готовить mfm поток, после первичного калибровочного чтения (для нормализации скоростных характеристик). И тот, который обеспечит анализ всяких защищенных дисков, то есть точные расстояния между импульсами. Для него нужно капчурить магнитный поток в несколько проходов, усреднять, итд. И тут 520кб памяти esp32 более чем достаточно.
Промежуточные какие-то версии типа бюджетных st32 особого смысла не имеют. Они все равно не дадут нужной детализации для качества, хотя бы близкого к kryoflux, но их возможности будут избыточнее ардуины.
дампом произвольного flux потока хотя бы с частотой 8МГц
На ардуине-то? Good luck, Mr.Gorsky.
Но микроконтроллеры с 8кб уже считаются "огого" по сравнению с ардуинским копеечным мусором с 2кб оперативы.. Не смешно?
Если не отлипать от ардуины, то можно ухохотаться, да.
На ардуине-то? Good luck, Mr.Gorsky.
На ардуине сами мучайтесь :). Да с LCD экранами вместо оперативки. Я же раза 3 выше это уже сказал.
Не могу понять, почему вам так принципиально читать всю дорожку целиком... ведь можно это делать посекторно, или часть дорожки, потом еще часть и т.д., да скорость чтения будет медленнее, но зато не нужны большие объемы памяти, считал килобайт, закинул на флешку и читай дальше...
Не могу понять, почему вам так принципиально читать всю дорожку целиком... ведь можно это делать посекторно, или часть дорожки, потом еще часть и т.д., да скорость чтения будет медленнее, но зато не нужны большие объемы памяти, считал килобайт, закинул на флешку и читай дальше...
есть трековые форматы, например, MX для ДВК.
Не могу понять, почему вам так принципиально читать всю дорожку целиком... ведь можно это делать посекторно
Можно. Но смысл? Ни одну защиту это не возьмет. Плюс бывают сектора 4к размером. Плюс один фиг надо продумывать способ адаптации к плавающим скоростям, не в постобработке на ПК, а «налету».
или часть дорожки, потом еще часть и т.д., да скорость чтения будет медленнее, но зато не нужны большие объемы памяти, считал килобайт, закинул на флешку и читай дальше...
Каким образом «продолжить чтение», если там расстояния постоянно плавают, и невозможно точно попасть в то же место на другом обороте? Да и сами импульсы бывает есть, а бывает нет (хоть это и не часто, но это помешает найти ту же позицию для сшивания).
Продумай стабильный алгоритм такой безглючной многопроходной склейки, вперед.
Добавлено: 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.
sbic 0x09, 4 ;1
rjmp .-4 ;2
Так что точность на этой ардуине получается всё равно не 16MHz, а ~5MHz, то есть где-то 0.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битный меня вообще никак не волнует - главное, что он умеет сам детектить фронт. Ну и заодно избавился от необходимости сбрасывать значение счетчика (вместо этого смотрю дельту). В общем сейчас от проекта Роба Смита мало что осталось, даже распиновка немного другая.
Эти примеры выше - 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/Greaseweazle/wiki/Hardware-Connections
На хосте через питон, пишет scp образы.
Открыл отдельный топик:https://zx-pk.ru/threads/31038-greaseweazle-byudzhetnyj-usb-kontroler-dlya-chteniya-zapisi-obrazov-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
SoftLight
22.11.2019, 00:14
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). Пока они достаточно быстро проскакивают, можно пропустить и не заметить. Потому планирую сделать "терминальный" интерактивный режим при импорте-экспорте, с возможностью сохранения списка нестандартных треков и возможностью просматривать их структуру вербозно. В перспективе - подтягивать отдельные дорожки с "железа" (это когда уже взаимодействие с железом будет).
По правде говоря, у меня очень скромная база специфических образов дисков с защитой, на которых можно было бы все это дело отлаживать. Поэтому если попадётся что-то нестандартное, нераспознаваемое, будет интересно его пощупать и подфиксить тулзу.
SoftLight
22.11.2019, 08:52
Если я правильно помню, scp позволяет хранить в себе несколько разных попыток считать сектор. Мне вот стало интересно, какую попытку сохраняет конвертер француза в hfe. Выбора там никакого нет. Я просто сейчас вижу, что в файле после считывания диска на 53 дорожке только три сектора и это явно не защита, а просто дырка при чтении. Конвертер hfe2udi все сделал верно, а вот что происходило при конвертации из scp в hfe непонятно.
С большой вероятностью конвертируется первый оборот. Вообще по моему опыту эти несколько оборотов не помогут прочитать данные. Они лишь помогут увдеть насколько там все плохо. Посмотри в этой французской утилите саму поверхность (нижняя кнопка). Там обороты можно перематывать насколько я помню.
--добавлено--
Нет, французская утилита от HxC вообще бесполезна в этом смысле. Используй другую французскую утилиту - Aufit (https://info-coach.fr/atari/software/pc-projects/Aufit.php)
Как успехи? Есть куча дисков c защитой и в нестандартных форматах, ожидающих прочтения.
Как успехи? Есть куча дисков c защитой и в нестандартных форматах, ожидающих прочтения.
А как же Spectrum Archive Reader (https://zx-pk.ru/threads/31601-spectrum-archive-reader-programma-dlya-chteniya-tr-dos-diskov.html)?
Со своим скриптованием тормознулось, т.к. практически исчезло свободное время. Застрял с алгоритмом склеивания кусочков для режима тщательной загрузки, а до считывания с вариабельной скоростью просто не добрался... увы
А как же Spectrum Archive Reader?
Лучший софт!
Но он защиту и mfm он не умеет же. Плюс хотелось бы цифровать в 2-3 потока.
Как это он не умеет mfm? Хитрую защиту с межсекторными данными - допускаю, что он плохо умеет, т.к те же самые проблемы с чтением raw (ошибочные 0xc2), что и на ВГ93, но mfm-то явно в норме.
Ну и главный недостаток этих продуктов, основанных на драйвере fdc, что самого контроллера сейчас нет, только древние материнки подойдут:(. Хотя у спектрумистов это наверное не проблема, большинство сидит на древних компах...
Я в принципе мог бы выложить текущие наработки, но едва ли они кому-то помогут, т.к там дофига всего не вылезло из стадии экспериментов, и даже примитивной читалки в питон не встроил, все в рамках той графической приблуды, написанной на дельфи. *пожал плечами*
И что это за цифрование в 2-3 потока??
Новорождёныш. Умеет только капчурить в UDI с дефолтовыми значениями.
http://volutar.eu5.org/afd001a.7z
Все тот же питон и pyserial. Много чего надо приделать, знаю. Если надо по 80 дорожек капчурить — в скрипте надеюсь найдете и поправите.:)
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot