Важная информация

User Tag List

Страница 4 из 4 ПерваяПервая 1234
Показано с 31 по 39 из 39

Тема: Arduino Floppy Disk Reader

  1. #31
    Activist
    Регистрация
    04.08.2005
    Адрес
    Nizhnevartovsk
    Сообщений
    491
    Спасибо Благодарностей отдано 
    5
    Спасибо Благодарностей получено 
    32
    Поблагодарили
    18 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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



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

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


    0я,1я, 80я (пустая) дорожка.

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

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

  2. #31
    С любовью к вам, Yandex.Direct
    Размещение рекламы на форуме способствует его дальнейшему развитию

  3. #32
    Activist
    Регистрация
    04.08.2005
    Адрес
    Nizhnevartovsk
    Сообщений
    491
    Спасибо Благодарностей отдано 
    5
    Спасибо Благодарностей получено 
    32
    Поблагодарили
    18 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

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

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

  4. #33
    Activist
    Регистрация
    04.08.2005
    Адрес
    Nizhnevartovsk
    Сообщений
    491
    Спасибо Благодарностей отдано 
    5
    Спасибо Благодарностей получено 
    32
    Поблагодарили
    18 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    От автора 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
    Последний раз редактировалось Dexus; 04.11.2019 в 21:42.

  5. Эти 2 пользователя(ей) поблагодарили Dexus за это полезное сообщение:

    goodboy (04.11.2019), SoftLight (04.11.2019)

  6. #34
    Activist
    Регистрация
    04.08.2005
    Адрес
    Nizhnevartovsk
    Сообщений
    491
    Спасибо Благодарностей отдано 
    5
    Спасибо Благодарностей получено 
    32
    Поблагодарили
    18 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Состояние дел:
    Понемногу вникаю в скриптование на питоне, пишу конвертер из 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), потому как перечитывание сложных мест лучше делать отдельно, плюс лучше иметь возможность загрузки имеющихся образов и их корректировки без полного перечитывания всего диска. Т.е. имеется необходимость в интерактивности.
    Последний раз редактировалось Dexus; 15.11.2019 в 17:05.

  7. Этот пользователь поблагодарил Dexus за это полезное сообщение:

    Black Cat / Era CG (15.11.2019)

  8. #35
    Activist
    Регистрация
    04.08.2005
    Адрес
    Nizhnevartovsk
    Сообщений
    491
    Спасибо Благодарностей отдано 
    5
    Спасибо Благодарностей получено 
    32
    Поблагодарили
    18 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Пока доделал набросок конвертера HFE->UDI.
    Работает не сверх-быстро, но что ж поделать - питон все-таки далёк от скорости нативного кода, но в реальном времени это делать не нужно, поэтому, думаю, простительно. К тому же он позволит быстро накидать любые другие форматы вывода, и подкорректировать в случае чего.
    Подсчёт кривого UDIшного CRC делается вручную, потому в конце слегка будто подвисает.
    pyhfe2udi.zip
    Последний раз редактировалось Dexus; 21.11.2019 в 01:11.

  9. Эти 2 пользователя(ей) поблагодарили Dexus за это полезное сообщение:

    anasana (21.11.2019), SoftLight (21.11.2019)

  10. #36
    Veteran Аватар для SoftLight
    Регистрация
    28.02.2005
    Адрес
    Москва
    Сообщений
    1,487
    Спасибо Благодарностей отдано 
    80
    Спасибо Благодарностей получено 
    45
    Поблагодарили
    38 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  11. #37
    Activist
    Регистрация
    04.08.2005
    Адрес
    Nizhnevartovsk
    Сообщений
    491
    Спасибо Благодарностей отдано 
    5
    Спасибо Благодарностей получено 
    32
    Поблагодарили
    18 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    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). Пока они достаточно быстро проскакивают, можно пропустить и не заметить. Потому планирую сделать "терминальный" интерактивный режим при импорте-экспорте, с возможностью сохранения списка нестандартных треков и возможностью просматривать их структуру вербозно. В перспективе - подтягивать отдельные дорожки с "железа" (это когда уже взаимодействие с железом будет).

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

  12. Этот пользователь поблагодарил Dexus за это полезное сообщение:

    SoftLight (22.11.2019)

  13. #38
    Veteran Аватар для SoftLight
    Регистрация
    28.02.2005
    Адрес
    Москва
    Сообщений
    1,487
    Спасибо Благодарностей отдано 
    80
    Спасибо Благодарностей получено 
    45
    Поблагодарили
    38 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  14. #39
    Activist
    Регистрация
    04.08.2005
    Адрес
    Nizhnevartovsk
    Сообщений
    491
    Спасибо Благодарностей отдано 
    5
    Спасибо Благодарностей получено 
    32
    Поблагодарили
    18 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

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

  15. Этот пользователь поблагодарил Dexus за это полезное сообщение:

    SoftLight (22.11.2019)

Страница 4 из 4 ПерваяПервая 1234

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. Ответов: 75
    Последнее: 12.12.2019, 18:03
  2. [zs scorpion 256] Floppy disk a: not recognized
    от lukezab в разделе Устройства ввода
    Ответов: 5
    Последнее: 13.10.2016, 19:42
  3. Floppy Disk Ripper (Firmware, ZX and PC utilities)
    от TSL в разделе Софт
    Ответов: 52
    Последнее: 08.02.2015, 16:16
  4. TRD image -> floppy disk
    от Error404 в разделе Утилиты
    Ответов: 13
    Последнее: 28.01.2007, 20:15

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •