Проблема с незагрузкой RSX11M немного локализовалась.
Оказалось, что возникает она в ситуации, когда программа обращается к PSW по адресу 177777. Как следует из описания процессора, при этом сигналы на внешней шине не формируются, вся обработка происходит внутри процессора. И обычно так оно и бывает, особенно после недавнего патча от VSLAV. Но иногда, вместо того чтобы тихо обработать команду внутри себя, процессор генерирует внешний цикл обращения к странице ввода-вывода с адресом 777776.
Вот осциллограмма, поясняющая ситуацию: https://disk.yandex.ru/i/mgKlqKVvWC92tg
Это кусок начального загрузчика RSX-11M (одна из частей SAV.TSK), выполняющий раннюю инициализацию устройств в процессе загрузки системы.
По адресу 110600-110602 расположена команда CLRB @#177776. После ее выборки процессор почему-то поднимает сигнал обращения к странице ввода вывода (wbm_ios, последняя строка), а затем и строб wbm_stb (предпоследняя строка). Подождав для приличия, процессор констатирует таймаут шины и уходит выбирать вектор 4. Дальше уже неинтересно, ибо этого быть не должно.
Конечно, прежде чем пытаться обратиться к первоисточнику VSLAV, надо как-то локализовать условия, при которых проблема проявляется. Надо как-то вытащить из процессора в сигналтап как минимум PSW и регистр SR0, чтобы понять текущий режим работы процессора. И найти в исходниках SAV этот фрагмент. Но в любом случае, какой бы режим не был в данный момент активен, ситуация эта ненормальная. Раз процессор поднял сигнал IOS, значит он целенаправленно лезет на страницу ввода-вывода. А на этой странице по адресу 177776 ничего нет и быть не может, ибо PSW через шину недоступно. Следовательно, по этому адресу процессор НИКОГДА штатно не должен лезть через внешнюю шину.
Буду думать дальше. Видимо, пора лезть в схему самого процессора и искать, где там лежат внутренние регистры.
Ответить с цитированием