ZEvS, спасибо, уточню, кажется действительно было FF5E (не очень это просто и быстро с 8-канальным анализатором)
А вообще сильно подозреваю, что из стека вместо необходимого адреса возврата считывается 8686h - слово состояния процессора при чтении из стека.
В общем, проверю и отпишусь.
Последний раз редактировалось Pyk; 19.04.2017 в 00:28.
Ок, я как то для проверки памяти навешивал SRAM. Если есть возможность, попробуйте - не пожалеете. В микроше для этого все предусмотрено, надо подпаять микросхему МГТФами к адресу, данным, и OE + WE, и отключить два резистора на родной плате. Если заведется, то это было точно ОЗУ, можно менять микросхемы (и поставить панельки).
Проследи дешифрацию адреса, такое ощущение, что вместо ОЗУ выбирается "пусто", как в диапазоне 8000-BFFF.Сообщение от Pyk
ZEvS,
b2m,
Совершенно верно. Понаблюдал за тем, что происходит на шине адреса: перед уходом в бесконечный цикл на шине адреса последовательно появляются значения FF5E (выборка RET), 76C1, 76C2 (выборка из стека) и затем 8686, 8687 и т.д.
Буду смотреть дешифрацию адресов ОЗУ (с адресацией ПЗУ и устройств вроде бы все в порядке).
Pyk, а ПДП у Вас работает? Есть запросы? Мусор в памяти может быть, если она не регенерируется.
- - - Добавлено - - -
После команды RET по адресу FF5E, процессор должен перейти по адресу FE82.
Запросов нет, так как, хотя контроллер ПДП уже инициализирован, но ВГ75 получил команду "preset counters" (F850: mvi m, e0h) и поэтому не запрашивает у контроллера ПДП данные. Про мусор в памяти даже речь не идет, из памяти вообще ничего не читается, на шине данных остается слово состояния процессора.
Он должен перейти по адресу FE82, который записан на вершине стека по адресу 76С1. А он переходит на адрес 8686, то есть из адресов 76C1-76C2 считались 8686 вместо FE82. То есть слово состояния процессора при чтении из стека.
Вот еще лог обращения к памяти (сигналы RAS, CAS, W/R):
http://emu80.org/temp/logs2.zip
Большого опыта в подобных делах у меня нет, но, насколько я могу судить, тут все правильно: в начале, пока выполняется код из ПЗУ, активен только RAS, причем видны пара импульсов CAS и WE - запись в стек адреса возврата при вызове CALL (запись не с начала старта Монитора, я тормозил выполнение нажатием на РУС/ЛАТ). Потом чередуются периоды обращений к адресам 8000-BFFF, когда CAS не активен, потом два цикла записи в стек при выполнении команды RST 7 по адресу C000, и периоды обращений к адресам 0038-7FFF, когда к RAS добавляется CAS. Немного смущают одиночные импульсы сигнала RAS, затрудняюсь определить их происхождение...
В общем, складывается ощущение, что сдохли все 8 штук РУ5, а их выходы просто всегда находятся в высокоимпедансном состоянии и не влияют на состояние шины данных. Хотя могу и ошибаться - я не большой специалист в этой области. Да и с чего бы это вдруг все 8 штук вышли из строя? (Хотя предыстория этой Микроши мне неизвестна, и что привело ее к выходу из строя - тоже). Как и почему они обычно дохнут? Это типичный симптом?
Да, действительно похоже на то.
В моем случае, в одной из моих сдохло 6 из 16ти... Просто от времени.
И в первый раз встречаю 8 РУ5ых, вместо 16 РУ6ых. А могло быть так, что кто-то до Вас пытался заставить работать микрошу на РУ5ых и ничего не вышло? А Вы, теперь голову ломаете, почему не работает, а оно и не должно?
Не похоже. Разводка под дополнительную линию на плате присутствует, отверстия под еще 8 корпусов на плате чистые, без следов пайки. Да и некому было - насколько я знаю историю этого экземпляра, она работала в школе, потом Микроши заменили Корветами, и она пылилась где-то там, пока через моего знакомого лет 10 назад не попала ко мне...
Нужны какие-то особые меры предосторожности при пайке РУ5?
Вроде нет. Микросхемы - как микросхемы. Многие ставят панельки, заметно, потом удобнее менять и тасовать микросхемы.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием