Ремонт материнки РВИЖ

Привет!

Решил описать историю, она не длинная.

Раньше (около 2010 года) материнки ремонтировались мной сразу по мере поступления, и в дальнейшем, обычно, не отказывали (во всяком случае крупных ремонтов не требовалось). Но эта плата ко мне попала где-то в 2017, заниматься ей времени не было, да и необходимости тоже. При этом она уже была явно "паханная".
Возможно, её ремонтировали как раз перед тем, как отправить мне, причем безуспешно.
Но подтверждений тому уже нет.

Итак:

0) Включается, есть растр, какая-то картинка, похожая на агатовскую, режим 128x128x4.

1) Отладочные прошивки даже вид не делают, что работают. Подключаю аппаратный отладчик, он тоже ничего не может сделать.

ОЗУ не читается и не пишется, точнее, реакция на запись хаотичная: что-то меняется во всех видимых в дампе ячейках сразу. Это не означает, что такие значения есть в ОЗУ, это означает лишь, что на ША, между её чтениями отладчиком, что-то меняется.

Но если коротнуть выходы DRAM, картинка логично меняется.
Т.е. DRAM доступна ДК, но не доступна никак для ЦП и устройств на шине.

Когда так много всего не работает, сперва нужно проверить системный фазогенератор. Но в его сигналах всё вполне хорошо.

Пошаговый проход есть, но что выполняет ЦП - не ясно, похоже на сигналы из космоса. Шум на ША подсказывает ткнуться в буфера ША.

Оказывается, они отключены. Нет сигнала разрешения их работы. Этот сигнал зависит только от буфера, который принимает сигнал !DMA от слотов. Это ЛН1 и у неё мощная утечка на землю по входу.
Хм, на микрухе моя пометка карандашом "?". Разве я уже лазил по этой плате?! Мог бы сразу заметить...

Меняем.

2) ОЗУ всё ещё не доступно, зато теперь, даже при воткнутом отладчике, ДК через несколько секунд или почти сразу перекидывается в Apple-mode. И гарантированно перекидывается, если отладчик лезет в ОЗУ. Это нашлось не сразу, я листал в дампы ОЗУ в надежде на что нибудь интересное и заметил, что перекидывание ДК происходит в определённых адресах.
Теперь вместо шума читаются везде константы вроде $FF, $FE... В общем, много единичек. Но в регионе $700..$7FF почему-то виден мусор. Вроде бы как увеличивающийся на единицу по мере возрастания адресов, хотя и не стабильно. Вот на нём ДК и меняет режим. Хм?

О чём-то таком я и думал, когда для хранения адресов дампера предусмотрел их расположение в EEPROM отладчика. Чтобы можно было легко щёлкать питанием системы при ремонте и потом автоматически возвращаться к исследуемым регионам.

На селекторе сигналов чтения/записи ОЗУ (ИД4) тишина. Отслеживаем цепочку сигналов, похоже, что системная ROM D14 не разрешает доступ к ОЗУ. Кстати, на ROM виден карандашный значёк "?". Похоже, я всё таки лазил уже по этой плате. Но тогда у меня ещё не было программатора для 556 серии. Видимо, поэтому не довёл ремонт до конца.

Да, у ROM мощная утечка по 23 входу, это как раз "Блокировка ОЗУ".

Тут я тупанул: воткнул вместо 556й микрухи at28c16. Вроде объём тот же, ног столько же, выходы там же.
Ушло несколько часов, пока я допёр, что у неё сигналы CS по другому расставлены. Но это было чуть позднее....

3) Пока всё продолжает не работать (с at28c16), а я интересуюсь, почему у меня ДК скачет. Логично предположить, что переход в Apple-режим может быть связан не с обращением к C05x, но также и с переходом контроллера ОЗУ в Apple-mode (он потянет за собой и ДК).
Смотрим триггеры  сигналов ПМ и ПА. Да, тут не всё хорошо, один из выходов триггеров перешел в Z-state, который совсем не предусмотрен у ТМ2.

Опознаётся это легко: выходы ТМ2 парафазны, так что даже ткнув вольтметром и увидев два нуля на выходах делаем вывод, что тут есть проблема. Дальше мульт в режим измерения тока и коротко пытаемся замкнуть каждый выход на питание и землю. При исправном выходе короткое касание не убъёт микру, а ток в десятки ма покажет, что она исправна (выход работает) либо есть утечка по входу. Но как раз ток около 1 ма или меньше говорит о том, что нет утечки по входу, а вот выход явно неисправен.

Не хочу отстёгивать все шнуры на время перепайки, поэтому просто подтягиваю вывод резистором 1кОм к питанию. Я думал у триггера только верхнее плечо отпало, но оказалось, что оба. Так что трюк с резистором был неполноценным, но для дальнейших тестов сойдёт.

Но ничего не меняется, ДК всё равно слетает в Apple-mode.

Ок, тогда замыканием кондёра сброса возвращаем оба триггера в агат-mode и начинаем смотреть: откуда на триггер прилетает команда на переключение? По цепочке доходим до ROM D14: от неё должен приходить сигнал "C" (обращение в регион $Cxxx), а там.... а там 1.0вольт. Или чуть больше.
Так что любое обращение на адреса $x700 сейчас интерпретируется последующей цепочкой дешифраторов как обращение к РУ ДК, ... Вероятно, какое -то другое обращение к другим адресам тоже приводит к срабатыванию триггера режима контроллера ОЗУ, он перекидывается в Apple-mode и теперь обращение к $x7xx перекидывает и ДК в Apple-mode.

Хорошо, прошиваем 556 для d14 и меняем микруху триггеров ПМ и ПА.

Стоп! Мне всё ещё лень перекидывать провода. Поэтому сперва прошиваем 556-ую: программатор на заваленном столе лежит боком по диагнали, всё выглядит жутко, осторожные движения, чтобы что нибудь не оторвать, не свернуть и не коротнуть. Программатор под ДОС, перезагрузка - это значит остановить фильмик (смотрю пародию на Потера), закрыть браузеры (открыты вкладки и по работе и по агату)...
Ладно, потом сделаем "восстановление сессии".

4) Закинул в кроватку прошитую 556ю, отладчик увидел ОЗУ !
Запускаю тест ОЗУ: всё хорошо, кроме бита D3: он идёт с ошибкой по всем адресам.
Хм ? Да, по всем, т.е. и чётные и нечётные. Вольтметром смотрю выходы соответствующих микр,
странно, смотрю осцилографом - он согласен с вольтметром: там тишина в районе 1.5 вольта. Проверяю входы - там всё хорошо и одинакого выглядит как у исправных микр, так и у неисправных.
Нет повреждений платы, замыканий: миллиамперметр при замыкании выходной линии на питание и на общий показывает мизерный ток, при этом картинка на ДК логично меняется.

Итак, теперь меняем триггеры ПМ, ПА, а под DRAMки ставим кроватки. В агате почти всё 14-ногое можно просто менять, но 16-ногое (и если больше ног - тоже) надо ставить на кроватки. Такое вот эмпирическое правило, выведенное за много ремонтов.

Проверка пайки (обязательно прозвонкой проверять все соседние дорожки на замыкание !)
Глазами не увидишь то, что видит "звенелка".

Включаем, тест ОЗУ из отладчика идёт. Сисмон запускается.

Теперь закидываем игрушку MARS через XModem - идёт (традиционный у меня уже тест).
Лисин тем же путём попадает на комп - несколько проходов без ошибок.

Теперь плате предстоят испытания без отладчика, но с дисководом и кучей прог, начиная от "комплексного теста".