К1818ВГ93

[s_kosorev]

Абсолютно неверный, ВГ не может писать в то же место, так ка для это нужны следующие допущения
1. Дисковод очень равномерно крутит диск
2. Диск имеет очень жесткую структуру и не подлежит деформациям
3. Кварцевые резонаторы очень точный

Все пункты чушь, ответ Conan, который основан на не верной точке отсчета, тоже чушь
А про АМ, так читается тот маркер который на диске, а не тот который при форматировании Fx како то вызывает запись A2/C2 или как их там

А первый ответ четко и ясно, ВГ не пишет бит в бит, к тому же, что бы писать правильно битики, нужно знать последний бит предыдушего байта, так как от этого зависит ка нужно начинать писать

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

Голову на отсечение даёшь, если ты не прав? А то я склоняюсь к верности про неотключение адресного маркёра. Про магию не понял.

Склоняться мож как угодно, а микруха на 5тыс транзюков не в силах всякие DRM через 40 лет изобретенные юзать

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

Если бы адресный маркер был отключам, была бы на порядок хуже каша

[Titus]

Все пункты чушь, ответ Conan, который основан на не верной точке отсчета, тоже чушь

Какой ты категоричный)))

Я делал защиты, основанные на этом эффекте еще в 1995 году)
Даже делал версию игры StreetFighter, в которой не было секторов вовсе, а была одна сплошная дорожка, записываемая разом, никакой рассинхронизации из-за смещения бит там не было и быть не могло.
Разумеется, я прекрасно знал, из-за какой комбинации бит идет сбой контроллера, и просто напросто не использовал ее, потому вся дорожка читалась идеально.

Но, если тебе нравится своя, параллельная реальность ВГ93, то я спорить не буду)

[s_kosorev]

Почитай первый ответ. Там четко и ясно описана причина. Рассинхронизация возникает из за повторной записи поверх форматированной дорожки. Все.

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

Разумеется, я прекрасно знал, из-за какой комбинации бит идет сбой контроллера

Нет никакой комбинации. Есть диск вставлен не 100% как при записи из за этого индексное отверстие на несколько бит пришло раньше или позже.
Смешно же, делать защиты и не понимать как работает дисковод и контроллер.

Хочешь устойчивого чтения при любом положении, используй индексный маркер. Когда его контроллер встретит, на нем он синхронизируется. А комбинацию битов, для синхронизации, невозможно получить никак, кроме спец команда при записи дорожки

[Dexus]

Есть диск вставлен не 100% как при записи из за этого индексное отверстие на несколько бит пришло раньше или позже.

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

А комбинацию битов, для синхронизации, невозможно получить никак, кроме спец команда при записи дорожки

Особая синхро-комбинация битов дешифруется автоматически, все эти MFM sync bytes не видятся дальше микросхемы контроллера. Как и CRC. На уровне взаимодействия с ПО их нет потому что они не нужны. При записи эти "неправильные" синхро-биты вписываются автоматически в ходе raw-write, во время форматирования. Контроллер в последовательности байт выделяет данные, и в них не лезет, а во всех остальных областях байты #C2 / #A1 "награждаются" особым битом (маркеры IAM, IDAM и DAM). При записи отдельных секторов идет идентификация местонахождения сектора, даётся 12 байт #00 (для настройки на скорость - минимальный размер домена - ~4мс), маркер DAM, скармливаются данные сектора. Сразу за этим - два байта CRC.
https://retrocomputing.stackexchange.com/a/7845

Почитай первый ответ. Там четко и ясно описана причина. Рассинхронизация возникает из за повторной записи поверх форматированной дорожки. Все.

Рассинхронизация происходит когда raw-read используется, которому нельзя приказать непрерывно синхронизироваться исключительно по MFM меткам. В итоге при повторной записи домены могут сместиться на полубит, и индексные биты оказываются битами данных и наоборот. При перезаписи отдельных секторов идеального попадания магнитного домена с точностью до полубита - не бывает. А только что отформатированный трек гарантировано будет сихронизирован по первому маркеру.
Чтобы трек всегда читался качественно в raw-виде, необходимо чтобы контроллер мог фоново, непрерывано пересинхронизировать данные встречая синхробиты. Но у ВГ93 этого видимо не происходит (синхронизируются только до первого сектора).

Полагаю, что сами данные формата (коды 4E) по-идее всегда должны быть "в фазе". Как и адресные метки (они не перезаписываются).

[s_kosorev]

Рассинхронизация происходит когда raw-read используется, которому нельзя приказать синхронизироваться исключительно по MFM меткам. В итоге при повторной записи домены могут сместиться на полубит, и индексные биты оказываются битами данных и наоборот. При перезаписи отдельных секторов идеального попадания магнитного домена с точностью до полубита - не бывает. А только что отформатированный трек гарантировано будет сихронизирован по первому маркеру.

что и написанно в первом ответе? не?

[Dexus]

что и написанно в первом ответе? не?

Там написано про индексный маркер (он же - индексное отверстие).

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

От него вообще ничего не зависит.
Речь же про синхро-байты (синхро-маркеры). А не индексные.

А защиты от копирования таки были. В частности - у того же Спектрофона читалась 0я дорожка в raw формате, и в определенном месте, уже за 16 сектором (смещение #1782), где по-идее находится мусор, ищутся определенные байты (#a1,#fb,#53), то есть огрызок 17го сектора, у которого первым байтом стоит #53 ("S").

[Titus]

Такое ощущение, что вы тему не читали вообще, кроме первой страницы)
Советую смотреть тему отсюда https://zx-pk.ru/threads/859-k1818vg...ll=1#post16970

Lion17 согласился с Conan'ом)

[Dexus]

Кстати, собрал немного статистики. Рассинхронизация хорошо заметна по гаповым вставкам (#4E). Порой они превращаются в другие байты - #9C,#21,#27,#90,#48.. В MFM #4E выглядят как [--|--|--|-|-|--] (333223), а остальные - его своеобразные вариации, смещенный влев код MFM на 1, или 2, или вправо на 1, 2, или 3 такта. После CRC, и вначале дорожки, пока синхрокод #A1A1A1 не встретился, но после встречи #A1A1A1 данные снова корректные. И это логично.

Эти области, забитые #4E, и нужны, чтобы поверху записываемые данные секторов имели некоторый геометрический люфт, учитывающий возможную разницу скорости вращения диска. И, соответственно, какая-то сбивка неизбежна, нередко после CRC остается кусок предыдущего CRC, или даже хвостик одной из прошлых версий секторов, записанных на медленной скорости.

Примечательно, что после заголовочной области гап с кодом #4E никогда не сбивается - он прописывается во время форматирования, и больше никогда не трогается.

ЗЫ: Это наблюдения чтения "в идеале", когда сбивки на байте #29 нет.

ЗЗЫ: Lion17 в своих расчётах был не прав. Синхрокод #A1 ни в каком виде нигде больше не повторяется. Он представляет собой последовательность [---|--|---|--|-] (43432)
Обычный #A1 - [---|--|-|-|--|-] (432232)
А #29 - [-|--|---|--|--|] (234331) - длительности 1 не существует, бывают только 2,3 и 4, и единичка всегда присовокупляется к следующей, то есть #292929 = 23433,33433,33433,1... в принципе 33433 отчасти похож на 43432, то есть длительности 4 и 3 достаточно близки, и наверное могли бы спутаться, но это надо еще проверить, прогнать все варианты.

ЗЗЗЫ: Совершенно железобетонно, MFM синхрокод #a1 (43432) никоим образом ни в каких других комбинациях появиться не может. Вообще сочетание (434) невозможно в MFM данных. 343 и 444 - сколько хочешь, а 434 - только в синхрокоде.

[goodboy]

защиты от копирования таки были. В частности - у того же Спектрофона читалась 0я дорожка в raw формате, и в определенном месте, уже за 16 сектором (смещение #1782), где по-идее находится мусор, ищутся определенные байты (#a1,#fb,#53), то есть огрызок 17го сектора, у которого первым байтом стоит #53 ("S").

в последних номерах защита была чуток изменена/улучшена. подробностей не помню, вот часть переписки
"Простановка лишнего маркера A1 со сдвигом от нормального положения кроме защиты от копирования на
амиге защищает и от копирования на ВГ93 командой "чтения дорожки", т.к. в этом режиме детектор
адресного маркера всегда включен и неминуемо произойдет синхронизация по второму A1 и вместо 4E
будут декодированы байты 09"

[Dexus]

в последних номерах защита была чуток изменена/улучшена.

Я вообще не уверен что эта защита была от Спектрофона. Тут своих умельцев хватало, перепродающих их со своими "защитами".

и неминуемо произойдет синхронизация по второму A1 и вместо 4E
будут декодированы байты 09"

ВГ93, и для процесса чтения абсолютно по барабану какие там байты в GAP-пространствах. А 4E и 09 - это одна и та ж последовательность.

4e4e - |--|--|--|-|-|--|--|--|--|-|-|-- : 333223333223
0909 - |-|-|-|--|--|--|--|-|-|--|--|--| : 2223333223331

А вот если после 4E какие-то важные внесекторные данные идут, тогда их потрековым копированием действительно не возмешь.

http://volutar.myds.me/php/mfm.php?h...9090+2727+4848