А в тест смк добавить диагностику этой проблемы возможно?
Разработчик не смог понять замысел с RPLY, прокомментировал так:
При таком раскладе проще те самые адреса запретить в режиме 20 для памяти, хотя тогда не совсем понятно, как в оригинальном СМК это не конфликтует. Просто задерживать RPLY толку не видно, все равно сначала выставляются нужные данные на шину, потому уже RPLY в конце, а процессор по RPLY читает уже то, что выставлено.
На вопрос, что же делать, он ответил:
Адреса блокировать в режиме 20, если там свободные макроячейки еще есть для дополнительной логики. Но дело в том, что мне вообще неясно, как там могут быть конфликты на пространстве внешних устройств и почему это вообще кто-то допустил. Но если конфликт реально есть, то не факт, что все ограничится вот этим набором адресов, это просто именно что при прерывании к ним обращение идет. Бодание двух стройств на шине - это не есть хорошо, даже если ничего не сгорит при этом. В оригинальной шине QBUS все драйверы с открытым коллектором и на данных вроде тоже, так что ничего не может сгореть в принципе, но в СМК это не так.
Я попробую придумать, как там поделикатенее блокировать адреса, но впорос в том, какие на самом деле блокировать кроме тех, что уже себя проявили.





Ответить с цитированием