Может, проблемы с записью? Я как-то неправильно пишу?
Команда:
fluxengine.exe write -c agat -d drive:0 -i ikp2-19311.dsk
или
fluxengine.exe write agat840 —drive.rotational_period_ms=200 —usb.greaseweazle.port=COM9 -i "ikp2-19311.dsk" —drive.high_density=0
Но тогда программа ругается: Error: unrecognised flux filename 'rive.rotational_period_ms=200'
Именно так и пишет: "rive" вместо "drive", как будто не видит букву d.

Есть пара %subj в несовсем живом состоянии. Требуется запустить до того уровня, чтобы
потестить головы.

Всё выглядит так, что после старта они оба не выдают сигнал track0.

Причем шпиндель оба заводят только при условии, что головка при включении уже стоит в положении трека 0.

Сигнал с датчиика index и track 0 проходит усилок DD2 и успешно наблюдается на X16 и X17.
Но дальше index, возможно, доходит до шлейфа на контроллер, а вот track 0 зачем -то ныряет внутрь процессора cm650 и наружу выходит уже только постоянная единица, которая попадает на буфер DD1.

Хотелось бы понять: это проц косячит или ему что-то на входах не нравится ?
1) Т.е. зачем ему вообще пропускать track 0 через себя, в каком случае он может его выдавать как постоянную единицу ?
2) Имеет ли этот проц программу первоначальной установки головки на нулевой трек ? Знаю, что некоторые поздние флопики делают это сразу при подаче питания.

Я не исключаю отказа DD8/DD9 (усилки шагового двига), но будет ли их отказ причиной такого поведения ?

Есть мысли такого плана:

А Вы что думаете?

Предисловие

Иногда я пишу истории не столько в расчёте на сторонних читателей, сколько на самого себя. Это что-то вроде блога: дневник, но публикуемый. Он нужен, с одной стороны - чтобы при необходимости перечитать собственные заметки и вспомнить, что же там такое было, с другой стороны - чтобы во время написания текста ещё раз обдумать произошедшее. Дальнейший текст - именно из этой серии.

История одного ремонта

Возможно, это произведение кому-то поможет в ремонте Агатов. Или покажется занятным для читателей, связанных с ремонтом цифровой техники.

А дело было так: мне прислали системную плату Агат-9 в неисправном состоянии, производства ВЗЭВТ. История её была неизвестна, т.к. с момента поломки сменился не один владельц. Было ясно лишь, что на монитор не выдаётся сигнал синхронизации развёртки.

Одной из целей изучения платы было снятие образов ПЗУ для сайта. Логичнее было сначала отремонтировать, а потом снимать образы, чтобы быть уверенным, что образы будут верны. С другой стороны, неисправность могла быть обусловлена разрушением содержимого какой нибудь ПЗУ (а на девятке их много), поэтому я решил начать с ремонта.

В работе использовались, в основном, лишь заслуженный осцилограф ОЛМ-2М - старый, советский, но довольно надёжный. И хотя полоса его частот ниже тех, что есть в Агате (1 МГц против 14), это меня не особенно смущало. 14 МГц в Агате есть далеко не везде, да и часто важна не точная форма сигнала, а лишь некоторые виды искажений и относительная амплитуда (т.е. возможность сравнить амплитуду сигнала в двух точках). А полоса в 1 МГц говорит лишь о том, что осцилограф будет правильно показывать форму и абсолютную амплитуду сигнала в полосе от 0 до 1 МГц.

Второй прибор - мультиметр vc9805a. Он звёзд с неба не хватает, переменку измеряет только синус-формы и только для звукового диапазона частот, ну да и ладно. Зато звенит в звуковом тесте хорошо.

D88

Итак, сначала выясняем, куда пропал сигнал синхро. Он основан на сигнале генератора с кварцем BQ2, ... тут что-то переменное высокочастотное видно, D81 - тоже, с 7-й ножки у неё идёт что-то высокочастотное, а доходит ли оно до D87, D88 - да, доходит. D88 - защёлка, должна передавать всё со входов на выход. Раз синхро есть, значит сигналы на входах/выходах должны мелькать. А оно... а оно не мелькает. Ну, допустим, у неё на входах константы. Тогда на выходах тоже должны быть константы. Проверим ? Вход 3, выход 2 - уровни совпадают. Вход 4, выход 5 - совпадают. ... Вход 14 - единичка, выход 15 - ноль. Неисправность. Но в чём ? Либо D88 не пропускает сигнал, либо кто-то его садит на "землю". Проверка простая: выключаем питание, омметром прозваниваем между "землёй" и выходом. Либо выходной каскад микрухи пробит, либо входной каскад какой-то другой микрухи, которая подключена к данной - тогда будет почти ноль. Либо замыкание дорожек - тогда точно ноль. Либо логика микрухи убита внутри, тогда будет бесконечка либо очень много. По факту - почти ноль. Куда идёт дорожка ? Упс.. Тут много всего. Вот, например, вход соседней D65. А это ПЗУ, его всё равно выпаивать для снятия образа. Совместим приятное с полезным.

Случайно скользнув выводом омметра по соседним дорожкам обнаруживается, что ещё несколько трасс замкнуты на общий. Нда...

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

D65
Раз уж снимать ПЗУшки - то все и сразу. Поехали.

Как лучше - каждый выбирает по себе. Я использую два способа: большой кусок олова распплавляется по всем выводам микрухи, обеспечивая равномерный нагрев всех ножек. Паяльник нужен ватт 40, с толстым жалом. Либо паяльная станция. У меня - Quick 850 ad. Станцией снять микруху быстрее, но брызки олова потом ловить нужно, чтобы они дорожки не коротнули. Так что способы чередуются в зависимости от фазы Луны.

Снять микрухи не так уж сложно. Немного сложнее не повредить при этом дорожки, но этому тоже можно научится. Сложнее потом убрать олово из отверстий. Можно иголкой и паяльником, можно сверлить - но легко соскользнуть и попортить проводящий слой внутри отверстия, можно отсосом, но не очень удобно. Можно станцией продувать, но олово назад возвращается и дырка стягивается, даже если не исчезает совсем. Я придумал простой способ: станицей на невысокой температуре (250..280 градусов) продуваю, а паяльником с тонким жалом снимаю выдуваемое олово с другой стороны. Быстро и просто. Особенно если работать вдвоём. Мне жена помогает. А можно расплавлять олово обычным паяльником и потом втыкать в отверстие деревянную зубочистку. Если плата не толстая - тоже хорошо получается.

Чтение ПЗУшек показало, что D65 сдохла. Вообще. У неё просто половина выводов внутри намертво спеклись с общим. Интересно, что это единственная импортая ПЗУшка на плате, остальные - СССРовские. И остальные читаются.

Почему могла сдохнуть микросхема ? Чаще всего из-за диких условий работы - типа повышенного питания или перегрузок (замыкания) выходов. Но эта микруха работает на внутреннюю часть схемы, значит перегрузка выводов вроде как исключена. Особенно если выяснится, что остальная часть схемы исправна. Но второй вариант предполагает мощный бросок питания, тогда бы сдохло много чего, помимо этой микросхемы. Плохо... На сисплате почти сотня кристалов, все менять ? С другой стороны - другие ПЗУшки прочитались... Значит если и сдохло, то не всё. Попробуем ковыряться дальше. Запаиваем ПЗУшки, D65 пока не ставим - нет чистого кристала. Прошивка есть, но из другой платы, волжской, а у них есть отличия от московских, может быть и в этом прошивке тоже.

С другой стороны - D65 отвечает за генерацию видеосигнала в графрежиме, на текстовые вроде не влияет. Судя по схеме. Попробуем её пока вообще не ставить.

D87
Хи! Сигнал на выходе D88 стал более логичным. А развёртки всё нет. Но есть ещё D87. А на ней та же проблема: синхро на 11-й лапке есть, а сигналы на входах/выходах нелогичные. Причем не на одном выходе, а на нескольких. Опять омметр, но замыканий не видно.

На входе сигнал переменный, а на выходе - нет. Ну может в тот момент, когда приходит синхро, сигнал на входе всегда один и тот же ? Проверим.

Проверка жестокая, но, в данном случае, допустимая. Просто замыкаем (информативнее - через миллиамперметр) вход на общий или на питание. Жестокая - потому что это перегрузка предыдущего выхода, который управляет данным входом, но кратковременно (ну за треть секунды можно же засечь изменения в работе схемы?) - поэтому не смертельно.

На выходе D87 единичка ? Значит вход цепляем на ноль. Сигнал выхода не изменился ? А если теперь выход D87 на ноль ? Ток около 10 ма. Это D87 пытается выдать единичку. Если бы следующий за ней вход был пробит (или странным образом притягивался бы к питанию при вклюнии схемы) на единичку, ток бы зашкалил за сотни ма, иначе D87 могла бы управлять таким входом.

Значит, выдираем D87. Ставим новую. Опа !...

D90
... Развёртка появилась ! Яркость на максимум...... Но, кроме бэкфона, на мониторе ничего нет. Так и есть: D86 на выходах имеет нули. Это выходной буфер видеосигнала. Интересно, но и на входах у него тоже что-то не густо. Сам помер ? Буферная схема имеет право сдохнуть. Выпаиваем ?

Нет. Потому что есть ещё один симпотом, и от него никуда не денешся - на синхровходе 1 у D86 нет пульсаций. Проверим заодно и вход сброса - там всё в порядке. Откуда синхро идёт на D86 ? А оно как раз идёт с кварцевого генератора, но его уже проверяли. А, вот тут ещё примостилась пара элементов D90.1, D90.2. Логической функции они не выполняют, повторяя сигнал, но, возможно, их задача - просто линия задержки. Чтобы очередное состояние выдеовыходов защёлкивалось чуть позднее, чем успеют сработать остальные элементы пиксель-генератора.

Так что с сигналом на D90 ? На входе есть, на выходе - нет. Меняем ? Меняем!

D74

Картинка есть !

Только косая. Надпись "агат" сверху не полностью, больше напомниает "гат" или что-то такое, но ещё интереснее: четыре курсора мигают одновременно. Курсор у Агата програмный. Даже в аппаратном текстовом режиме. Просто подчерк чередуется с текущим символом. Как над машиной не издевайся, но выводить одной командой подчерк в четыре ячейки видеопамяти одновременно не получится. Адрес-то на адресных входах микросхем памяти конкретный. Пусть неправильный, но конкретный.

А вот видеоконтроллер может читать данные четырёх разных позиций из одной и той же ячейки.

Заменяем D6 - это ПЗУ системного монитора - на специально подготовленное, диагностическое. Там примитивная прога, которая ничего не читает из памяти, а только забивает видеопамять специальной последовательностью символов, по которой можно легко ловить ошибки адресации.

Т.е. в случае практически любой ошибки в адресе картинка будет отличаться от эталонной. А чтобы мозги не сильно загружать, эталонную картинку наблюдаем, заменив файл ПЗУ сисмона в эмуляторе, на PC.

Что же мы видим ? Каждая третья и четвёртая строка повторяет первую и вторую. Но этого мало: каждая третья и четвертая строка в правой половине изображения странно мерцает. Не Flash-аттрибут, а какое-то хаотическое моргание, среди которого, как в тумане, видны нужные символы. И это ещё не всё: каждые 16 символов в левой половине всех строк повторяются. Вот отсюда было и четыре курсора: два по вертикали, два по горизонту.

Повтор пар строк - признак ошибки адресной шины. В агате два ряда микросхем памяти. Четные адреса обслуживает одна половина, нечётные - другая. В видеостроке 64 байта, в двух строках - 128, но, с учётом чередования микросхем, это 64 адреса. Итого врёт линия A6. Микросхемы памяти имеют мультиплексированный вход адреса, значит если коротнуть лапку на "землю" или питание, внесём ошибку и в старший разряд адреса. Но видеостраница - 2 кб, к тому же сейчас мы в самом начале ОЗУ, так что большинство старших разрядов и так нули.

Проверяем, убеждаемся в правильности расчёта адреса. Аналогично проверяем повтор в группах по 16 знаков: это A3.

За младшие разряды адресной шины видеопроцессора отвечает, например, D74. Ну и коммутаторы шин: D25..D28. Их проверить легко: коротнуть последовательно A3 у микросхем памяти, затем у выходов коммутаторов, затем у входов коммутаторов, затем на входе D74. Таким перебором быстро выяснилось, что D74 держит на выходе ноль. Меняем !

Замыкание дорожек
В группах-16 повторы прекратились. И это хорошо. А в группах пар строк - нет. А ведь этот адрес тоже проходит через D74... Кстати, а как он проходит ? По какой лапке ?

Опять короткие замыкания на общий, линии A0, A1... реакция правильная - картика портится как положено. А вот с A7 и A6 какая-то фигня. Они вроде как влияют, но на всё сразу. Не только свой адресный бит, но и какой-то ещё, пососедству.... Какой ? Опс ! Да они ОДИНАКОГО влияют на картинку.

Выключаем питание, выдёргиваем разъёмы, осмотр платы - так и есть - кусочек олова залетел между дорожек, когда выпаивались ПЗУ. И даже слегка приплавился к ним. Удаляем его - картинка отличная !

Меняем D6 на родной сисмон - работает ! Сейчас воткнём контроллер дисковода, загрузим Бейсик... Да, щас ! Тёмный экран. Иногда текстовый мусор, иногда - тёмный.

А, точно, забыли D65. Она, оказывает, не только в кодировании заморочек эпловской графики участвует, но и в чисто агатовских графрежимах. Программируем, запаиваем. Проверяем графрежимы из сисмона. Есть. А ИКП всё равно не грузится. Даже близко. Даже на Enter не реагирует.

Как мне помнится, начальную картинку с дискетками он загружает с дискеты, а не рисует сам. И грузится он довольно долго, значит дорожки с картинкой читает. Значит картинка где-то в памяти. Можно даже посмотреть в эмуляторе - где именно. Но переключая видеорежим - вместо картинки - мусор. Причем "чистый", будто в микросхемы после включения питания вообще никаких данных не записывали. В чём дело ?

Кстати, а как себя чувствует слово состояния памяти, селектор банков памяти ? C100.C17F ? А фигня тут какая-то. Должно быть равномерное увеличение - все банки подряд подключены к адресному пространству - так их сисмон инициализирует, а на самом деле - фигня какая-то. То вроде как банк B, то банк A на всех адресах.

D22
Под подозрение сразу попадает ряд микрух. Регистр банков - микросхема D21 - быстрое статическое ОЗУ. Вокруг него формирователь сигналов управления D21 (несколько простых элементов), формирователь-коммутатор данных D11, формирователь адреса D16, формирователь-коммутатор выходного кода (для программного чтения регистра) D22.

Во первых, вспоминаем, что диагностическое ПЗУ работает. Оно использует нулевую страницу видео, это нулевые старшие адреса всего и вся, а значит, если бы проц писал на самом деле в банк A или B - картинки бы на экране не было.

Пробуем переключать участок адресов 1 - он не используется сисмоном, подключаем на него разные банки памяти. Участок занимает адреса 2000.3FFF, записываем туда какую-нибудь цифру, переключаем банк, читаем цифру. Интересно, похоже, можно подключить только банки 0 и 1. Т.е. реально на адресную шину попадает только младший бит номера банка, остальные - константы. С другой стороны, из регистра читается номер банка A или B. Странно ? Вот и я так подумал. Поменял микруху регистра - та же фигня. Значит точно не она.

Попробуем сменить D22. Проверять что либо замыканиями бесполезно - он выдаёт сигналы на шину данных - проц даже к клавиатуре обратится не сможет, если начать тут безобразничать. Нельзя также влиять и на его входы - они напрямую связаны со старшими адресами памяти и если их переключить, сисмон не сможет даже выводить курсор в видеоозу. Значит просто меняем.

И, кстати, это помогло....

Опять замыкание между дорожками, но уже заводское
Данные из регистра банков читаются правильно. Но, чтобы уж наверняка, запускаем не ИКП, а тест Лисина - официальный тест памяти. Кстати, ИКП продолжает, точно также как и раньше, не работать.

Тест Лисина вроде как крутится, что-то находит, ... но интересно, что ему кажется, будто есть ошибки управления.

Лезем в мануал теста, разбираемся, как именно выявляется этот тип ошибок (номер 64, кажется). Пробуем смоделировать эту ситуацию в сисмоне.

Хм. Интересно. Похоже в первое адресное окно можно подключить теперь любой банк, но он же будет подключен в третье адресное окно (6000.7FFF).

С проца не попадают старшие биты в транслятор банка ? А как же он тогда обращается и к клавиатуре (которая сидит на C00x) и в младшую видеостраницу (которая, наоборот - на 0xxx) ?

Не работает буфер-коммутатор адресов D11 ? Проверить сложно, все действия кратковременные, входы прямо на магистрали. Меняем.

А вот шиш! Глюк остался.

Ну а сигналы-то на него попадают с адресной ? Да, дорожки звонятся... Друг с другом !!! От проца A14 и A15 приходят замкнутыми.

А дорожки эти длинные и идут много куда. Но мне повезло. Через пару минут, между слотами, заводской деффект. Его пытались перерезать, но мааааленький волосок остался и, видно, замкнулся вновь.

Итого - один симптом, две неисправности. Так тоже бывает.

RAM
Тест Лисина пошел. Бейсик грузится. Но в тесте кое какие микрухи глючат. Шесть микрух сразу, но все с одной стороны - на нечётных адресах. Может их выходной буфер глючит ? А может, наоборот, не отключается буфер чётных адресов и мешает нечётным ?

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

Ставим на панельку, тест. Странно, те же ошибки. Причем почему-то всегда в 8-м, реже 9-м, банке. Ошибки похожи на случайные, но всегда в конце страниц (xxFx) и всегда при записи контрольных чисел вроде FF, FE.. Причем иногда читается сразу 80 - т.е. ошибка почти во всех битах. И только на нечётных адресах. На некоторых проходах валятся кучами, а на других - ни одной. О чём это говорит ? Каждая микросхема отвечает за свой бит по конкретному адресу, следовательно, чтобы была ошибка в нескольких битах, нужно, чтобы у нескольких микросхем был отказ по одному и тому же адресу.

Номер банка - это, фактически, лишь комбинация старших адресных бит, поступающих на микросхемы. Следовательно, ошибки у всех микросхем, происходящие в одном и том же банке (т.е. - по одним и тем же адресам) - тоже событие маловероятное.

Шины данных и адреса у Агата не мультиплексированы. Мультиплексируется только младшая и старшая часть адреса и только для микросхем ОЗУ - у них такая схемотехника.

Откуда тогда такая странная зависимость? Может, это просто броски по питанию, но где ? Агат не обвешан конденсаторами, но у девятки вокруг микросхем памяти кондёров всё же много. Все разом вряд ли сдохли.

Ну ладно, меняем микруху. Нет, то есть сначала не меняем, а для чистоты эксперимента ставим старую во впаянную панельку. Так, результаты те же. Теперь ставим другую... Вроде также. А третью ? А вот тут интересно: вроде как ошибки по этому биту уменьшились. Это интересно. Меняем ещё на одну (из обломков спектрума снято 8 микросхем - есть с чем экспериментировать). А вот тут ошибок стало явно меньше. Значит, возможно, глюк с ошибками в разных битах и глюк с ошибками в одном бите имеют разную природу ? И передо мной опять совпадение ?

Итак, закупаемся новой памятью и устраиваем глобальное тестирование. Десять новых микрух (ну не совсем новых - на них тот же 92-й год, только лапки не паяные) и восемь спектрумовских. Итого: из 8 спектрумовских микрух одна совсем мёртвая (даже сисмон не стартует), одна глючит как агатовская, другая глючит, но чуть меньше, ещё одна почти не глюкает (за полчаса теста одна-две ошибки), ещё у четырех ошибок дождаться не удалось (может мало ждал ?). Т.е. явно заметно улучшение ситуации в зависимости от экземпляра микросхемы.

Десяток новых РУшек тоже имеет отказы. Три из десяти бракуем.

Пробуем заменить наиболее часто глючащие хорошими из новых. Результат: одиночные сбои бит прекратились полностью.

Не решённая загадка

Но остались групповые. Т.е. тест записывает, например, число 0xFE, а читается 0x80. Интересно, что сбои на 90% происходят при подключении 8-го банка памяти и только в конце страниц - т.е. младшие восемь бит адреса - единицы.

Попытка воспроизвести ситуацию в сисмоне (т.е. явно записать в ячейку число и прочитать не то, что записано, однажды увенчалась успехом (после множества попыток). Занятное наблюдение: после многократных попыток прочитать ячейку возвращалось одно и то же неверное значение. Но при повторной записи - ошибка пропала: что пишем то и читаем.

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

Почему я так думаю ? Тест Лисина больше всего ошибок (а после смены микросхем памяти - вообще все ошибки) обнаруживает в режиме бегущего бита ("<01>"). При записи 0xFE считывается 0x80. 0x80 - судя по документации на тест - записывается как раз перед записью 0xFE. Т.е. тест просто считывает ПРЕДЫДУЩЕЕ значение ячейки: её значение не меняется при записи. Значит - это либо ошибка адреса либо ошибка генерации сигнала "запись".

Вспомним, что ошибки сыпятся, в основном, на определенных адресах, характерных наличием большого количества "1". Изучив принципиальную схему, обнаружим ещё одно занятное совпадение: микросхемы памяти имеют 8 бит адресной шины, с мультиплексированием по сигналам !RAS и !CAS. Причем по сигналу !CAS на эту шину поступают как раз младшие биты адреса (A1..A7) и A16М - старший разряд выбора банка. Тот, который тоже == 1 (адрес банка - 4 бита: A13М..A16М, 8-й банк - 0001).

В то же время, перед !CAS, идёт сигнал !RAS, в котором передаются разряды A8..A11, A120, A13М..A15М. Тест Лисина подключает тестируемый банк к адресам 0x2000..0x3FFF, значит по !RAS почти все разряды будут = 0. На самом деле глюки ловятся, например, по адресам 0x26ff, 0x27ff, 0x2bff, 0x28ff, 0x29ff, 0x2cff, 0x2eff.... На 0x3xxx я их не замечал. Изредка бывают глюки в банке 9. Т.е. можно сказать, что по !RAS выстраивается примерно такая цепочка бит адреса (от старшего к младшему): 00z0 0hhh. Здесь z - почти всегда 0 (для банка 9 становится 1), hhh - почти всегда единицы (точнее: хотя бы один-два из этих разряда - единица).

Т.е. сбой происходит при резкой смене почти всех выходных магистралей адреса с нуля на единицу. Но в то же время, только по !RAS младшие разряды всё таки должны быть равны единице.

Что это может быть ?

Я предположил сбой по питанию. Резкий переход уровней в группе шин вызывает бросок, который влияет.. на что ? Да на кучу разных компонент он может влиять. Почему не влиял на заводском тестировании ? А сколь глубоким было тестирование ? Бейсик и у меня уже грузится...

-- сбой по питанию -> отказ какого-то из выходных каскадов мультиплексера адреса: например, он не успевает перевести старшую !CAS-часть шины из 0 в 1.

-- сбой по питанию -> ошибка генерации сигнала !W.

Не забываем и про то, что ошибка возникает только при записи числа 0xFE. Тоже почти все единицы. Остальные тесты проходят нормально. Перегрузка выходных буферов шин адреса и данных ? D4, 17, 18. Там 580ва86 стоят.

Интересно: на принципиальной схеме питание D4 (буфер шины данных) подаётся через дроссель, который зачёркнут. На реальных платах его питание сделано по разному. В частности, на подопытной, дорожки питания отрезаны и питание подводится отдельными толстыми проводами прямо от силового разъёма. Она - напомню - московская. Есть ещё загорская - у неё также. А ещё есть волжская - у неё D4 питается штатными - и не очень толстыми, и не сильно прямыми - дорожками.

Гадать можно долго, проще проверить: пять свежих импортных конденсаторов по 1000 мкф в следующих точках: 1) параллельно буферу шины данных, 2) буферам шины адреса, 3) поблизости от D14 - там все формирователи служебных сигналов шины, 4) на шины питания RAM, где уже стоит линейка керамики, 5) рядом с коммутаторами адресов и микросхемой памяти регистров банков.

Думаете - помогло ? Неа :( Те же ошибки, может даже в чуть бОльшем количестве.

Вообще, ошибки редкие: они возникают только по определённым адресам определённого банка при записи определённого значения. А возможно это зависит и ещё от каких-то причин. Хотя, возможно, исходная проблема приводит к возникновению других ситуаций, которые тест не выявляет.

Закидываем плату на шкаф, возможно, в дальнейшем придёт какая нибудь ещё идея. Или мимо меня будет пробегать многоканальный цифровой анализатор и я его приторможу до решения загадки.

Резюме
Почему я описал именно этот случай ? Он мне интересен. Так и не стало ясно: почему столько отказов в разных местах платы ? Может быть предыдущий ремонтник регулярно ронял отвёртку на плату в разных местах ? Или вместо пяти вольт подавал шесть ? Ведь отказ любой из микрух привёл бы машину в состояние полной неработоспособности, и, следовательно, юзеры бы к ней уже не подходили. Питание было выключено, почему продолжалась деградация ? Или микрухи могут дохнуть даже просто от хранения ?

Ну и еще, можно писать мне в телеграмм, так будет быстрее: https://t.me/electroscatnes

Купил на Авито (с доставкой из Нижнего Новгорода) АГАТ-7 ЛЭМЗ 1987. Хотел именно такой, на которых мы в школе 716 работали в 90-92 годах.

Из хорошего - запускается, есть ЧБ видео сигнал, крутится дисковод.

Из плохого - клавиатура не работает. Лампочки регистра переключаются, УПР-СБР работает. При нажатии на клавиши выскакивают произвольные символы. Что-то типа ЪЪЪ/?ЪЪ?. Сама клавиатура странная - в железном корпусе. Никогда таких не видел.

Кто-нибудь по описанию проблемы может сказать в чем дело? 
Может ли кто-нибудь в Москве мне помочь и одолжить на недельку рабочую клавиатуру, что бы выяснить это материнка или клавиатура неисправны?

Кто-нибудь может мне помочь и записать диск с ИКП 140Кб, что бы дисковод проверить. Какую дискету надо на Авито покупать?  на 360 кб?

Заранее спасибо.

Я в агатах новичок, поэтому будут совсем глупые вопросы, прошу не ругаться :)

Итак, в данный момент имеется только основной блок (с генплатой и нерабочим дисководом и куча ячеек) и ч/б монитор. Клавиатура где-то была, но найти не могу. Родной блок питания отсутствует.

Имею следующие вопросы:
1) для запуска и работы напряжение минус 12 вольт не нужно? Вроде как используется для магнитофона.
2) запуск без клавиатуры возможен?

Питание берется с БП АТХ.

Ситуация следующая. В генплату не вставлены никакие ячейки. При подаче питания (+5, +12) на мониторе появляется некий узор и ничего более не происходит.

Если "потыкать" в контакт разъема клавиатуры, то появляется примерно следующее.

Насколько это все плохо?
Что можно сделать без клавиатуры и дисковода с точки зрения проверки?
(Имеется куча дисководов 3,5, и наверное парочка 5,25).

Ситуация такая, блок после нескольких часов работы начал явно нестабильно выдавать +12 (что замечено), определили по явно нестабильным оборотам вращения шпинделя 5088.02. После выключения не включился.

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

После того как поработал минут 20 в Агате, снова после выключения не включился.

Далее, заменил 2 конденсатора по 47 мк по входу на один на 150 мкХ400в, заменил частично выходные фильтрующие, заменил мелких несколько. С9, в общем все что может влиять на включение и не только.. Блок начал четко запускаться, на холодную.

Но поработав с час снова после выключения не включается, правла если пощелкать выключателем питания может на 8 - 16 раз включиться.

Проверил все транзисторы и диоды, они на холодную прекрасно звонятся без утечек и прочего.

Включил под нагрузкой, то есть с Агатом, без кожуха, померял температуру радиаторов и транзисторов лазерным термометром, в итоге КТ840 греется до 46 градусов, при работе дисковода, в целом норм. Больше всего греются диоды, по 5 в, на радиаторе которые, там до 58 градусов во время работы дисковода температура поднимается.

Транзисторы в окружении КТ840 - греются не значительно, до 42 - 43 градусов.. По обратной связи 315 или 361 - в районе 36 - 38 градусов температура.

Да, и еше, поменял на всякий случай диод который в пускалке отсекает отрицательный период, на более мошьный, не возимело эффекта.

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

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

Раньше (около 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 - идёт (традиционный у меня уже тест).
Лисин тем же путём попадает на комп - несколько проходов без ошибок.

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

Сюда собрал про ремонт платы ЯБ из темы аппаратного отладчика.

1) Установка панели под D6, установка тестовой прошивки.
2) Устранение замыкания адресных линий А9-А10
3) Замена дохлых микросхем ОЗУ D38, D44, D45
4) Плата как-то подвисала, помогало постукивание по кварцу..В итоге заменил кварц BQ1.
5) Выдернул и проверил D14 - оказалась живой.
6) Увидел, что перерезана дорожка С на D47-D48. Восстановил. Как-то странно заработало ОЗУ.
7) Нашёл замыкание A14 на R/W. Сопля, однозначно ещё с завода..При монтаже D18.
8) Замена D51 - оказалась живой
9) Замена D92 - оказалась живой
10) Удаление D53, принудительная установка в режим Агат. С установленной D53 Неверное включение сигналов ПМ и /ПМ. Пока победить не удается, непонятно работает D92 - до сброса выход 13 висит в Z-состоянии, чего быть не может. Заменил на 7402 - та же фигня. Пока не понимаю.
11) Запаял выкушенный конденсатор С6 - пошёл звук, звук правильный.

ДК Что-то показывает. На выходах ОЗУ все статично. CAS-RAS-W-Din присутствуют. CAS - очень грязный. Выяснилось, что паукопаятели припаяли провод не к 3, а к 12 выводу D13. Поэтому и перерезали дорожку из п.6! Удалил провод из паука, дорожка уже была восстановлена - cas пришел в норму, озу заработало.

Видно двоение символов, строк, столбцов (по 8) и половинок экрана..Но, по крайней мере, куски картинки уже похожи на тестовую прошивку. Родной сисмон при нажатии сброса издает правильный одиночный сигнал. Похоже, процессорная часть работает и проблема где-то в ДК. Сигналы на D75 в норме. Продолжение следует..

Судя по всему, платы из заводского брака, которые сходу поднять не удалось. Обнаружено уже минимум 2 ошибки монтажа.

Теперь буду писать здесь.

Леон просил фото плат - все сделал, выкладываю. Сначала платы расширения:

Всего 22 платы.

Добавлена прошивка D65