К1818ВГ93

[Lion17]

Провел дополнительные исследования:
проверил все 9 битные последовательности (512)
~A1=0100010010001001
xx0001001000xxxx - уникальна
xx000100100xxxxx,
x1000100100xxxxx,
01000100100xxxxx - встречаются 32 раза (включая 029,129)
xxx001001000xxxx,
xxx0010010001xxx - 32 раза (вкл. 129)
xxx00100100010xx - 24 раза (вкл. 129)
xxx001001000100x - 12 раз (вкл. 129)
xxx0010010001001 - 4 раза (вкл. 129)
xxxx010010001001 - 12 раз (вкл. 14,29,114,129)
xxxxx10010001001 - 20 раз (вкл. 14,29,114,129)
Под известную информацию попадают только две последних.
Но синхронизация должна обрываться при каждой встрече x29,
хотелось бы посмотреть на дампы чтения дорожек (с оригинальными
секторами), тогда можно было бы сказать более конкретно.

полный список последней последовательности:
Analize sample: 10010001001
014 101010100100010010
028 101010010001001010
029 101010010001001001
050 101001000100101010
051 101001000100101001
052 101001000100100100
053 101001000100100101
094 100100100100010010
0A0 100100010010101010
0A1 100100010010101001
0A2 100100010010100100
0A3 100100010010100101
0A4 100100010010010010
0A5 100100010010010001
0A6 100100010010010100
0A7 100100010010010101
114 010010100100010010
128 010010010001001010
129 010010010001001001
194 010100100100010010
Found 20/512

[GriV]

жалько я раньше тему не видел

Тем не менее, сам я пробовал сделать копировщик трек в трек, будучи начитавшись книжек про TRDOS и прямое управление ВГ93 (особенно толковый пример был в ZX Review 95 номер не помню, кажется 4).

Так вот, после записи дорожки я делал её контрольное считывание и имелись следующие результаты:

Контроллер ВГ93 САМ подстраивает синхронизацию после встречи управляющих меток (A1, C2). Это выливается в тот факт, что начало сектора (в среднем приблизительно 100 байт) считывается на ура (не проверялось специально с значениями 29, хотя вообще информация писалась совершенно разная). Далее происходит указанный сбой сихнхронизации (в битовом потоке, не в байтовом, появляются "лишние" биты), вероятность их возникновения одинаковая, однако возникают они вообще говоря где попало, поэтому КОРРЕКТНО восстановить информацию по считанной дорожке НЕ УДАВАЛОСЬ.

Т.о. если записать информацию на дискету (скажем оссмысленный текст), потом считать её командой чтения дорожки, то где то на 100м символе текста будет происходить абраказябривание текста.

На самом деле, при использовании команды записи дорожки и записи последовательностей совпадающих с управляющими метками, контроллер интерпретирует эти значения не как данные, что и выливается в то, что с самого начала НЕЛЬЗЯ записать дорожку целиком с произвольными данными, т.е. вначале надо отформатировать дорожку (просто запись дорожки) а только затем поверх писать сектора.

Значения 29 (условно его можно назвать магическим числом) я так понял в битовом представлении совпадает со смещённой меткой сектора, поэтому при попытке записать дорожку с таким значением (или с любым из значений ряда, представленного выше), происходит аналогичный сброс контрольной суммы, и ВГ начинает писать НОВЫЙ сектор, соответственно закрывая его контрольной суммой и т.д.

Я попытаюсь дома проверить указанные значения на своём Scorpion, потом доложу о том, как оно работает.
Т.о. мусор, который появляется при чтении затем такой дорожки с магическим числом УЖЕ ЗАПИСАН на дорожке, а не появляется в процессе собственно чтения.

[Conan]

Т.о. мусор, который появляется при чтении затем такой дорожки с магическим числом УЖЕ ЗАПИСАН на дорожке, а не появляется в процессе собственно чтения.

Вы наверно невнимательно читали предыдущие сообщения в топике, иначе не было бы так удивительно, почему этот «мусор» оказывается совершенно нормальной информацией, при чтении сектора тем же контроллером на ВГ93.
И еще более удивительно то, что эта же дорожка, совсем без «мусора» считывается в имидж копировщиком на PC.


P.S. Давайте уважать друг друга, и внимательно читать, что пишут другие. Если не понятно, переспрашивать. Иначе в каждом новом сообщении мы будем опять "открывать Америку".

[SMT]

#29 не сбивает синхронизацию, если установлен старший бит предыдущего байта. кому интересно посмотреть на дампы дорожек самостоятельно - вот они

[Djoni]

Быть может для разрешения данного вопроса могла бы помочь достаточно интересная и познавательная статья о контроллерах дисководов http://zx.pk.ru/showthread.php?t=556. Если бы удалось ее найти.
Несколько лет назад, я пытался самостоятельно разрешить данный вопрос. До конца дело не дошло, но удалось выяснить, что при использовании данной команды имеет место срыв синхронизации, но информация считывается по четкому алгоритму. Выяснить алгоритм не удалось. Я считаю, что если-бы сепаратор данных перестраивался при встрече AM,а он как известно отличается по синхропоследовательности, то все работало бы нормально.

Чудом смог от сканировать журнал "Радиолюбитель. Ваш компьютер" статью “Контроллер дисковода. Канал чтения”
к сожалению в статье не хватает журнала №7 за 1998, может у кого нибудь есть
номера 7,11,12 этого чудного журнала за 1998 ?

http://zx.pk.ru/showthread.php?t=556

[deathsoft]

Провел тест на "магические числа", читал дорожку (командой чтения дорожки, прогой которую кидали в этот топик) первый сектор которой содержал 32 байта 0xAA в среди которых один байт заменялся на 0x29 ил 0x14, результат был один и тотже:
вместо байта 0x29 или 0x14 читалось всегда 0x14 а после шли нули (хотя должны были идти 0xAA), если вместо 0x29 записать 0x55 то все читается как надо.

[Conan]

Возник вот какой вопрос (прежде всего к уважаемым Lion17 и SMT). Поскольку с «загадочным» явлением вроде как разобрались, возможно ли использовать результаты практически? То есть, реально ли доработать существующие эмуляторы, что бы они эмулировали такую особенность ВГ93 как «сбои при чтении дорожки»?

[goodboy]

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

[CHRV]

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

Это экономили на пластмассе! Такие обязательно надо лаком закрашивать - а то гниют они быстро!

[Conan]

Я не технолог (в отличие от CHRV ), но когда-то задавался аналогичным вопросом о цели «отверстий» и «разломов» на больших корпусах ИМС. Как мне объяснили, это делалось для термокомпенсации при использовании не очень качественных смол, из которых делали корпуса микросхем. Такое решение снижало нагрузку на кристалл и разварку, возникающую при нагреве и охлаждении. Разумеется, при этом так же снижалась прочность самих корпусов и требовалась защита для оголившихся проводников (то о чем говорил Роман).