К1818ВГ93

[Lion17]

Как выянилась последовательность импульсов A1 с пропущенным синхроимпульсом не такая уж уникальная:
A1 = 10100001 = 0100010010101001
~A1 = 10100001 = 0100010010001001 (это с пропуском)

предположим что VG93 думает что это байт A1 если встречает:
10010001001
я построил все последовательности от 0 до 255 (при условии что перед ними байт заканчивался 0 битом)
вот такие байты отвечают этому ключу:
14 1010100100010010
28 1010010001001010
29 1010010001001001
50 1001000100101010
51 1001000100101001
52 1001000100100100
53 1001000100100101
94 0100100100010010

Как видим среди этих кодов старые знакомые - 14 и 29
естественно есть еще последовательности для байт последний бит перед которым был не 0, а 1, а также пары байт на пересечении которых будет встречаться эта последовательность.

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

В итоге можно заключить, что прав был Conan. И сбой синхронизации особенность вг93. Из-за того, что в качестве синхронизирующей была избрана неуникальная последовательность. Вот если бы выбрали последовательность в которой встречаются 4 нуля подряд (что нереально в MFM коде), дорожки бы читались без проблем

[spensor]

Есть ли у кого прога, которая делает чтение дорожки и скидывает результат в файл? Или самому писать придется?

Могу предложить для эксперементов прогу, которой пользовался сам.

[Conan]

Как выянилась последовательность импульсов A1 с пропущенным синхроимпульсом не такая уж уникальная:
A1 = 10100001 = 0100010010101001

Спасибо Владимир, за толковое объяснение! Занимаясь изучением этого вопроса (15 лет назад), дальше нахождения числа 29h я продвигаться не стал, потому как команда чтения дорожки с таким «дефектом» практического интереса уже не представляла.

сбой синхронизации особенность вг93. Из-за того, что в качестве синхронизирующей была избрана неуникальная последовательность. Вот если бы выбрали последовательность в которой встречаются 4 нуля подряд (что нереально в MFM коде), дорожки бы читались без проблем

Другим решением этой проблемы было бы отключение детектора адресной метки, после ее первого нахождения и синхронизации. Но, увы, ошибка запечатлена на кристаллах WD1793 и скопирована в наши КР1818ВГ93 навечно.

Хотелось бы поделиться еще некоторым «сокровенным знанием» по контроллерам Beta Disk:

1. Предкомпенсация при записи. Сначала несколько слов, зачем вообще она нужна. У большинства современных дисководов, угловая скорость носителя одинакова, а линейная различается, уменьшаясь от нулевой (внешней) дорожки к внутренним. Поскольку с уменьшением линейной скорости, увеличивается линейная плотность записи, это ухудшает амплитудно-частотные (и как следствие фазовые) характеристики записи-чтения на внутренних дорожках. Фактически для MFM это приводит к усреднению скважности (фазы) импульсов, а значит к большей вероятности ошибки. Искажения зависят так же от типа дисковода и качества магнитного материала носителя (дискеты). Для компенсации этих искажений, при записи на внутренних дорожках импульсы в MFM последовательности смещают, увеличивая расстояние между ними при переходе из «0» в «1» и из «1» в «0». Для управления смешением используются сигналы SL (Shift Left) и SR (Shift Right) контроллера ВГ93. Разделением дорожек на внешние и внутренние управляет сигнал TR43 (Track 43). Оптимальное время сдвига импульсов (предкомпенсации), зависит от типа дисковода и носителя. Как показала практика, время предкомпенсации 250нс является оптимальным для отечественных дисководов и носителей 5,25. В тоже время для дисководов 3,5 рекомендуется предкомпенсация 125нс.

Теперь о реалиях жизни. Некоторые разработчики отечественных клонов, просто не использовали схем предкомпенсации (ZX-777), наверно для экономии элементов. А некоторые включали предкомпенсацию 250нс всегда, не используя сигнал TR43 (KAY 256-1024). Большинство же контроллеров ограничивались одним временем 250нс управляемым сигналом TR43. Единственной схемой использующей два времени предкомпенсации (125/250нс) является контроллер дисковода для ZX-Next.

2. Так же часто разработчики отечественных Speccy забывали задействовать сигнал WF/DE, разрешающий поступление данных в сепаратор при чтении (рекомендация в описании WD179x).

3. Reset. На контроллерах Beta, где порт #FF аппаратно «обнуляется», при системном Reset, в режиме 128К (без инициализации TR-DOS) нажатие Magic может привести к порче диска. Это происходит из-за инициализации ВГ93 при «отпускании» Reset, во время обработки процедуры NMI в ПЗУ TR-DOS. Проблема решается просто: Reset ВГ93 (вывод 19) отсоединяется от выхода порта #FF и подключается к системному Reset.

P.S. Конечно все вышесказанное представляет сейчас больше теоретический интерес, но возможно будет кому-то интересным, как ответы на вопросы, о причинах тех или иных проблем.

[spensor]

Но, увы, ошибка запечатлена на кристаллах WD1793 и скопирована в наши КР1818ВГ93 навечно.

Подождите, а стоит ли говорить столь категорично. Было ли где-нибудь упоминание в зарубежных источниках о глюке в микросхеме. Может это и не глюк вовсе, или глюк отечественной микросхемы?

[Conan]

Подождите, а стоит ли говорить столь категорично. Было ли где-нибудь упоминание в зарубежных источниках о глюке в микросхеме. Может это и не глюк вовсе, или глюк отечественной микросхемы?

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

Что касается WD1793, в моем древнем «Пентагон 48» стоял именно он. При проведении изысканий, разумеется, тестировались и наши КР1818ВГ93. Результат был одинаковым.



P.S. Микросхемы копировались переносом накристальной топологии, при этом никаких изменений в логику работы даже теоретически внесено быть не может.

[spensor]

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

Согласен, но где bug report? Ведь WD1793 использовалась во многих компах (MSX, TRS-80) и неужели никто не столкнулся с данной проблемой? Они что, из принципа не пользовались данной командой? А как дела обстояли в более раних WD (WD1771, WD1773), ведь и они применялись на Spectrum-FDC? Неужели "жук" всплыл именно на этом чипе? И надо-же быть такими невезучими, чтобы глючный чип скопировать. Что то уж очень это все подозрительно!

И еще один вопрос - кто может перечислить всех "родственников" ВГ93? Имеются ввиду чипы с родственной системой команд.

[Advertiser]

[Conan]

Согласен, но где bug report? Ведь WD1793 использовалась во многих компах (MSX, TRS-80) и неужели никто не столкнулся с данной проблемой?

Вполне возможно bug reports были, только Western Digital их вряд ли афишировала, да и найти их будет очень нелегко, прошло 25 лет, отсканированные описания самого контроллера и то редкость, а уж такая специфичная информация и подавно.

Они что, из принципа не пользовались данной командой?

А разве хоть одна DOS под WD1793 штатно использует эту команду?

А как дела обстояли в более раних WD (WD1771, WD1773), ведь и они применялись на Spectrum-FDC? Неужели "жук" всплыл именно на этом чипе?

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

И надо-же быть такими невезучими, чтобы глючный чип скопировать. Что то уж очень это все подозрительно!

А причем тут везение или невезение? Копировали, элементную базу, а про то как ее использовать и как выполняются команды думали совсем другие люди. Например, в ГДР скопировали Z80, и что можно программно отличить UB880 от оригинала? Кстати Z80 на порядки более распространен нежели WD1793, так вот много ли фирменных описаний, где подробно рассказано обо всех неопубликованных командах? А об отличиях CMOS от NMOS версий Z80 можно, где ни будь почитать на английском? А ведь и те и другие ставились в ZX-Spectrum, и работали по-разному. Иными словами отсутствие информации в данном случае – не аргумент, а вот реальные проблемы с реальными микросхемами WD1793 (ВГ93) – факт.

[spensor]

можно всю жизнь заниматься исследованием ошибок допущенных при разработке различных микросхем, но какое отношение это имеет к проблеме топика? Например в i8272, насколько я помню, команда чтения дорожки работает нормально, и что нам с этого?

Все WD родственны между собой, и с большой долей вероятности их внутренние цепи совпадают, а соответственно bug должен проявляться и в других чипах. А до i8272 нам в общем-то дела нет.

А разве хоть одна DOS под WD1793 штатно использует эту команду?

Ну, а внешний софт разве никогда по это дело не писался?

А причем тут везение или невезение?

Как причем? Взять первый попавшийся чип и именно в нем должен был оказаться "жук". Тогда наверное многие WD должны быть с этим глюком. Но почему-то зарубежные пользователи других FDC на WD о подобных фокусах никогда не высказывались.
Как было сказанно выше "сбой на #29 иногда не происходит (редко)", а почему он не происходит? Может есть способ так построить сепаратор, что этот внутренний глюк будет скомпенсирован. Что это возможно подтверждает сообщение Sonic. Люди у кого есть MSX с фирменным контроллером и имеется возможность проверить команду чтения дорожки помогите пожалуйста разобраться в данном вопросе!

[Conan]

Все WD родственны между собой, и с большой долей вероятности их внутренние цепи совпадают, а соответственно bug должен проявляться и в других чипах. А до i8272 нам в общем-то дела нет.

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

Ну, а внешний софт разве никогда по это дело не писался?

Да писался, 25 лет назад Mr. Pumpkin писал кривой копировщик, в котором эта команда не заработала. И что было дальше? А дальше он подумал и решил, что это кривой контроллер дисковода и появились те же слова в книжке Родионова и Ларченко. Но только вот и без этой команды все великолепно обходились и обходятся. Тема слишком узкая и специфичная.

Как причем? Взять первый попавшийся чип и именно в нем должен был оказаться "жук". Тогда наверное многие WD должны быть с этим глюком.

Не бачу логики. В первом скопированном микропроцессоре К580ИК80 были все те же ошибки, что и в родном i8080. Ах, как не везло отечественным копировщикам, что ни микросхема, то с "жуком", не находите? Просто злой рок, какой то. Наверно буржуины нарошно в них "жуки" встраивали!

Но почему-то зарубежные пользователи других FDC на WD о подобных фокусах никогда не высказывались.

Ссылку на описание проблемы при чтении дорожки у MSX я уже приводил выше в этом топике.

Как было сказанно выше "сбой на #29 иногда не происходит (редко)", а почему он не происходит? Может есть способ так построить сепаратор, что этот внутренний глюк будет скомпенсирован.

Сепаратор не имеет никакого отношения к внутренней логике побайтовой синхронизации ВГ93, и управлять ею не может. Впрочем, можете продолжать верить в чудеса.

[spensor]

Сепаратор не имеет никакого отношения к внутренней логике побайтовой синхронизации ВГ93, и управлять ею не может. Впрочем, можете продолжать верить в чудеса.

Может это конечно и чудеса, но ведь хоть и "редко", но чудеса происходят. Возможно фишка в том, какой байт шел до этого, а может быть - на какой фазовый сдвиг пришелся перепад импульса. Если последнее верно, то глюк устраним...