Просмотр полной версии : Spectrum Archive Reader - Программа для чтения TR-DOS дисков
Программа читает диски через драйвер fdrawcmd.sys (https://simonowen.com/fdrawcmd/). Версию драйвера не проверяет, поэтому можно запускать с любым и смотреть что получится. На моём железе заработала с драйвером версии 1.0.0.19 (позже заработала и с 1.0.1.11).
Что может делать:
• Читать диски (5.25'' Double Density) форматов TR-DOS, IS-DOS, CP/M посекторно, до 172 треков.
• Дочитывать только непрочитанные сектора. Очень экономит время на плохо читающихся дисках.
• Читать только указанный диапазон треков на диске. Позволяет пропустить области диска которые заведомо нечитаемы и сразу сосредоточиться на указанном треке у которого есть потенциал прочитаться. Это также ускоряет чтение верхней стороны имеющей разные форматы в разных местах: можно указывать формат и нужные треки и сразу читать их, не тратя время на сбор ошибок на других треках.
• Читать диски в обратном направлении. Как ни странно, у меня это улучшало чтение.
• Сохраняет образы в TRD и FDI. Можно позже загрузить TRD/FDI-образ и снова попытаться прочитать только bad-сектора.
При сохранении образа в TRD его bad-сектора заполняются символом B (как это делает WinTRD). Необработанные сектора (у которых не было попытки чтения) заполняются символом N. При загрузке образа по этим меткам определяются плохие и еще не читавшиеся сектора.
• Может читать верхнюю сторону двумя способами: задавать верхнюю сторону равной 0 либо 1. Оказалось что на Спектруме было 2 вида форматирования верхней стороны. В одном случае в трек писалось что это сторона 1, в другом писалось что это сторона 0. TD-DOS читал оба таких формата без проблем. Драйвер fdrawcmd.sys имеет с этим сложности: он требует передачи ему информации о физической головке и о стороне указанной в разметке диска. Физическая головка говорит драйверу какую сторону диска прочитать. Но он еще делает сверку с разметкой на диске. Если сторона переданная драйверу не совпадает с тем что он видит на диске (что указано в заголовочной области сектора), то драйвер выдает ошибку 21 (the device is not ready). Поэтому драйверу нужно передавать нужную логическую сторону в зависимости от того как отформатирован диск.
• Может читать только одну сторону: верхнюю или нижнюю, либо обе стороны. Практика показала что иногда бывает быстрее прочитать диск по сторонам отдельно, потому что верхняя сторона может быть отформатирована разными способами и должна читаться с разными настройками. У меня были диски где формат менялся много раз. Так получалось потому что я мог форматировать диск много раз и делать это разными программами и каждый раз не до конца, т.е. прерывая форматирование, поэтому разные виды форматов могли таким образом наложиться. Этой программой можно прочитать отдельные области верхней стороны диска указывая формат для каждой области.
• Интерфейс имеет смесь русского и английского. Не стал это менять.
Терминология
Обработанный сектор – сектор у которого была попытка чтения. Это либо успешно прочитанный сектор, либо bad-сектор.
Необработанный сектор – сектор у которого не было попыток чтения. В образе такие заполнены символом N.
Bad-сектор – сектор у которого была попытка чтения, которая оказалась неуспешной. В образе такие заполнены символом B.
Good-сектор – успешно прочитанный сектор.
Нулевой сектор – Good-сектор содержащий одни нули.
Описание интерфейса
Track From – номер трека с которого будет производиться чтение.
Track To – номер трека до которого будет производиться чтение. Сам этот трек читаться не будет.
Параметры Track From и Track To отображаются черной полосой над картой образа. Их можно поменять сделав выделение мышью на карте образа. Двойной клик по этой полосе - установка с 0 по 180.
Read Side – читаемая сторона диска: верхняя, нижняя или обе. Влияет только на то какая сторона читается. Диск всегда считается двухсторонним.
Disk Format – формат верхней стороны диска. “Upper Side As 0” означает что верхняя дорожка отформатирована как нулевая сторона. В этом случае при чтении верхней стороны драйверу дается указание прочитать с верхней головки сторону с номером 0. “Upper Side As 1” означает что верхняя дорожка отформатирована как первая сторона: драйверу указывается прочитать с верхней головки трек имеющий сторону 1.
Track Read Attempts – количество попыток чтения трека как партии из 16 секторов.
Sector Read Attempts – количество попыток чтения сектора.
Кнопки:
New – создание образа. При создании указывается размер образа в треках и его имя. Образ создается также автоматически при запуске приложения.
Load – загрузка образа trd. При загрузке также указывается размер в треках. Можно указать 0 и тогда будет автоопределение.
Save – сохранить образ в формате TRD. Образ сохраняется до последнего сектора, у которого была попытка чтения, включительно. Последние сектора, у которых не было попыток чтения, не сохраняются. Сохраняется минимум два трека – нулевой и первый, даже если первый трек не читался – это сделано чтобы файл мог быть прочитан в UnrealSpeccy, который выдает ошибку если TRD состоит только из нулевого трека.
Set Size – изменить размер образа в треках. При уменьшении размера лишние данные теряются. При увеличении – нет.
Merge – слияние образов TRD. Делал чтобы слить образы полученные разными чтениями WinTRD. Для этого сначала надо загрузить или создать один образ, потом нажать Merge и указать образ для слияния. В логе будет указано количество добавленных good-секторов. Можно делать слияние несколько раз. Плохие сектора в загружаемом образе определяются как полностью заполненные символом B.
Show Catalogue – показ каталога образа.
Show Cat From Track – показ каталога с указанного трека образа. Были коммандеры которые сохраняли копию каталога на 160 или 162 трек, можно их просмотреть по этой кнопке.
Read Forward – чтение диска. Читаются только те сектора, которые не были до этого успешно прочитаны. Чтение идет от Track From до Track To (не включая его; при условии невыхода за пределы образа и при условии что Track To > Track From). Для каждого трека сначала делается попытка прочитать 16 секторов партией, количество попыток задается параметром Track Read Attempts. Если это не удалось, то включается чтение по отдельным секторам, количество попыток – Sector Read Attempts.
Read Backward - Чтение диска в обратном направлении. В остальном аналогично Read Disk,
Read Random Sectors – случайное чтение отдельных секторов. Читаются только сектора которые еще не читались или оказались битыми. Выбираются только в пределах Track From и Track To и только на указанной стороне (либо на обоих). На моём железе читаемость сектора по какой-то причине носит серийный характер, и если сектор не прочитался, то высока вероятность того что не прочитается и следующий, вне зависимости от того где он находится. Я эту функцию не особо много использовал, но в некоторых случаях она позволяла прочитать дополнительные сектора, которые находились после битых и которые по этой причине не позволял прочитать эффект серийности.
Read Catalogue – чтение каталога (9 секторов) с диска и показ в отдельной форме. Данные не сохраняются, на имеющийся образ не влияют.
Abort – прекращение чтения. Реакция происходит не сразу, а с некоторой задержкой, связанной с ожиданием завершения текущей операции драйвером.
Build Disk Table – построение таблицы дисков (trd-образов), с указанием их размера, количества bad-секторов, файлов и поврежденных файлов, а также общая статистика – сколько секторов прочитано, сколько битых. Сохраняется в виде HTML.
Build Maps – построение карт для указанных trd-образов, где отмечены хорошие, битые и нулевые сектора. Сохраняется как HTML.
Build Sector Content Maps – построение карт содержимого секторов для указанных trd-образов. Определяет исходники TASM4.0 (иногда выдавая ложноположительный результат, но мне было качества достаточно), GENS, графику, текст, нулевые сектора и код. Я использовал эту функцию для поиска своих исходников на дисках.
Build Duplicate Maps – построение карт секторов-дубликатов. У меня были случаи когда сектор прочитывался из другого места диска, например вместо сектора 0 читался сектор 1, из-за чего происходило искажение данных, и драйвер никак не регистрировал ошибки, выдавая данные как валидные. Не помню чтобы такое было на реальном Спектруме, но на двух PC-контроллерах у меня такое встречалось минимум 7 раз из 280 000 секторов. Чтобы находить такие случаи я написал эту функцию, но она далеко неидеальна, т.к. оказалось что дублирование секторов это часто встречающаяся вещь даже на валидных данных. Строит она сектора которые по содержимому полностью совпадают друг с другом, находятся в пределах 16 секторов друг от друга и не идентифицируются как графика (у графики очень высокий процент дублей сам по себе), сохраняется как HTML.
Mark Sector Unprocessed – маркировать сектор в образе как необработанный. После этого при чтении диска программа будет пытаться его прочитать. Сделал чтобы снова перечитать сектора-дубли в некоторых дисках.
Build File Table – построение таблиц файлов для указанных trd-образов. Поврежденные файлы отмечаются красным цветом, указывается количество bad-секторов у них. Сохраняется как HTML.
Driver Version - показ версии драйвера и типа контроллера.
Использование
Настроить параметры чтения, после чего нажать Read Forward. Перед этим можно загрузить образ из TRD.
UPD: Есть пример (https://zx-pk.ru/threads/31601-spectrum-archive-reader-programma-dlya-chteniya-tr-dos-diskov.html?p=1061501&viewfull=1#post1061501) когда программа не может прочитать один из секторов трека, при том что ZX Disk Studio читала диск успешно.
Проблема чтения первых секторов решается закрытием индексного отверстия на диске.
Программа написана на C# и требует .NET Framework 2.0.
UPD
В версии 1.0.0.10 добавлено автоопределение параметра Head верхней стороны и чтение дисков CP/M.
17.07.2020: В версии 1.0.0.11 добавлено чтение формата IS-DOS.
21.07.2020: Добавлен формат FDI.
14.01.2021: В версии 1.0.0.15 добавлен выбор дисковода. Сделано чтение кастомных форматов, но не полностью.
Исходник (C#, Microsoft Visual Studio 2015): https://github.com/dalvx/SpectrumArchiveReader
SoftLight
10.04.2020, 11:26
Вопрос: с какой операционкой лучше запускать? Тут же как: если материнка содержит FDD-контроллер, то она, скорее всего, старая. Если старая, даже windows 8 уже скорее всего не взлетит. А еще и второй фреймворк нужен.
Вопрос: с какой операционкой лучше запускать? Тут же как: если материнка содержит FDD-контроллер, то она, скорее всего, старая. Если старая, даже windows 8 уже скорее всего не взлетит. А еще и второй фреймворк нужен.
У меня заработала на Windows 7. Теоретически, второй дотнет должен работать начиная с Win98, но драйвер работает вроде только начиная с Win2000. Короче, по идее любая винда начиная с Windows 2000.
Вопрос: с какой операционкой лучше запускать? Тут же как: если материнка содержит FDD-контроллер, то она, скорее всего, старая. Если старая, даже windows 8 уже скорее всего не взлетит. А еще и второй фреймворк нужен.
FDD-контроллер содержало большинство материнок на LGA1156, и на LGA1155 Sandy Bridge можно найти материнки с FDD. Это вполне себе живые машины, десятка них чувствует себя вполне комфортно.
Black Cat / Era CG
10.04.2020, 13:08
https://simonowen.com/fdrawcmd/
Тут требования самого драйвера к системе. Все построенные на основе него утилиты (их немало) соотв-но работают не раньше, чем на 2000. У меня на 7ке работает, как и Диск Студио и другие.
Show Catalogue – показ каталога образа.
реально добавить сохранение каталога (в текстовом файле) ?
реально добавить сохранение каталога (в текстовом файле) ?
Реально. Я могу добавить сохранение как текстового файла, это не проблема. Прямо в том виде как он показан в форме так и сохранить?
Но вообще, можно сохранить TRD, потом нажать Build File Table, выбрать сохраненный TRD и сохранить каталог как html, откуда потом из браузера скопировать как текст. Если это не устраивает, то да, могу сделать сохранение как текст.
Я могу добавить сохранение как текстового файла, это не проблема. Прямо в том виде как он показан в форме так и сохранить?
мне кажется достаточно сохранять только имена (удобно при создании коллекций)
трек/сектор и.т.д - уже избыточно
мне кажется достаточно сохранять только имена (удобно при создании коллекций)
В форме показа каталога добавил кнопку сохранения списка файлов в виде .txt-файла.
Load – загрузка образа trd
а можно сделать фильтр (показывать только файлы с расширением TRD) ?
- - - Добавлено - - -
добавил кнопку сохранения списка файлов
как вариант можно списку сразу давать то-же имя что и у рабочего образа
а можно сделать фильтр (показывать только файлы с расширением TRD) ?
как вариант можно списку сразу давать то-же имя что и у рабочего образа
Фильтр по TRD сделал. Задание имени равного рабочему образу тоже.
а создание папки Log можно сделать опциональным ?
а создание папки Log можно сделать опциональным ?
Для этого надо придется файл настроек делать. Не знаю насколько удобно его наличие. Сейчас создается Log, а тогда будет создаваться файл настроек.
А в чем проблема удалить потом эту папку?
Для этого надо придется файл настроек делать.
Достаточно ключа командной строки ведь. Кому надо - сделает ярлык.
А в чем проблема удалить потом эту папку?
я не пойму где она создаётся? если программа запущена из окна архиватора.
Достаточно ключа командной строки ведь. Кому надо - сделает ярлык.
Точно. Не подумал об этом.
я не пойму где она создаётся? если программа запущена из окна архиватора.
Она создается там же где основное приложение. В случае запуска из архиватора это будет временная директория которую он создает при распаковке. Узнать путь можно в диспетчере задач, выбрав процесс, нажав правую кнопку и в меню выбрав Open File Location.
Сделал отключение записи лога в файл (включая создание папки Log). Если запустить с ключом /logoff то папка Log не создается.
WXP / W10
FDRAWCMD v1.0.1.9 и v1.0.1.11
SpectrumArchiveReader ни первая, ни версия 1.0.0.3 ничего не читают.
12:52:30.768: Log.Init: Log initialized. Time: 11.04.2020 12:52:30
12:52:38.158: MainForm.C_CreateImage_Click: Образ диска создан. Имя: D000 | Размер: 4 треков (64 секторов).
12:52:46.923: MainForm.C_ReadDiskCombined_Click: Чтение диска. Disk Format: UpperSideAs1. Side: Both
12:52:48.767: Driver.ReadSectorArray: Track: 0 | Error: 1122 | Bytes Read: 0
12:52:49.595: Driver.ReadSector: Track: 0 | Sector: 0 | Error: 1122 | Bytes Read: 0
12:52:50.423: Driver.ReadSector: Track: 0 | Sector: 0 | Error: 1122 | Bytes Read: 0
12:52:50.423: ERROR: DiskReader.ReadCombined: Не удалось прочитать сектор. Трек: 0. Сектор: 0
12:52:51.266: Driver.ReadSector: Track: 0 | Sector: 1 | Error: 1122 | Bytes Read: 0
12:52:52.095: Driver.ReadSector: Track: 0 | Sector: 1 | Error: 1122 | Bytes Read: 0
12:52:52.095: ERROR: DiskReader.ReadCombined: Не удалось прочитать сектор. Трек: 0. Сектор: 1
12:52:52.923: Driver.ReadSector: Track: 0 | Sector: 2 | Error: 1122 | Bytes Read: 0
12:52:53.766: Driver.ReadSector: Track: 0 | Sector: 2 | Error: 1122 | Bytes Read: 0
12:52:53.766: ERROR: DiskReader.ReadCombined: Не удалось прочитать сектор. Трек: 0. Сектор: 2
12:52:54.594: Driver.ReadSector: Track: 0 | Sector: 3 | Error: 1122 | Bytes Read: 0
12:52:55.422: Driver.ReadSector: Track: 0 | Sector: 3 | Error: 1122 | Bytes Read: 0
12:52:55.422: ERROR: DiskReader.ReadCombined: Не удалось прочитать сектор. Трек: 0. Сектор: 3
При этом работают (пишут и читают)
WinTRD (maketrd.exe a 1 1 filename.trd)
ZXDStudio v1.16
Вопрос: Устанавливается ли IOCTL_FD_SET_DATA_RATE, и в какое значение?
---
Уточнение: дискета(-ы) отформатирована на реале RDS-ом.
Вопрос: Устанавливается ли IOCTL_FD_SET_DATA_RATE, и в какое значение?
Устанавливается в значение FD_RATE_250K. При других значениях у меня ничего не читалось.
Устанавливается в значение FD_RATE_250K. При других значениях у меня ничего не читалось.
На моем железе совместимость с реалом при значении 300K.
Вижу необходимость вынести выбор этого параметра на форму.
Вижу необходимость вынести выбор этого параметра на форму.
Хорошо, я сделаю. И даже ключ в командную строку добавлю, может кому-то будет так удобнее, чтобы не переключать вручную каждый раз.
Вообще, если это действительно причина, то становится понятно почему maketrd у меня не работала. (Хотя она работала на другой мат.плате, но та приказала долго жить.)
- - - Добавлено - - -
Вообще, если это действительно причина, то становится понятно почему maketrd у меня не работала.
А хотя нет, не становится. Там можно указывать датарейт и я пробовал 250 и 300, и оба не работали.
Вижу необходимость вынести выбор этого параметра на форму.
Сделал. Можно еще задать в командной строке, тогда параметр будет выставлен при запуске приложения.
Ключи такие:
/250K
/300K
/500K
/1M
Сделал. Можно еще задать в командной строке, тогда параметр будет выставлен при запуске приложения.
Ключи такие:
/250K
/300K
/500K
/1M
(у меня) дискета успешно прочиталась при 300К.
При чтении каждого дорожки головка возвращается на нулевой трек.
---
На пустом диске (без файлов) в отчёте "Disk Table":
Good Files Share NaN %
Damaged Files Share NaN %
При чтении каждого дорожки головка возвращается на нулевой трек.
Интересный случай. У меня есть одно предположение почему так может быть. Запусти здесь чтение кнопкой Test (добавил её на форму). Она должна попытаться прочитать 10 первых треков диска. Если головка не будет отъезжать на нулевой трек каждый раз, то тогда я переделаю работу с драйвером по схеме как сделано в этой кнопке. Если будет, то тогда не знаю в чём причина.
NaN в таблице исправил.
Запусти здесь чтение кнопкой Test (добавил её на форму). Она должна попытаться прочитать 10 первых треков диска.
Прочитала,
быстро,
головка идёт только вперёд.
Прочитала,
быстро,
головка идёт только вперёд.
Отлично. Переделал работу с драйвером. В первой версии при чтении трека или сектора драйвер каждый раз открывался и потом закрывался. Я этот код скопипастил из примеров к драйверу, знал что это неэффективно, но потом забыл про это увлекшись чтением своего архива дисков, потому что у меня это всё работало. Видимо это и приводило к возврату головки на нулевой трек.
Переделал работу с драйвером.
Замечательно.
Сделал карту образа. Лог ошибок убрал, т.к. он стал не нужен. Я его использовал чтобы видеть какие треки дали ошибки. Теперь они видны на карте. (Полный лог всё равно оставил, решил что всё-таки он мне может быть полезен. Его по-прежнему можно отключить в командной строке.)
На карте показываются сектора: good, zero, bad и bad21. Bad21 это когда сектор дает ошибку 21, то есть вероятно не угадан формат верхней стороны или диск неформатирован. То есть это такая ошибка которую стоит отличать от других. В остальных случаях сектор обозначается просто как bad (чаще всего это ошибка 23 - CRC error). Zero это good-сектор заполненный нулями.
Над картой есть толстая черная черта - она обозначает область чтения и строится по параметрам Track From и Track To. Эти параметры можно теперь задать мышью, сделав "выделение" мышью на карте образа.
Тонкая черная черта над картой надчеркивает область 160-168 треков, просто чтобы знать где она.
Добавил кнопку Driver Version. Показывает версию драйвера, тип контроллера и поддерживаемые скорости. Тип контроллера у меня оказался 82077, и похоже это что-то очень старое. Хотел сделать измерение вращения диска, но у меня это не заработало (функция драйвера измеряющая время вращения постоянно выдает ноль). Не знаю, может заработало бы у других. А может и нет.
При запуске приложения образ теперь создается автоматически, поэтому не надо больше нажимать Create. Сама кнопка Create переименована в New.
Ну вот вроде и все изменения.
PS
Забыл написать: двойной клик по области "толстой черной полосы" устанавливает область чтения с 0 до 180.
Увидел здесь на форуме (https://zx-pk.ru/threads/12842-zx-disk-studio-programma-dlya-raboty-s-obrazami-diskov/page26.html?p=864057#post864057) идею чтения трека с позиционированием с обратной стороны. Я подумал что идея в том что головка не успевает стать на трек и можно прочитать трек слегка сдвинутой головкой. По-началу отнесся к этому скептически, потому что head settle time составляет всего 15 мс (оборот диска - 200 мс), но всё равно решил проверить чтобы убедиться в том что это не будет работать. Написал код чтения диска в обратном направлении: со 159 трека по нулевой. И оказалось что процент битых секторов стал меньше почти в 2 раза у меня на моём плохо читающемся диске (у меня все диски плохо читающиеся). Делал много тестов и результаты достаточно стабильные, в том числе на других дисках: обратное чтение дает значительно меньше bad-секторов чем прямое. Возможно это лишь особенность моего дисковода и моих дисков, но особенность интересная.
Было сделано 2 алгоритма обратного чтения: быстрый и медленный. В обоих случаях треки перебирались в обратном направлении - со 159 по 0. При быстром алгоритме трек читался в прямом направлении, то есть сектора читались с 1 по 16. В медленном алгоритме сектора внутри трека читались в обратном направлении: с 16 по 1, на что уходило в 16 раз больше времени, т.к. на каждый сектор требовался целый оборот диска, поэтому этот алгоритм я назвал медленным.
Еще сделал алгоритм чтения в прямом режиме, но с обратным позиционированием при ошибке. Работает так: читает в прямом режиме как обычно, а если встречается ошибка, то головка сдвигается на 2 цилиндра вперед, потом снова назад на нужный цилиндр, таким образом приезжает на него с обратной стороны (со стороны центра диска).
Результаты такие (через запятую перечислено количество bad-секторов в результате трех экспериментов):
Прямое чтение: 215, 198, 203
Быстрое обратное чтение: 116, 87, 82
Медленное обратное чтение: 95, 122, 91
Прямое с обратным позиционированием при ошибке: 112, 104, 103
(Во всех случаях сектор читался в 3 попытки)
Для примера, на карте образа одного из дисков это выглядело так:
72327
Таким образом, получилось что быстрое обратное чтение мало чем отличается от медленного по числу bad-секторов, но скорость имеет гораздо выше. Прямое чтение с обратным позиционированием дало результат примерно такой же, но работает тоже значительно медленнее из-за частого позиционирования. Поэтому из этих трех экспериментальных алгоритмов я решил оставить только алгоритм быстрого обратного чтения и повесить его на кнопку Read Backward.
Почему чтение улучшается при обратном движении головки это отдельный вопрос. Моё предположение таково, что головки немного отклоняются при движении по диску (они подвешены на гибком основании), поэтому движение в разных направлениях приводит к отклонению головок в разную сторону. Одним из самых эффективных способов улучшения чтения что я знаю это небольшой сдвиг головок рукой, меньше миллиметра. Обратное чтение позволяет получить подобный эффект, хотя и в значительно меньшей степени, без прикосновения к головкам руками. Этот диск, на котором делались эксперименты, может быть прочитан на 100% если сдвигать головки вручную. С помощью многократного чтения (прямое + обратное) удавалось достичь цифры 78 bad-секторов без сдвига головок руками.
Еще догадался как измерить скорость вращения диска с помощью простого чтения (очень хотелось померять скорость диска, а функция драйвера у меня не работает, либо я неправильно её использую). Читается один и тот же сектор и замеряется частота чтения. Оказалось что диск у меня вращается со скоростью 295 оборотов в минуту. По логу выложенном в этом сообщении (https://zx-pk.ru/threads/31601-spectrum-archive-reader-programma-dlya-chteniya-tr-dos-diskov.html?p=1056768&viewfull=1#post1056768) можно вычислить что скорость вращения диска составила 288 об/мин. Фунцию измерения скорости вращения диска также добавил.
Сделал help, в котором нет ничего нового и который представляет собой сокращенную версию первого поста из этой темы.
Новую версию добавил в первое сообщение темы.
Serebriakov
29.04.2020, 11:53
CPLx, а можно добавить формат CP/M-дискет Корвета в вашу утилиту?
Стандартный формат *.kdi - это простая посекторная копия 800 KБ = 2 стороны * 80 дорожек * 5 секторов * 1024 байта.
Пустой образ или битые сектора заполняются символом с HEX: E5 (судя по анализу образов, именно этим символом в Корветовских дискетах заполнены пустые байты, а не нулем NULL).
Вот здесь можно взять (http://pk8020.fdd5-25.net/s2-download-soft.html) примеры образов.
CPLx, а можно добавить формат CP/M-дискет Корвета в вашу утилиту?
Да, я думаю можно. Не знаю точно, но на первый взгляд всё выглядит вполне реализуемо. Я посмотрю что там можно сделать. Но я сейчас другим занят (мне захотелось прочитать формат interleave на высокой скорости), поэтому это чуть позже.
Моё предположение таково, что головки немного отклоняются при движении по диску (они подвешены на гибком основании), поэтому движение в разных направлениях приводит к отклонению головок в разную сторону.
Всё гораздо проще - люфт механизма позиционирования головок. Особенно сильно этим страдает советский 5305. У 5311 и 5313 такое тоже может проявляться, но обычно в том случае, если провода к головке задубели и не дают нормально подойти к треку с одной стороны. На Тиках не встречал, на дисководах с червячным приводом тоже. Обычно на дорожку становятся намертво. Но иногда тоже может помочь в чтении подойти с обратной стороны. Я обычно на сбойных секторах помогаю головке пальцем, подталкивая немного или в одном, или в другом направлении.
На MFM-винчестерах вообще есть механизм микростеппинга, когда можно активировать этот режим и головка будет делать шаги меньше, чем шаг между дорожками для восстановления информации.
(очень хотелось померять скорость диска, а функция драйвера у меня не работает, либо я неправильно её использую)
Похоже у меня индексный импульс не доходит до контроллера и отсюда эти проблемы. Я заклеиваю индексное отверстие на дискете и ничего не меняется - всё так же читается, прямо как у меня обычно это и было. Я и до этого думал что симптомы у меня такие, будто индексный датчик не работает, потому что именно тот функционал драйвера где используется датчик оказался неработоспособным у меня. Но я недавно мерял его напряжение на разъеме, и оно падало при перекрытии (или при открытии, не помню точно) индексного датчика.
Сегодня додумался заклеить контакт INDX изолентой. В итоге дисковод вообще перестал читать. Потом убрал эту заклейку, а он по-прежнему не читает. Уже думал что дисководу конец. А он через какое-то время снова заработал. Не знаю что это было, но больше так проверять не хочу. А вот заклейка дискеты показала что ничего не меняется. В общем, странно всё это.
Специально зашёл сказать, что автор программы крут =)
прога очень нужная. До этого с дискетами ZX не имел опыта, замучался подключать с
"гаражного" хранения MC5305, убил часов 8, но прога своё дело сделала,
прочитались с минимальными потерями штук 10 древних дисков.
Очень наглядный интерфей.
Есть большое пожелание. У меня разрешение монитора 1024х768, а окно программы не массштабируется,
в итоге три правые кнопки не видны, опытным путем понял, что третья сохраняет образ =)))
------
Для тех кто будет запускать на WinXP MC5305
1. настройки в биос 360к, перемычка BH01 (третья)
2. положение на шлейфе А: (с переворотом, дальний), определяется как А:
3. работа на скорости только 250
4. и самое главное, нужно резать на дисководе самый крайний сигнал (34й),
без него ошибка 1112 - нет диска.
5. DOS дискеты прочитать не удалось, а ZX читает нормально и довытягивает битые сектора.
6. На плохих секторах, которые обычным путем не читались очень помогал режим "случайное чтение"
плохих секторов, в этом случае из-за случайного быстрого перемещения головки между плохими секторами
плохие вычитывались, видимо решало случайно небольшое смещение головы при постановки на сектор...
----
Ещё раз спасибо за софт.
Pyhesty, спасибо за отзыв!
Есть большое пожелание. У меня разрешение монитора 1024х768, а окно программы не массштабируется,
в итоге три правые кнопки не видны, опытным путем понял, что третья сохраняет образ =)))
Предполагал что такое может быть, но надеялся что всё будет хорошо. :) Сделал возможность менять размер окна, будут появляться скроллбары.
Еще у меня есть просьба кому-нибудь сделать небольшое тестирование. Суть такова:
1. Скачать приложение из этого сообщения.
2. Вставить диск формата TR-DOS.
3. Нажать кнопку Test. Программа попытается прочитать сектор 1 с трека 20 с параметром head=0 (по идее должен прочитаться успешно), после чего его же с параметром head=1 (что должно дать нужную мне ошибку).
4. Выложить сюда полученный лог.
Поскольку у меня очень похоже на то что отсутствует индексный импульс, то я могу получать неправильные коды ошибок. Например когда программа читает несуществующий сектор, то у меня она получает ошибку 21 через 4 секунды. В то же время, судя по описанию контроллера, она должна получать ответ через 2 индексных импульса, то есть в пределах 400 миллисекунд. Поэтому у меня есть предположение что когда сектора нет, то контроллер ждет импульсы, а если их нет, то возвращает 21 - устройство не готово, и что он сигнализирует этим уже отсутствие импульсов, а не отсутствие сектора, и таким образом ошибка ненайденного сектора может теряться. Я хочу точно знать так это или нет, потому что получается что вся программа оказывается заточенной под неработающий INDX, чего бы мне не хотелось. Я собираюсь сделать функцию автоопределения параметра head дорожки (это будет гораздо удобнее, чем устанавливать его вручную), и для этого мне надо точно знать какую ошибку выдает драйвер когда нет нужного сектора.
А что за софт на тех десяти древних дисках ?
07:04:46.889: Log.Init: Log initialized. Date: 06.05.2020
07:04:46.889: MainForm..ctor: Образ диска создан. Имя: | Размер: 160 треков (2560 секторов).
07:05:40.273: Driver.ReadSectorX: Track: 20 | Head: 0 | Sector: 1 | Error: 0 | Bytes Read: 256
07:05:40.632: Driver.ReadSectorX: Track: 20 | Head: 1 | Sector: 1 | Error: 27 | Bytes Read: 0
Error: 27
Спасибо. Мои предположения подтвердились, потому что я получаю 21 через 4 секунды. А тут 27 через 359 мс, по-видимому на втором синхроимпульсе, как и сказано в описании к контроллеру.
У меня 27 получается когда по внешним признакам больше похоже на ошибку CRC в заголовке сектора.
У меня появилась другая странная ошибка - на всех треках не читается нулевой сектор, и так на всех дискетах, привожу последний фрагмент лога:
07:47:51.909: Driver.ReadSector: Track: 159 | Sector: 0 | Error: 27 | Bytes Read: 0
07:47:51.940: Driver.ReadSector: Track: 159 | Sector: 1 | Error: 0 | Bytes Read: 256
07:47:51.955: Driver.ReadSector: Track: 159 | Sector: 2 | Error: 0 | Bytes Read: 256
07:47:51.987: Driver.ReadSector: Track: 159 | Sector: 3 | Error: 0 | Bytes Read: 256
07:47:52.018: Driver.ReadSector: Track: 159 | Sector: 4 | Error: 0 | Bytes Read: 256
07:47:52.033: Driver.ReadSector: Track: 159 | Sector: 5 | Error: 0 | Bytes Read: 256
07:47:52.065: Driver.ReadSector: Track: 159 | Sector: 6 | Error: 0 | Bytes Read: 256
07:47:52.080: Driver.ReadSector: Track: 159 | Sector: 7 | Error: 0 | Bytes Read: 256
07:47:52.127: Driver.ReadSector: Track: 159 | Sector: 8 | Error: 0 | Bytes Read: 256
07:47:52.143: Driver.ReadSector: Track: 159 | Sector: 9 | Error: 0 | Bytes Read: 256
07:47:52.174: Driver.ReadSector: Track: 159 | Sector: 10 | Error: 0 | Bytes Read: 256
07:47:52.205: Driver.ReadSector: Track: 159 | Sector: 11 | Error: 0 | Bytes Read: 256
07:47:52.221: Driver.ReadSector: Track: 159 | Sector: 12 | Error: 0 | Bytes Read: 256
07:47:52.252: Driver.ReadSector: Track: 159 | Sector: 13 | Error: 0 | Bytes Read: 256
07:47:52.267: Driver.ReadSector: Track: 159 | Sector: 14 | Error: 0 | Bytes Read: 256
07:47:52.299: Driver.ReadSector: Track: 159 | Sector: 15 | Error: 0 | Bytes Read: 256
07:47:52.299: MainForm.<ReadDiskCombined_Click>b__19_0: Успешно прочитанных секторов: 2400
07:48:54.043: MainForm.NewImage_Click: Образ диска создан. Имя: D000 | Размер: 160 треков (2560 секторов).
У меня появилась другая странная ошибка - на всех треках не читается нулевой сектор, и так на всех дискетах, привожу последний фрагмент лога:
А предыдущие версии программы ведут себя так же? Или это только в последней версии появилось?
У меня появилась другая странная ошибка - на всех треках не читается нулевой сектор, и так на всех дискетах, привожу последний фрагмент лога:
Один трек читается 1.09 секунды, судя по логу. Такого я еще не видел. Какой-то странный формат диска, похоже. Плохо что не видно что было до ошибки 27 и сколько времени прошло между обращением к драйверу и тем как он выдал эту ошибку.
Точно так же
А другие программы читают хорошо?
Пока всё что могу предложить это запустить этот тест что приложил к посту (кнопка Test, как обычно). Там функция попробует определить формат диска и уже по тем данным прочитать сектора с 10-го трека. Может удастся увидеть какие-то аномалии в формате диска. Но если их нет, то не знаю что может быть причиной.
14:32:20.349: Log.Init: Log initialized. Date: 06.05.2020
14:32:30.739: MainForm.Test_Click: DataRate: FD_RATE_250K | High Resolution Timer Available: True
14:32:32.361: MainForm.Test_Click: Scanning track
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 14 Size: 1 Time: 12.49
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 7 Size: 1 Time: 12.40
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 15 Size: 1 Time: 12.32
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 8 Size: 1 Time: 12.30
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 16 Size: 1 Time: 12.36
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 9 Size: 1 Time: 26.14
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 2 Size: 1 Time: 12.45
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 10 Size: 1 Time: 12.32
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 3 Size: 1 Time: 12.30
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 11 Size: 1 Time: 12.34
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 4 Size: 1 Time: 12.40
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 12 Size: 1 Time: 12.46
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 5 Size: 1 Time: 12.47
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 13 Size: 1 Time: 12.51
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 6 Size: 1 Time: 12.54
14:32:32.798: MainForm.Test_Click: Scanning track
14:32:33.017: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 6 Size: 1 Time: 12.53
14:32:33.017: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 14 Size: 1 Time: 12.46
14:32:33.017: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 7 Size: 1 Time: 12.36
14:32:33.017: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 15 Size: 1 Time: 12.32
14:32:33.017: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 8 Size: 1 Time: 12.33
14:32:33.017: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 16 Size: 1 Time: 12.38
14:32:33.017: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 9 Size: 1 Time: 26.18
14:32:33.017: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 2 Size: 1 Time: 12.44
14:32:33.017: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 10 Size: 1 Time: 12.32
14:32:33.017: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 3 Size: 1 Time: 12.27
14:32:33.017: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 11 Size: 1 Time: 12.34
14:32:33.017: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 4 Size: 1 Time: 12.36
14:32:33.017: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 12 Size: 1 Time: 12.43
14:32:33.017: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 5 Size: 1 Time: 12.44
14:32:33.017: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 13 Size: 1 Time: 12.52
14:32:33.219: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 6 | Error: 0 | Bytes Read: 256
14:32:33.235: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 14 | Error: 0 | Bytes Read: 256
14:32:33.251: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 7 | Error: 0 | Bytes Read: 256
14:32:33.266: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 15 | Error: 0 | Bytes Read: 256
14:32:33.266: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 8 | Error: 0 | Bytes Read: 256
14:32:33.282: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 16 | Error: 0 | Bytes Read: 256
14:32:33.313: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 9 | Error: 0 | Bytes Read: 256
14:32:33.329: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 2 | Error: 0 | Bytes Read: 256
14:32:33.329: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 10 | Error: 0 | Bytes Read: 256
14:32:33.344: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 3 | Error: 0 | Bytes Read: 256
14:32:33.360: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 11 | Error: 0 | Bytes Read: 256
14:32:33.375: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 4 | Error: 0 | Bytes Read: 256
14:32:33.391: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 12 | Error: 0 | Bytes Read: 256
14:32:33.391: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 5 | Error: 0 | Bytes Read: 256
14:32:33.407: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 13 | Error: 0 | Bytes Read: 256
14:32:34.093: MainForm.Test_Click: Track Time: 199670 ms
14:32:34.093: MainForm.Test_Click: Completed.
- - - Добавлено - - -
Вот нашел одну нормальную дискету
14:40:40.981: Log.Init: Log initialized. Date: 06.05.2020
14:40:52.150: MainForm.Test_Click: DataRate: FD_RATE_250K | High Resolution Timer Available: True
14:40:54.007: MainForm.Test_Click: Scanning track
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 1 Size: 1 Time: 23.11
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 9 Size: 1 Time: 11.74
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 2 Size: 1 Time: 11.80
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 10 Size: 1 Time: 11.82
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 3 Size: 1 Time: 11.84
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 11 Size: 1 Time: 11.80
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 4 Size: 1 Time: 11.80
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 12 Size: 1 Time: 11.76
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 5 Size: 1 Time: 11.74
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 13 Size: 1 Time: 11.78
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 6 Size: 1 Time: 11.73
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 14 Size: 1 Time: 11.74
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 7 Size: 1 Time: 11.74
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 15 Size: 1 Time: 11.76
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 8 Size: 1 Time: 11.80
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 16 Size: 1 Time: 11.67
14:40:54.241: MainForm.Test_Click: Scanning track
14:40:54.475: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 1 Size: 1 Time: 23.21
14:40:54.475: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 9 Size: 1 Time: 11.71
14:40:54.475: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 2 Size: 1 Time: 11.78
14:40:54.475: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 10 Size: 1 Time: 11.80
14:40:54.475: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 3 Size: 1 Time: 11.84
14:40:54.475: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 11 Size: 1 Time: 11.79
14:40:54.475: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 4 Size: 1 Time: 11.79
14:40:54.475: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 12 Size: 1 Time: 11.77
14:40:54.475: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 5 Size: 1 Time: 11.76
14:40:54.475: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 13 Size: 1 Time: 11.77
14:40:54.475: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 6 Size: 1 Time: 11.74
14:40:54.475: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 14 Size: 1 Time: 11.73
14:40:54.475: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 7 Size: 1 Time: 11.73
14:40:54.475: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 15 Size: 1 Time: 11.76
14:40:54.475: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 8 Size: 1 Time: 11.80
14:40:54.475: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 16 Size: 1 Time: 11.76
14:40:54.662: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 1 | Error: 0 | Bytes Read: 256
14:40:54.678: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 9 | Error: 0 | Bytes Read: 256
14:40:54.693: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 2 | Error: 0 | Bytes Read: 256
14:40:54.693: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 10 | Error: 0 | Bytes Read: 256
14:40:54.709: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 3 | Error: 0 | Bytes Read: 256
14:40:54.724: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 11 | Error: 0 | Bytes Read: 256
14:40:54.740: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 4 | Error: 0 | Bytes Read: 256
14:40:54.740: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 12 | Error: 0 | Bytes Read: 256
14:40:54.756: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 5 | Error: 0 | Bytes Read: 256
14:40:54.771: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 13 | Error: 0 | Bytes Read: 256
14:40:54.787: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 6 | Error: 0 | Bytes Read: 256
14:40:54.787: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 14 | Error: 0 | Bytes Read: 256
14:40:54.802: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 7 | Error: 0 | Bytes Read: 256
14:40:54.818: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 15 | Error: 0 | Bytes Read: 256
14:40:54.834: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 8 | Error: 0 | Bytes Read: 256
14:40:54.834: Driver.ReadSectorF: Cyl: 5 | PHead: 0 | Head: 0 | Sector: 16 | Error: 0 | Bytes Read: 256
14:40:55.458: MainForm.Test_Click: Track Time: 199732 ms
14:40:55.458: MainForm.Test_Click: Completed.
Это формат интерлив. Но почему-то отсутствует сектор 1. У меня в программе сектора иногда нумеруются с 0 по 15, но вообще на диске они с 1 по 16, и вот этот 1-й сектор отсутствует (он же нулевой в некоторых функциях и логе SAR).
По идее сектор 1 должен быть между 16 и 9:
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 16 Size: 1 Time: 12.36
14:32:32.798: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 9 Size: 1 Time: 26.14
А здесь его нет. После 16 идет сразу 9. Так же видно что время между концом сектора 16 и концом сектора 9 составляет 26.14 мс, вместо 12 мс как это на других секторах. Поэтому этот первый сектор может быть где-то там, но почему-то драйвер не видит его заголовок.
Для сравнения, у меня это всё выглядит так (на диске с интерливом):
12:51:43.441: MainForm.Test_Click: DataRate: FD_RATE_250K | High Resolution Timer Available: True
12:51:45.021: MainForm.Test_Click: Scanning track
12:51:45.255: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 1 Size: 1 Time: 14.07
12:51:45.255: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 9 Size: 1 Time: 12.62
12:51:45.255: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 2 Size: 1 Time: 12.62
12:51:45.255: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 10 Size: 1 Time: 12.62
12:51:45.255: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 3 Size: 1 Time: 12.60
12:51:45.255: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 11 Size: 1 Time: 12.60
12:51:45.255: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 4 Size: 1 Time: 12.62
12:51:45.255: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 12 Size: 1 Time: 12.63
12:51:45.255: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 5 Size: 1 Time: 12.65
12:51:45.256: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 13 Size: 1 Time: 12.63
12:51:45.256: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 6 Size: 1 Time: 12.66
12:51:45.256: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 14 Size: 1 Time: 12.64
12:51:45.256: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 7 Size: 1 Time: 12.63
12:51:45.256: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 15 Size: 1 Time: 12.59
12:51:45.256: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 8 Size: 1 Time: 12.59
12:51:45.256: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 16 Size: 1 Time: 12.59
12:51:45.256: MainForm.Test_Click: Scanning track
Здесь сектора упорядочены начиная с 1, потому что так код написан что он делает упорядочивание начиная с сектора 1. Если сектора 1 нет, то упорядочивания не происходит, поэтому на твоём логе его нет. Но видно что после 16 сектора идет сектор 9, а не 1. Сектор 1 отсутствует вообще, общее количество секторов - 15.
Еще почему-то функция вычисления времени трека дала 330 мс, насколько я понял. Это довольно странное значение (должно быть около 200 мс). Можешь померять скорость моей функцией? Она есть в этой же тестовой программе на кнопке "измерить" на панели "скорость вращения диска". Только номер сектора выставь например 1 (главное что не 0, потому что нулевой сектор она у тебя не видит).
Дискеты где не читается нулевой сектор отформатированы в TR-DOS Ver 5.04T, а дискета где все нормально читается в ZX Disk Studio v1.16 на ПК.
Вот нашел одну нормальную дискету
14:40:40.981: Log.Init: Log initialized. Date: 06.05.2020
14:40:52.150: MainForm.Test_Click: DataRate: FD_RATE_250K | High Resolution Timer Available: True
14:40:54.007: MainForm.Test_Click: Scanning track
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 1 Size: 1 Time: 23.11
14:40:54.241: MainForm.Test_Click: Cyl: 5 Head: 0 Sector: 9 Size: 1 Time: 11.74
О, это интерлив с большим пробелом в конце трека. Такой мне не встречался.
- - - Добавлено - - -
Дискеты где не читается нулевой сектор отформатированы в TR-DOS Ver 5.04T,
У меня много дисков форматированных в TR-DOS 5.04T и таких проблем нет.
А другие читалки читают? ZX Disk Studio, WinTRD, TRReader?
PS
А, и еще у меня TR-DOS 5.04T форматировал так что сектора шли подряд, а не интерливом. Я конечно мог напутать и может то был не 5.04T, но это маловероятно.
ZX Disk Studio читает все отлично, а других у меня еще нет, скиньте мне если не трудно, что бы не тратить время на поиски.
а других у меня еще нет, скиньте мне если не трудно, что бы не тратить время на поиски.
TRReader находится здесь https://zx-pk.ru/threads/16236-trreader-chitalka-tr-dos-diskov.html
WinTRD не нашел. Но я думаю не стоит тратить время. Раз ZX Disk Studio читает, значит прочитать можно. Правда у меня она ничего не читает. Я собственно и стал свою писать потому что у меня ничего не работало.
Интересный случай, конечно. Может ZX Disk Studio читает сразу целый трек, а не посекторно. Но чтение трека я проверить не смогу: у меня индексного импульса нет, по-моему без него контроллер трек прочитать не сможет.
Для тех кто будет запускать на WinXP MC5305
1. настройки в биос 360к, перемычка BH01 (третья)
2. положение на шлейфе А: (с переворотом, дальний), определяется как А:
3. работа на скорости только 250
4. и самое главное, нужно резать на дисководе самый крайний сигнал (34й),
без него ошибка 1112 - нет диска.
Все рекомендации подтверждаю (в биосе, мне показалось, можно выставлять любой тип дисковода, главное что бы он был не NONE иначе сам драйвер просто-напросто не стартанёт), и есть идея на проверить:
Что бы НЕ резать на дисководе самый крайний сигнал (34й), а использовать просто штатный кабель с обычным MC-5305, проверить работу с софтом у которого непосредственно перед чтением дискеты программно вызывается команда драйвера:
DWORD dwRet; uint8_t checkD; //0 - no, 1U - yes
checkD = 0;
DeviceIoControl(h, IOCTL_FD_SET_DISK_CHECK, &checkD, sizeof(checkD), NULL, 0, &dwRet, NULL);
у меня после этого все работает не требуя механических доработок этого флоппика (я подвесил эту установку на кнопку обработки варианта "Продолжить", если предпроверка отвечала, что диск не обнаружен).
Некоторая проблема в том, что на современных материнках больше НЕТ контроллера FDD. В том числе и у меня, из-за чего я не стал развивать какую-либо читалку для этого драйвера. Кроме того, невозможность прочесть трек целиком вместе со служебными областями из-за потери синхронизации, сводит на нет попытки сделать хорошую читалку защищенных дисков.
есть очень много случаев, когда не требуется работа с защищенными дисками и тогда драйвер практически покрывает хотелки считать дюжину легальных секторов на дорожке, или хотя бы примерно "обнюхать" содержимое.
А что за софт на тех десяти древних дисках ?
сложил весь археологизированный софт в виде TRD образов здесь,
bad - указывает на количество битых секторов, если есть что-то особо ценное, что не прочиталось
буду пробовать ещё.
если вообще есть что-то полезное - то напишите, интересно =)
https://cloud.mail.ru/public/4m2d/4ZGvchvpg
- - - Добавлено - - -
Pyhesty, спасибо за отзыв!
Предполагал что такое может быть, но надеялся что всё будет хорошо. :) Сделал возможность менять размер окна, будут появляться скроллбары.
Большое спасибо! теперь удобно и кнопки видно.
Может быть кто-то сможет подсказать, записываю диски ZX Studio 360к (160 треков), пытаюсь прочитать readerom
и после 80го трека все повально bad, сыпет то 27ю, то 1122 ошибку.
вот ссылка на видео, логи и как выглядит чтение в Studio (то же странно)
https://cloud.mail.ru/public/4USQ/5qwKHm7ih
хотя этим же дисководом читал ZX штатные дискеты без проблем, а самозаписанные - вторая половина вся красная.
добавлю миниатюры, но по ссылке выше подробнее...
725317253272533
Спасибо! буду признателен.
Так же такой вопрос, заказал недорогой эмулятор дисковода... есть шанс, что он будет работать с ZX? =)))
72534
заказал недорогой эмулятор дисковода... есть шанс, что он будет работать с ZX?
да, конечно - будет работать.
можно сменить прошивку на альтернативную FlashFloppy https://zx-pk.ru/threads/25546-proshivka-gotek-floppy-disk-emulator-dlya-raboty-s-zx-spectrum.html
и сразу работать с TRDобразами
и после 80го трека все повально bad, сыпет то 27ю, то 1122 ошибку.
27 с такой задержкой (порядка 400 мс) это когда драйвер не видит заголовок сектора. Он ждет два импульса и возвращает ошибку 27. Диск выглядит как неформатированный в том месте. Но тут уже был случай когда драйвер не видел первый сектор, хотя тот существовал. Поэтому после этого мне судить стропроцентно о неформатированности по таким признакам сложно.
80-й трек наводит на мысли что диск форматирован только на 40 цилиндров. Такая разновидность форматирования существует.
- - - Добавлено - - -
, записываю диски ZX Studio 360к (160 треков),
Вот эти 360К меня сейчас смутили. 160 треков это 720К. 360К это как раз 80 треков (40 цилиндров).
Вот эти 360К меня сейчас смутили. 160 треков это 720К. 360К это как раз 80 треков (40 цилиндров).
ну значит я что-то сам намудрил... либо старые ZX дискеты форматированы как 720кБ (возможно жеж такое?)
https://cloud.mail.ru/public/4m2d/4ZGvchvpg
а Studio не смог форматнуть и записать 720к...
или у меня дискеты не поддерживают 720к...
чет я запутался, завтра поэкспериментирую...
а можно дискеты в студии форматнуть на минимальную плотность 320к? (что бы надежнее дискеты были, ну или дискеты или флоп (MC5303 не поддерживают?)
либо старые ZX дискеты форматированы как 720кБ (возможно жеж такое?)
Конечно возможно, их так и форматировали. Те образы размером 640К это диски 720К.
По ZX Disk Studio я не подскажу. Я её почти не знаю потому что она у меня не работает из-за глючного железа.
Сделал новую версию (1.0.0.10). Выложил в первом посте темы.
Что добавлено:
1. Автоопределение параметра Head верхней стороны. Когда сектор на верхней стороне не читается, то программа проверяет параметры заголовков на диске с целью определения значения head. Делаться это может на каждом треке отдельно (но только на верхней стороне). Поэтому теперь подбирать параметр не надо, всё может быть определено автоматически и я не ожидаю что с этим автоопределением могут быть какие-то проблемы, но тем не менее оставил возможность его отключать и задавать параметр вручную.
2. Быстрое чтение формата interleave и некоторых других. Не думаю что очень нужная вещь, но почему-то именно её я хотел сделать больше всего, она мне казалась самой интересной, но в итоге оказалась самой сложной и на неё ушло больше всего времени. Работать будет не на всех машинах, а только на тех где есть таймер высокого разрешения (обычно это компы датируемые с 2005 года и позже) и насколько я понял на винде Vista и выше. Некоторые форматы наоборот будут читаться медленнее, иногда значительно, поэтому есть возможность отключать эту функцию (она обозначается как Read Mode: Fast) и вместо неё включать режим чтения Standard, при котором сектора запрашиваются подряд с 1 по 16.
3. Ускореннное чтение bad-секторов (если их несколько на одной дорожке). Обычно (и как было в этой программе раньше) когда программа сталкивается с нечитающимся сектором, она пытается прочитать его еще раз, из-за чего головка пролетает весь трек вхолостую чтобы снова попасть на этот нечитающийся сектор, и так много попыток. В это время можно было прочитать другие сектора на треке, возможно тоже нечитающиеся, и увеличить счетчик попыток их чтения. В новой версии так и сделано: при встрече нечитающегося сектора продолжается чтение оставшихся секторов на дорожке. Если на дорожке есть N bad-секторов, то можно прочитать каждый из них 5 раз за 5 оборотов диска, вместо 5xN оборотов как было до этого.
4. Ускоренное чтение неформатированной области и сообщение о несоответствующем формате. Если программа не может найти заголовок сектора, то предполагается что остальные заголовки тоже могут отсутствовать, поэтому делается сканирование трека на предмет их наличия. Сканирование трека занимает порядка 215 мс и позволяет увидеть какие сектора отсутствуют и не пытаться их прочитать (попытка прочитать каждый такой сектор занимает 400 мс). Если будут обнаружены сектора нецелевого формата (то есть например размером 512 байт на диске читаемом как TR-DOS), то будет выдано сообщение об этом. Раньше это выглядело как обычная ошибка на диске.
5. Размер формы уменьшен. Диапазон допустимых треков сокращен до 172. Драйвер, по крайней мере у меня, всё равно не может позиционировать головку на 86-й цилиндр (считая от нуля). Т.е. у меня он работает только на 86 цилиндрах, с 0 до 85 включительно - это 172 трека.
6. Лог отключен. Лог-файл не создается, количество сообщений в окне уменьшено, оставлены только значимые для пользователя.
7. Сделано чтение формата CP/M. Но оно не протестировано, т.к. таких дисков у меня нет.
CPLx, а можно добавить формат CP/M-дискет Корвета в вашу утилиту?
Стандартный формат *.kdi - это простая посекторная копия 800 KБ = 2 стороны * 80 дорожек * 5 секторов * 1024 байта.
Пустой образ или битые сектора заполняются символом с HEX: E5 (судя по анализу образов, именно этим символом в Корветовских дискетах заполнены пустые байты, а не нулем NULL).
Вот здесь можно взять (http://pk8020.fdd5-25.net/s2-download-soft.html) примеры образов.
Чтение CP/M сделал, но не протестировал до конца. По сути написано всё это вслепую, по аналогии с TR-DOS. Поэтому рекомендую тщательно её протестировать, и не забыть проверить целостность данных.
Serebriakov
22.05.2020, 21:50
Чтение CP/M сделал, но не протестировал до конца. По сути написано всё это вслепую, по аналогии с TR-DOS. Поэтому рекомендую тщательно её протестировать, и не забыть проверить целостность данных.
Огромная благодарность! В ближайшие дни протестирую. Сейчас дамп-машинка слегка не работает, нужно починить =) Есть целая пачка сильно забэдованых дискет для Корвета, которые давно ждут своей участи =)
огромное спасибо!
есть несколько вопросов:
1. Друг принес дискеты на всех не читается 0й сектор, при этом в реальном ZX дискета читает,
это какой-то изощренный способ защиты от копирования? =)
не знаю насколько это актуально, но интересно как это реализовано? там реально ничего не записано на 0м секторе?
72721
2. Вторая проблема, я не могу записать обратно (на другой диск) считанный образ, для примера, есть дискета, она 158 треков.
72722
я её записываю обратно ZX Studio и не могу считать обратно этой прогой, выдает ошибку CRC Error на всех секторах,
при этом ZX Studio обратно считывает (кажется даже корректно, проверить не могу).
3. Третья проблема не относится к этой программе, но что бы не плодить сущностей =) чем создать удобно trd образ на 160 треков (750кБ?)
я очень надеялся, что это можно сделать просто в ZX Studio, но он создает только образ 80 дорожек (((
спасибо!!!
ps: ОС WinXP
1. Друг принес дискеты на всех не читается 0й сектор, при этом в реальном ZX дискета читает,
это какой-то изощренный способ защиты от копирования? =)
не знаю насколько это актуально, но интересно как это реализовано? там реально ничего не записано на 0м секторе?
Нет, это не защита от копирования, а уже встречавшийся феномен (https://zx-pk.ru/threads/31601-spectrum-archive-reader-programma-dlya-chteniya-tr-dos-diskov.html?p=1061501&viewfull=1#post1061501) которому у меня нет объяснения. Эта программа читает диск используя функцию чтения сектора, конкретно IOCTL_FDCMD_READ_DATA. Другая используемая функция - IOCTL_FDCMD_READ_ID - она читает заголовок первого попавшегося сектора. Как показал эксперимент здесь (https://zx-pk.ru/threads/31601-spectrum-archive-reader-programma-dlya-chteniya-tr-dos-diskov.html?p=1061518&viewfull=1#post1061518), на некоторых дисках обе эти функции драйвера не видят первый (он же нулевой в моей нумерации) сектор. Почему так происходит я не знаю. Как удается другим программам (той же ZX Disk Studio) читать такие диски мне тоже неизвестно. Может быть они используют функцию чтения трека (IOCTL_FDCMD_READ_TRACK), а может используют то же чтение сектора что и я, но с другими параметрами, неизвестными мне. Так или иначе, моей программой такие диски прочитать нельзя. У меня таких дисков нет, поэтому я не могу провести детальные исследования с ними и отладить их чтение. Мне остается в таких случаях только рекомендовать использовать ZX Disk Studio. Или что угодно еще что может их прочитать. Судя по всему, причина лежит в формате диска, но в чём именно особенность этого формата я не знаю.
я её записываю обратно ZX Studio и не могу считать обратно этой прогой, выдает ошибку CRC Error на всех секторах,
при этом ZX Studio обратно считывает (кажется даже корректно, проверить не могу).
Запусти программу с ключом /logfile (будет создан файл с логом), прочитай диск и скинь лог-файл сюда. Я хотел бы посмотреть что там, может удастся что-то понять.
По картинкам оказалось что цвет панели со статистикой отличается от цвета формы (по идее должен совпадать). В 7-й винде совпадет, а оказывается в XP нет.
На втором скрине диск читался 80 секунд и это в быстром режиме? Там наверное он быстрее прочитается в режиме Standard. Скорее всего формат хитрый, я на такие не расчитывал и думал что они редкость.
На первом скрине вообще 193 секунды. Что-то это всё работает у других гораздо хуже чем я предполагал.
3. Третья проблема не относится к этой программе, но что бы не плодить сущностей =) чем создать удобно trd образ на 160 треков (750кБ?)
я очень надеялся, что это можно сделать просто в ZX Studio, но он создает только образ 80 дорожек (((
У меня она создает образ на 160 дорожек без проблем. Там надо создать образ, потом сохранить как trd.
Если она создает 80 дорожек (т.е. 40 цилиндров), то может она использует настройки из биос и надо дисковод по-другому там настроить? Но это только догадка.
ок! во вложении лог,
пока экспериментировал, оказалось, что если переключить скорость на 300к, то все прочиталось )))
(это есть в логе)
хотя ZX настроен на 250к, вот так, получается драйвер один, а работают в разных приложениях по разному))
так что вопрос снят =) спасибо)
пока экспериментировал, оказалось, что если переключить скорость на 300к, то все прочиталось )))
Вот это новость. Получается что одни диски читаются на 250К, а другие на 300К, и это всё на одной машине?
И большое спасибо за лог. Может сделаю обработку этой ситуации, чтоб таких тормозов не было. Потому что сектора вообще-то в неправильном порядке читались и поэтому всё медленно было.
во вложении добавил лог чтения диска, у которого не читаются 0е сектора.
Black Cat / Era CG
25.05.2020, 23:48
0 сектора не читаются часто на дискетах отформатированных средствами самой TR-DOS. Расстояние от индексного отверстия до начала сектора слишком маленькое и контроллер не успевает его схватить. Это известная проблема.
ZX Disk Strudio должен уметь создавать образа на 160 треков, просто про 80 дорожек имеется в виде одна сторона. Создайте, сохраните, проверьте.
В таком случае могу порекомендовать Pyhesty заклеить на дискете индексное отверстие полностью и посмотреть что будет.
Кстати, не получается ли так что диск в этом сообщении (https://zx-pk.ru/threads/31601-spectrum-archive-reader-programma-dlya-chteniya-tr-dos-diskov.html?p=1065121&viewfull=1#post1065121) читается быстрее в режиме Standard чем в Fast?
MetalliC
26.05.2020, 12:26
Расстояние от индексного отверстия до начала сектора слишком маленькое и контроллер не успевает его схватить.
еще говорят это потому что WD17xx-контроллеры детектят индекс по переднему фронту, а PC-шные контроллеры по заднему, и типа по-этому и не могут прочитать 1е сектора дисков с очень коротким (или отсутсвующим как у трдос) GAP4A.
и да, частичная заклейка отверстия (при чем с определенной стороны) вроде как помогала.
Улыбнулась удача и дисковод завелся на ново приобретенном Celeron 950.
Считал 33 дискеты из 60, вот фидбек/хотелки:
1.Запоминать Data Rate и при следующем старте программы выставлять прошлый
2. Типичный скрипт оцифровки:
а) вставляем дискету
б) считываем каталог что бы понять спектрумовская она или нет
в) если не спектрумовская - отклываем в сторону
г) если спектрумовская то начинаем считывание, но для этого нам нужно: закрыть окно, нажать Read
было бы удобно иметь кнопку Read в окне каталога, и что бы после ее нажатия каталог закрывался.
д) диск считался, видим что есть ошибки, начинаем пробовать чтение задом на перед и случайное чтение. Хорошо бы сделать что бы программа в случае ошибок сама пыталась перечитать диск (если стоит такая галочка), скажем разок пробежалась назад, разок вперед - результата нет? Тогда разок или пару рандомно. Ежели диск прочитался без ошибок то пусть автоматом сохраняется (ведь имя уже задано, можно сделать по галочке)
е) диск считался и дальше приходится делать лищние движение, нажимать Save и в открывшемся окне еще раз нажимать Сохранить.
ж) ура! сохранили. Теперь нужно считать следующий диск, диски мы именовали по номерам по порядку... хм, а ведь программа может это делать сама, к имени след диска прибавляя 1
Коллекция считана, идем в каталог, все файлы на месте, но чего то не хватает. Ага, не хватает файла отчета с ошибками, где указано имя образа, номера ошибочных секторов и имена файлов на которые попали эти сектора.
Еще момент, когда на диске много ошибок, ты забываешь что там на этом диске, ибо каталог видел 5-10 минут назад, да и то мельком, просто что бы убедится что это TRD диск. И вот тут не плохо было если бы каталог был под рукой. А в каталоге этом было видно какие же файлы у нас битые и на сколько секторов.
Пока все. В любом случае величайший респект за прогу!! Куда слать донаты?
- - - Добавлено - - -
Еще из хотелок: IS-DOS формат
у меня скопилось порядка 200 дисков, уверен что там будет эксклюзив.
- - - Добавлено - - -
При сохранении образа в TRD его bad-сектора заполняются символом B (как это делает WinTRD). Необработанные сектора (у которых не было попытки чтения) заполняются символом N. При загрузке образа по этим меткам определяются плохие и еще не читавшиеся сектора.
То есть, если в секторе у нас был битый 1 байт, то в итоге мы получаем убитый сектор целиком? (благодаря заполнению N/B)??
- - - Добавлено - - -
Еще не удобно что на каждом диске спрашивают сколько секторов. Во первых откуда я знаю сколько их там? Во вторых наверное можно сделать автодетект (по галочке).
Black Cat / Era CG
13.07.2020, 06:38
Была у меня такая фигня, она смотрела trd и искала рядом файлик с тем же именем, но с расширением .bslist и показывала карту образа. Но я на нее забил
Ага, не хватает файла отчета с ошибками, где указано имя образа, номера ошибочных секторов и имена файлов на которые попали эти сектора.
Там есть кнопка Build Maps на вкладке Various. Нажимаешь, выбираешь файлы (можно выбирать много, там multi-select) и сохраняешь результат как html, который потом смотришь в браузере. Там будут карты образов с битыми секторами. Можно просматривать и образы созданные WinTRD, она тоже заполняет битые сектора байтом 'B', по которым ориентруется мой алгоритм при построении карт.
Есть еще кнопка Build File Table, работает аналогично (выбираются файлы, результат пишется в html-файл) и формирует списки файлов указанных образов с указанием какие оказались битыми, и там же внизу общая статистика.
Еще момент, когда на диске много ошибок, ты забываешь что там на этом диске, ибо каталог видел 5-10 минут назад, да и то мельком, просто что бы убедится что это TRD диск. И вот тут не плохо было если бы каталог был под рукой. А в каталоге этом было видно какие же файлы у нас битые и на сколько секторов.
По-моему это делает кнопка Show Catalogue на панели образа, если я правильно понял.
В любом случае величайший респект за прогу!! Куда слать донаты?
Спасибо! Не, донаты не нужны. Прога бесплатная. Можете считать что это мой долг форуму. Мне тут помогли и донатов не просили.
Еще из хотелок: IS-DOS формат
IS-DOS формат сделаю.
Из остального - посмотрю что там можно сделать.
То есть, если в секторе у нас был битый 1 байт, то в итоге мы получаем убитый сектор целиком? (благодаря заполнению N/B)??
Если сектор битый, то драйвер не выдает ни одного его байта. Поэтому потери данных из-за этого заполнения не происходит. Непрочитанный сектор всё равно был бы заполнен нулями.
Еще не удобно что на каждом диске спрашивают сколько секторов. Во первых откуда я знаю сколько их там? Во вторых наверное можно сделать автодетект (по галочке).
Ну, знать ты можешь исходя из свойств своего дисковода, например, т.к. у них бывает разное количество цилиндров. Автодетект конечно сделать можно, но мне кажется он будет слишком медленно работать.
Там есть кнопка Build Maps на вкладке Various. Нажимаешь, выбираешь файлы (можно выбирать много, там multi-select) и сохраняешь результат как html, который потом смотришь в браузере. Там будут карты образов с битыми секторами. Можно просматривать и образы созданные WinTRD, она тоже заполняет битые сектора байтом 'B', по которым ориентруется мой алгоритм при построении карт.
Есть еще кнопка Build File Table, работает аналогично (выбираются файлы, результат пишется в html-файл) и формирует списки файлов указанных образов с указанием какие оказались битыми, и там же внизу общая статистика.
А сорцы проги можно глянуть или на гитхаб выложить?
Я бы может сделал небольшой форк для поточной работы.
Когда цифруешь 1000 дискет, каждый лишний клик на вес золота.
- - - Добавлено - - -
А что такое "header not found", это так-же убитый целиком сектор?
А сорцы проги можно глянуть или на гитхаб выложить?
Я бы может сделал небольшой форк для поточной работы.
Когда цифруешь 1000 дискет, каждый лишний клик на вес золота.
- - - Добавлено - - -
А что такое "header not found", это так-же убитый целиком сектор?
Исходник я завтра выложу. Наверное вместе с форматом IS-DOS (он почти доделан).
header not found это когда заголовок сектора не найден. Случаться может просто случайно (т.е. сектор может быть, но просто не прочитался и может прочитаться в другой раз), может быть следствием того что диск неформатирован, или форматирован в другом формате где нет сектора с запрашиваемым номером, или какой-то заданный параметр сектора не совпал с параметром реального сектора (например не совпал параметр Head, размер сектора или номер цилиндра). Есть также примеры когда сектор существует, но драйвер почему-то не находит даже его заголовок. Такое было уже в этом треде вот здесь (https://zx-pk.ru/threads/31601-spectrum-archive-reader-programma-dlya-chteniya-tr-dos-diskov.html?p=1061501&viewfull=1#post1061501), случается с первыми секторами на каждом треке почему-то. Мне не удалось выяснить причину почему так происходит. При этом другая программа (ZX Disk Studio) диск читала. Так что моя прога не на все случаи жизни подходит, это надо иметь ввиду.
Твоя цель в упрощении процесса чтения мне понятна и я её разделяю. Я так понял число кликов надо максимально сократить. Постараюсь придумать что там можно сделать с этим.
Еще наблюдение. Data rate опасно близко расположен к Read Catalogue, один раз случайно нажал и не заметил что выставилось 500к и таким образом счел последующие 3 диска не рабочими.
Сделал чтение формата IS-DOS. Бинарник добавил в первый пост темы (версия 1.0.0.11).
Исходник: https://github.com/dalvx/SpectrumArchiveReader
Насчет формата IS-DOS. Точного и подробного описания я не нашел, но из тех отрывочных данных что есть, я понял что сектора там имеют размер 1024 байта и номера 1, 2, 3, 4, 9. Надеюсь проблем с параметром Head верхней стороны не будет. Дисков таких у меня нет, поэтому протестировать код я не могу и всё написано вслепую. Образ имеет формат аналогичный TRD, и сохраняется с расширением .isd, т.к. "правильного" расширения я опять же не нашел.
Насчет формата IS-DOS. Точного и подробного описания я не нашел, но из тех отрывочных данных что есть, я понял что сектора там имеют размер 1024 байта и номера 1, 2, 3, 4, 9. Надеюсь проблем с параметром Head верхней стороны не будет. Дисков таких у меня нет, поэтому протестировать код я не могу и всё написано вслепую. Образ имеет формат аналогичный TRD, и сохраняется с расширением .isd, т.к. "правильного" расширения я опять же не нашел.
IS-DOS диски обычно сохраняют в FDI формате (поддерживает большинство эмуляторов).
Реже сохраняют в TD0.
- - - Добавлено - - -
Сделал чтение формата IS-DOS. Бинарник добавил в первый пост темы (версия 1.0.0.11).
Спасибо!
Сегодня протестирую.
IS-DOS диски обычно сохраняют в FDI формате (поддерживает большинство эмуляторов).
Добавил FDI-формат.
Добавил FDI-формат.
Спасибо!
А вывод каталоге не планируется для исдоса?
Спасибо!
А вывод каталоге не планируется для исдоса?
Я не знаю формата каталога. Если есть где-то описание, то тогда смогу ответить насколько сложно будет это реализовать.
(Про ис-дос я вообще ничего не знаю, у меня не было таких дисков, я его видел только один раз когда знакомый приносил показать их и я даже не мог их скопировать из-за нестандартного формата.)
Поработал с десятком IS-DOS дисков. Странно, но ощущение что читаются они менее стабильно. К концу часто есть наростающие беды. Которые в результате рандомного, прямого и обратного чтения удается почти убрать. Жалко что приходится делать это в ручном режиме (сначала запускаю рандом, потом вперед, назад, опять рандом).
- - - Добавлено - - -
Я не знаю формата каталога. Если есть где-то описание, то тогда смогу ответить насколько сложно будет это реализовать.
(Про ис-дос я вообще ничего не знаю, у меня не было таких дисков, я его видел только один раз когда знакомый приносил показать их и я даже не мог их скопировать из-за нестандартного формата.)
Тут есть описание многих форматов:
http://zxpress.ru/article.php?id=8564
- - - Добавлено - - -
Попробовал CP/M диск от Хоббита, считался.
- - - Добавлено - - -
Нашел баг. В какой-то момент Read Random Sectors перестал зацикливаться. Вероятно после того как я пробовал читать тольк 1 сторону.
Заметил пару нюансов. Имя файла которое вводишь при нажатии New не синхронизировано с именем по нажатие Save. Из-за этого иногда возникает путаница, записал диски не записал, какое имя ему назначить и т.п.
А еще в Поле Track To всегда висит 172 трек, хотя при создании диска я выбираю 160 всегда. Тут попутно вопрос, почему при старте 172, а по умолчнию при New - 160.
- - - Добавлено - - -
Кстати, было бы удобно иметь стандартные сочетания клавиш: CTR + S - save, CTR + N - new, С - каталог
- - - Добавлено - - -
Оцифровал сабжем уже порядка 200 дискет. Впереди еще больше.
Еще заметил. Что при закрытии программы, она предупреждает что не сохранен образ, но вот не указывает какой (tr-dos, cp/m, is-dos).
А еще в Поле Track To всегда висит 172 трек, хотя при создании диска я выбираю 160 всегда. Тут попутно вопрос, почему при старте 172, а по умолчнию при New - 160.
Track To это область чтения. 160 - это размер образа. Реальная область чтения является пересечением отрезка [TrackFrom, TrackTo) и [0, "размер образа"). Т.е. реальным TrackTo будет значение Min(TrackTo, ImageSize).
160 по умолчанию потому что я думаю большинству именно это и надо, т.к. большинство дисков всего на 160 треков.
Я могу специально для тебя сделать отдельную вкладку с кнопкой на которую будет повешен скрипт делающий всё автоматом: определяющий тип диска, читающий его нужной функцией (TR-DOS/IS-DOS/CP/M), в нужной комбинации (случайное, вперед, назад и т.п.), сохраняющий образ в нужную папку с нужным названием файла. Будет спешиал эдишон. Максимальная автоматизация. Но многие вещи будут захардкодены, выглядеть с точки зрения UI всё это будет криво, как костыль, почему я и не особо имел энтузиазма это делать. Если интересно, то напиши какие настройки тебе нужны, какая конкретно последовательность действий нужна. Раз уж у тебя так много дисков, это реально может всё облегчить.
И еще: ты когда читаешь нечитающиеся сектора, какие-то манипуляции с головкой дисковода делаешь для улучшения чтения (прижимаешь, сдвигаешь и т.п.?)
По несоответствиям New и Save я посмотрю что там.
И еще: ты когда читаешь нечитающиеся сектора, какие-то манипуляции с головкой дисковода делаешь для улучшения чтения (прижимаешь, сдвигаешь и т.п.?)
Делаю да.
Но 90% ошибок уходят сами, при рандоме + вперед + назад (поэтому и хочется автоматизации в этом вопросе).
Если не ушли, то прижимание головки помогает в ~30% случаев.
Насчет того что доработка только для меня. Это не совсем так. Есть еще ААА он много цифрует. За 15 лет он оцифровал тысячи 3 дисков. Я не сильно меньше. Был еще Страйкер, у него тоже такие же обьемы были (спасал диски со всей Беларуси). Есть и другие люди который цифруют диски сотнями.
Нашел баг. В какой-то момент Read Random Sectors перестал зацикливаться. Вероятно после того как я пробовал читать тольк 1 сторону.
Сделал отдельную вкладку для быстрого чтения и автоматической записи прочитанных образов.
Добавленная вкладка называется HT. Суть такова: вставляем диск, нажимаем кнопку New Disk, диск читается и сохраняется в директорию.
Конкретно по кнопке New Disk происходит следующее:
- Создается новый образ размером Default Image Size треков.
- Определяется формат нулевого трека (TR-DOS, IS-DOS, CP/M).
- Если формат определился, то делается чтение диска (если стоит галка напротив соответствующего формата) в режиме вперед-назад Number of Reads раз. Например, если Number of Reads равен 3, то диск будет прочитан вперед, потом назад, потом снова вперед (всего, таким образом, будет пройден 3 раза).
- После первого чтения вперед, происходит автоопределение размера диска. Определяется формат треков и их соответствие целевому. Изучаются треки которые имеют номер больше чем Default Image Size и меньше чем Max Tracks. Параметр Max Tracks зависит от дисковода, максимально допустимое число - 172. Default Image Size я думаю имеет смысл ставить равным 160 треков. Функцию автоопределения размера диска можно отключить установив Max Tracks равным Default Image Size.
- После выполнения чтения вперед-назад, включается случайное чтение (если стоит соответствующая галка). К нему задается таймаут и количество error подряд при чтении секторов - для остановки чтения. 00:00:00 - отсутствие таймаута. Нулевое значение параметра Stop On Nth Fail означает отсутствие ограничения по количеству ошибочных чтений.
- Потом производится автоматическое сохранение образа в указанную директорию (для каждого типа диска своя) по указанному шаблону файла (для каждого типа диска свой). Шаблон задается задается именем файла и непрерывной последовательностью звездочек, которые будут заменены на порядковый номер. Число звездочек обозначает длину числа как строки. Например "Disk ***" будет записываться как Disk 000, Disk 001, и так далее. Расширение будет добавлено соответствующее выбранному формату файла. Формат файла также задается (FDI, TRD, Modified TRD, и KDI для CP/M).
Кнопка Repeat Reading - Заново запустить цикл чтения, но без создания нового образа, автоопределения типа диска и его размера.
Save - Сохранение образа. (Хотя он сохраняется автоматически, но можно это сделать еще раз. Будет сохранен в тот же файл что было сделано ранее автоматом.)
Баг с чтением случайных секторов исправил.
Еще мне в личку сообщили что вот это является ошибкой:
Если сектор битый, то драйвер не выдает ни одного его байта. Поэтому потери данных из-за этого заполнения не происходит. Непрочитанный сектор всё равно был бы заполнен нулями.
И действительно, драйвер всё же выдает данные если сектор оказался с ошибкой CRC. Поэтому сейчас я сделал так что в образ могут быть записаны прочитанные с ошибкой данные. Если такой образ сохранить в формате TRD, то эти данные будут вписаны в сектор, но будет потеряна информация о том что он имеет ошибку CRC. Если сохранить как Modified TRD, то будет сохранение как в первой версии и как сделано в WinTRD - т.е. bad-сектор будет заполнен символом 'B', и таким образом будет потеря данных, хотя сохранится информация о том что он bad. Аналогично для загрузки образа: при загрузке как Modified TRD, сектора заполненные символом 'B' будут восприняты как CRC-Error. При загрузке просто TRD (без Modified) такого не будет. Надо сказать что нормальные сектора могут естественным образом содержать сплошные 'B' - это случается в однотонной графике, где атрибуты могут быть заполнены этим символом сразу на 3 сектора подряд, такие диски встречаются.
По этой причине я рекомендую сохранять образы в формате FDI - там сохраняется как содержимое bad-сектора, так и признак того что он bad.
Сообщение о несохраненном образе при закрытии приложения я убрал. Вместо него в таблице указывается был ли образ изменен.
Также сделал настройки (которые не хотел делать раньше). Сохраняются в файл xml создаваемый в директории приложения. Параметры вкладок теперь сохраняются. Ключи DataRate убраны из командрой строки и больше не работают. Вместо них можно использовать настройки - всё сохранится автоматом.
Эту версию я не считаю окончательной, может быть много багов.
Затестил последнюю версию.
В вкладке HT как-будто перепутаны скорости, при 250 начало читать, а при 300 отказалось.
После чтения первого дороги вылетел эксепшн:
https://yadi.sk/i/FSyqFEcJvpGrRg
- - - Добавлено - - -
При чтении в режиме TRD та-же беда, пользоваться программой пока не получается.
Тем временем в самой первой версии тоже словил баг. После рандомного чтения и попадания на HD диск, сектор и трек самопрозвольно выставились на 45 - 45
(видимо на значение последнего бэда).
Затестил последнюю версию.
Странное дело. Я у себя не нашел перепутанных скоростей.
Попробуй взять вот эту версию (там я прикрепил еще файл pdb с отладочной информацией), и если будет исключение, то выложи его полный текст здесь (скрина я думаю будет недостаточно, там обрезается часть инфы обычно).
Можешь заодно потестить новую фичу чтения кастомных форматов (она сделана еще не до конца, но уже почти до конца).
PS
Еще лучше запустить с ключом /logfile и посмотреть лог.
Довольно забавным образом удалось прочитать трек включая межсекторные данные благодаря особенностям формата этого трека. На одном из моих дисков оказались треки где были сектора с размерами 4, 5, 6, 7, 8 и 9. Цифра 6 означает размер сектора 8192 байта (размер всего трека - 6250 байт). Что означают остальные я даже не знаю. Тайминги между заголовками секторов указывали на то что реально их размер составляет 256 байт. Но в сами заголовки вписаны неправильные размеры. Дал команду прочитать сектор с размером 6 (8192 байта), получил ошибку 23 (ошибка CRC), и данные всего трека вместе со всеми пробелами, т.к. контроллер читая сектор размером 8192 байта в итоге выдал данные всего трека. Прочитано было порядка 8192 байта (не менее 8118, остальные там нули и трудно понять были эти нули прочитаны или были изначально в памяти). Глядя на сами данные видно что там похоже синхронизация слетает на конце трека (где стык окончания и начала, в районе индексного импульса это должно быть по идее), и вместо 4E начинают идти E4, ну и вся остальная инфа искаженная оказывается. Жаль что это сработало только благодаря ошибкам в формате и другие треки таким способом не прочитать. Ну хоть увидел структуру дорожки, впервые за 23 года наверное. Последний раз я видел такое только читая трек на ВГшке.
Shadow Maker
13.08.2020, 11:49
мне кажется достаточно сохранять только имена (удобно при создании коллекций)
трек/сектор и.т.д - уже избыточно
Размер надо полюбому и стартовый адрес. Полно одинаковых названий.
А драйвер не позволяет читать RAW содержание полной дорожки?
А драйвер не позволяет читать RAW содержание полной дорожки?
У драйвера есть функция чтения трека, описываемая как Raw track read: https://simonowen.com/fdrawcmd/ioctls/#cmd_read_track
Но у меня индексного импульса нет (баг железа, как я полагаю), поэтому эта функция возвращает у меня ошибку 21 (device not ready) и я не знаю работоспособна ли она в принципе. По некоторым по чужим постам (https://zx-pk.ru/threads/12842-zx-disk-studio-programma-dlya-raboty-s-obrazami-diskov.html?p=981045&viewfull=1#post981045) можно прийти к выводу что драйвер может читать трек в сыром виде только с двумя дисководами (для этого есть другая команда: https://simonowen.com/fdrawcmd/ioctls/#raw_read_track ). Как на самом деле - не знаю.
CPLx, Понятно. Вообще конечно прискорбный факт... Получается что это какое-то искусственное ограничение...
CPLx, Понятно. Вообще конечно прискорбный факт... Получается что это какое-то искусственное ограничение...
Провел небольшое исследование на эту тему.
Сначала убедился что у меня нет индексного импульса именно из-за неисправности дисковода, а не контроллера. Потом направил на провод INDX сигнал с TR00. Это дало мне возможность имитировать наличие индексных импульсов путем перекрывания TR00 вручную. Жуткое извращение, но именно оно окончательно доказало неисправность именно дисковода. Эта самая имитация индексных импульсов (путем вставления и выстаскивания в датчик TR00 ножниц с большой частотой руками) позволила частично запустить команду чтения трека, т.к. контроллер стал видеть индексные импульсы (а она читает от индексного импульса, и без него не отрабатывает). Команда постоянно выдавала ошибку 23, но это не особо важно. Важно что она выдавала данные. Данные были какой-то кашей, которую я не смог найти на читаемом диске. Но где-то она их брала. Потом я вставил чистый диск (TR-DOS, все сектора заполнены нулями) и попробовал прочитать уже его. И тут оказалось что команда чтения трека возвращает одни нули на этом диске (по прежнему с ошибкой 23). Проверял много раз оба диска: записанный возвращает кашу, чистый возвращает нули. Никаких межсекторных данных, которые я ожидал увидеть на чистом диске более четко видными. Возвращение нулей на чистом диске навело меня на мысль что команда чтения трека читает на самом деле не трек, а содержимое секторов. Т.к. в драйвере уже был ранее мной найден один хак, то я решил проверить нет ли и тут хака.
(Хак который был найден ранее заключается в следующем. В драйвере есть команда ожидания индексного импульса. По логике кажется что для ожидания индексного импульса драйвер должен проверять значение индексного датчика, и при регистрации отверстия сигнализировать об импульсе. Но оказалось что сделано там это всё иначе. Вместо этого драйвер пытается прочитать несуществующий сектор, после чего возвращает управление. Контроллер, когда не может найти сектор, ждет 2 импульса и отвечает ошибкой что сектор не найден. Таким образом, чтение несуществующего сектора обеспечит нам попадание на индексный импульс (второй по счету при этом; т.е. один импульс мы пропустим). В ВГ93 можно было напрямую посмотреть состояние этого датчика. Но в этом контроллере - нет. В нём можно посмотреть датчик TR00 и датчик защиты от записи, но индексный датчик недоступен для прямого чтения.)
Так вот, в поисках предполагаемого хака я полез в исходный код драйвера и увидел что здесь никакого хака нет и что он честно передает команду чтения трека COMMND_READ_TRACK драйверу FDC. Дальше я полез в документацию контроллера. А там я увидел следующее:
73266
Если я правильно понял описание, то команда чтения трека читает все сектора подряд, начиная от индексного импульса, не проверяя параметры секторов. В этом её главное отличие от команды Read Data, которая читает только сектора с указанными параметрами (номер, цилиндр, сторона, размер), и при несовпадении параметров она такие сектора игнорирует (надо сказать что ВГ93 проверяла только цилиндр и номер сектора, и точно не проверяла сторону, из-за чего существуют разные варианты форматирования верхней стороны - поэтому иногда бывает что верхняя сторона не читается на PC-шном контроллере). Чтобы прочитать ей (командой read data) сектора, надо заранее точно знать все их параметры, иначе ничего не получится. Read track же читает сектора не глядя на их параметры: попался сектор, она прочитала; попался следующий - снова прочитала. Получается что-то вроде совмещенного сканирования и чтения, всё в один проход. Но читаются именно данные секторов, а не межсекторное пространство.
Судя по документации, команды, аналогичной чтению дорожки у ВГ93, данный контоллер не имеет. Именно контроллер, а драйвер уже как следствие.
Судя по документации, команды, аналогичной чтению дорожки у ВГ93, данный контоллер не имеет. Именно контроллер, а драйвер уже как следствие.
Я лично пробовал читать весь трек целиком вместе с межсекторным пространством. И именно через этот драйвер. Но использовать не стал, т.к. контроллер сбивался на синхропоследовательностях также, как на спектруме при чтении трека целиком.
Я лично пробовал читать весь трек целиком вместе с межсекторным пространством. И именно через этот драйвер. Но использовать не стал, т.к. контроллер сбивался на синхропоследовательностях также, как на спектруме при чтении трека целиком.
А каким образом, какой командой? И были ли признаки что он выдает межсекторные данные?
А каким образом, какой командой? И были ли признаки что он выдает межсекторные данные?
DeviceIoControl(h, IOCTL_FDCMD_SEEK, &Track, sizeof(Track), NULL, 0, &dwRet, NULL);
SetDataRate(h, 1); // 300kbps
FD_READ_WRITE_PARAMS rwp = {FD_OPTION_MFM, 1, 0, 0, // Определить rpw:
0, 7, 10, 0, 0}; // Режим чтения - MFM
// PHead - 0 (Phisycal Head 0)
// Cyl - 0 (not used)
// Head - 0 (not used)
// Sector - 0 (not used)
// Size - 0 (0 - 80 байт?,
// 1 - 256 байт,
// 2 - 512 байт,
// 3 - 1024 байта,
// 4 - 2048 байта,
// 5 - 4096 байт,
// 6 - 8192 байт,
// 7 - 16384 байта.
// EOT - 5
// Gap - 0 (not used?)
// DataLen - 0 (not used)
printf("\nRaw Read");
DeviceIoControl(h, IOCTL_FDCMD_READ_TRACK, &rwp, sizeof(rwp),
DataBuf, 0x2000, &dwRet, NULL);
printf("\nAdr = %X, Len = %X\n", DataBuf, dwRet);
// pause
WriteFile(rawFile, DataBuf, 0x2000, &dwRet, NULL); // Записываем raw-дорожку в файл
Да, сырая дорожка читалась.
Да, сырая дорожка читалась.
Точно! У меня тоже прочиталась. Хотя тут надо именно те параметры выставлять. Круто.
Точно! У меня тоже прочиталась. Хотя тут надо именно те параметры выставлять. Круто.
Лично мне показалось, что толку от чтения трека целиком маловато, т.к. когда сбивается синхронизация, невозможно восстановить информацию.
Лично мне показалось, что толку от чтения трека целиком маловато, т.к. когда сбивается синхронизация, невозможно восстановить информацию.
Синхронизация срывается в момент окончания записи данных сектора - там возникает шов новой записи (записи сектора) и старой (данных записанных при форматировании). По этой причине, если трек форматирован, но на нём не производилась запись секторов, то синхронизация на нём не срывается (это я только что проверил: прочитал трек, и все пробелы там отображены корректно). Сейчас посмотрел на записанном треке - весь первый сектор прочитан правильно, а срыв синхронизации происходит в момент окончания его записи: по идее должны идти байты 4E, но идут 0x27 (которые представляют собой сдвинутый 4E). Т.е. мы знаем в какой точке происходит срыв синхронизации - это сразу после CRC сектора. Мы также знаем чем заполнены эти пробелы между секторами (байтом 4E), поэтому можем вычислить насколько там произошло смещение, сравнив полученные данные с теми что должны быть. Поэтому в принципе восстановить трек можно и попытаться.
Мы также знаем чем заполнены эти пробелы между секторами (байтом 4E), поэтому можем вычислить насколько там произошло смещение, сравнив полученные данные с теми что должны быть. Поэтому в принципе восстановить трек можно и попытаться.
Нельзя восстановить, т.к. сместившись, информация уже не может быть расшифрована из MFM. Вернее, она расшифровывается но не правильно и с потерями. Обратно ее преобразовать в MFM, сместить на бит, и перерасшифровать не получится.
Лично мне показалось, что толку от чтения трека целиком маловато, т.к. когда сбивается синхронизация, невозможно восстановить информацию.
Мне кажется, что использовать её всё-таки можно. Для того чтобы обнаруживать те же самые защиты - плавающие данные, данные без заголовков секторов. Данные самих секторов читать ей не получится действительно. Но хорошо, что после сбивки, очередной правильный синхрокод A1A1A1 возвращает все на место.
Межсекторные 4E даже сбитые прекрасно восстанавливаются. Но сами сбитые данные это не поможет увидеть (при перезаписи секторов перезаписанные тайминги не совпадают с межсекторными).
Вообще можно попробовать перевести данные в МFM поток и сравнить с тем что должно читается без сбивки (прочитав другими утилитами). Возможно, не все так плохо.
MFM поток представляет собой последовательность длительностей в пропорции 2/3/4, а фальшивый синхрокод C2 смещает байтовое окно. Так вот насколько я понял, при этом смещении происходит дублирование куска байта в MFM представлении. Эти закономерности можно было бы попытаться вычислить и сделать некий компенсатор.
Для того чтобы обнаруживать те же самые защиты - плавающие данные, данные без заголовков секторов.
Данные совсем без заголовков секторов она прочитать не сможет, судя по всему. Работает эта команда не так как в ВГ93. Она ждет индексный импульс, после чего ищет первый заголовок сектора, потом начинает читать содержимое трека. Первый выданный ей байт это первый байт данных этого сектора. Когда сектор кончается, она продолжает читать данные дальше, пока не считается весь трек (в моем случае она это делает циклически несколько раз, т.е. несколько оборотов диска, выдавая порядка 28 000 байт). Если на треке нет заголовков секторов, то эта команда ничего не читает и драйвер выдает ошибку 1122. У меня подозрение, то что как Titus её использовал это нестандартный прием, т.к. не соответствует документации.
очередной правильный синхрокод A1A1A1 возвращает все на место.
Вот почему-то не возвращает. Этот синхрокод A1A1A1 пишется перед данными каждого сектора и по идее данные секторов должны быть правильными по этой причине. Но на практике это не так, и синхронизация почему-то не восстанавливается, и данные секторов оказываются искаженными.
Вот картинка полученная при чтении чистого трека, на который не производилось посекторной записи и где синхронизация не слетает в конце секторов.
https://ibb.co/WtpF9Wc
(Значения байт указаны в десятичной системе. 78 это 4E) Первым синим прямоугольником обведен 15-й сектор размером 256 байт (имеет код 1), там же видно что это 61-й цилиндр. Вторым синим прямоугольником - 16-й сектор. Большие области нулей - данные, перед которыми идут байты 161, 161, 161, 251 (A1 A1 A1 FB). А красный квадрат это момент срыва синхронизации, как я полагаю из-за шва который получается при записи трека когда он зацикливается. И дальше все сектора идут искаженные, в том числе их данные. Данные становятся равными 255 - это явно попали синхроимпульсы MFM вместо данных. И синхронизация не восстанавливается почему-то перед областями этих данных, хотя по идее должна. Почему так происходит непонятно.
У кого-то есть материнка с набортным контроллером дисковода, поддерживающим функцию однопроходного форматирования трека при этом сразу с пользовательскими данными?
У драйвера Саймона для этого режима заготовлена отдельная функция, но код реализации одинаков с обыкновенным форматированием (однобайтным заполнителем).
Вообще сразу после форматирования поток трека читается очень чисто, т.к. нет срывов от дозаписей.
Данные становятся равными 255 - это явно попали синхроимпульсы MFM вместо данных. И синхронизация не восстанавливается почему-то перед областями этих данных, хотя по идее должна.
Область с 12 ноликами идет перед A1A1A1, и действительно странно, поскольку Этот синхрокод в контроллере автоматом должен смещать начало байта. Вне зависимости от режима чтения. Может новые контроллеры позволяют отключать пересинхронизацию после первичной? Старые вроде не позволяют (равно как и отключать синхронизацию по C2).
Грустновато с этой точки зрения. Пространства для маневров мало.
Учитывая, что на современных материнках вообще перестали устанавливать контроллеры FDD, есть смысл переходить на собственную железку, которая может всё.
Самая дешёвая и при этом способная на это железка - это greaseweasel, проблема только в том что софтовая часть пишется неторопливо, да и есть некоторые проблемы с 5.25" дисководами. Т.е перспективы мощные, но пока далеко не раскрыты. Ну я вот по-немногу пилю свой вариант на Ардуино ещё дешевле, но слабоват для глубоко анализа, да и с записью сложности. Но в целом - да. От встроенных в мать контроллеров пришлось отказаться в силу ограниченных возможностей с не стандартными дисками защитами или испорченностями.
Самая дешёвая и при этом способная на это железка
Не надо дешевую. Надо полнофункциональную. Чтобы она могла все. И читать в аналоговом виде трек, и позиционироваться по дорожкам дискретностью не менее 1/8 шага. А лучше 1/16.
Тогда можно сделать 'фотографию' любого диска и уже разбирать ее программно сколько угодно.
Тогда можно сделать 'фотографию' любого диска и уже разбирать ее программно сколько угодно.
Зачем? Чтобы молиться на нее?:)
Для 0.001% дисков, с областями, которые размагнитились за пределами чувствительности АРУЗ головки дисковода, но в то же время отличимыми от шума?
Ну это такое...
Для того чтобы вытащить данные со сбойного диска например ?
^m00h^, Если не получается вытащить оттуда средствами обычного дисковода, через обработку оцифрованного потока, то в 99.99% случаев и аналоговый слепок не поможет. Я говорю про сцарапанный магнитный слой или физические дыры.
Мне было бы любопытно посмотреть на кейс несвежего диска, который получилось без ошибок вытянуть только через аналоговый магнитный слепок со сверхдетализацией. Я просто не могу себе такое представить. Гипотетический аппарат конечно такой возможен, только я вижу в нем цену с не менее чем шестью нулями в евро, который бы помог только в одном из миллиона дисков. И наверное на этом диске была бы формула бессмертия, или телепортации. Иначе овчинка выделки не стоит.
Домены со временем сглаживаются. Энтропия беспощадно уничтожает все детали. Считывающая головка уже неплохо борется с уменьшением магнитного контраста, и растворением деталей. Аналогово просто увидишь эту грустную размытую картину, и констатируешь гибель информации. А сейчас мы загружая этот прошедший через пороговый фильтр поток просто не ощущаем степень размагниченности. Мы косвенно можем его видеть через увеличение отклонений с увеличением плотности (переходя от внешнего трека к внутреннему).
только я вижу в нем цену с не менее чем шестью нулями в евро
Что за ерунда)
Сделать платку с контроллером шагового двигателя с микростеппингом, и от нее управлять мотором. Вот тебе и микрошаги.
И для головок дисковода сделать быстрый АЦП, и на него завести сигнал с головок.
Какие шесть нулей)))
- - - Добавлено - - -
Если не получается вытащить оттуда средствами обычного дисковода, через обработку оцифрованного потока, то в 99.99% случаев и аналоговый слепок не поможет.
Моя распознавалка аудиокассет показала, что хорошая аналоговая оцифровка позволяет вытащить не то, что 1 из миллиона записей, а практически 99.9% всех плохих записей. С диском там посложнее, конечно, т.к. плотность записи выше. Но думаю, что много что получится считать из нечитаемого.
Titus, Я буду рад когда-нибудь почитать на хабре про кейс подобного «наконец-то» прочитанного диска с драгоценными данными.
Ну и в конечном итоге можно брать данные с донорских дисков. Может где-то сохранилось интро но испорчен кодовый блок и наоборот.
И для головок дисковода сделать быстрый АЦП, и на него завести сигнал с головок.
А головки показывают направление магнитных доменов? Ну то есть в этом гипотетическом убер-устройстве оно должно оцифровывать силу и направление магнитного поля у поверхности, а не просто величину в каком-то фиксированном направлении... Такие головки есть? Если нет, то тезис о шести нулях не отменяется.
А головки показывают направление магнитных доменов? Ну то есть в этом гипотетическом убер-устройстве оно должно оцифровывать силу и направление магнитного поля у поверхности, а не просто величину в каком-то фиксированном направлении... Такие головки есть? Если нет, то тезис о шести нулях не отменяется.
Конечно показывают. На выходе головки полярность магнитного поля и сила. Т.е. сила со знаком.
- - - Добавлено - - -
Titus, Я буду рад когда-нибудь почитать на хабре про кейс подобного «наконец-то» прочитанного диска с драгоценными данными.
Меня нет на хабре, да и кому это надо)
Про прочитанные пленки с драгоценными данными можно сто страниц написать)
Titus, знака мало. Магнитное поле может иметь любое направление в пространстве. Оно тоже важно.
Область с 12 ноликами идет перед A1A1A1, и действительно странно, поскольку Этот синхрокод в контроллере автоматом должен смещать начало байта. Вне зависимости от режима чтения. Может новые контроллеры позволяют отключать пересинхронизацию после первичной?
Может когда он читает данные сектора, то перестает обращать внимание на синхропоследовательности (или как там они называются). Потому что всё это чтение очень похоже на чтение данных: начинается прямо с начала данных сектора.
CPLx, вроде защита даже такая есть — сектор в секторе, когда внутри блока данных новый синхрокод, заголовок, и сектор (меньшего размера). Так что, думаю, что синхронизация должна работать везде и всегда. Еще раз — возможно новые контроллеры умеют их игнорировать при каких-то установках. Я не особо разбираюсь в контроллерах, я свой в какой-то степени сочиняю.
CPLx, вроде защита даже такая есть — сектор в секторе, когда внутри блока данных новый синхрокод, заголовок, и сектор (меньшего размера).
Я не понял почему из этого следует что синхронизация должна работать везде.
Теоретически, такой сектор можно прочитать обычными средствами, без чтения raw-трека. В том числе этим драйвером.
- - - Добавлено - - -
У кого-то есть материнка с набортным контроллером дисковода, поддерживающим функцию однопроходного форматирования трека при этом сразу с пользовательскими данными?
Судя по документации, контроллер 82078 поддерживает такую запись. Думаю что его производные тоже.
Titus, знака мало. Магнитное поле может иметь любое направление в пространстве. Оно тоже важно.
Мы говорим о конкретном формате записи. А он подразумевает лишь два направления.
Мы говорим о конкретном формате записи. А он подразумевает лишь два направления.
Этот же формат записи подразумевает и то, что треки имеют определённую ширину, и надобности в 1/8 и 1/16 нет, равно как и анализе аналоговой части. И если уж вы настаиваете что у полнофункционального устройства должны быть эти фишки, будьте последовательны, учитывайте перемагничивание внешним полем, которое может быть любым, и фиксироваться должен не один вектор по касательной, но и радиальный, и поперечный. А такая головка я не знаю сколько будет стоить.
Плюс бывают случаи когда сам магнитный диск смят в гармошку - убер-устройство должно вообще в полном объёме делать слепок, не требуя прямого полотна... эдакий сверхдетальный объемный сканер магнитной неоднородности.
Я же лично считаю, что это убер-устройство избыточным, и любого дисковода в принципе в 99.99% будет достаточно, надо просто чтобы контроллер имел режим незамутненного, максимально сырого дампа (максимум с различением поляризации доменов, но и без этого можно).
Этот же формат записи подразумевает и то, что треки имеют определённую ширину, и надобности в 1/8 и 1/16 нет,
Сдвиг головок это один из самых эффективных способов улучшения чтения, и при этом безопасный (в отличие от их прижатия). Так что такая фича как раз бы помогла.
CPLx, у вас есть кейсы дискет, которым помогал сдвиг головок?
Я конечно допускаю варианты, когда диски писались на заведомо кривом устройстве, головка которого на пол трека сдвинута, но лично я с таким не сталкивался. Куда чаще помогает доступ до непосредственно таймингов и учет четной-не четной поляризации (что недоступно через стандартные fdc).
CPLx, у вас есть кейсы дискет, которым помогал сдвиг головок?
Почти 100% (если не 100%) моих дисков были прочитаны только так и без этого прочитать их бы не удалось. (А дисков у меня 115 - вот и число кейсов.) В некоторых случаях приходилось прижимать головку. Например диск из этого поста (https://zx-pk.ru/threads/31601-spectrum-archive-reader-programma-dlya-chteniya-tr-dos-diskov.html?p=1058946&viewfull=1#post1058946) был прочитан на 100% именно сдвигом головок, без которого он читается так как там показано, т.е. далеко не на 100%. Я собственно и добавил чтение назад чтобы получить эффект сдвига головок. Диски писались на моём же дисководе на котором я их читал, так что это не похоже на проблему юстировки.
CPLx, Мне почему-то кажется что вся эта эквилибристика — сугубо из-за того что raw поток вытаскивать нельзя дефолтовым контроллером — уж очень он привередлив к таймингам. Поэтому и приходится устраивать танцы с бубнами чтобы головки придавливать, чтобы датчик индексный двигать. Нет случаем сырого SCP образа каких-нибудь из них?
MetalliC
16.08.2020, 08:32
у вас есть кейсы дискет, которым помогал сдвиг головок?
Я конечно допускаю варианты, когда диски писались на заведомо кривом устройстве, головка которого на пол трека сдвинута, но лично я с таким не сталкивался.
да мешок таких кейсов :)
в 90х это было обычным явлением - если какая-то часть чужой дискетки не читалась (типично в конце диска) - голову пододвигали пальцом в одну или другую сторону, и часто это помогало.
голову пододвигали пальцом в одну или другую сторону, и часто это помогало.
Если будет SCP образ подобного диска, который без шатания головки не читается, он бы помог понять, вытащилась бы эта инфа raw устройствами, или без смещения головки (что я считаю дичью, и свою трогать не буду) вообще никак. Текущая моя гипотеза, что из raw потока со спец обработкой такое несложно прочитать.
из raw потока со спец обработкой такое несложно прочитать.
RAW-поток - это дауншифтинг относительно аналогового микростепперного потока) После магнитной головки идет компаратор, который понимает только смену направления магнитного поля и все. Это подходяще, когда запись хорошая, и совершенно убийственно, когда на записи помехи.
Тоже самое было с магнитными лентами. Если запись хорошая, то компаратор прекрасно подходит. Если плохая, то хоть тресни, ты уже потерял информацию. Тогда как по аналоговому сигналу восстанавливались 99.9% таких записей просто влёт.
Titus, надеюсь ты понимаешь, что сравнивать плёнку с плавающей скоростью и полным разнобоем с подстройкой, с куда более технологичным дисковым решением не очень корректно? Вообще положение головки с завода "стандартизировано" и не нуждается в подстройке.
RAW-поток - это дауншифтинг относительно аналогового микростепперного потока)
Если ты не обеспечишь аналоговый захват магнитного потока по всем трём осям, то это не особо что-то улучшит. Компаратор вполне справляется с диффузией и размагничиванием, а где он не справляется - поможет разве что только сверхтехнологичный трехмерный захват за кругленькую сумму. Да и то, не факт что поможет. Никто таким заморачиваться не будет. Хотя возможно все не так уж и сложно - по сути нужно использовать три головки с разной ориентацией вместо одной, и при захвате потока просто учитывать темпоральное смещение. Но даже KryoFlux таким не промышляют, это просто убер-избыточно.
Но прочитать про кейс о том как смогли вытащить данные с дискеты которая была пропущена через шредер, будет интересно :)
Поэтому и приходится устраивать танцы с бубнами чтобы головки придавливать, чтобы датчик индексный двигать. Нет случаем сырого SCP образа каких-нибудь из них?
Индексный датчик там роли не играл у меня - у меня инфы от него контроллер не получает. У меня так, что можно индексное отверстие заклеить и ничего не меняется.
Нет, образа SCP нет.
А почему сдвиг головок работает можно предположить что либо почему-то дорожка пишется криво, либо запись происходит по более широкой полосе чем чтение. Я думаю что скорее имеет место второй вариант. Намагниченность создается широкой, а читается слабо чувствительной головкой по узкой зоне. Поэтому если данные исказились в одном месте (в центре дорожки), то могут еще остаться с краю. Этим же можно объяснить почему сдвиг не приводит к ухудшению чтения, которое должно было бы быть если бы запись шла по кривой траектории. Но это только догадки, разумеется.
Этим же можно объяснить почему сдвиг не приводит к ухудшению чтения, которое должно было бы быть если бы запись шла по кривой траектории. Но это только догадки, разумеется.
У меня другая теория. Намагничивание происходит с нарастающим расширением зоны перехода, с такой силой тока чтобы с учетом скорости движения поверхности доходить до границы, но не влиять на соседние дороги. Но даже будучи смещенным с "центра" намагниченности, домены остаются достаточно намагниченными, чтобы усилитель головки мог переход-границу "увидеть". Она может и будет размытой, но пока самый короткий домен не исчезнет вообще, он будет читаться. Именно этим объясняется то, что при смещении головки оно все равно нормально читается. Просто потому что система устроена таким образом, что уменьшение "контраста" не сильно ломает чтение, триггер все равно распознает переход, даже если он небольшой.
Но когда например в серии ++-----++ перемагничивается маленький домен, и получится ++--+--++, то тогда - да, появляются ложные импульсы (причем - всегда парно). Но такие маленькие искажения внести внешним полем нельзя - это должно быть сверхточечное воздействие.
Чаще проблемы происходят из-за размагничивания самой головкой в процессе включения/выключения (пусковым током), но тогда влияние происходит на все домены в приличном радиусе, и это можно обнаружить за счет сравнения таймингов четных и нечетных переходов (они просто разойдутся).
Или же возможно что диск положили рядом с динамиком и магнитное поле сместит вообще все домены... тогда мы просто увидим вместо трех тайминговых кластеров шесть (есть у меня такой диск, но там расхождение пока не настолько большое).
Физические дыры просто создают области без намагниченности, и тогда АРУЗ головки просто шум ловит.
Неровная поверхность (плавающая дистанция от поверхноти до головки) уменьшает силу магнитного поля считываемого домена, тем самым добавляет воздействие соседних (т.е. теряется "фокусировка").
Возможно что шпиндель при записи крутился неравномерно изза каких-то конструктивных проблем, и тогда скорость будет существенно плавать и чтение также будет затруднено.
Возмозжно и то, что отверстие в самом диске шире чем положено (с учетом допуска), и тогда центровка может пойти по одному месту - для таких дисков действительно микростеппинг мог бы помочь, только едва ли такой диск вообще был бы юзабельным изначально - в нем бы после перетыкания в дисковод уже переставалось бы всё читаться - такие диски мгновено оказывались в помойном ведре.
Все эти проблемы практически неустранимы при чтении штатным контроллером. При чтении потока импульсов с последующей обработкой (как делают всякие KryoFlux'ы и недорогие аналоги) такая обработка возможна. Гипотетические убер-устройства с аналоговым чтением и микростеппингом про которое говорит Titus, в природе вроде нет, поэтому сложно судить о его плюсах (помимо проблемы с центровкой, с которой лично я никогда не сталкивался).
Если ты не обеспечишь аналоговый захват магнитного потока по всем трём осям, то это не особо что-то улучшит.
Мне кажется, ты или прикалываешься, или троллишь, или это просто демагогия)
Мне кажется, ты или прикалываешься, или троллишь, или это просто демагогия)
Я пытаюсь продемонстрировать что это или недомера, или избыточно, но никак не практичное. И воспринял как прикол/троллинг/демагогию именно это:
Не надо дешевую. Надо полнофункциональную. Чтобы она могла все. И читать в аналоговом виде трек, и позиционироваться по дорожкам дискретностью не менее 1/8 шага. А лучше 1/16.
Тогда можно сделать 'фотографию' любого диска и уже разбирать ее программно сколько угодно.
"Чтобы она могла все" - надо учитывать и перпендикулярные записи, и сдвиги магнитных доменов в разных направлениях (размагничивания бывают разными), и поэтому все 3 измерения в случае "МОЧЬ ВСЁ" - необходимы. Сказав А, надо сказать и Б.
MetalliC
16.08.2020, 13:24
надеюсь ты понимаешь, что сравнивать плёнку с плавающей скоростью и полным разнобоем с подстройкой, с куда более технологичным дисковым решением не очень корректно? Вообще положение головки с завода "стандартизировано" и не нуждается в подстройке.
надеюсь ты понимаешь, что речь идёт в том числе о "вытаскивании с того света" дисков записанных еще во времена царя гороха отечественными флопами ?
а наша техника в ту эпоху была крайне пахабного качества, и "плавало" там всё что угодно и как угодно. надежностью или стандартизацией тоже особо не пахло, нормальное явление если свежекупленный новый девайс мог требовать юстировки или наладки/доработки (например чтоб не запарывал диски). емнип особо отличались таким с позволения сказать качеством т.н. "армянские" флопы (хз реально ли они производились в Армении), зато были несколько дешевле других, потому у людей в наших местностях были самыми массовыми.
и теперь вот это всё требуется как-то прочитать :)
надеюсь ты понимаешь, что речь идёт в том числе о "вытаскивании с того света" дисков записанных еще во времена царя гороха отечественными флопами ?
Я вроде слышал только про успех при вытаскивание то ли исходников, то ли ещё чего-то такого, самой первой версии Принца Персии...
и теперь вот это всё требуется как-то прочитать
Сделайте, пожалуйста кто-нибудь, у кого есть такой убитый диск, слепок в Greaseweazel, в .scp формате. Чтение уже расшифрованного MFM в сабже вообще не поможет понять, что там на самом деле не так. А scp можно поисследовать хотя бы, чтобы понять в каком направлении рыть в таких случаях.
именно на спеке ещё важную роль играет схема контроллера (точнее то что называют фапч)
несколько раз сталкивался с ситуацией когда на скорпе спокойно читалось то что сбоило на пентагоне (дисковод тот-же)
Удалось отремонтировать дисковод и восстановить нормальную работу индексного датчика. Выяснилось сразу несколько неизвестных ранее для меня вещей.
ZX Disk Studio стала работать. Сканирует диск и читает. Таким образом, оказалось что она у меня не работала из-за отсутствия индексных импульсов.
На некоторых дисках перестали читаться первые сектора. Явление которое ранее встречалось здесь (https://zx-pk.ru/threads/31601-spectrum-archive-reader-programma-dlya-chteniya-tr-dos-diskov.html?p=1061501&viewfull=1#post1061501) и с которым я лично не сталкивался никогда до этого. Теория, согласно которой причиной является близкое расположение сектора к индексному отверстию, выглядит правдоподобной. Обычно у нормально читающихся дисков первый сектор находится на расстоянии около 145 байт от начала трека. У дисков с невидимыми первыми секторами расстояние оказалось равным 11-12 байт (началом сектора здесь считается первый ноль из последовательности нулей за которой следует синхропоследовательность A1A1A1). Помимо этого, у проблемных дисков отсутствует заголовок трека.
Ранее в этой теме писали что ZX Disk Studio может читать такие сектора, но у меня она не может ни просканировать, ни прочитать их.
Мне не удалось подобрать параметры для функции драйвера, чтобы она смогла прочитать такие сектора. Не удалось найти и другого чисто программного способа их чтения.
Закрытие индексного отверстия решает проблему чтения этих секторов. Закрытие должно быть полным, а не частичным. Мне не удалось частично закрыть отверстие так чтобы сектор стал читаться и при этом контроллер сохранял возможность видеть индексный импульс. Даже когда на глаз отверстие закрыто частично и сектор читается, всегда оказывалось что контроллер не получает индексный импульс вообще. Уменьшение закрытия, которое влекло восстановление индексного импульса, всегда приводило к невозможности прочитать первый сектор.
Чем индексное отверстие мешает контроллеру осталось загадкой. Я склонен считать что это баг контроллера.
ZX Disk Studio проверяет наличие диска, и как следствие требует наличия индексных импульсов, только в начале цикла чтения, когда гоняет головку по диску туда-сюда. Поэтому можно вставить диск, запустить чтение, подождать пока она погоняет головку, после чего перекрыть индексное отверстие, и программа начнет чтение, в том числе будет способна читать первые сектора. Главное успеть это сделать до чтения первого трека (т.е. нулевого), иначе первый сектор на нём не будет прочитан. Я перекрывал индексный датчик визиткой из магазина радиодеталей размером 48x90 мм, вставляя её поверх диска в дисковод. Нужной мне микросхемы у них не оказалось, так хоть визитка пригодилась. Получается что всё-таки не зря ездил туда.
SAR был изначально написан из расчета отсутствия индексного импульса. Была идея переделать его так чтобы он его использовал, т.к. информация с него в принципе полезна в некоторых случаях. Но, ввиду проблемы нечитаемости первых секторов, похоже придется сохранить в значительной степени всё как есть, чтобы для чтения таких секторов была возможность закрытия индексного датчика без сильной потери работоспособности программы.
Более детальный анализ происходящего на одном из проблемых дисков (с невидимыми первыми секторами) показал следующее.
Время от индексного импульса до выхода из команды чтения заголовка сектора составило 13.65 мс. Этот выход из команды чтения происходит в момент когда головка находится на следующем байте после контрольной суммы заголовка второго сектора. Читался заголовок второго сектора, т.к. первый сектор контроллер не видел. Сектора на треке шли последовательно: 1, 2, 3, и т.д.
Данные для 99 чтений: среднее: 13.659 мс, стандартное отклонение: 0.016 мс, MAE = 0.0093 мс. Погрешность для MAE в пересчете на байты оказывается равной 0.28 байт. Для стандартного отклонения – 0.49 байт.
(A) Время между индексным импульсом и концом заголовка второго сектора 13.65 мс означает что прошло 420.42 байт от индексного импульса, со стандартным отклонением 0.49 байт.
Исследуемый диск был записан на ВГ93. При форматировании происходит наложение записи при зацикливании трека, из-за чего происходит срыв синхронизации в этой точке, что легко видно на глаз. По этой точке можно определить положение на треке где ВГ93 видела индексный импульс. Просмотр данных сырого трека показал что между этой точкой и моментом окончания заголовка второго сектора находится 422(±1) байта. Из пункта (A) известно что между индексным импульсом PC-контроллера и концом заголовка второго сектора проходит 420.42 байт. Таким образом, ВГ93 видела индексный импульс на 422 - 420.42 = 1.58 байт раньше чем PC-контроллер (с погрешностью не менее 1.5 байта).
Есть теория, согласно которой проблема невидимости секторов возникает из-за того что ВГ93 регистрирует индексный импульс по переднему фронту, а PC-контроллер по заднему, из-за чего получается эффект смещения точки индексного импульса на треке и приближения его к сектору [ссылка (https://zx-pk.ru/threads/2131-sokhranim-diski-s-zashchitoj-dlya-potomkov!.html?p=71090&viewfull=1#post71090)]. Но полученные факты показывают что ВГ93 и PC-контроллер видят индексный импульс в одном и том же месте трека, с разницей не более одного-двух байт, причем эта разница лежит в пределах погрешности оценки.
Эту теорию можно подвергнуть проверке и другим способом. Исходя из размеров индексного отверстия можно оценить с какой разницей должны видеть контроллеры индексный импульс, если они регистрируют его в диаметрально противоположных точках отверстия. Диаметр индексного отверстия составляет не менее 2.5 мм. Расстояние от центра индексного отверстия до центра диска – 25 мм. Это дает длину окружности на уровне центра индексного отверстия равной 157.07 мм. Что дает угловой размер индексного отверстия 5.73 градусов. Что в свою очередь дает размер индексного отверстия равным 99 байт. Поэтому точка индексного импульса на треке должна отличаться минимум на 99 байт между ВГ93 и PC. Повторюсь, на практике разница оказалась не более одного-двух байт. Поэтому теория о разном методе регистрации индексного импульса выглядит ошибочной. Как следствие, идея частичного закрытия отверстия не имеет удовлетворительного теоретического объяснения.
По крайней мере на моём железе так.
Надо отметить еще одну особенность формата проблемых дисков (у меня найдено их пока два): на них отсутствует заголовок трека. На треке, после пробела в 11-12 байт 0x4E после индексного импульса, сразу идут сектора. У непроблемных дисков сначала идет пробел 80 байт 0x4E, потом заголовок трека, потом еще один пробел и только после него идут сектора. Расположение секторов на этих двух проблемных дисках оказалось разным: у одного сектора идут последовательно, у другого интерливом. Значит проблемный формат делали разные программы, а не какая-то одна.
CPLx, А про какой дисковод идет речь?
CPLx, А про какой дисковод идет речь?
Про мой МС 5313, который не имел индексного импульса и с которым я тем не менее прочитал свои диски и написал эту прогу, по-началу даже не зная об этой проблеме.
Может таки лучше сменить mc5313 на Teac ?
ZX_NOVOSIB
21.08.2020, 17:43
Не обязательно на тик, можно на митсуми, или на эпсон или на панасоник или на ... ... ... .
Может таки лучше сменить mc5313 на Teac ?
Зачем? Чем он лучше? Мой диски читает, в целом работает. А за TEAC мало того что деньги платить надо, так еще возиться с отправкой денег и ждать доставки, и я даже не знаю что хуже. И тоже неизвестно как он там еще работать будет. Мне дисковод теперь нужен только для развития этой программы, исправления багов и так далее. В остальном я сделал с ним всё что мне надо было - прочитал все диски. Я, пока его ремонтировал, дважды попадал в ситуацию когда мне казалось что я его безнадежно сжег, и как-то не особо расстраивался по этому поводу. В одном случае таки сжег микросхему отвечающую за TR00 - я же в электронике ноль. С TEAC мне будет еще и страшно экспериментировать. Я, пока еще индекс был неисправен, хотел купить что-то вроде Mitsumi или Fujitsu (они продаются по сотне-две долларов, включая доставку). Но сейчас смысла в этом не вижу.
ZX_NOVOSIB
21.08.2020, 17:46
Mitsumi или Fujitsu (они продаются по сотне-две долларов, включая доставку). Но сейчас смысла в этом не вижу.
откуда такие цены? Я 6 лет назад митсуми идеальный за 300 рублей взял ))) Какие-то сотни долларов откуда-то.... Тыщи за полторы рублей с доставкой можно взять 5-ти дюймовый идеальный дисковод, не российскую дрянь.
откуда такие цены?
Я на ebay смотрел. А на российском рынке я не видел ничего кроме хлама.
Тыщи за полторы рублей с доставкой можно взять 5-ти дюймовый идеальный дисковод, не российскую дрянь.
Это где например?
- - - Добавлено - - -
Удалось несколько раз прочитать первый сектор (на диске где он невидимый) чисто программным методом, без закрытия индексного датчика. Но чтение очень нестабильное, получается редко.
ZX_NOVOSIB
21.08.2020, 18:54
Это где например?
Да блин, х.з. на местной барахолке разве не продают? Там периодически устраивают распродажи! Создай тему, мол куплю протестированный импортный 5 дисковод. Тебе точно кто-нибудь да продаст.
А на российском рынке я не видел ничего кроме хлама.
хм.. странно, я тупо на авито в 14-15 годах купил несколько 5" дисководов за копейки и в идеальном состоянии.
хм.. странно, я тупо на авито в 14-15 годах купил несколько 5" дисководов за копейки и в идеальном состоянии.
Я допускаю что я плохо искал. Но искал на авито как раз.
Сам на авито смог приобресть самсунг sfd-560d за 2к.
CPLx, А этот МС твОй до какой дороги максимально добирается? В DCU максимальный формат, который на моем старом теаке 83 дороги делал (бОльшая часть моих дисков как раз 83 дорожечные). На самсунге нынешнем тоже 83 прекрасно видятся. Написано что типа это редко такое встречается. Странно что мне дважды везло.
CPLx, А этот МС твОй до какой дороги максимально добирается?
84 цилиндра там, от 0 до 83. 168 треков (0 - 167).
Да, на Авито удалось найти кучу дисководов по низким ценам. Не знаю почему раньше ничего не находилось.
ZX_NOVOSIB
22.08.2020, 07:50
Не знаю почему раньше ничего не находилось.
потому что не искал )
Подключил тут к компу второй дисковод, и сразу возник вопрос, а что в программе нет выбора дисковода?
Подключил тут к компу второй дисковод, и сразу возник вопрос, а что в программе нет выбора дисковода?
Потому что у меня плата поддерживает только один дисковод, да и сам дисковод только один, поэтому я даже не думал о такой возможности. Будет время - может добавлю выбор дисковода. На данный момент дисковод читается только A:
Удобно ведь два дисковода 3.5" и 5.25".
У меня материнка поддерживала один, но сейчас я собрал другой комп где два флопика поставил.
У меня материнка поддерживала один, но сейчас я собрал другой комп где два флопика поставил.
Я недавно собирал себе из сорцов версию, работающую с B: (и только с ним) - было проще, чем раскручивать корпус и переставлять перемычку на флопе
Вот она - https://cloud.mail.ru/public/GZo4/JWDEg1uk5
Спасибо автору за выложенные исходники!
CPLx, Программа настолько хороша, что я даже не могу понять, как она без запинки читает диск, у которого на реальном спектруме более 20 секторов не читаемы совсем.
P.S. Может допилить, для полного счастья, еще и режим записи?
не могу понять, как она без запинки читает диск, у которого на реальном спектруме более 20 секторов не читаемы совсем.
так может читается без проверки ? если так то это хреново.
раньше по сети гуляло много битых образов снятых как раз кривыми читалками
CPLx, Программа настолько хороша, что я даже не могу понять, как она без запинки читает диск, у которого на реальном спектруме более 20 секторов не читаемы совсем.
P.S. Может допилить, для полного счастья, еще и режим записи?
Если читает без ошибок в "прямом" режиме (при движении головки вперед, т.е. к центру диска), то это действительно странно, и, я бы сказал, заслуживает изучения. Если же она дочитывает битые сектора обратным или случайным чтением (чего на Спектруме не делается), то объяснением может быть особенность дисковода.
Запись теперь можно сделать, но зачем она? ZX Disk Studio записывать умеет, чего в ней не хватает?
так может читается без проверки ? если так то это хреново.
раньше по сети гуляло много битых образов снятых как раз кривыми читалками
При чтении проверка делается всегда и битые сектора показываются на карте. Но если есть подозрения, то рекомендую убедиться в целостности данных, сверив с эталоном на всякий случай. Я как раз больше всего боялся именно такого эффекта, но пока никогда не замечал потери или искажения данных, кроме как в случаях когда искажения выдает сам драйвер или железо.
ZX Disk Studio записывать умеет, а не хватает как раз проверки записанного.
Подключил тут к компу второй дисковод, и сразу возник вопрос, а что в программе нет выбора дисковода?
Добавил выбор дисковода. Новую версию выложил в первом посте темы. Т.к. у меня второго дисковода нет (и даже контроллер не поддерживает второй дисковод), то код протестирован не полностью.
Добавил выбор дисковода. Новую версию выложил в первом посте темы. Т.к. у меня второго дисковода нет (и даже контроллер не поддерживает второй дисковод), то код протестирован не полностью.
Спасибо!
А на чем остановилась разработка?
Переводил на днях 200 дисков, впереди еще 500 и у коллег столько же.
Спасибо!
А на чем остановилась разработка?
Переводил на днях 200 дисков, впереди еще 500 и у коллег столько же.
Разработка остановилась на чтении произвольных форматов. Там с одной стороны хочется использовать инфу с индексного датчика, а с другой хочется чтобы можно было её игнорировать (иногда он мешает читать первые сектора дорожек). Как это всё совместить трудно догадаться и в итоге я всё бросил. Эта функция работает в общем-то, но инфу с INDX она игнорирует. Плюс там еще баги есть с отображением кривых форматов (когда сектора имеют реальный размер 256 байт, а в заголовке у них указано что размер 8096 например).
Еще была идея как можно читать те нечитающиеся первые сектора чисто программно (без закрывания индексного отверстия), и это даже удается делать, но там много странностей возникает и чтение нестабильно. Разобраться почему так получается не удалось и я опять это бросил тоже.
CPLx, помните я писал в посте #37, что у меня на всех треках не читается нулевой сектор, контроллер BDI-ZX, TR-DOS Ver 5.04T (Base version 5.03, High speed, Turbo format. Copyright C.C. 1991).
Намедни блуждая по сайту польских товарищей прочёл, что все версии TR-DOS имеют кучу ошибок, и чтоб было вам счастье нужно узать TR-DOS Ver 5.041 (Based on 5.4T. More bug fixed, code updated. 14/11/2012 by Vadim).
Скачал, прошил контроллер и точно нулевой сектор теперь читается без проблем, а в остальном пока вроде ни каких отличий не заметил.
CPLx, возможно ли поддержать диски формата ASC?
Их попадается немало с музыкой.
Тут описан формат: http://zxpress.ru/article.php?id=8564
Еще из интересного описан Агат, Орион, Радио РК, БК, но дисков от них у меня к сожалению нет. Хотя для Агата могу записать.
CPLx, возможно ли поддержать диски формата ASC?
Еще из интересного описан Агат, Орион, Радио РК, БК, но дисков от них у меня к сожалению нет. Хотя для Агата могу записать.
Все эти форматы по идее можно прочитать на вкладке Custom Format. Делать отдельную вкладку по типу, как есть для TR-DOS, для ASC будет трудно, потому что у ASC разное количество секторов на треках (на нулевом треке 9 секторов, на остальных - 10, да еще размеры секторов разные), это не вписывается в существующую архитектуру тех вкладок. Там могут быть только форматы у которых все треки имеют одинаковое число секторов и размеры секторов тоже одинаковые. Может я буду это переделывать, может нет - не знаю.
Повторюсь, что на вкладке Custom Format прочитать должно быть возможно такой формат, там таких ограничений нет. Надо только смотреть чтобы все сектора на треке нормально прочитались и не было выпавших секторов (как бывает на первых секторах в некоторых случаях). Карта там показывается по другому: показывается весь трек - сектора на нём и пробелы. Размеры пробелов и секторов на карте пропорциональны соответствующим размерам на диске. Выпавшие сектора выглядят как большие белые участки на треке, т.е. как пробелы. Если пробел такой что туда поместился бы целый сектор, то возможно сектор там и есть но контроллер его не видит, и тогда надо попробовать закрыть индексное отверстие чтобы его увидеть если он там есть. И еще диск должен быть хорошо читаемым. Плохо читающиеся диски там могут плохо обрабатываться из-за несовершенной автоматической обработки ошибок. Это можно по карте сориентироваться. Если нет подозрительно больших пробелов и все сектора нужных размеров (там размер сектора на карте пропорционален размеру сектора на диске), то прочиталось всё правильно. Если же есть слишком большие пробелы, или размеры секторов нестандартные, то могли быть ошибки определения формата трека и надо перечитать заново этот участок с удалением инфы о формате (во всплывающем меню выбрать "Mark selection as unscanned", и заново прочитать). Короче, прочитать можно, но это надо делать самостоятельный контроль. Я не смог продумать автоматику так чтобы она сама все эти ошибки отслеживала. Автоматическое отслеживание ошибок можно сделать если специально сравнивать с целевым форматом (с тем же ASC например), как это сделано в тех вкладках (TR-DOS, IS-DOS и так далее), но ASC не вписывается в их архитектуру и там придется много писать заново с нуля практически.
Повторюсь, что на вкладке Custom Format прочитать должно быть возможно такой формат, там таких ограничений нет. Надо только смотреть чтобы все сектора на треке нормально прочитались и не было выпавших секторов (как бывает на первых секторах в некоторых случаях). Карта там показывается по другому: показывается весь трек - сектора на нём и пробелы. Размеры пробелов и секторов на карте пропорциональны соответствующим размерам на диске. Выпавшие сектора выглядят как большие белые участки на треке, т.е. как пробелы. Если пробел такой что туда поместился бы целый сектор, то возможно сектор там и есть но контроллер его не видит, и тогда надо попробовать закрыть индексное отверстие чтобы его увидеть если он там есть. И еще диск должен быть хорошо читаемым. Плохо читающиеся диски там могут плохо обрабатываться из-за несовершенной автоматической обработки ошибок. Это можно по карте сориентироваться. Если нет подозрительно больших пробелов и все сектора нужных размеров (там размер сектора на карте пропорционален размеру сектора на диске), то прочиталось всё правильно. Если же есть слишком большие пробелы, или размеры секторов нестандартные, то могли быть ошибки определения формата трека и надо перечитать заново этот участок с удалением инфы о формате (во всплывающем меню выбрать "Mark selection as unscanned", и заново прочитать). Короче, прочитать можно, но это надо делать самостоятельный контроль. Я не смог продумать автоматику так чтобы она сама все эти ошибки отслеживала. Автоматическое отслеживание ошибок можно сделать если специально сравнивать с целевым форматом (с тем же ASC например), как это сделано в тех вкладках (TR-DOS, IS-DOS и так далее), но ASC не вписывается в их архитектуру и там придется много писать заново с нуля практически.
Спасибо! Попробую
а в каком формате сохраняется custom?
а в каком формате сохраняется custom?
FDI. Он позволяет любой формат сохранить, насколько я помню.
Жаль программа больше не совершенствуется, а то попали тут ко мне две коробки старинных 5 дюймовых дискет, читаются они конечно плоховато, а данной программой, как я и писал ранее, на всех треках не читается нулевой сектор.
на всех треках не читается нулевой сектор.
Индексное отверстие пробовал закрывать?
А как это лучше сделать?
Я засовывал лист бумаги в дисковод поверх диска (диск уже был в дисководе), так чтобы отверстие оказывалось перекрытым. Но у меня дисковод открыт и я вижу куда эта бумага (точнее, картонка в моём случае) зашла и перекрыла ли она отверстие. После этого всё работало. Можно это делать прямо в процессе чтения и сразу видеть начинают ли читаться нулевые сектора.
Хорошо попробую, всё стало читаться, попробовал два диска заклеив изолентой.
Интересный момент, если диск был записан как положено, то закрытие индексного отверстия приводит к обратному результату.
Интересный момент, если диск был записан как положено, то закрытие индексного отверстия приводит к обратному результату.
Хм. А по идее не должно. У меня такого никогда не было. А какие конкретно сектора перестают читаться, неужели нулевые опять?
Вообще при закрытии индексного отверстия проблема должна быть только при попытке чтения несуществующих секторов (что бывает на неформатированной области или если формат диска не угадан), и выражается она в сильно замедленной работе, потому что вместо двух индексных импульсов (т.е. около 0.4 секунды) контроллер начинает ждать по 4 секунды. В остальном у меня разницы не было. Ну еще и головка перепозиционируется по-моему каждый раз.
Ну да нулевые перестают читаться.
Black Cat / Era CG
14.04.2022, 17:51
Там же часть индексного отверстия надо закрывать, да?
Там же часть индексного отверстия надо закрывать, да?
Нет, целиком. И начинает читаться.
Что касается закрытия части, то лично у меня это не получалось: если сектор начинал читаться после частичного закрытия, то в реальности индексный импульс пропадал полностью. Если же частичное закрытие было таким что импульс не пропадал, то нулевой сектор не читался.
Я более детально исследовал это здесь (https://zx-pk.ru/threads/31601-spectrum-archive-reader-programma-dlya-chteniya-tr-dos-diskov.html?p=1077701&viewfull=1#post1077701).
Black Cat / Era CG
14.04.2022, 17:57
Прикольно. Спасибо
Вылез ещё один интересный момент, на некоторых дисках с заклеенным индексным отверстием, первые 1000 байт просто не читаются и ошибки ни какой при этом нет.
Вылез ещё один интересный момент, на некоторых дисках с заклеенным индексным отверстием, первые 1000 байт просто не читаются и ошибки ни какой при этом нет.
Интересный случай. А можно поподробнее? Первые 1000 байт образа нулевые или что?
Ну да - https://www.dropbox.com/scl/fo/4ysfbi30su8dcnujwjtb5/h?dl=0&rlkey=ol6wxzmqdifmoaomhkjmxqxa6
Ну да - https://www.dropbox.com/scl/fo/4ysfb...moaomhkjmxqxa6
Там весь нулевой трек в нулях. Не только 1000 байт. А дальше игры какие-то, судя по всему.
А другие читалки как читают эти диски, ZX Disk Studio например?
PS
Я к тому что может диск сам по себе имеет нулевой трек весь заполненный нулями.
ZX Disk Studio читает даже с заклеенным индексным отверстием, как я говорил у меня две коробки дисков, накануне вашей программой первую коробку прочитал без проблем, а на второй перестал читаться нулевой трек, сегодня попробовал снова и перестала читаться даже первая коробка. Притом тоже самое происходит на нормальных 3.5" дисках, может у меня что то с железом случилось.
nimdasys_inbox_ru
02.08.2022, 09:10
ZX Disk Studio читает даже с заклеенным индексным отверстием, как я говорил у меня две коробки дисков, накануне вашей программой первую коробку прочитал без проблем, а на второй перестал читаться нулевой трек, сегодня попробовал снова и перестала читаться даже первая коробка. Притом тоже самое происходит на нормальных 3.5" дисках, может у меня что то с железом случилось.
А какая версия используется ?!
CPLx, И ещё один момент, последняя версия программы поддерживает два дисковода, но при чтении каталога обращение только к дисководу А, не зависимо от того какой выбран.
CPLx, И ещё один момент, последняя версия программы поддерживает два дисковода, но при чтении каталога обращение только к дисководу А, не зависимо от того какой выбран.
Исправил. Новая версия в первом посте темы.
Намедни тестировал дисковод 5.25 Larsen & Toubro YD 380, и в данной программе и в ZX Disk Studio читает все отлично, подключил к реальному спектруму и тут полный облом Disk Error, Invalid media, самое смешное, что у меня есть ещё пара таких же флопов YD-380 только от другого производителя YE Data с ними проблем нет.
SoftLight
07.08.2022, 16:40
Намедни тестировал дисковод 5.25 Larsen & Toubro YD 380...
Был у меня однажды такой опыт (https://zx-pk.ru/threads/10863-podklyuchenie-diskovoda-5-25-ye-data-yd-380c.html?p=948675&viewfull=1#post948675)
Может поможет
Разработка остановилась на чтении произвольных форматов. Там с одной стороны хочется использовать инфу с индексного датчика, а с другой хочется чтобы можно было её игнорировать (иногда он мешает читать первые сектора дорожек). Как это всё совместить трудно догадаться и в итоге я всё бросил. Эта функция работает в общем-то, но инфу с INDX она игнорирует. Плюс там еще баги есть с отображением кривых форматов (когда сектора имеют реальный размер 256 байт, а в заголовке у них указано что размер 8096 например).
Еще была идея как можно читать те нечитающиеся первые сектора чисто программно (без закрывания индексного отверстия), и это даже удается делать, но там много странностей возникает и чтение нестабильно. Разобраться почему так получается не удалось и я опять это бросил тоже.
А возможно сделать отображение IS-DOS каталога?
Кстати, пробывал тут копировать IS-DOS, на большинстве дисков читается только одна сторона. Хотя на реальном спектруме такие диски нормально запускаются. Нормально прочитался один диск из 10.
CP/M от Скорпиона и ATM не читаются вообще.
А возможно сделать отображение IS-DOS каталога?
Формат файловой системы IS-DOS сложный, быстро его не сделать. Дисков IS-DOS у меня нет, и без тестирования я сделать не смогу. Как минимум мне нужен образ диска IS-DOS с имеющимися на нём файлами, в том числе с вложенными директориями, и софт который эти директории сможет показать. Это чтобы я потом мог проконтролировать правильно ли я сделал чтение каталогов.
Кстати, пробывал тут копировать IS-DOS, на большинстве дисков читается только одна сторона.
Чтобы помочь мне разобраться в чём причина сделай следующее:
- Включи вкладку Custom Format.
- Нажми кнопку Read Forward.
- После того как диск прочитается нажми кнопку Save Format. Формат сохранится как xml-файл. Выложи этот xml-файл здесь. Можешь еще выложить скрин вкладки Custom Format после чтения диска, чтобы я карту посмотрел.
То же самое сделай с одним из дисков CP/M что не читается.
Формат файловой системы IS-DOS сложный
и их вроде было два варианта.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot