Могу предложить для эксперементов прогу, которой пользовался сам.Сообщение от deathsoft
Все на благо человека!
Могу предложить для эксперементов прогу, которой пользовался сам.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Спасибо Владимир, за толковое объяснение! Занимаясь изучением этого вопроса (15 лет назад), дальше нахождения числа 29h я продвигаться не стал, потому как команда чтения дорожки с таким «дефектом» практического интереса уже не представляла.
Другим решением этой проблемы было бы отключение детектора адресной метки, после ее первого нахождения и синхронизации. Но, увы, ошибка запечатлена на кристаллах WD1793 и скопирована в наши КР1818ВГ93 навечно.сбой синхронизации особенность вг93. Из-за того, что в качестве синхронизирующей была избрана неуникальная последовательность. Вот если бы выбрали последовательность в которой встречаются 4 нуля подряд (что нереально в MFM коде), дорожки бы читались без проблем
Хотелось бы поделиться еще некоторым «сокровенным знанием» по контроллерам 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. Конечно все вышесказанное представляет сейчас больше теоретический интерес, но возможно будет кому-то интересным, как ответы на вопросы, о причинах тех или иных проблем.
Подождите, а стоит ли говорить столь категорично. Было ли где-нибудь упоминание в зарубежных источниках о глюке в микросхеме. Может это и не глюк вовсе, или глюк отечественной микросхемы?
А сколько еще ждать, пока подобные контроллеры вымрут как вид? С битовыми последовательностями работает внутренняя логика ВГ93, и если ошибка возникает именно при их обработке, то где еще может быть причина?
Что касается WD1793, в моем древнем «Пентагон 48» стоял именно он. При проведении изысканий, разумеется, тестировались и наши КР1818ВГ93. Результат был одинаковым.
P.S. Микросхемы копировались переносом накристальной топологии, при этом никаких изменений в логику работы даже теоретически внесено быть не может.
Согласен, но где bug report? Ведь WD1793 использовалась во многих компах (MSX, TRS-80) и неужели никто не столкнулся с данной проблемой? Они что, из принципа не пользовались данной командой? А как дела обстояли в более раних WD (WD1771, WD1773), ведь и они применялись на Spectrum-FDC? Неужели "жук" всплыл именно на этом чипе? И надо-же быть такими невезучими, чтобы глючный чип скопировать. Что то уж очень это все подозрительно!
И еще один вопрос - кто может перечислить всех "родственников" ВГ93? Имеются ввиду чипы с родственной системой команд.
Вполне возможно bug reports были, только Western Digital их вряд ли афишировала, да и найти их будет очень нелегко, прошло 25 лет, отсканированные описания самого контроллера и то редкость, а уж такая специфичная информация и подавно.
А разве хоть одна DOS под WD1793 штатно использует эту команду?
Влад, можно всю жизнь заниматься исследованием ошибок допущенных при разработке различных микросхем, но какое отношение это имеет к проблеме топика? Например в i8272, насколько я помню, команда чтения дорожки работает нормально, и что нам с этого?
А причем тут везение или невезение? Копировали, элементную базу, а про то как ее использовать и как выполняются команды думали совсем другие люди. Например, в ГДР скопировали Z80, и что можно программно отличить UB880 от оригинала? Кстати Z80 на порядки более распространен нежели WD1793, так вот много ли фирменных описаний, где подробно рассказано обо всех неопубликованных командах? А об отличиях CMOS от NMOS версий Z80 можно, где ни будь почитать на английском? А ведь и те и другие ставились в ZX-Spectrum, и работали по-разному. Иными словами отсутствие информации в данном случае – не аргумент, а вот реальные проблемы с реальными микросхемами WD1793 (ВГ93) – факт.
Все WD родственны между собой, и с большой долей вероятности их внутренние цепи совпадают, а соответственно bug должен проявляться и в других чипах. А до i8272 нам в общем-то дела нет.
Ну, а внешний софт разве никогда по это дело не писался?
Как причем? Взять первый попавшийся чип и именно в нем должен был оказаться "жук". Тогда наверное многие WD должны быть с этим глюком. Но почему-то зарубежные пользователи других FDC на WD о подобных фокусах никогда не высказывались.
Как было сказанно выше "сбой на #29 иногда не происходит (редко)", а почему он не происходит? Может есть способ так построить сепаратор, что этот внутренний глюк будет скомпенсирован. Что это возможно подтверждает сообщение Sonic. Люди у кого есть MSX с фирменным контроллером и имеется возможность проверить команду чтения дорожки помогите пожалуйста разобраться в данном вопросе!
Как оказалось - нет, при чтении дорожки командой "чтение дорожки" на i8272 происходят сбои синхронизации после поля GAP следующего за данными сектора (межсекторным пробелом), при этом адресный маркер следующего сектора читается неверно (все байты искажены), также происходит второй сбой синхронизации на границе адресного маркера сектора и поля данных сектора (где идет поле синхронизации из 12 нулей).
Данная ошибка принципиально отличается от того что происходит на ВГ93, т.к. на i8272 сбой синхронизации не зависит от данных в секторе, а происходит всегда на границе секторов, причем синхронизация может восстанавливаться через несколько секторов.
Из-за чего именно происходит сбой синхронизации необходимо выяснять отдельно, похоже, что вместо импульсов данных за данные контроллер принимает импульсы синхронизации (сдвиг на пол битового интервала).
Последний раз редактировалось deathsoft; 03.02.2007 в 13:34.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
