Titus, знака мало. Магнитное поле может иметь любое направление в пространстве. Оно тоже важно.
Titus, знака мало. Магнитное поле может иметь любое направление в пространстве. Оно тоже важно.
Может когда он читает данные сектора, то перестает обращать внимание на синхропоследовательности (или как там они называются). Потому что всё это чтение очень похоже на чтение данных: начинается прямо с начала данных сектора.Сообщение от Dexus
CPLx, вроде защита даже такая есть — сектор в секторе, когда внутри блока данных новый синхрокод, заголовок, и сектор (меньшего размера). Так что, думаю, что синхронизация должна работать везде и всегда. Еще раз — возможно новые контроллеры умеют их игнорировать при каких-то установках. Я не особо разбираюсь в контроллерах, я свой в какой-то степени сочиняю.
Я не понял почему из этого следует что синхронизация должна работать везде.
Теоретически, такой сектор можно прочитать обычными средствами, без чтения raw-трека. В том числе этим драйвером.
- - - Добавлено - - -
Судя по документации, контроллер 82078 поддерживает такую запись. Думаю что его производные тоже.
Мы говорим о конкретном формате записи. А он подразумевает лишь два направления.
Этот же формат записи подразумевает и то, что треки имеют определённую ширину, и надобности в 1/8 и 1/16 нет, равно как и анализе аналоговой части. И если уж вы настаиваете что у полнофункционального устройства должны быть эти фишки, будьте последовательны, учитывайте перемагничивание внешним полем, которое может быть любым, и фиксироваться должен не один вектор по касательной, но и радиальный, и поперечный. А такая головка я не знаю сколько будет стоить.
Плюс бывают случаи когда сам магнитный диск смят в гармошку - убер-устройство должно вообще в полном объёме делать слепок, не требуя прямого полотна... эдакий сверхдетальный объемный сканер магнитной неоднородности.
Я же лично считаю, что это убер-устройство избыточным, и любого дисковода в принципе в 99.99% будет достаточно, надо просто чтобы контроллер имел режим незамутненного, максимально сырого дампа (максимум с различением поляризации доменов, но и без этого можно).
Последний раз редактировалось Dexus; 16.08.2020 в 05:34.
Сдвиг головок это один из самых эффективных способов улучшения чтения, и при этом безопасный (в отличие от их прижатия). Так что такая фича как раз бы помогла.
Titus(16.08.2020)
CPLx, у вас есть кейсы дискет, которым помогал сдвиг головок?
Я конечно допускаю варианты, когда диски писались на заведомо кривом устройстве, головка которого на пол трека сдвинута, но лично я с таким не сталкивался. Куда чаще помогает доступ до непосредственно таймингов и учет четной-не четной поляризации (что недоступно через стандартные fdc).
Последний раз редактировалось Dexus; 16.08.2020 в 06:27.
Почти 100% (если не 100%) моих дисков были прочитаны только так и без этого прочитать их бы не удалось. (А дисков у меня 115 - вот и число кейсов.) В некоторых случаях приходилось прижимать головку. Например диск из этого поста был прочитан на 100% именно сдвигом головок, без которого он читается так как там показано, т.е. далеко не на 100%. Я собственно и добавил чтение назад чтобы получить эффект сдвига головок. Диски писались на моём же дисководе на котором я их читал, так что это не похоже на проблему юстировки.
CPLx, Мне почему-то кажется что вся эта эквилибристика — сугубо из-за того что raw поток вытаскивать нельзя дефолтовым контроллером — уж очень он привередлив к таймингам. Поэтому и приходится устраивать танцы с бубнами чтобы головки придавливать, чтобы датчик индексный двигать. Нет случаем сырого SCP образа каких-нибудь из них?
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием