Изучаю фоново тему по статьям/даташитам на MB8877 (ВГ93 почитал, местами не очень понятно, остались вопросы - вот в импортной доке все четко, просто, понятно и не надо гадать и искать вероятные ошибки в тексте, хотя очепятки и там есть). Из открытых вопросов пока работа 25-го пина MB8877/ВГ93 - сигнал Read Gate типа чип сигнализирует, что нашел синхропоследовательность или что RCLK синхронизировался с данными чтения от флопа (RAW READ), но на сигналах анализатора, это не очень похоже на обнаружение синхропоследовательности (буду еще копать), в частности при чтении данных, записанных на дискету во время форматирования, этот сигнал вообще никак себя не проявляет, хотя синхропоследовательности там пишутся.Сообщение от Kulich
Снял анализатором сигналы, которые приходят/уходят с FDD при форматировании компандой TR-DOS, DCU и RDS (картинки чуть позже выложу). Даже удалось рашифровать MFM поток (ручками/формулами в Экселе). Удручает, что при форматировании всеми этими прогами сигнал разрешения записи (Write Gate) включается только на время записи первого сектора на каждом трэке! Хотя в коде должны форматироваться 15 секторов - тут тоже косяк, вроде как на диске TR-DOS должно быть 16 секторов, но в коде выбор 16-го сектора из таблицы секторов как раз является условием прекращения процесса... Вот если условием было бы #1 (стоит в таблице после 16-го сектора), а не #10 (16 сектор), то записалось бы 16 секторов
Таблица секторов:
1fb9 DEFB 1,9,2,10,3,11,4,12,5,13,6,14,7,15,8,16,1
Более того расшифровка MFM потока при форматировании командой TR-DOS показала, что запись выключается прямо во время записи первого байта контрольной суммы (на предпоследнем бите), который идет сразу после записи длины сектора. Вот хз как после этого полученная односторонняя дискета остается рабочей. Хотя, помнится, она не хотела форматироваться на скорпе (новая из коробки с MS DOS форматом) пока я ее предварительно не отформатировал на фениксе, от сюда предположение, что запись (например, копирование) на ней работает просто по старой разметке секторов - они же не затираются при "форматировании" скорпом
Я копаюсь в этом потому что пока (умеренно) интересно. В практическом плане предполагаю косяк в схеме ФАПЧ, либо в чип-селекте ВГ93 или еще какой-нить ноге, от которой зависит ее работа - чего это она обрывает сигнал разрешения записи? Пощупаю потом еще. Выковыривать ее боюсь (есть еще одна) - родную хрустнул при вытаскивании (она была с окошками), поставил сплошную (поведение то же) и вот на ней ставлю опыты. Крайне неудачное место для нее на плате - хрен подлезешь отверткой, а корчевателем вот - сломал.
PS Кстати, при записи файлов, например, в FATALL пишутся, как положенно все 16 секторов и сигнал разрешения записи включается как и должен - на каждый сектор.
- - - Добавлено - - -
Веселые картинки:
Вот, что творится при выполнении Format в TR-DOS. Видно, что (согласно коду кстати) что-то пишется на нижнюю сторону, потом на верхнюю (должно быть форматирование этих дорожек), затем опять переключается на нижнюю сторону - в коде стоит чтение номера дорожки - 4 оборота пытается его считать, забивает, переключается на верхнюю сторону и далее форматит только ее. Причем вся запись - что-то около 1 мс.
Update: высокий уровень сигнала WF/DE во время попытки прочитать номер дорожки на нижней стороне, вроде как намекает, что чип на самом деле ничего не читает - в даташите 33 пин (активность низким уровнем) во время операции чтения сообщает, что флоп читает диск. А тут он на верху... Как будто чип не получил команду чтения.
DCU:
В DCU все примерно также, только на обоих сторонах, но запись также продолжается только 1 мс.
RDS:
А вот в RDS запись идет дольше - 4 мс.
Ответить с цитированием