Ищу схему/совет по ремонту

[Lion17]

процессор по ходу работает...
больше всего это похоже на нерабочее ПЗУ, процессор все время считывает код FF - RST #38, забивает через стек кодом 0039 (адрес воврата) всю память - отсюда на экране матрас. Но при этом в каждой команде должен быть сигнал ~WR, так как все время пишется в память адрес возврата.
Кстати по цвету и рисунку полос можно определить так это или не так.
Смотрим по экрану: идет одна полоса 0 в пикселах и 0 в атрибутах - это черная полоса шириной 8 пикселов, вторая полоса 00111001 в пикселах,
0 0 111 001 в атрибутах (синим по белому) - это 2 пиксела белых, 3 синих, опять 2 белых и 1 синий.

[SMT]

Итак, процессор шуршит только сигналами ~RD и ~MREQ.
Сигналы ~WR и ~IORQ неактивны (высокий уровень). К тому же, из-за постоянно высокого уровня на ~IORQ наблюдается постоянный низкий уровень на линии ~INT (если я правильно проследил зависимости).
Картинка на экране чаще всего состоит из вертикальных полос (редко - с разными вкраплениями и шумом), а не из прямоугольников, как на фотографиях в теме про "Байт". Нажатие Reset на картинку не влияет совсем.
Означает ли это, что процессор умер?

скорее всего не умер. IORQ и WR появляются по определенным командам из ПЗУ. а если постоянно активен INT, ничего хорошего не выйдет. попробуй (по схеме или дорожкам) отследить, как он формируется и почему активен. когда победишь INT, попробуй вытащить ПЗУ (см. тему про байт)

[Alchemist]

скорее всего не умер. IORQ и WR появляются по определенным командам из ПЗУ. а если постоянно активен INT, ничего хорошего не выйдет. попробуй (по схеме или дорожкам) отследить, как он формируется и почему активен. когда победишь INT, попробуй вытащить ПЗУ (см. тему про байт)

Отрезал питание от ПЗУ (т.к. оно впаяно в плату). На экране появились знакомые полоски. INT остается низким, потому что его выдает триггер, который сбрасывается (точнее, устанавливается в 1), когда процессор подтверждает прерывание сигналами M1 и IORQ.
Буду пробовать менять ПЗУ.

[jtn]

Отрезал питание от ПЗУ (т.к. оно впаяно в плату). На экране появились знакомые полоски. INT остается низким, потому что его выдает триггер, который сбрасывается (точнее, устанавливается в 1), когда процессор подтверждает прерывание сигналами M1 и IORQ.
Буду пробовать менять ПЗУ.

на экране #0039 (синебелые полоски потом черный атрибут)?
если да, то пзу не причем.
1. смотри почему int висит в 0.
2. не надо выпаивать м/сх, чтобы плату не повредить. лучше выкусить кусачками или в случае пзу заблокировать его выбор (отрезать дорожку к 20 или 22 ноге и подать туда 5v)

[Alchemist]

на экране #0039 (синебелые полоски потом черный атрибут)?
если да, то пзу не причем.

Экран черно-белый, поэтому непонятно
А что это еще может быть кроме ПЗУ?

1. смотри почему int висит в 0.

Потому что его держит триггер, который сбрасывается при обработке прерывания (при выборке вектора прерывания). Так как прерывания после RESET запрещены, то и INT не сбрасывается.

2. не надо выпаивать м/сх, чтобы плату не повредить. лучше выкусить кусачками или в случае пзу заблокировать его выбор (отрезать дорожку к 20 или 22 ноге и подать туда 5v)

ПЗУ (РФ8) выкусил, поставил 2x28c64 (EEPROM). На экране мусор

[Alchemist]

на экране #0039 (синебелые полоски потом черный атрибут)?
если да, то пзу не причем.

0039 означает, что все время выбирается RST 38, да? А почему же тогда в этом случае ПЗУ не причем, раз все узлы без него работают?

[Advertiser]

[Lion17]

по-моему именно пзу виновато...
хотя есть другие варианты, например сигналы адреса не все доходят до пзу и поэтому не те инструкции считываются

[Lion17]

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

[SMT]

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

наверное, тут то, о чём писал nemo в письмах. идея в том, что триггер устанавливается по кадровому сигналу (т.е. от развёртки), а сбрасывается по комбинации M1+MREQ. то есть при выборке первой команды, длительность подбирать не надо

ПЗУ (РФ8) выкусил, поставил 2x28c64

зря плату попортил. вдруг ПЗУ не при чём...
а попробуй подать на INT +5v. спектрум сбрасывается без INT, только клава не работает

[Lion17]

наверное, тут то, о чём писал nemo в письмах. идея в том, что триггер устанавливается по кадровому сигналу (т.е. от развёртки), а сбрасывается по комбинации M1+MREQ. то есть при выборке первой команды, длительность подбирать не надо

Не совсем так, при подтверждении прерывания z80 выдает M1+IORQ