Arduino Floppy Dump utility

В соседнем треде была презентация моей мини-разработки.
Тут - отдельная тема, с продолжением самостоятельной жизни.

Arduino Floppy DUMP utility - консольное приложение, написанное на python, предназначено для дампования флопиков (главным образом 5.25", но и 3.5" даже PC-шные HD диски по идее должен без проблем захватываться), и для сохранения образов в разных форматах. Работает в связке с микроконтроллером ATMega328(16MHz).

Ссылка на предка - http://amiga.robsmithdev.co.uk/instructions

Вводные данные:
При MFM кодировании один байт информации конвертируется в 4-8 импульсов. Импульс генерируется при развороте направления намагниченности.
В MFM всего возможно 3 разных длительности (4, 6, 8мкс для DD и 2, 3, 4мкс для HD дисков).
Скорость вращения диска - 300об/мин, или 5об/с (бывает 360об/мин, но это не наш случай). Таким образом длительность трека - 200мс, или 200000мкс. То есть для DD диска один трек вмещает 25000-50000 импульсов, а HD диска - 50000-100000 импульсов.
При загрузке данных из Arduino одна длительность кодируется 2 битами (используются комбинации b01 b10 и b11, а b00 - служебный, завершение потока - 0x00). Таким образом мы имеем в одном переданном байте 4 MFM длительности (импульса). То есть каждый байт исходной информации - это 1-2 байта, переданных из устройства.
То есть, длина дорожки при загрузке данных из устройства - это от 6250 до 12500 байт для DD диска. Для HD диска, соответственно, от 12500 до 25000 байт.
DD диски (основная масса 5.25" включая ZX, а также старые 3.5") имеют длину дорожки в исходных данных 6250 байт, HD диски - 12500 байт.
За одну секунду трек загружается 5 раз (поскольку совершается 5 оборотов). Таким образом, плотность информации, загружаемой с устройства в MFM формате - это до 62500 байт в секунду (cps) для DD диска, и до 125000 cps для HD диска.

То есть минимально возможная скорость, при которой HD дорожка будет успевать передаваться через USB-Serial - это 125000*(8+2) = 1250000Кбит/с. Для DD дисков, соответственно, 625000 Кбит/с.

Таким образом для работы с HD дисками скорость работы UART должна быть 2Мбита/с, а для DD дисков достаточно 1Мбита/с. Это необходимо учитывать.

Что нужно:
1. Arduino (варианты)
- а) Устройство на ATMega328 (16mhz), типа того как на рисунке (Arduino Pro Mini) + USB-Uart контроллер - FTDI-совместимый (т.к. без труда 2Мбита прокачивает). CP2102 не подходит (макс 1Мбит).
- б) Вероятно будут работать и Arduino Uno (на AtMega328-16), и другие платы с интегрированными USB-Uart адаптерами на FTDI/FT232RL, обеспечивающие скорость 2Мбит/с. Это надо проверять.
- в) Дешевый Arduino Nano, со встроенным CH340 (без кристаллов) - фирмварь прошивается в режиме Old bootloader. На скорости 2МБита работает с ошибками (~0.02% ошибок), на 1Мбита - ошибок нет, т.е. пойдёт только для DD дисков.
2. Обвязка ардуины
- бредборд (монтажная доска).
- соединительные провода (возможно и без бредборды, если цеплять к самим ножкам ардуины).
- 1кОм сопротивление (для подтягивания линии данных до 5в).
- блок питания и шлейф для FDD.
3. На хостовом ПК
- Windows>=7, вроде и Linux и MacOS (но это не проверялось).
- python>=v3.6. Библиотека pySerial
- Arduino SDK.

Запись дисков не предусмотрена (и, вероятно, не будет), поэтому ардуиновые ножки A0/A1/A2, и 3 не задействованы. Кроме того, поменяны местами ножки 4 и 8 (это все в сравнении с проектом Роба Смита).

Если используется Arduino с UART, не дающим безглючные 2Мбита, то HD диски читать не получится. Однако, с DD дисками возможно будет работать. Для этого необходимо сообразно поправить скетч (.ino файл строка вначале "#define BAUDRATE 2000000"), и сам .py файл (строка "ser.baudrate=2000000"), на, соответственно 1000000.

Схема:
http://volutar.eu5.org/afdcircuit.png

Мой сетап:
http://volutar.eu5.org/afdsetup.jpg

Питание для дисковода отдельное. Шлейф - родной спектрумовский. Ножки 10-12-14-16 разъема соединены между собой на монтажной платке (чтобы было пофигу - перевернут кабель или нет). Шлейф насажен на обычные недорогие контактные штырьки (причём впаяно не всей гребенкой, а по-отдельности штырьки, а для земли всего 1 линия) - покупкой 34-пинового разъема не заморачивался. Шлейф воткнут с обратной стороны (на фото не видно).

--------
Зачем вообще? Материнки перестали делать с FDD контроллерами, raw driver никак не подцепишь. Да даже если подцепишь — этот raw driver весьма ограничен в своих возможностях «подкрутить» параметры чтения, что мешает нормально читать некоторые не очень качественные диски.
Ардуино — дёшево, и сердито (это попытка выжать максимум из 8мибитного 16мгц микроконтроллера с 2кб ОЗУ), прекрасно работает с 5в устройствами, и есть почти в каждой российской семье. Люди относятся к Ардуине, как платформы для захвата, весьма скептически. Вот и посмотрим.

Альтернативы:
- greaseweazle - неплохой проект, работает на недорогой STM32 "blue pill", захватывает поток по таймингам не хуже kryoflux, но плохо дружит с 5.25" дисководами (вроде этот аспект недавно поправили - дребезг оптического датчика индекса теперь _вроде_ фильтруется). Но хостовая часть пока мало что позволяет. Плюс он появился позднее, чем я начал свой проект, так что пусть.
- Arduino floppy disk reader/writer - проект-предок сабжа. Умеет даже писать, но не всеядный - ориентирован на Амиги, и вообще, достаточно плохо оптимизирован с точки зрения firmware, не умеет HD диски, тайминги захардкодены. То есть очень узкозаточенный.
- FluxEngine - неплохой вариант. Построен на достаточно экзотичной плате CY8CKIT-059, которая дороже Arduino раз в 10 (но с учетом необходимого FTDI - всего раз в 5), умеет писать некоторые форматы, но спектрумских вообще не знает.
- всякие дорогие устройства (сами знаете).

--------
Текущая версия скрипт + фирмварь:
0.01b http://volutar.eu5.org/afd001b.7z

--------
История изменений:
2020-08-07 v0.01b - подстройка под тайминги для каждой дороги, дорожки за 80й обрезаются (если пустые), вывод красивой статистики
2020-08-05 v0.01a - первый релиз, сохраняет UDI, настроена на стандартные тайминги DD дисков 32/48/64 (4/6/8мкс)

Цитата:

Сообщение от Dexus

Каким образом можно ответить в теме, не приклеивая к предыдущему сообщению, без вот этой шняги с "Добавлено"?
Мне нужно новое сообщение, не трогая нуль-поста.

Ждать...

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

Или писать новое сейчас вот :)

Смотрю тут, насколько удобно будет выводить "содержимое" дорожки для юстировки пороговых значений...
Если брать просто усредненное, то там не факт что поможет. Вот например:

Код:

Arduino floppy dump utility v0.01b (UDI) (c) 2019-2020 by Denis Dratov Port: COM6 - AFD device, firmware version 1.0 Rotation speed: 300.2883 rpm Probing track stats, to figure thresholds.. us-----2|------3|------4|------5|------6|------7|------8|------9| ,Xx. .xX#- #Xx. .xX+. .,... X%+. ,xx. .... %+ .%- +% XX- xx#+ x#Xx- . ,+xx+. . .,... . ,..-xX#-,,,,,...,,.,,.,,,.,,,,.,..,... . .. .... . ... . . ,---++--+++++--+-----------,----,,-,... ..... ...... ,----+++++x++++----+-----+----,-.,.,... . .. ...,. . . .,,-.-,-+-----+--,+-+++---+---,,,----,,,,,......... . .... ...,-,+++++++---------,,-,-.,,-,--,,,,--.,.-,,,,,..., . .. ...,.x#+++xxxx++,.,. ,.... .,,,-,. +% %, %+ %%.. ,.,. ##x,. .+x##, ..... %+-.. .-++.. ..... %X x% .%, X#x. .xx#x. +%x-. -+x+. ..,., -%, %X X% +%+, -x+. #X+ .##+. .,,. X%. ,.. ., x%- ,%# %% x%, ,#+#- ... +%# .++x, .,.. %% #%, ,%X %X +xx+ .#%. ,x#x. .,,. x%+ +%X %% %%, . #X+ .x#x#- , . .x%# -+,+, ... %X +%X +%X .#Xx ,xxxx, ,X. +###- #x .x##x, .x#. +###x ##. .x#Xx- .x#x -+x##x+, ,Xx xx##+ +xx+ .++xxxxx- .#x +#X#. ,X+ x#X#. ##. -x##x. ##. .x##+ x#. +#X#. x# -###- ,X. ####. .X+ -###- #x -XX- x# .#X#. +X. ,XX- .X- ##X. Xx +XX, #x .XXx ## #X# ## ###. ## #X# ## #Xx ## XXx #x -XXx Xx +XX+ .X+ x#X, .X- X#X. .X, X#x. -X. -XXx +X x#X- xX. ##X, ## .X##, ## ,X##. #x +XXx X+ xXX- .X- x#X- ,X. ##X, .X- ##X ,X- .X##, -X+ -X#x +X- +XX+ . x#. +### .

Я уже показывал этот диск в соседней теме, но в графическом виде:
http://volutar.eu5.org/fddscan6f2.png

Очень сильно плавающие значения. Это максимальное разрешение по времени (сверху вниз, каждая строка - информация о таймингах на ~~128~~ 512 поворотов доменов). Если для каждого куска использовать свои пороги - в принципе даже что-то можно вытащить (конечно, не того участка который почти в самом начале - там дохлый номер). Но если первым этапом сканировать нулевую дорожку, и использовать усредненные тайминги для прочитки всего диска...

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

Но если такую логику применить к этому диску - на первой же дорожке фейл. Т.е. усредненное будет мусорным, прочитать ничего не сможет с константным значением, взятым из этой кривой нулевой дороги.
И тут ведь как повезёт - первая дорога может быть отличной, а следующие все с другими, кривыми таймингами. В таком случае он будет впустую шлёпать до конца с относительно быстрой скоростью... просто потом ещё разок будет читать, но в 2 раза медленнее, по фактически всем дорожкам.
Как быть? Не хотелось бы городить лишние параметры. Учитывая, что заранее ведь человеку неизвестно насколько там всё плохо...
Даже брать пару дорожек, и усреднять их может не помочь...

Вот так будет выглядеть утрамбованная в 4 раза "картинка":

Код:

%%#, ,X%X- .,-,.. x#%%+ . ,+###+ . .,... . . .--++#XXxxxxx##xxxxxxxxxxxxxxxx+++x++-++--,,,,,-,,..-,,,,. .,.--#%xxx#x#xxx-------,---.,,-,--,,,,--.,.------,.., . .. %%#x,, .+###,. ,..., %%#x. .xx#x. +%%-. -+x+. ..,., +%%x -X#+. .-,. ,%%# -#x#+ .,.. %%% +xx+ .X%% ,x#x. .,,. .%%% .x#x#+ -.. ,%%% +XXXx, .x##X%x -+x####X#X%Xx, ,X##%# x#XX#x#%%X, %%. -X%%%- ,%% #%%%#. +%# ,%%%x %% %%%. .%X #%%# x%+ #%%%. %%. x%%%- -%x %%%+ . #%x +#%%X, .

Выводить на второй стадии для каждой дорожки, на которой были ошибки CRC, такое вот ASCII'шное "художество"?
~20 строки на дорожку DD диска, соответственно ~40 для HD (которые PCшные, 1.2/1.44). В принципе, для HDшных можно ужимать в 8 раз, чтобы не засирать экран ими.
Символы для отображения плотности сделал пока .,-+x#X% - можете предложить свои варианты.

Есть вариант объединить 1й и 2й проход. Т.е.:
0. Сканировать 0ю дорогу, взять из нее усредненные тайминги.

1. Читать дорогу с усредненными таймингами (с предыдущего шага).
2. Если были ошибки - сканировать тайминги, и повторно перечитывать дорогу с подробными таймингами. Взять из них же усреднённые, "на будущее".
3. Следующая дорога, шаг №1

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

0.01b http://volutar.eu5.org/afd001b.7z
- Капчурятся 83 дорожки, но если последние пустые - в образ они не сохраняются.
- Собирается статистика, выбираются значения для MFM порогов (из-за этого дорожка читается дважды)
- Статистика выводится для КАЖДОЙ дорожки (и поэтому скорость медленнее для всего диска)
- Сохраняет журнал в dump.log
- Если имя не указано в параметре - спрашивает его после захвата, перед непосредственным сохранением
- Обновлена фирмварь, пороговые значения повышены до 192 (вдруг это SD диск)

Загрузка со статистикой выглядит подобрым образом:

Код:

Rotation speed: 300.2883 rpm .: V V :: .. :::. ::: ::::: ::::. . :::::. :::::: .::: :::::: :::::: :::::: : :.::::::: .::::::: :::::: . .:::.::::::::::::: :.: :::::::::: ... .:::::::. :. us------2-------3-------4-------5-------6-------7-------8-------9 Track type: MFM/DD Period=4.00us Quality: 90.61% 000: T000:0 len256 01 09 02 0A 03 0B 04 0C 05 0D 06 0E 07 0F 08 10 .:. V V :::. .::. ::::: ::::: .: :::::: :::::. :::: :::::: :::::: :::::. .:::::: ::::::: :::::: . .:::::::. ::::::: :::::: . :: :...:::::::::. :::..:::::::: ... ::::::. : us------2-------3-------4-------5-------6-------7-------8-------9 Track type: MFM/DD Period=4.00us Quality: 91.26% 001: T000:0 len256 01 09 02 0A 03 0B 04 0C 05 0D 06 0E 07 0F 08 10

Буковками V обозначается место, которое автоматом выбирается для порога (всего два порога)

Словом, HD диски, которые 1.44, капчурятся без особых проблем (что с прошивкой Роба Смита было невозможно).
Статистика выглядит вот так:

Код:

.: :: : :: :: . :: :: .: ::. :: :: ::: ::: ::: : ::::.. .:::: :::: :::::::::::::::.. ::::: : ... .. : ... . ::: :. us------2-------3-------4-------5-------6-------7-------8-------9

А неформатированные вот так:

Код:

.::::::...... :::::::::::::::::::::::::.................... .::::::::::::::::::::::::::::::::::::::::::::::::::::::: .::::::::::::::::::::::::::::::::::::::::::::::::::::::::: .... .:::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: us------2-------3-------4-------5-------6-------7-------8-------9

Почему там от 2.5микросекунд идет спад - хз. Это 5.25" дисковод, и возможно, что просто быстродействия компонентов не хватает чтобы в этой шустрой части спектра было достаточно насыщено. На 3.5" дисководе неформатированные пока не смотрел. Но там 2мкс тайминги спокойно захватываются, влоть до ~1.4мкс (цикл захвата соптимизировал как смог). В общем-то мне 3.5" постольку поскольку - весь архив в 5.25".

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

Сейчас размышляю о том, каким образом лучше создавать "кривую скорости". Т.е. чтобы справиться с ситуацией из поста №3. Какой-то чуть более хитрый, двухмерный стат.анализ надо привлекать..

А помимо этого еще есть вот такие ситуации:

Код:

us------2-------3-------4-------5-------6-------7-------8-------9 X%x. .x+- . . . .xX#-. .x##x- ..... xXx-xX-.. -+.. ..,--, .... ... X#. .##-. .++. ..-+, .. . .. #X +%+ .X#+Xx .xXx. .+##+. ,. . . -XX#. .,xx ... xX+Xx, .-++++-. ,,... +%#X. ,%#X . x#,#x- .xx, xx. . . . x###x, .-x+++-. ...,.... +%+. ,xx+ -,. #% . -##x . x##+ -+-. .+#x#x, +x++x+,. .,..... x#,+xx+. .+x+ -++-. .+-, ,+-. -#xxx+, ,xx-xx+. ,--,--. .+#xx- ,xxxx. .-x+++ xX#, .x##x. .... -x#xxxx-. ,+++--x+-, .,., .-,.. +#- +xx+ +x, ,+x- .-+. ---,. +#- +xx+. xx. -+x+. ,+-, -+-, -xx+xx--. -+xx-+xx-.. .-. ..,,. #%x, .+#x- . --, -x##x- ++xx-, .-+x+.. -x#xx+ +xx+x, --+--. . +xxxx+. . +x++x+. .-+-+,. xx.-#+. -#+. +#+ . . .. .. .,###x. -xxx+. -++, +##+ +#x+ .+x+. +##+ +xx, .+x+, :.. .. . .:::. :: :: . . ::::: :::::. :..:: ::::: .:::::: :::::: :::::. ::::::: ::::::: :::::: ::::::: ::::::: :.: :::::: .::::::: . ::::::: .. ..:::::.::::::. :: .::::::::::.: ::::::::::::. . us------2-------3-------4-------5-------6-------7-------8-------9

Что тут? Очевидно, перемагниченные области, в которых сдвигается магнитная поляризация целых фрагментов дисков. Таким образом все четные домены оказываются чуть короче, а нечётные - длиннее (общая длительность остается той же, просто сдвигаются границы в + или в -).
Линии "раздваиваются". Если "плюс" одной полоски пересекается с "минусом" другой (т.е. эти раздвоенности залазят на соседние) - уже стандартным способом не прочитаешь. Тут либо надо читать полный RAW, в котором и четные и нечетные тайминги будут очевидны. И тогда можно компенсировать, "выровнять" эти расплывы (но на это Ардуино скорее всего не способен, ибо памяти мало чтобы все читать без обработки), либо изобретать какой-то способ раздельного чтения четных и нечетных полосок, с последующей рекомбинацией... Нормализацию четных-нечётных доменов, кстати, и greaseweasle не умеет (хотя это ему ничего бы не стоило).

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

Чтобы выводить "подробный" график дорожки, в текущей версии (0.01b) достаточно раскомментировать строку №182 (# print_ba(stats[a-64:a])). Если у кого-то есть подобные кейсы - прошу делиться.

Есть некоторые затруднения с анализом статистики
Такой пример:

Код:

us------2-------3-------4-------5-------6-------7-------8-------9 x#, xx+.. -#x. .,+x+. .,, ..... +#x .+x++, ,+x, +x+-. ,++. .--,, #x, .x+x,. .x#, .-xx, ., ... .x#, .xxx.. ,#x .,xx- ,,. ...,. x#- .#x--. .+x. ,-++. ,- ..,,, . ##. .#++ .,x+. . +-+, . . +#+.,x+x+. .xx, ..-+++. .--. .---,. xx, x+x- -#x- .+xx+. ... .... x#, .xx-. ,#x, .-+#- .,. .., +xx.,++x+, ,+x-. .+++-. ,++, ,-+-- +#, .xx-. . +#x, .-x+x, .. .... +#+ ,xx-, .x#-. ,-xx. . ..,,.. . +#+ +x+x, . xx-, .-x+x- ., . .

Тут - обычный MFM. Должно быть 3 полоски. но их тут 6. Это и есть то самое перемагничивание. Четные импульсы удлиняются, нечётные укорачиваются
Происходит вот такое:

Код:

-------\ /------\ \ / \ +++++++++\-----------/++++++++++\------ \ / \ \_______/ \____ -----\ /--\ \ / \ +++++++\---------------/++++++\-------- \ / \ \ / \ \ / \ \_______/ \____

Соответственно, выделять первые три (две) полоски для разметки таймингов для таких вот дисков - нельзя. Тут надо делить на четные и нечетные. Проблема в том что есть плавающая скорость, а есть плавающая перемагниченность, и их нужно обрабатывать соответствующе. Поскольку изменение скорости влияет на 1.5х и 2х длительности как множитель, а перемагничивание влияет как суммирование. Если это просто скорость - тут проблем нет. Можно за счет динамического изменения пороговых значений, которые перед чтением впихнуть в ардуину перед чтением MFM потока.

Но для каждой такой "перемагниченной" дорожки нужно несколько раз считывать статистику четных и нечетных (несколько - потому что нет никакой гарантии, что чтение начнется с четной или не четной - импульсы одинаково кодируются). Потом находить траекторию по каждому потоку - четному и нечетному, если они совпадают - значит перемагничивания нет, и можно читать без четного/нечетного, если расходятся - значит есть перемагниченность, и тогда нужна ОТДЕЛЬНАЯ процедура чтения, в которую нужно впихивать два массива для компенсации внутридорожной динамики - помимо пороговых значений, еще и отклонения для четных-нечетных импульсов. А потом читать дорогу, возможно несколько раз, поскольку также нет никакой гарантии, что четные попадут на четные.

Сразу понять что в дороге есть эта перемагниченность в принципе можно - статистика для них будет не из трёх бугров состоять а как минимум четырёх. Но это не обязательно - если там плавает скорость (как в примере из поста №3), то количество бугров вообще ничего не значит - там они все дико размыты:

Код:

. ... .. ::: . ::::::::::.:::::..:::: :::::::::::::::::::::::. :::::::::::::::::::::::::: ::::::::::::::::::::::::::. ::::::::::::::::::::::::::::.:.:: .. . .::.. ::::::::::::::::::::::::::::::::::.::.:::.:.::::::.::: : :: : :::::::::::::::::::::::::::::::::::::::::::::::::::::: us------2-------3-------4-------5-------6-------7-------8-------9

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

Один и тот же фрагмент статистики, взятой разными способами (это диск isdos, приличная часть секторов которого не читается):

Код:

Общий -X#, .xxxx, .xx -%x x+.#- -x+ -Xx .x+-#. -#. +Xx ,#--x- -x, xx-#xx. .xxxx, -x+. +x, ,xxx+, ,+++ +++ .+x+- -#. ..xxx++x-.. x+ -#, . #- xx x#- xx-#, . . .X+,#-.++...+x,. ..,x..+-.,. . .. xx . +x+x-,xx. -xx .xx, x+ +##+ ,xx +x- ,x+ +# xx#. ,#-#+ -x- .#,+#x+ +#x. +x, +##x ,xxxx, -x+ ,X#. xx .xx -#. .X#, xx..xx xx. +##x .xxxx -x- #-x#x .#x #+ us------2-------3-------4-------5-------6-------7-------8-------9 Четный ,##- xx -#x #+ .#x x+ +#x ,#- -#xx. -+x. ,xxx+- +x+ ..xxx+. . .#+ . xx xx-#, . .#-,+-., ...,x,.+-. . .. . +x+x- ,xx +xx+. +x- xx#. .#+ +#x+ .xx. x#x. ,x+. .##. xx. ,##. +x. +#x. .xx. .x#x ,x+ us------2-------3-------4-------5-------6-------7-------8-------9 Нечетный -#. .+x, ,xx. .#, ,#- ,x+ -# -#. -# -#, -x+ ,#, xx. .x++ -x+, +x, ,+++ +x+, ,#. .+x-. -#- #- x#- . .,X+. +x,. ,. xx -x+, .xx, xx ,x+ ,xx +# -#- -#, .#. +x- xx, +x. .xx. -x+ #, xx -# #. .x+ xx. +x .xx. -x- #- xx .x+ us------2-------3-------4-------5-------6-------7-------8-------9

Чётный/нечётный берутся на "как повезет", т.е. нет 100% гарантии что загрузится именно чётный а не нечётный, и в ~20% случаев чётный равен нечётному. По факту-то, конечно, это не так (не равны), но в силу неидеальных таймингов электроники дисковода, пропуск одного магнитного импульса после появления индекса не помогает.

В общем, сейчас дошел до такого алгоритма (в случае ошибки чтения дорожки в быстром режиме):

1. Загрузить ОБЩУЮ статистику
2. Загрузить статистику через один импульс (как повезет - 80% нечётную и 20% чётную)
3. Вычислить разницу между общей и половиной и проанализировать:
А) Половины почти совпадают (отклонения несущественные) - значит перемагниченности нет (эту характеристику, кстати, неплохо было бы выводить в инфо о треке).
Б) Половины заметно не совпадают - значит дорожки имеют перемагниченность. В таком случае необходимо вычислить кривую для компенсации перемагниченности (№1), с учётом того, что в разности будет выпирть чётный.
4. Усреднить общие-нечётные, и составить кривую пороговых значений, компенсирующую плавающую скорость (№2). Также вывести величину неравномерности скорости.
5. Читать дорожку в режиме "особый", с кривыми скорости и перемагниченности. В 80% случаев она будет прочитана как надо, и в 20% случаев компенсация перемагниченности усугубит картину. За несколько попыток всё должно будет прочитаться (1-80% 2-96% 3-99.2% 4-99.84% 5-99.97%).

Но если и в этом случае будут проблемы, необходимо дампить "сырые" данные таймингов, и делать что-то с ними. Хотя скорее всего это будет означать что там плавающие биты, либо дорога местами физически провреждена, либо размагнитилась (когда граница между + и - размывается до исчезновения). Ну, в этой ситуации... мы... просто наша, эта самая... мы уже здесь наши полномочия всё, окончены.

ЗЫ: Процедуру особого чтения уже сделал, перед чтением дорожки нужно загрузить массив порогов и четно-нечетных отклонений. По 3 байта на каждый "чанк" (который равен 128 байтам, т.е. 512 MFM импульсам). По сути остается всю эту алгоритмику, анализ статистики и вычисления графиков в питоне запрограммировать.

Цитата:

Сообщение от Dexus

Альтернативы:
- greaseweazle - неплохой проект, работает на недорогой STM32 "blue pill", но плохо дружит с 5.25" дисководами. Плюс появился позднее, чем я начал свой проект.
- Arduino floppy disk reader/writer - тоже неплох. Умеет даже писать, но не всеядный - ориентирован на Амиги, и вообще, достаточно плохо оптимизирован с точки зрения firmware, не умеет HD диски, тайминги захардкодены.
- всякие дорогие устройства (сами знаете).

Так а чем плох FluxEngine ?
Я тоже часто предпочитаю делать свои устройства, потому что мне нужно не всегда то, что удобно всем. Но обычно у меня есть четкие 2-3 пункта, по которым я могу отличить возможности моего поделия от имеющихся. В данном случае такие пункты есть? Или просто еще один велосипед?

Цитата:

Сообщение от dk_spb

Так а чем плох FluxEngine ?

ХЗ.
Я понятия не имею, работает ли он с важными для нас TRD/FDI/UDI/HFE (что в моем планируется).
И также я понятия не имею, умеет ли он подстраиваться под плавающую скорость и перемагниченные поверхности (что в моем также достаточно приоритетно).

Цитата:

Сообщение от dk_spb

Или просто еще один велосипед?

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

FE тоже умеет подстраиваться. Цена готовой платки - 10$ (надо только разъем IDC34 припаять).
Можно и BluePill использовать.

>Я понятия не имею, работает ли он с важными для нас TRD/FDI/UDI/HFE (что в моем планируется).
>И также я понятия не имею, умеет ли он подстраиваться под плавающую скорость и перемагниченные поверхности (что в моем также достаточно приоритетно).
Странно, Вы же о нем сами писали.
https://zx-pk.ru/threads/31038-greas...ght=fluxengine

> Да, максимально дешёвый велосипед из говна и палок, который сможет читать даже убитые диски, не читающиеся обычными контроллерами.
Ну то есть еще один. Никаких принципиальных отличий нет.

Цитата:

Сообщение от dk_spb

Цена готовой платки - 10$

На Алиэкспресс самые дешевые 1400р. Это $20. На чипдипе - 1900р. Подозреваю, что о тех местах, где вы их за 800р покупаете, никто больше не знает.

Цитата:

Сообщение от dk_spb

FE тоже умеет подстраиваться.

Не нашел этого в описании. Скудные гистограммы в inspect, и ничего о том что размытость может быть следствием того что скорости при записи могли плавать, и домены могли перемагнититься, что неплохо было бы компенсировать при чтении (или же распознавании, если это raw).

Цитата:

Сообщение от dk_spb

Странно, Вы же о нем сами писали.

Писал что "он есть", а не что он умеет. Вам виднее что он умеет. Но судя по всему вышеперечисленные форматы - не про него. И лично для меня этот вариант: а) дороговат - 1500 против 300; б) экзотичен (никак особо и не поиграешься для других целей); в) нельзя применить к эмуляторам спектрума или железному через Gotek; и г) у меня (и у многих других) уже есть Atmega.

Если вам с вашим флюксэнджиновским патриотизмом (вы сами говорили что кучу сил в него вложили) так хочется доказать всем что флюксэнджин гораздо перспективнее и интереснее чем сабж, или что-либо еще - можете затеять тему с опросом (пусть список включает всё).

Цитата:

Сообщение от Dexus

Подозреваю, что о тех местах, где вы их за 800р покупаете, никто больше не знает

Демо-кит на сайте производителя чипа стоит именно 10$.
Опять же, вы сами писали что FE умеет и через BluePill работать.

Цитата:

Сообщение от Dexus

и ничего о том что размытость может быть следствием того что скорости при записи могли плавать, и домены могли перемагнититься

То есть прямо в коде должны были написать _базовые_ причины, из-за которых бывают проблемы с чтением?
Или где "ничего" ?

>в) нельзя применить к эмуляторам спектрума или железному через Gotek.
Ну так я и начал с вопроса, а чем Ваша разработка лучше?
Если и FE нельзя и Вашу нельзя, то о чем разговор?

>так хочется доказать всем что флюксэнджин гораздо перспективнее и интереснее чем сабж
Как раз наоборот, я просто поинтересовался чем subj отличается от FE, а в ответ только напор патриотизма...

>можете затеять тему с опросом
О чем опрос? Кому какое название больше нравится? Вы же даже на словах не написали чем subj лучше FE.
А уж примеров дискет, которые FE на прочитал, а subj прочитал - точно не выкладывали.

Поймите, ни опрос о том, кто красивее напишет фразу "размытость может быть следствием того что скорости при записи могли плавать, и домены могли перемагнититься", ни, тем более, результат этого опроса мне неинтересен. Меня интересует выбор инструмента. Если где-то появляется инструмент, который, по словам разработчика, является новым словом в вопросе и имеет массу преимуществ, то я интересуюсь какие же это преимущества и в чем новизна: что новый инструмент умеет такого, чего не умеют другие, или какие проблемные дискеты он прочитал, в отличие от других инструментов.
Если разработчик в ответ сразу пишет что-то про "патриотизм", а не про факты - я делаю выводы что фактов нет.
А уж использовать для каждого случая самопальный инструмент или взять готовый, пусть даже на 10$ дороже - личное дело каждого.
Вполне возможно что Ваш инструмент ничем не отличается, просто удобнее именно Вам. Это нормально. Но мне неинтересно. Так что дайте знать если это именно так.

dk_spb, слушай, интересно чем отличается - выясняй сам. Всё что касается проекта я тут выкладываю (точнее, выкладывал, пока ты тут не начал флеймить). По поводу всяких левых флюксэнджинов мне вопросов больше не задавай. Это не коммерческий проект, а хоббистский. Был бы коммерческим, и хотел бы я его впаривать кому-то - я бы выяснял все возможности, все мелкие нюансики всех альтернатив, и строил бы таблицу по пунктам "умеет-не умеет". А так - мне пофигу что альтернативы умеют или не умеют, и какое преимущество у AFD над кем есть. И особенно не надо тут "а вот этот умеет а твоя нет". Пофиг. Вот если есть какие-то недоделки или недостатки - это да, это важно знать. Но их я и так знаю. Только не надо меня спрашивать о том есть ли такие же недостатки у альтернатив. Я в душе не шатаю что там у альтернатив :)

>Вот если есть какие-то недоделки или недостатки - это да, это важно знать.
Сложно знать недостатки какого-то устройства, про которое известно только что оно должно уметь читать дискеты. Если даже ты не пишешь подробностей что должно делать и что не должно твоё устройство - я то уж точно не буду выяснять, тут заплечных дел мастер нужен.

Но суть я понял. Оказывается это мода такая: не успеет человеку понадобится что-то чуть большее, чем переходник на три контакта, это сразу называют проект. Потому что в магазине готовое на 100 руб дороже, да еще и идти надо. И важнее процесс, чем результат. То есть единственная цель и задача - обеспечить процесс, а что делаем и для чего, с какими особенностями - это "выясняй сам", ибо автор и сам не знает.

Больше не мешаю саморазвлекаться.

Цитата:

Сообщение от dk_spb

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

Если бы ты потрудился просто хотя бы почитать тему (в части изменений), не говоря уж о скачать и почитать readme.txt, таких глупых пассажей мог бы и избежать. А вообще, я не понимаю что ты тут делаешь. Ты же любитель советских компуктеров типа Радио 86-РК, ДВК и УКНЦ, и Спектрум тебе глубоко чужд... Сидишь тут и флеймишь в форуме "ZX Spectrum Hardware". Предлагаю тебе научить EF работать с образами Спектрумовских дисков - тогда и можно будет сравнивать. А до тех пор этот FE - бесполезная для спектрумовского сообщества поделка скучающего шотландца, которую даже упоминать тут не стоило.

Прошу админов удалить из этой темы флейм (начиная с сообщения №8, включая это). Спасибо заранее.

Вполне нормальный подход - прокачать скилы и попробовать сделать что-то свое. Возможно, получится лучше, чем у конкурентов. Какая разница ну да есть аналоги. Но пусть будут. Пусть то что я не сниму с Грисвизл я считаю с Arduino Floppy Dump. Первую я собрал, соберу и этот проект, вроде все просто. Надо пробовать.

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

А сказать вот так что все уже изобретёно до вас это офигенно демотивирует.

Иногда бывают такие истории (для наглядности, с каждой итерацией отсекается распознанный "горб", и остаток нормализуется):

Код:

.: .::: .. .:::: :: .:::::: .::: .. ::::::: :::: .:: ::::::::. .::::: :::. .:::::::::: ::::::. : .::::. .::::::::::::...:::::::::::::..::::::::. us------2-------3-------4-------5-------6-------7-------8-------9 .. :: .::: . :::: :: ::::. ::: .::::: :::: .::::::: .:. :::::. .:::::::::::::.:::::::::. us------2-------3-------4-------5-------6-------7-------8-------9 32 . :: .:: ::: :::: : .:::: .::. :::::: . ::::::::::::::: us------2-------3-------4-------5-------6-------7-------8-------9 42 . :: .:: ::: :::: .:::: :::::: . :::::::::: us------2-------3-------4-------5-------6-------7-------8-------9 47 : :: :: us------2-------3-------4-------5-------6-------7-------8-------9

Вместо 3х пиков распознаются 5. А может и больше. Пики между пиками (т.е. как раз те самые неоднозначно классифицируемые импульсы).
Достаточно нетривиальная задача анализировать подобное, дабы установить пороговые границы. Необходимо кластеризовать эти бугры с учетом основной MFM пропорции 1/1.5/2.
Пока в этом затык.

- Статистику по полной+четной/нечетной собираю.
- Выявляю график чётно/нечётного "расползания", компенсирую его.
- По результату повторно обрабатываю статистику для вычисления наиболее корректных пороговых значений (для каждого фрагмента) <- я тут

Часто ведь бывает вообще 2 бугра (т.е. 1+1.5), если это межсекторный промежуток. Алгоритм должен это учитывать и в этом плане быть максимально адаптивным.

Зачем вся эта мат.статистика и численная эквилибристика, спросите?
Потому что это ардуино с 2кб оперативы, и читать весь трек она не может. Поэтому приходится изголяться, делать это за несколько проходов - сначала собирать усредненную статистику, затем генерировать графики компенсаций и порогов, и потом уже запускать чтение самого MFM потока с учетом этих графиков. Т.е. алгоритм не может сразу сказать об ошибке CRC при изменении этих порогов - необходимо каждый раз проходить весь (ну или почти весь) маршрут. С устройствами которые читают в сыром виде, типа Greazeweasel это проще - там читается за один раз, а потом можно распознавать в оффлайне сколько хочешь.

Может взять тогда за основу ардуину чуть покруче, которая как и greazeweasel читает за 1 раз ?

Цитата:

Сообщение от ^m00h^

Может взять тогда за основу ардуину чуть покруче, которая как и greazeweasel читает за 1 раз ?

Зачем? Greazeweasel уже прекрасно справляется с этой функцией (хотя с 5.25" вроде проблемы есть).
А Ардуина "Чуть покруче" наверняка будет дороже блюпилла. А этот проект - про абсолютно минималистичную читалку, выжать из нее максимум. Поэтому и приходится извращаться, расчитывать такты, байты оперативы. Практически как в демомейкерстве ;).

А не вредно ли будет для диска примерно 25-30 летней давности читать по несколько раз одни и те же места ?

Моим дискетам как раз лет по 25+. Читаются в целом без проблем. Те которые не читаются и тогда не читались. И еще есть пару дискет, у которых кожух (внешняя оболочка) искорежилась в местах склейки. Такие пришлось аккуратно вскрывать (и использовать кожух-донор). Но и они хорошо прочитались. Где-то 120 дисков, большинство которых я прочитал на реанимированном старом компе с fdd контроллером c помощью zx disk studio. Часть дисков читалась очень плохо или какие-то нестандартные форматы. Их я оставил тогда «на потом», и вот как раз сейчас, собственно, занялся ими.
В общем, если головку не придавливать так чтобы она начинала царапать магнитное покрытие, по-идее проблем быть не должно. А придавливать головку — плохая идея.

Это зависит от диска. У меня есть диск который в целях экспериментов я читал более 500 раз один трек, и он продолжает читаться (диск ГМД-130 записи 1996 года, производства примерно тогда же). А есть такие у которых в процессе чтения магнитный слой ссыпался и осталась просвечивающаяся царапина (но я успел прочитать) (диски записи 1994-1997 годов, но произведены значительно раньше, еще для односторонних дисководов - у них окна для записи есть с обоих сторон, они были старыми даже в 90е когда мой отец непонятно где их откопал по дешевке). Я заметил зависимость от качества диска. Хорошие диски не сыпятся, плохие - сыпятся. Те, что сыпятся, я еще в 90е считал плохими по своему качеству (они еще не сыпались, но на них часто были ошибки). Лишние чтения на таких дисках это рискованная операция. Я например на них никогда не отрабатывал работу своего кода чтения, используя для этого только хорошие диски, и только когда код был оттестирован на них, тогда уже начинал читать те рассыпающиеся. Головку на них прижимал, и это позволяло прочитать их перед тем как они рассыпятся. Без прижатия рассыпались бы тоже, никуда бы не делись, разве что на несколько десятков оборотов позже. Нулевые треки сыпятся в первую очередь. Они заезжены и на нормальных дисках, а на тех плохих превращаются в прозрачное узкое кольцо безо всяких прижатий головки, просто потому что головка там бывает чаще чем на каком-либо другом треке. То что диск сыпется можно увидеть по быстро засоряющимся головкам. Именно разрушающимся магнитным слоем диска они и забиваются и чтение резко ухудшается. При чтении таких дисков мне приходилось промывать их спиртом через каждые 10-20 цилиндров из-за этого засорения.
А прижатие головки это идея действительно опасная. И опасность её не столько в протирании дыры в диске, сколько в выходе из строя самих головок (хотя тут смотря что считать более ценным, дисковод или диск).
Я, кстати, читал диск с искривленной поверхностью вследствие удара, которая при вращении била головки - это еще покруче чем их прижатие. А, и еще и прижимал при этом. В 90е я не решался вставить этот диск в дисковод, а сейчас уже как-то легче к этому отношусь.

Цитата:

Сообщение от CPLx

Головку на них прижимал, и это позволяло прочитать их перед тем как они рассыпятся. Без прижатия рассыпались бы тоже, никуда бы не делись, разве что на несколько десятков оборотов позже.

Это прям какой-то садизм!

Цитата:

Сообщение от CPLx

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

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

Цитата:

Сообщение от CPLx

Я, кстати, читал диск с искривленной поверхностью вследствие удара, которая при вращении била головки - это еще покруче чем их прижатие.

Такой наверное правильнее было бы через бумагу "прогладить" с недеструктивной температурой. Мне такие не попадались... Коллекция дисков у меня не огромная и бОльшая часть дисков - это 3М и dysan, и некоторая часть ГМД (не считая купленных с записанными играми/музыкалками - там могло быть что угодно, и они кстати тоже без проблем читаются). Т.е. каких-то совсем убитых с этой точки зрения нет. Есть какое-то количество IBMовских, и они вообще никак не читаются (там будто 5 полос таймингов).
Часть дисков с "перемагниченной" поверхностью - у них четные-нечетные импульсы гуляют туда-сюда, и в них только часть секторов читается. Над ними собственно сейчас и колдую.

Цитата:

Сообщение от Dexus

Вообще-то чтение не должно быть деструктивным, если головка над поверхностью магнитного диска на необходимом расстоянии висит.

Вроде бы устройство дисковода таково, что головка касается диска, а не висит над ним. Не было бы заезженых нулевых треков если бы головки висели.

Цитата:

Сообщение от Dexus

Есть какое-то количество IBMовских, и они вообще никак не читаются (там будто 5 полос таймингов).

А драйвер что пишет? (ZX Disk Studio показывает наличие каких-нибудь секторов?)

PS
Прогладить там не вариант. Словами трудно объяснить что там было. Может завтра сфоткаю когда светло будет. Там прямо перегиб диска получился.

Цитата:

Сообщение от CPLx

Вроде бы устройство дисковода таково, что головка касается диска, а не висит над ним. Не было бы заезженых нулевых треков если бы головки висели.

Похоже да. Был неправ. Видимо решил что коли головки HDD парят, то и у флопов тоже должны.
http://www.tpub.com/neets/book23/103.htm

У меня заезженных нулевых треков как таковых не было. Было такое, что нулевая дорога портилась вследствии того что не вовремя переставлял дискеты)
Также я обнаружил, что при перезаписи предыдущие магнитные домены отчасти остаются, именно поэтому желательно сначала стирать (писать 0x00,0xFF, чтобы не оставалось длинных доменов), а потом писать новое. Т.е. одиночного перемагничивания при записи не всегда достаточно (об этом Роб Смит на своей странице кстати писал). Поэтому при частой перезаписи одной и той же дороги просто "старые" данные могут не до конца исчезать, и тем самым портить CRC.

Цитата:

Сообщение от CPLx

А драйвер что пишет?

Я не вкурсе что драйвер пишет, у меня нет возможности проверить. Вообще эти диски без какого-то важного софта, просто какие-то ошмётки дистрибутивов IBMовского софта, которые предполагалось форматировать и использовать на спеке уже. Что с ними до этого было - хз.
Речь о том что справа:
http://volutar.eu5.org/fddscan5.png
5 полос, 0.8/1/1.5/2/3, первая и последняя - какие то очень "хилые".

Цитата:

Сообщение от CPLx

Прогладить там не вариант. Словами трудно объяснить что там было. Может завтра сфоткаю когда светло будет. Там прямо перегиб диска получился.

Просто "прогладить" первое в голову пришло. А как еще пластик можно выпрямить? Немного нагреть, чтобы стало поддатливым, и придавить как следует.

Цитата:

Сообщение от Dexus

У меня заезженных нулевых треков как таковых не было.

Это если диском много пользоваться: постоянно записывать, стирать, и так много раз. Я кодил в 90е, поэтому были рабочие диски на которые постоянно шла запись, и нулевые дорожки становились заезженными, что было видно на глаз.

Цитата:

Сообщение от Dexus

Я не вкурсе что драйвер пишет, у меня нет возможности проверить.

Можно в ZX Disk Studio посмотреть что там за формат, какие сектора существуют.

Можешь пояснить по своим картинкам? Потому что я ничего не понял. Что по осям отложено, что означают разные цвета, что означают вертикальные красные линии, и т.д.

Цитата:

Сообщение от CPLx

Можешь пояснить по своим картинкам? Потому что я ничего не понял. Что по осям отложено, что означают разные цвета, что означают вертикальные красные линии, и т.д.

Ок. Изображены 4 разных диска.
верхняя половина (синим) - взята из прямых длительностей (цифровым анализатором прям из дисковода на частоте в 8мгц, и потом переработано в длительности).
красные вертикальные полоски - распознанные синхрокоды (A1).
нижняя половина (зеленым) - то что читает ардуина (усредненная статистика по 512 импульсам друг за другой)
Лучше конечно верхняя половина - она детализирована (но ардуина так читать не умеет). Наверху - короткие длительности, внизу - длинные. Например на первых двух дисках полосы идут по 4, 6 м 8мкс. На третьем - 2, 3 и 4. Соответственно на самом правом - примерно 2, 2.5, 3.7, 5 и 7.8мкс.
Визуализация аналогична Scatter plot:
https://goughlui.com/wp-content/uplo...n-1024x377.png
Кстати тут видно что тоже есть участки с перемагниченностью - в правом графике нижняя полоса немного раздваивается и гуляет восьмёркой.

Цитата:

Сообщение от CPLx

Можно в ZX Disk Studio посмотреть что там за формат, какие сектора существуют.

Да никакие он там не показывает. Ошибка чтения.

Цитата:

Сообщение от Dexus

Да никакие он там не показывает. Ошибка чтения.

Там какая-то другая модуляция, если я правильно понял. Интересный случай.

Цитата:

Сообщение от CPLx

Там какая-то другая модуляция, если я правильно понял. Интересный случай.

Да не. Обычная MFM. Других просто быть не могло. Просто судя по всему это тот случай, когда диффузия между магнитными разворотами так расширилась, что некоторые сочетания просто растворились (судя по всему, с участием самых длинных доменов).
Во-первых очевидно что мощность намагниченности тут очень слабая — полосы с большим джиттером (толстые). Видимо плотность магнитного слоя недостаточна для HD дисков, и он будто на пороге возможного (при этом он не в стандартных таймингах HD - 2/3/4us, а на 20-25% медленнее). Хотя, возможно, оно записывалось на дисководе, с вращением шпинделя 360об/мин.
Во-вторых там где нет 3й полоски, нет и этих двух артефактовых слабых. Что также означает что это МЧМ с межсекторным рисунком 333223 333223 (4e4e) http://volutar.myds.me/php/mfm.php?hex=4e4e
Восстанавливать их конечно нет смысла, они не спековские даже, но случай любопытный.

Была помимо дампящего функционала у меня еще задумка о некотором «изображении» FDC, т.е. в том числе и форматирования и записи. Это три функции:
1. Форматирование. Загружать в буфер (макс 1.5кб) данные о формате. Весь трек понятное дело не вместится. Но в некотором «запакованном» формате — вполне. Что-то типа RLE, в рилтайме, думаю, вполне потянет.
2. Чтение отдельных секторов, максимальный размер 1кб. Подстройка по «кратчайшим» таймингам (серия 12х00), вылавливание синхрокода A1A1A1, Чтение данных — заголовка, потом самого сектора.
3. Запись сектора. Сначала вылавливание заголовка (как в функции выше) а потом спустя некоторое время (чтобы попасть куда надо) — запись самих данных, предварительно загруженных в буфер.
CRC считать можно было бы только у заголовка (как раз в промежутке, плюс там всего 8 байт). Контрольная сумма данных должна считаться или хостовым софтом, или перед записью / после чтения. Хостом быстрее, но неизвестно насколько будет хватать скорости, чтобы при записи «всасывать» очередные данные сектора, и потом их писать. Вероятно будет по 1 сектору за оборот.

Но это так, параллельные мысли, не особо резонные. Смысл в этом разве что только чтобы какой-нибудь эмулятор научить работать с таким псевдо-контроллером флоппа. Но это вообще вряд-ли. Возможно, просто проверить этот proof of concept.

Цитата:

Сообщение от Dexus

Смысл в этом разве что только чтобы какой-нибудь эмулятор научить работать с таким псевдо-контроллером флоппа.

\
А чем устройство прикидываться будет? Прямо ВГшкой или дисковертом?

Black Cat / Era CG, не, ВГшкой явно не сможет. ВГшкой сможет попробовать прикидываться разве что управляющий софт, прослойка между девайсом и эмулем. Причем, видимо, тормозной ВГшкой (потому что не совсем в рилтайме).

Тогда наверное с эмулем проблематично.

Зато диски можно будет писать. Не защищенные. Но кому это надо, если gotek много удобнее (когда образы под рукой)? В самом деле не мурыжиться же через дискеты с двумя дисководами. К тому же это все равно крайне не труЪ. Запись вообще не нужна. Главное — вовремя остановиться.

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

Попробовал с Arduino nano на ch340. Ситуация не очень веселая — на 2Мбод/с полноценно работать не может, так что HD диски не получится с ней. Дополнил первый пост.