Пока для ВМ3 вряд ли будут новые тесты - надо сначала закончить с ВМ2.
Тест VM2DB на ВМ3
Код:.RUN VM2DB
>
@ 170000
@
@M
HALT INSTRUCTION
@R6/000774
@R7/170000
@RS/000020
@774/001242
00000776/000340
@R701400
@RS0340
@P
@ 170000
---------- Post added at 19:28 ---------- Previous post was at 19:19 ----------
Alex_K, Можно в редакторе найти отличия 134 и 377 и дизассемблировать только отличия. Я думаю там только добавлен автозагрузчик DW и тест ВМ4.
...
С ВМ3 закончено?
А вот это уже интересно. Похоже 1801ВМ3 пробует читать код нового процесса, даже не обрабатывая новых прерываний. Ну и адрес останова не PC+2, а PC.
MiX, для выхода в RT-11 надо было установить R7. В команде забыли ввести слэш "/". Т.е. надо было R7/.
---------- Post added at 19:33 ---------- Previous post was at 19:29 ----------
Увы, там же двоичный код. Различаться уже могут смещения при относительной адресации. Так что только дизассемблировать и смотреть.
Наверное да. Да и Patron отлаживает 1801ВМ2 в своем эмуляторе.
Еще раз огромное спасибо.
Тест VM2MEM.SAV - проверяет распределение памяти в пространстве HALT платы МС1201.02.
При запуске в эмуляторе результат такой:
Код:.RU VM2MEM
VM2MEM - v1.0
1801VM2 HALT mode Memory Map
... 000000-137776
ROM 140000-157776
RAM 160000-177776
.
Похоже - есть продвижение в понимании механизмов МЕГА-глюка процессора 1801ВМ2.
Ранее было замечено, что длина последовательности одинаковых команд типа MOV (PC),R0 влияет на вероятность возникновения Trap_to_04, при появлении команды NOP в конце последовательности.
Наиболее логичное ( на мой взгляд ) объяснение следующее.
Поскольку любая команда с адресаций (PC) выполняется процессором 1801ВМ2 как последовательность команд cmd (PC)+,arg | BR .-2., то на время выполнения этой виртуальной последовательности команд прерывания запрещаются.
Когда глюк активен - запрет прерываний продолжает действовать на момент первого ( глючного ) исполнения следующей команды и если это такая же "глюкогенная" команда - на время выполнения всей последоватености глюкогенных команд прерывания запрещаются.
Когда же начинается глючное выполнение команды NOP - прерывания разрешаются и чем дольше они были до этого запрещены - тем выше вероятность, что в этот момент произойдёт прерывание.
А так как в сдвиговом регистре из кода команды NOP извлекаются не только четыре бита признаков, но и пятый бит флага S/C - в буфере от кода команды NOP ( 0240 ) отстаётся только число 5, которое и заменяет собой передаваемый по шине вектор.
Т.е. на самом деле происходит Trap_to_05, но поскольку состояние линии A0 в циклах чтения игнорируется - происходит Trap_to_04.
...
Для проверки гипотезы о запрете прерываний глючной командой написан тест VM2T20.SAV, который полезно запустить и на плате МС1201.02 ( где глюк не активен ), и на УКНЦ ( где глюк активен ).
При запуске в эмуляторе результат такой:
Код:.RU VM2T20
1801VM2 MegaBUG test #20
01034 BiS #100, @#TTPS
01042 Mov (PC), R0
01044 >>> Interrupt <<< 064
01044 Mov (PC), R0
01046 Tst R0
01050 BiC #100, @#TTPS
01076 BiS #100, @#TTPS
01104 Mov (PC), R0
01106 >>> Interrupt <<< 064
01106 Mov (PC), R0
01110 BiC #100, @#TTPS
Program completed.
.
Прохождение теста такое же как в эмуляторе.
---------- Post added at 19:15 ---------- Previous post was at 18:56 ----------
Alex_K, Раз уж 134 прошивка дезассемблирована то можешь выковырять оттуда загрузчик DW. Мысль какая, этот загрузчик можно прикрутить вторым ПЗУ в эмулятор.
Тогда на команду В $DW пойдёт загрузка с жёсткого диска.
Когда глюк не активируется - прерывания проходят как надо, но когда глюк активен - пока непонятно, что происходит..
А как выглядит на УКНЦ запуск тестов VM2T18.SAV и VM2T19.SAV ( в ответ на вопросы нажимать ВВОД ) ?
---------- Post added at 19:39 ---------- Previous post was at 19:32 ----------
На команду В $DW загрузка с DW не пойдёт, но если код автозагрузки с DW посадить по адресу 0173000 - ДВК-2 будет автоматически грузиться с DW при SEL = 140006