да мешок таких кейсов :)
в 90х это было обычным явлением - если какая-то часть чужой дискетки не читалась (типично в конце диска) - голову пододвигали пальцом в одну или другую сторону, и часто это помогало.
Вид для печати
Если будет SCP образ подобного диска, который без шатания головки не читается, он бы помог понять, вытащилась бы эта инфа raw устройствами, или без смещения головки (что я считаю дичью, и свою трогать не буду) вообще никак. Текущая моя гипотеза, что из raw потока со спец обработкой такое несложно прочитать.
RAW-поток - это дауншифтинг относительно аналогового микростепперного потока) После магнитной головки идет компаратор, который понимает только смену направления магнитного поля и все. Это подходяще, когда запись хорошая, и совершенно убийственно, когда на записи помехи.
Тоже самое было с магнитными лентами. Если запись хорошая, то компаратор прекрасно подходит. Если плохая, то хоть тресни, ты уже потерял информацию. Тогда как по аналоговому сигналу восстанавливались 99.9% таких записей просто влёт.
Titus, надеюсь ты понимаешь, что сравнивать плёнку с плавающей скоростью и полным разнобоем с подстройкой, с куда более технологичным дисковым решением не очень корректно? Вообще положение головки с завода "стандартизировано" и не нуждается в подстройке.
Если ты не обеспечишь аналоговый захват магнитного потока по всем трём осям, то это не особо что-то улучшит. Компаратор вполне справляется с диффузией и размагничиванием, а где он не справляется - поможет разве что только сверхтехнологичный трехмерный захват за кругленькую сумму. Да и то, не факт что поможет. Никто таким заморачиваться не будет. Хотя возможно все не так уж и сложно - по сути нужно использовать три головки с разной ориентацией вместо одной, и при захвате потока просто учитывать темпоральное смещение. Но даже KryoFlux таким не промышляют, это просто убер-избыточно.
Но прочитать про кейс о том как смогли вытащить данные с дискеты которая была пропущена через шредер, будет интересно :)
Индексный датчик там роли не играл у меня - у меня инфы от него контроллер не получает. У меня так, что можно индексное отверстие заклеить и ничего не меняется.
Нет, образа SCP нет.
А почему сдвиг головок работает можно предположить что либо почему-то дорожка пишется криво, либо запись происходит по более широкой полосе чем чтение. Я думаю что скорее имеет место второй вариант. Намагниченность создается широкой, а читается слабо чувствительной головкой по узкой зоне. Поэтому если данные исказились в одном месте (в центре дорожки), то могут еще остаться с краю. Этим же можно объяснить почему сдвиг не приводит к ухудшению чтения, которое должно было бы быть если бы запись шла по кривой траектории. Но это только догадки, разумеется.
У меня другая теория. Намагничивание происходит с нарастающим расширением зоны перехода, с такой силой тока чтобы с учетом скорости движения поверхности доходить до границы, но не влиять на соседние дороги. Но даже будучи смещенным с "центра" намагниченности, домены остаются достаточно намагниченными, чтобы усилитель головки мог переход-границу "увидеть". Она может и будет размытой, но пока самый короткий домен не исчезнет вообще, он будет читаться. Именно этим объясняется то, что при смещении головки оно все равно нормально читается. Просто потому что система устроена таким образом, что уменьшение "контраста" не сильно ломает чтение, триггер все равно распознает переход, даже если он небольшой.
Но когда например в серии ++-----++ перемагничивается маленький домен, и получится ++--+--++, то тогда - да, появляются ложные импульсы (причем - всегда парно). Но такие маленькие искажения внести внешним полем нельзя - это должно быть сверхточечное воздействие.
Чаще проблемы происходят из-за размагничивания самой головкой в процессе включения/выключения (пусковым током), но тогда влияние происходит на все домены в приличном радиусе, и это можно обнаружить за счет сравнения таймингов четных и нечетных переходов (они просто разойдутся).
Или же возможно что диск положили рядом с динамиком и магнитное поле сместит вообще все домены... тогда мы просто увидим вместо трех тайминговых кластеров шесть (есть у меня такой диск, но там расхождение пока не настолько большое).
Физические дыры просто создают области без намагниченности, и тогда АРУЗ головки просто шум ловит.
Неровная поверхность (плавающая дистанция от поверхноти до головки) уменьшает силу магнитного поля считываемого домена, тем самым добавляет воздействие соседних (т.е. теряется "фокусировка").
Возможно что шпиндель при записи крутился неравномерно изза каких-то конструктивных проблем, и тогда скорость будет существенно плавать и чтение также будет затруднено.
Возмозжно и то, что отверстие в самом диске шире чем положено (с учетом допуска), и тогда центровка может пойти по одному месту - для таких дисков действительно микростеппинг мог бы помочь, только едва ли такой диск вообще был бы юзабельным изначально - в нем бы после перетыкания в дисковод уже переставалось бы всё читаться - такие диски мгновено оказывались в помойном ведре.
Все эти проблемы практически неустранимы при чтении штатным контроллером. При чтении потока импульсов с последующей обработкой (как делают всякие KryoFlux'ы и недорогие аналоги) такая обработка возможна. Гипотетические убер-устройства с аналоговым чтением и микростеппингом про которое говорит Titus, в природе вроде нет, поэтому сложно судить о его плюсах (помимо проблемы с центровкой, с которой лично я никогда не сталкивался).
Я пытаюсь продемонстрировать что это или недомера, или избыточно, но никак не практичное. И воспринял как прикол/троллинг/демагогию именно это:
"Чтобы она могла все" - надо учитывать и перпендикулярные записи, и сдвиги магнитных доменов в разных направлениях (размагничивания бывают разными), и поэтому все 3 измерения в случае "МОЧЬ ВСЁ" - необходимы. Сказав А, надо сказать и Б.
надеюсь ты понимаешь, что речь идёт в том числе о "вытаскивании с того света" дисков записанных еще во времена царя гороха отечественными флопами ?
а наша техника в ту эпоху была крайне пахабного качества, и "плавало" там всё что угодно и как угодно. надежностью или стандартизацией тоже особо не пахло, нормальное явление если свежекупленный новый девайс мог требовать юстировки или наладки/доработки (например чтоб не запарывал диски). емнип особо отличались таким с позволения сказать качеством т.н. "армянские" флопы (хз реально ли они производились в Армении), зато были несколько дешевле других, потому у людей в наших местностях были самыми массовыми.
и теперь вот это всё требуется как-то прочитать :)
Я вроде слышал только про успех при вытаскивание то ли исходников, то ли ещё чего-то такого, самой первой версии Принца Персии...
Сделайте, пожалуйста кто-нибудь, у кого есть такой убитый диск, слепок в Greaseweazel, в .scp формате. Чтение уже расшифрованного MFM в сабже вообще не поможет понять, что там на самом деле не так. А scp можно поисследовать хотя бы, чтобы понять в каком направлении рыть в таких случаях.
именно на спеке ещё важную роль играет схема контроллера (точнее то что называют фапч)
несколько раз сталкивался с ситуацией когда на скорпе спокойно читалось то что сбоило на пентагоне (дисковод тот-же)
Удалось отремонтировать дисковод и восстановить нормальную работу индексного датчика. Выяснилось сразу несколько неизвестных ранее для меня вещей.
- ZX Disk Studio стала работать. Сканирует диск и читает. Таким образом, оказалось что она у меня не работала из-за отсутствия индексных импульсов.
- На некоторых дисках перестали читаться первые сектора. Явление которое ранее встречалось здесь и с которым я лично не сталкивался никогда до этого. Теория, согласно которой причиной является близкое расположение сектора к индексному отверстию, выглядит правдоподобной. Обычно у нормально читающихся дисков первый сектор находится на расстоянии около 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-контроллер по заднему, из-за чего получается эффект смещения точки индексного импульса на треке и приближения его к сектору [ссылка]. Но полученные факты показывают что ВГ93 и PC-контроллер видят индексный импульс в одном и том же месте трека, с разницей не более одного-двух байт, причем эта разница лежит в пределах погрешности оценки.
Эту теорию можно подвергнуть проверке и другим способом. Исходя из размеров индексного отверстия можно оценить с какой разницей должны видеть контроллеры индексный импульс, если они регистрируют его в диаметрально противоположных точках отверстия. Диаметр индексного отверстия составляет не менее 2.5 мм. Расстояние от центра индексного отверстия до центра диска – 25 мм. Это дает длину окружности на уровне центра индексного отверстия равной 157.07 мм. Что дает угловой размер индексного отверстия 5.73 градусов. Что в свою очередь дает размер индексного отверстия равным 99 байт. Поэтому точка индексного импульса на треке должна отличаться минимум на 99 байт между ВГ93 и PC. Повторюсь, на практике разница оказалась не более одного-двух байт. Поэтому теория о разном методе регистрации индексного импульса выглядит ошибочной. Как следствие, идея частичного закрытия отверстия не имеет удовлетворительного теоретического объяснения.
По крайней мере на моём железе так.
Надо отметить еще одну особенность формата проблемых дисков (у меня найдено их пока два): на них отсутствует заголовок трека. На треке, после пробела в 11-12 байт 0x4E после индексного импульса, сразу идут сектора. У непроблемных дисков сначала идет пробел 80 байт 0x4E, потом заголовок трека, потом еще один пробел и только после него идут сектора. Расположение секторов на этих двух проблемных дисках оказалось разным: у одного сектора идут последовательно, у другого интерливом. Значит проблемный формат делали разные программы, а не какая-то одна.
CPLx, А про какой дисковод идет речь?
Может таки лучше сменить mc5313 на Teac ?
Не обязательно на тик, можно на митсуми, или на эпсон или на панасоник или на ... ... ... .
Зачем? Чем он лучше? Мой диски читает, в целом работает. А за TEAC мало того что деньги платить надо, так еще возиться с отправкой денег и ждать доставки, и я даже не знаю что хуже. И тоже неизвестно как он там еще работать будет. Мне дисковод теперь нужен только для развития этой программы, исправления багов и так далее. В остальном я сделал с ним всё что мне надо было - прочитал все диски. Я, пока его ремонтировал, дважды попадал в ситуацию когда мне казалось что я его безнадежно сжег, и как-то не особо расстраивался по этому поводу. В одном случае таки сжег микросхему отвечающую за TR00 - я же в электронике ноль. С TEAC мне будет еще и страшно экспериментировать. Я, пока еще индекс был неисправен, хотел купить что-то вроде Mitsumi или Fujitsu (они продаются по сотне-две долларов, включая доставку). Но сейчас смысла в этом не вижу.
Я на ebay смотрел. А на российском рынке я не видел ничего кроме хлама.
Это где например?
- - - Добавлено - - -
Удалось несколько раз прочитать первый сектор (на диске где он невидимый) чисто программным методом, без закрытия индексного датчика. Но чтение очень нестабильное, получается редко.
Да блин, х.з. на местной барахолке разве не продают? Там периодически устраивают распродажи! Создай тему, мол куплю протестированный импортный 5 дисковод. Тебе точно кто-нибудь да продаст.
хм.. странно, я тупо на авито в 14-15 годах купил несколько 5" дисководов за копейки и в идеальном состоянии.
Сам на авито смог приобресть самсунг sfd-560d за 2к.
CPLx, А этот МС твОй до какой дороги максимально добирается? В DCU максимальный формат, который на моем старом теаке 83 дороги делал (бОльшая часть моих дисков как раз 83 дорожечные). На самсунге нынешнем тоже 83 прекрасно видятся. Написано что типа это редко такое встречается. Странно что мне дважды везло.
Подключил тут к компу второй дисковод, и сразу возник вопрос, а что в программе нет выбора дисковода?
Удобно ведь два дисковода 3.5" и 5.25".
У меня материнка поддерживала один, но сейчас я собрал другой комп где два флопика поставил.
Я недавно собирал себе из сорцов версию, работающую с B: (и только с ним) - было проще, чем раскручивать корпус и переставлять перемычку на флопе
Вот она - https://cloud.mail.ru/public/GZo4/JWDEg1uk5
Спасибо автору за выложенные исходники!
CPLx, Программа настолько хороша, что я даже не могу понять, как она без запинки читает диск, у которого на реальном спектруме более 20 секторов не читаемы совсем.
P.S. Может допилить, для полного счастья, еще и режим записи?
Если читает без ошибок в "прямом" режиме (при движении головки вперед, т.е. к центру диска), то это действительно странно, и, я бы сказал, заслуживает изучения. Если же она дочитывает битые сектора обратным или случайным чтением (чего на Спектруме не делается), то объяснением может быть особенность дисковода.
Запись теперь можно сделать, но зачем она? ZX Disk Studio записывать умеет, чего в ней не хватает?
При чтении проверка делается всегда и битые сектора показываются на карте. Но если есть подозрения, то рекомендую убедиться в целостности данных, сверив с эталоном на всякий случай. Я как раз больше всего боялся именно такого эффекта, но пока никогда не замечал потери или искажения данных, кроме как в случаях когда искажения выдает сам драйвер или железо.
ZX Disk Studio записывать умеет, а не хватает как раз проверки записанного.
Разработка остановилась на чтении произвольных форматов. Там с одной стороны хочется использовать инфу с индексного датчика, а с другой хочется чтобы можно было её игнорировать (иногда он мешает читать первые сектора дорожек). Как это всё совместить трудно догадаться и в итоге я всё бросил. Эта функция работает в общем-то, но инфу с 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
Еще из интересного описан Агат, Орион, Радио РК, БК, но дисков от них у меня к сожалению нет. Хотя для Агата могу записать.
Все эти форматы по идее можно прочитать на вкладке Custom Format. Делать отдельную вкладку по типу, как есть для TR-DOS, для ASC будет трудно, потому что у ASC разное количество секторов на треках (на нулевом треке 9 секторов, на остальных - 10, да еще размеры секторов разные), это не вписывается в существующую архитектуру тех вкладок. Там могут быть только форматы у которых все треки имеют одинаковое число секторов и размеры секторов тоже одинаковые. Может я буду это переделывать, может нет - не знаю.
Повторюсь, что на вкладке Custom Format прочитать должно быть возможно такой формат, там таких ограничений нет. Надо только смотреть чтобы все сектора на треке нормально прочитались и не было выпавших секторов (как бывает на первых секторах в некоторых случаях). Карта там показывается по другому: показывается весь трек - сектора на нём и пробелы. Размеры пробелов и секторов на карте пропорциональны соответствующим размерам на диске. Выпавшие сектора выглядят как большие белые участки на треке, т.е. как пробелы. Если пробел такой что туда поместился бы целый сектор, то возможно сектор там и есть но контроллер его не видит, и тогда надо попробовать закрыть индексное отверстие чтобы его увидеть если он там есть. И еще диск должен быть хорошо читаемым. Плохо читающиеся диски там могут плохо обрабатываться из-за несовершенной автоматической обработки ошибок. Это можно по карте сориентироваться. Если нет подозрительно больших пробелов и все сектора нужных размеров (там размер сектора на карте пропорционален размеру сектора на диске), то прочиталось всё правильно. Если же есть слишком большие пробелы, или размеры секторов нестандартные, то могли быть ошибки определения формата трека и надо перечитать заново этот участок с удалением инфы о формате (во всплывающем меню выбрать "Mark selection as unscanned", и заново прочитать). Короче, прочитать можно, но это надо делать самостоятельный контроль. Я не смог продумать автоматику так чтобы она сама все эти ошибки отслеживала. Автоматическое отслеживание ошибок можно сделать если специально сравнивать с целевым форматом (с тем же ASC например), как это сделано в тех вкладках (TR-DOS, IS-DOS и так далее), но ASC не вписывается в их архитектуру и там придется много писать заново с нуля практически.