Тех. раздел "Scorpion ZS 1024 Turbo+" (savelij)

[Kulich]

Я свой победил. Была повреждена дорожка между 30 ногой 8877(wgate) и ЛН5. Восстановил контакт и диск успешно отформатировался в мониторе и в тр-дос как двусторонний.

[Advertiser]

[Evgeny Muchkin]

Была повреждена дорожка между 30 ногой 8877(wgate) и ЛН5.

А кто её повредил? Или она была повреждена в процесса производства?

[Vogul]

Люди, а чем закончилась история с дисководом?

Изучаю фоново тему по статьям/даташитам на MB8877 (ВГ93 почитал, местами не очень понятно, остались вопросы - вот в импортной доке все четко, просто, понятно и не надо гадать и искать вероятные ошибки в тексте, хотя очепятки и там есть). Из открытых вопросов пока работа 25-го пина MB8877/ВГ93 - сигнал Read Gate типа чип сигнализирует, что нашел синхропоследовательность или что RCLK синхронизировался с данными чтения от флопа (RAW READ), но на сигналах анализатора, это не очень похоже на обнаружение синхропоследовательности (буду еще копать), в частности при чтении данных, записанных на дискету во время форматирования, этот сигнал вообще никак себя не проявляет, хотя синхропоследовательности там пишутся.

А вот с записью беда. Тр-дос успешно форматирует его как односторонний, но по факту содержимое остаётся. Монитор форматирует как DS, зелёненьким проверяет, но опять после вся информация на диске остаётся. Стоит MB8877 и gal16v8...

Снял анализатором сигналы, которые приходят/уходят с 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 форматом) пока я ее предварительно не отформатировал на фениксе, от сюда предположение, что запись (например, копирование) на ней работает просто по старой разметке секторов - они же не затираются при "форматировании" скорпом . Это же может объяснить, почему не затирается содержимое дискеты - у меня оно тоже не затирается, точнее файлы отображаются, хотя счетчик файлов показывает 0 и удаленных тоже 0 - это и после команды Format, и после DCU (кстати делает нормальную 2-х стороннюю дискету). А вот RDS v.3.1 все успешно форматирует и затирает содержимое. Как у него это получается, я пока не смотрел, запись включается также только на запись первого сектора на каждой дорожке... Может он все же каталог затирает, просто я дампил только несколько дорог в начале процесса, а он начинает с 79 трэка.

Я копаюсь в этом потому что пока (умеренно) интересно. В практическом плане предполагаю косяк в схеме ФАПЧ, либо в чип-селекте ВГ93 или еще какой-нить ноге, от которой зависит ее работа - чего это она обрывает сигнал разрешения записи? Пощупаю потом еще. Выковыривать ее боюсь (есть еще одна) - родную хрустнул при вытаскивании (она была с окошками), поставил сплошную (поведение то же) и вот на ней ставлю опыты. Крайне неудачное место для нее на плате - хрен подлезешь отверткой, а корчевателем вот - сломал .

PS Кстати, при записи файлов, например, в FATALL пишутся, как положенно все 16 секторов и сигнал разрешения записи включается как и должен - на каждый сектор.

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

Веселые картинки:



Вот, что творится при выполнении Format в TR-DOS. Видно, что (согласно коду кстати) что-то пишется на нижнюю сторону, потом на верхнюю (должно быть форматирование этих дорожек), затем опять переключается на нижнюю сторону - в коде стоит чтение номера дорожки - 4 оборота пытается его считать, забивает, переключается на верхнюю сторону и далее форматит только ее. Причем вся запись - что-то около 1 мс.

Update: высокий уровень сигнала WF/DE во время попытки прочитать номер дорожки на нижней стороне, вроде как намекает, что чип на самом деле ничего не читает - в даташите 33 пин (активность низким уровнем) во время операции чтения сообщает, что флоп читает диск. А тут он на верху... Как будто чип не получил команду чтения.

DCU:


В DCU все примерно также, только на обоих сторонах, но запись также продолжается только 1 мс.

RDS:



А вот в RDS запись идет дольше - 4 мс.

[Kulich]

А кто её повредил? Или она была повреждена в процесса производства

Я ее повредил когда перепаивал все диоды на плате )

[Vogul]

Из открытых вопросов пока работа 25-го пина MB8877/ВГ93 - сигнал Read Gate типа чип сигнализирует, что нашел синхропоследовательность или что RCLK синхронизировался с данными чтения от флопа (RAW READ), но на сигналах анализатора, это не очень похоже на обнаружение синхропоследовательности (буду еще копать), в частности при чтении данных, записанных на дискету во время форматирования, этот сигнал вообще никак себя не проявляет, хотя синхропоследовательности там пишутся.

Был не прав - на втором обороте после записи первого сектора в месте, где производилась запись, Read Gate все же поднялся, посмотрел по декодированным данным - случилось это после 4 байт 00 (на 3-м бите 5-го байта 00) - синхропромежуток из 12 байт 00 перед адресом сектора (дорожка, сторона, сектор, длина). Сигнал опустился во время следующего байта после того, где должна была быть вторая часть контрольной суммы (в моем случае не дописанная)...

[Kulich]

Что-то я не пойму, у меня совершенно другая картина рисуется.WGATE И WDATA от индекса до индекса идут

Вот так начинает ТР-ДОС в итоге SS получился
https://disk.yandex.ru/i/zc8nrN2ugKsfvw

Вот кусочек поподробнее, но это я уже монитором форматировал он выдал после как проложено DS
https://disk.yandex.ru/i/MsXAl8H8YiLN6g

[Vogul]

Что-то я не пойму, у меня совершенно другая картина рисуется.WGATE И WDATA от индекса до индекса идут

Вот так начинает ТР-ДОС в итоге SS получился
https://disk.yandex.ru/i/zc8nrN2ugKsfvw

Вот кусочек поподробнее, но это я уже монитором форматировал он выдал после как проложено DS
https://disk.yandex.ru/i/MsXAl8H8YiLN6g

Вот у вас Write Gate и Write Data правильно работают - так и должно быть, 15 секторов, потом до заполнение остатка дорожки 00.

Начало Format в TR-DOS почти совпадает с моим - у меня 4 оборота пытается читать нижнюю дорожку, у вас - 2. Но походу у вас также не получается прочитать номер дорожки на нижней стороне, поэтому дальше форматирует только верхнюю сторону. Хорошо бы еще сверить сигнал WF/DE - 33 пин MB8877/ВГ93. Когда он внизу чип типа сообщает, что флоп читает диск (в даташите в режиме чтения этот сигнал командует включить схему ФАПЧ). Так вот у меня эти 4 оборота он вверху, что неправильно.

PS Также полезно добавить сигнал DRQ (38 пин FDC) - при чтении чип дергает его вверх, когда в регистре данных выставляет считанный байт, если во время чтения номера дорожки на нижней стороне DRQ молчит, то, возможно, чип ничего не смог прочитать. При записи чип этот сигнал дергает в верх, когда просит очередной байт для записи.

[Vogul]

Проблема с ВГ93 закрыта - как оказалось, чип косой. Не сказать, чтобы сильно он меня обидел, хотя купил его несколько лет назад нулячим у форумчанина - достал из золотинки первый раз только для этого скорпа. Как грится, не было щастья - нещастье помогло: давно хотел вникнуть в работу флоп-контроллера - вот он меня и заставил вчитаться в доки и на практике прощупать сигналы анализатором.

Итак диагноз кратко: при форматировании дорожки (операция write track) чип стабильно выключает сигнал разрешения записи (WriteGate) при записи последнего бита в первом байте контрольной суммы индексного массива (там где номер дорожки, стороны, сектора и его длина), а при последующем чтении регистра состояния в нем выставлен флаг ошибки CRC. Я не смотрел, что происходит в операции записи сектора, но поскольку, кроме форматирования дискеты, другие косяки в работе ВГ93 не наблаются (дискеты пишутся и читаются исправно, хотя проверял только на нем), то скорее всего запись сектора работает корректно. Перекинул ВГ93 с Феникса, на котором предварительно форматировал и записывал дискеты - на скорпе форматирование заработало и в теневике, и командой format; на анализаторе WriteGate на нем включен в течение всего оборота диска - от индекса до индекса.

Подробнее: вот как выглядит попытка форматирования 1 дорожки на нулевой стороне командой Format TR-DOS 5.03 - успевает записаться индексный массив 1-го сектора:
1. На чип приходит команда записи дорожки 1111-0100 (единица во 2 бите - инструкция предварительно выждать задержку 15 мс, )
2. Чип выставляет запрос DRQ 10 раз и соответственно получает 10 байт 4E в регистр данных (дес. 78 в дизассембле TR-DOS в строке 8199) - т.н. первый пробел.
3. Аналогично п. 2 на чип приходит 12 байт 0 - синхропромежуток.
4. Далее в регистр данных пишется 3 байта F5 - условная команда записи метки A1 (1010-0001, в отличие от обычной записи между нулями во 2-3 битах нет переключения полярности магнитного потока на дискете).
5. В регистр данных приходит байт FE - адресная метка индексного массива.
6. Далее чип получает байты самого индексного массива: 01 00 01 01 - соответственно номер трека 1, сторона 0, номер сектора 1, длина сектора 256 байт (условно обозначается значением 01).
7. Наконец, в регистр данных пишется F7 - команда записать 2 байта контрольной суммы, включающей данные п. 4-6.
8. Чип успевает запросить и получить следующий байт 4Е второго пробела, но во время записи последнего бита первого байта в п. 7 сигнал разрешения записи (WriteGate) отключается.



Гадаю, что причина выключения записи - паразитный переход полярности посреди отрезка, отведенного под 0 в последнем бите. Контрольная сумма вычисляется по алгоритму CRC-CITT (0xFFFF), он же CRC-16/CCITT-FALSE, например, здесь он упоминается для чипа WDC 179X-02 (с которого сделали ВГ93 и на который также ссылается дока по MB8877A). Он-лайн калькуляторы [1, 2] для последовательности A1A1A1FE01000101 вычисляют контрольную сумму 8CB8, т.е. двоично: 1000-1100 1011-1000. Вот как выглядит запись первого байта на шлейфе флопа (т.е. сигнал WriteData с учетом предкомпенсации):



Последний бит выделен вешками B1-B2, посреди нуля в нем никак не может быть переключения полярности на дискете, однако оно выдается на шлейф - возможно, сбой внутренних часов ВГ93 и фальстарт записи второго байта CRC - как раз начинается с 1. Read Clock (пин 26) тут не при делах, но в этом месте по нему еще примерно видны такты каждого бита - согласно MFM нули обозначены переключением полярности в начале такта (в данном случае посреди отрицательного полупериода RCLK), единицы - посреди такта (положительного полупериода), между 0 и 1 в MFM переключения полярности нет.

Кстати, чип успевает выключить WriteGate до выдачи паразитного пульса посреди последнего бита (за 540 нс до него). После этого, если я правильно понял доку по WDC 179x-02, переключение WF/DE в низкий уровень при выключенном WriteGate - команда включить схему ФАПЧ (в оригинале "variable frequency oscillator"), т.е. чип прерывает команду записи и переключается в режим чтения... - байтов на запись не просит, правда, и считанное в регистр данных не выставляет, но под конец этого безобразия 6 раз поднимает DRQ (х.з., что он имеет в виду - запрос байта или выдача байта, раз он в режиме чтения находится), на что комп реагирует записью в регистр данных байтов 4E (обозначают пробел между полями) - наверное, комп думает, что запись продолжается, возможно, в этом месте как раз конец сектора и пробел до следующего. После 6-го байта чип требует к себе внимание - поднимает IRQ.



Комп читает статусный регистр, а в нем 0000-1000 бит S4=1 для команды записи трэка означает ошибка CRC в поле индекса сектора.

В RDS v3.1 форматирование отличается - в п. 1 на чип приходит команда записи трека 1111-0000, т.е. без выдержки паузы 15 мс. Первый сектор дорожки успевает записаться почти весь - запись обрывается на последнем байте CRC, после поля данных (256 нулей). Видимо, поэтому после форматирования этой прогой на данном чипе каталог дискеты затирается (в отличие от DCU и Format в TR-DOS). Еще существенное отличие - RDS начинает запись трэка с канонического заголовка начала дорожки - 80 байт пробела (4E), 12 байт нулей, трех меток C1 и метки FC (все согласно доке на WDC 179x-02), далее 10 байт пробела 4E до индекса сектора (с которых как раз начинает запись Format TR-DOS).



В предыдущем сообщении я заблуждался, что чип 4 оборота пытается прочитать, что записал на нижнюю дорожку в начале команды форматирования TR-DOS - он там просто бездействует, какой-либо команды чтения на него не приходит.

Турбирование ВГ93 сделано некрасиво - вместо 2МГц после выдачи сигнала Step на ВГ93 приходит переменная частота: 1 период - 2,326 Мгц, 1 период - 1,724 МГц. Ну, как-то работает и ладно.



Постскриптум: если кому-то еще будет интересно вчитаться в доки по FDC, английский первоисточник, ИМХО, легче и понятнее - меньше напрягает интеллект, чтобы догадаться, что хотел сказать автор. Например, в русской книге по флопам по ВГ93 пишут, что метка в поле данных может быть "FB (без стирания данных) или F8 (со стиранием)" - вот ХЗ, что значит со стиранием/без стирания; в описаннии команд также пишут, что флаг a0 указывает могут ли стираться данные или нет - не понятно, зачем такое может быть предусмотрено в команде записи сектора... (защита данных от перезаписи что ли? - бред какой-то), а в доке WDC все четко и понятно: FB - метка данных, F8 - метка УДАЛЕННЫХ данных, никаких там может/не может.

Может кому-то будет интересно, дампы с анализатора и доки WD и Fujitsu закинул на яндекс диск. Дампы читаются родным софтом KingstVIS. Если сигнал взят с ВГ93, то в скобках в названии указан пин, без указания пина сигналы взяты со шлейфа флопа.

[Гаррий]

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

[izzx]

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

По-моему Grand умеет так делать. Была такая версия TRDN или GB.