Просмотр полной версии : Особенности процессоров и устройств архитектуры PDP-11. Тесты. Диагностика.
Страницы :
1
2
3
4
[
5]
6
7
8
9
10
Тест Эл.85Эл.85 ( и наверняка Pro-350 ) получают высший балл за оригинальность, потому что и команда DIV R2,R0, и команда DIV R2,R1 - помещают результат деления в R0, а остаток в R1.
Не удивлюсь, если и значение старшего слова делимого команда DIV R2,R1 там берёт не из R1, а из R0.
Друзья, не забываем запускать тест TSTVM2 v0.3a (http://zx-pk.ru/showpost.php?p=749151&postcount=981) на ВМ3 и других машинах. Интересует последняя страница теста, где тест команды MARK.
На 11/83 все ок кроме тех же:
+OMANDA DELENIQ (^ASTI^NYJ TEST):
DIV (even) - ERROR: 0x9E4A / 0xD5C6
DIV (odd) - ERROR: 0x43D5 / 0xE035
Кстати, если
SWAB - OK
Учитывает флаги PSW, этот тест должен давать сбой на 11/20.
Учитывает флаги PSW, этот тест должен давать сбой на 11/20.
Разумеется, учитывает. Даже MARK учитывает флаги на всякий случай.
Разумеется, учитывает. Даже MARK учитывает флаги на всякий случай.
Ну 11/20 единственный не трогает V при SWAB.
---------- Post added at 19:30 ---------- Previous post was at 19:28 ----------
Кстати тест все-таки учитывает не все CLx/SEx команды :)
CLx вернее все за счет отдельного тестирования команды NOP, а вот SEx как я понимаю не проверяет команду с кодом 260.
не забываем запускать тест TSTVM2 v0.3a (http://zx-pk.ru/showpost.php?p=749151&postcount=981) на ВМ3 и других машинах.Не забываем также запускать тесты TDIV1.SAV и TDIV2.SAV из пакета TDIV.zip (http://emulator.pdp-11.org.ru/misc/TDIV.zip) на процессоре 1801ВМ2.
Друзья, не забываем запускать тест TSTVM2 v0.3a (http://zx-pk.ru/showpost.php?p=749151&postcount=981) на ВМ3 и других машинах. Интересует последняя страница теста, где тест команды MARK.А как тест проходит на ВМ2? Может мне через КЦГД прогнать, там какое то окно есть для запуска программ.
Не забываем также запускать тесты TDIV1.SAV и TDIV2.SAV из пакета TDIV.zip (http://emulator.pdp-11.org.ru/misc/TDIV.zip) на процессоре 1801ВМ2.
Это можно запускать и в эмулях УКНЦ, ибо они в этих командах точны.
---------- Post added at 17:35 ---------- Previous post was at 17:34 ----------
А как тест проходит на ВМ2? Может мне через КЦГД прогнать, там какое то окно есть для запуска программ.
Пишет ОК, разумеется)
Кстати давно была мысль написать тест который проверяет все команды и выдает талицу что команда делает с C,V,Z,N (0, 1, *, -), а также проверяет для какого результата (MUL на нечетный регистр). Вот еще идейка если кому не лень :)
Тест ВМ3
.TSTVM2
Тест процессора КР1801ВМ2 v0.3a (c) by dr.Titus
Тестирование правильности выполнения команд процессора:
Однооперандные байтовые команды:
NOP - OK
MOVB - OK
CLRB - OK
COMB - OK
INCB - OK
DECB - OK
NEGB - OK
TSTB - OK
ROLB - OK
RORB - OK
ASRB - OK
ASLB - OK
ADCB - OK
SBCB - OK
SXT - OK
Однооперандные словные команды:
MOV - OK
Next page?
CLR - OK
COM - OK
INC - OK
DEC - OK
NEG - OK
TST - OK
ROL - OK
ROR - OK
ASR - OK
ASL - OK
ADC - OK
SBC - OK
SWAB - OK
Двухоперандные байтовые команды:
CMPB - OK
BITB - OK
BICB - OK
BISB - OK
Двухоперандные словные команды (частичный тест):
ADD - OK
SUB - OK
Next page?
CMP - OK
BIT - OK
BIC - OK
BIS - OK
XOR - OK
Команды работы с флагами:
CLx - OK
SEx - OK
Команды условных переходов:
Bcc - OK
Команда умножения (частичный тест):
MUL (even/even) - OK
MUL (even/odd) - OK
MUL (odd/odd) - OK
MUL (odd/even) - OK
MUL (table) - OK
Команды сдвига (частичный тест):
ASH (test 1) - ERROR: 0x47F3 / 0x47E5
ASH (test 2) - ERROR: 0xB7C3 / 0xB7F1
Next page?
ASHC (even) - ERROR: 0x69EB / 0xBF41
ASHC (odd) - ERROR: 0x32A3 / 0x1ADB
Команда деления (частичный тест):
DIV (even) - ERROR: 0x9E4A / 0x920C
DIV (odd) - ERROR: 0x43D5 / 0x281D
Специальные команды:
MARK - OK
Интересно прогнать тесты на МС-0515 бы.
И на Немиге.
Кстати тест все-таки учитывает не все CLx/SEx команды :)
CLx вернее все за счет отдельного тестирования команды NOP, а вот SEx как я понимаю не проверяет команду с кодом 260.
Почему это не проверяет? Младшие 4 бита в команде гоняются от 0 до 15, т.е. все 16 комбинаций.
Почему это не проверяет? Младшие 4 бита в команде гоняются от 0 до 15, т.е. все 16 комбинаций.
Ну значит невнимательно посомтрел :)
Тогда тест NOP лишний :)
---------- Post added at 21:10 ---------- Previous post was at 20:51 ----------
А "SOB Rx,.+2" проверяется? - сил нет смотреть уже :)
Интересно прогнать тесты на МС-0515 бы.
Как говорится- чем богаты... :)
http://s004.radikal.ru/i207/1410/c1/3a51a545df2c.jpg (http://www.radikal.ru)
И на Немиге. К сожалению проект заморожен.
Как говорится- чем богаты... :)
Гы... юмор зачтен))) Если че, в этом эмуле тот же ВМ2, так что все будет идентично УКНЦ)
---------- Post added at 19:24 ---------- Previous post was at 19:23 ----------
К сожалению проект заморожен.
На настоящей Немиге, разумеется.
---------- Post added at 19:25 ---------- Previous post was at 19:24 ----------
А "SOB Rx,.+2" проверяется? - сил нет смотреть уже :)
SOB вообще пока не проверяется, ибо уж очень простая команда, косяк в ней скорее всего сделает неработоспособной систему априори.
SOB вообще пока не проверяется, ибо уж очень простая команда, косяк в ней скорее всего сделает неработоспособной систему априори.
Не факт. В родном софте от DEC (для RT-11) эта команда вообще не применяется по понятной причине (если видишь ее в исходниках - не верь глазам своим - это макрос). А кроме того вариант с ".+2" обычно никто не использует и его просто интересно посмотреть как он где работает :)
Пока пью кофе на работе, пара слов касаемо TSTVM2 и не только :)
Вместо
BIS #TTSPC$,@#$JSW
достаточно просто сделать
.ASECT
.=$JSW
.WORD TTSPC$
.PSECT
в начале программы.
Теперь пара слов на предмет CTRL/C - в примерах:
.SCCA #AREA,#FLAG ;БЛОКИРУЕМ CTRL/C
...
.TTYIN
CMP #3,R0 ;НАЖАТ CTRL/C?
...
TST FLAG ;НАЖАТ ДВОЙНОЙ CTRL/C?
BNE ... ;ДА
Насчет векторов 4/10, прямо на примере TSTVM2:
.TRPSET #AREA,#TRINT ;УСТАНАВЛИВАЕМ ОБРАБОТЧИК 4/10
...
TRINT:: MOV #42401,R5 ;ЗНАЧЕНИЕ ДЛЯ TRAP TO 4
ADC R5 ;ЕСЛИ C=1, ЭТО TRAP TO 10
...
AREA: .BLKW 2
FLAG: .BLKW
как-то так...
Ну и пара мыслей вслух... Если MFPS/MTPS заменить на TRAP 1/TRAP 2 (к примеру), тест можно будет гонять на всех машинах которые представлены на форуме (например в Э100/25 нет ни MFPS ни MTPS), а также легко адаптировать для запуска в RTEM и RSTS/E...
Ну и пара мыслей вслух... Если MFPS/MTPS заменить на TRAP 1/TRAP 2 (к примеру), тест можно будет гонять на всех машинах которые представлены на форуме (например в Э100/25 нет ни MFPS ни MTPS), а также легко адаптировать для запуска в RTEM и RSTS/E...
Что это за трапы 1 и 2?
Что это за трапы 1 и 2?
отвлекли :)
4/10 конечно
---------- Post added at 15:52 ---------- Previous post was at 15:51 ----------
Тюфу - ты - это сейчас отвлекли. Команды "TRAP 1" и "TRAP 2" :)
---------- Post added at 15:53 ---------- Previous post was at 15:52 ----------
Всмысле поставить перехватчик вектора 34 (можно через .ASECT) и отрабатывать.
Ничего не понял) Как на этих машинах с помощью трапов считывать и устанавливать регистр флагов?
Ничего не понял) Как на этих машинах с помощью трапов считывать и устанавливать регистр флагов?
Устанавливать собственно вообще можно (и нужно) SEx/CLx командами - приоритет же нам не важен (да и не сможем мы его вот так тупо изменить всегда даже в рамках RT-11). А читать - по-моему очевидно:
; MFPS R0
TRAP 0
TRAPV: CLR R0
BISB 2(SP),R0
RTI
---------- Post added at 15:59 ---------- Previous post was at 15:56 ----------
Ну или другой вариант - делать патчи на ходу как в BSTRAP от RT-11 -- это быстрее с точки зрения скорости выполнения, но муторнее в реализации.
Устанавливать собственно вообще можно (и нужно) SEx/CLx командами - приоритет же нам не важен (да и не сможем мы его вот так тупо изменить всегда даже в рамках RT-11). А читать - по-моему очевидно:
; MFPS R0
TRAP 0
TRAPV: CLR R0
BISB 2(SP),R0
RTI
А... со стека брать) Но это уже не то немного, придется все тесты переделывать) Пока что задачи такой не стоит, стоит задача сделать тест для ВМ2.
---------- Post added at 14:02 ---------- Previous post was at 14:00 ----------
Ну или другой вариант - делать патчи на ходу как в BSTRAP от RT-11 -- это быстрее с точки зрения скорости выполнения, но муторнее в реализации.
Вы напрасно оперируете такими терминами без разжевывания, как BSTRAP и т.д. Я ничего кроме процессора не знаю, и все эти системные термины от RT-11 для меня филькина грамота)
придется все тесты переделывать
Да уж, в двух-трех местах заменить MFPS к примеру на TRAP 0, а MTPS на TRAP 1 (это если надо ставить из регистра) или прямые команды - это ух какая переделка ;)
меня филькина грамота
В двух словах, пишется MFPS R0, NOP а в начале программы проверяется наличие команды MFPS и если ее нет - код заменяется на "MOVB @#177776,R0"... Такой вариант, понятно не полностью переносим и будет работать только в реальном RT-11 для невиртуальных заданий.
В архиве TDIV+.zip (http://emulator.pdp-11.org.ru/misc/TDIV+.zip) :
TDIV3.SAV - дополнительный тест деления с переполнением для процессора 1801ВМ3.
Пример работы на PDP-11/83:
.RU TDIV3
PSW[000] ; R0[100000] ; R1[000000] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000000]
PSW[000] ; R0[100000] ; R1[000001] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000001]
PSW[000] ; R0[100000] ; R1[000000] ; R2[177776] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000000]
PSW[000] ; R0[100000] ; R1[000006] ; R2[177774] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000006]
PSW[000] ; R0[100000] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[012] ; R0[100000] ; R1[000000]
PSW[000] ; R0[100000] ; R1[000000] ; R2[000002] >>> DIV R2,R0 >>>
PSW[012] ; R0[100000] ; R1[000000]
PSW[000] ; R0[100000] ; R1[000006] ; R2[000004] >>> DIV R2,R0 >>>
PSW[012] ; R0[100000] ; R1[000006]
PSW[000] ; R0[177776] ; R1[000006] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[177776] ; R1[000006]
PSW[000] ; R0[177776] ; R1[000006] ; R2[177776] >>> DIV R2,R0 >>>
PSW[002] ; R0[177776] ; R1[000006]
PSW[000] ; R0[177776] ; R1[000006] ; R2[177774] >>> DIV R2,R0 >>>
PSW[000] ; R0[077776] ; R1[177776]
PSW[000] ; R0[177776] ; R1[000006] ; R2[000001] >>> DIV R2,R0 >>>
PSW[012] ; R0[177776] ; R1[000006]
PSW[000] ; R0[177776] ; R1[000006] ; R2[000002] >>> DIV R2,R0 >>>
PSW[012] ; R0[177776] ; R1[000006]
PSW[000] ; R0[177776] ; R1[000006] ; R2[000004] >>> DIV R2,R0 >>>
PSW[010] ; R0[100002] ; R1[177776]
PSW[000] ; R0[000001] ; R1[000006] ; R2[177777] >>> DIV R2,R0 >>>
PSW[012] ; R0[000001] ; R1[000006]
PSW[000] ; R0[000001] ; R1[000006] ; R2[177776] >>> DIV R2,R0 >>>
PSW[012] ; R0[000001] ; R1[000006]
PSW[000] ; R0[000001] ; R1[000006] ; R2[177774] >>> DIV R2,R0 >>>
PSW[010] ; R0[137777] ; R1[000002]
PSW[000] ; R0[000001] ; R1[000006] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[000001] ; R1[000006]
PSW[000] ; R0[000001] ; R1[000006] ; R2[000002] >>> DIV R2,R0 >>>
PSW[002] ; R0[000001] ; R1[000006]
PSW[000] ; R0[000001] ; R1[000006] ; R2[000004] >>> DIV R2,R0 >>>
PSW[000] ; R0[040001] ; R1[000002]
.
TDIV4.SAV - дополнительный тест деления на 0 и деления нечётного регистра для Эл.85 :
.RU TDIV4
PSW[000] ; R0[177777] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[177777] ; R1[177774]
PSW[000] ; R0[000000] ; R1[177773] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[000000] ; R1[177773]
PSW[000] ; R0[000000] ; R1[000002] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[000000] ; R1[000002]
PSW[000] ; R0[000001] ; R1[000002] ; R2[000004] >>> DIV R2,R1 >>>
PSW[002] ; R0[000001] ; R1[000002]
PSW[000] ; R0[000001] ; R1[000002] ; R2[000010] >>> DIV R2,R1 >>>
PSW[000] ; R0[000001] ; R1[000002]
PSW[000] ; R0[000000] ; R1[000004] ; R2[000004] >>> DIV R2,R1 >>>
PSW[002] ; R0[000000] ; R1[000004]
.
Тест ВМ3
.RUN TDIV3
PSW[000] ; R0[100000] ; R1[000000] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000000]
PSW[000] ; R0[100000] ; R1[000001] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000001]
PSW[000] ; R0[100000] ; R1[000000] ; R2[177776] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000000]
PSW[000] ; R0[100000] ; R1[000006] ; R2[177774] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000006]
PSW[000] ; R0[100000] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000000]
PSW[000] ; R0[100000] ; R1[000000] ; R2[000002] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000000]
PSW[000] ; R0[100000] ; R1[000006] ; R2[000004] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000006]
PSW[000] ; R0[177776] ; R1[000006] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[177776] ; R1[000006]
PSW[000] ; R0[177776] ; R1[000006] ; R2[177776] >>> DIV R2,R0 >>>
PSW[002] ; R0[177776] ; R1[000006]
PSW[000] ; R0[177776] ; R1[000006] ; R2[177774] >>> DIV R2,R0 >>>
PSW[000] ; R0[077776] ; R1[177776]
PSW[000] ; R0[177776] ; R1[000006] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177776] ; R1[000006]
PSW[000] ; R0[177776] ; R1[000006] ; R2[000002] >>> DIV R2,R0 >>>
PSW[002] ; R0[177776] ; R1[000006]
PSW[000] ; R0[177776] ; R1[000006] ; R2[000004] >>> DIV R2,R0 >>>
PSW[010] ; R0[100002] ; R1[177776]
PSW[000] ; R0[000001] ; R1[000006] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[000001] ; R1[000006]
PSW[000] ; R0[000001] ; R1[000006] ; R2[177776] >>> DIV R2,R0 >>>
PSW[002] ; R0[000001] ; R1[000006]
PSW[000] ; R0[000001] ; R1[000006] ; R2[177774] >>> DIV R2,R0 >>>
PSW[010] ; R0[137777] ; R1[000002]
PSW[000] ; R0[000001] ; R1[000006] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[000001] ; R1[000006]
PSW[000] ; R0[000001] ; R1[000006] ; R2[000002] >>> DIV R2,R0 >>>
PSW[002] ; R0[000001] ; R1[000006]
PSW[000] ; R0[000001] ; R1[000006] ; R2[000004] >>> DIV R2,R0 >>>
PSW[000] ; R0[040001] ; R1[000002]
Пока яснее не стало.
Для продолжения тестирования - в архиве TDIV++.zip (http://emulator.pdp-11.org.ru/misc/TDIV++.zip) :
TDIV5.SAV - дополнительный тест деления с переполнением для процессора 1801ВМ3.
Пример работы на PDP-11/83:
.RU TDIV5
PSW[000] ; R0[177777] ; R1[177777] ; R2[177777] >>> DIV R2,R0 >>>
PSW[000] ; R0[000001] ; R1[000000]
PSW[000] ; R0[177777] ; R1[000000] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[177777] ; R1[000000]
PSW[000] ; R0[177777] ; R1[000001] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[177777] ; R1[000001]
PSW[000] ; R0[177777] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[012] ; R0[177777] ; R1[000000]
PSW[000] ; R0[177777] ; R1[000001] ; R2[000001] >>> DIV R2,R0 >>>
PSW[012] ; R0[177777] ; R1[000001]
PSW[000] ; R0[000001] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[000001] ; R1[000000]
PSW[000] ; R0[000001] ; R1[000001] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[000001] ; R1[000001]
PSW[000] ; R0[177774] ; R1[000000] ; R2[177774] >>> DIV R2,R0 >>>
PSW[002] ; R0[177774] ; R1[000000]
PSW[000] ; R0[177774] ; R1[000001] ; R2[177774] >>> DIV R2,R0 >>>
PSW[002] ; R0[177774] ; R1[000001]
PSW[000] ; R0[177774] ; R1[000000] ; R2[000004] >>> DIV R2,R0 >>>
PSW[012] ; R0[177774] ; R1[000000]
PSW[000] ; R0[177774] ; R1[000001] ; R2[000004] >>> DIV R2,R0 >>>
PSW[012] ; R0[177774] ; R1[000001]
PSW[000] ; R0[100001] ; R1[000000] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[100001] ; R1[000000]
PSW[000] ; R0[100001] ; R1[100001] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[100001] ; R1[100001]
PSW[000] ; R0[100001] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[012] ; R0[100001] ; R1[000000]
PSW[000] ; R0[100001] ; R1[100001] ; R2[000001] >>> DIV R2,R0 >>>
PSW[012] ; R0[100001] ; R1[100001]
PSW[000] ; R0[077777] ; R1[000000] ; R2[177777] >>> DIV R2,R0 >>>
PSW[012] ; R0[077777] ; R1[000000]
PSW[000] ; R0[077777] ; R1[077777] ; R2[177777] >>> DIV R2,R0 >>>
PSW[012] ; R0[077777] ; R1[077777]
PSW[000] ; R0[077777] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[077777] ; R1[000000]
PSW[000] ; R0[077777] ; R1[077777] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[077777] ; R1[077777]
.
TDIV6.SAV - дополнительный тест деления на 0 и деления нечётного регистра для Эл.85 :
.RU TDIV6
PSW[000] ; R0[177773] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[177773] ; R1[177774]
PSW[000] ; R0[177777] ; R1[177773] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[177777] ; R1[177773]
PSW[000] ; R0[000001] ; R1[000002] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[000001] ; R1[000002]
PSW[000] ; R0[177777] ; R1[000002] ; R2[000010] >>> DIV R2,R1 >>>
PSW[000] ; R0[177777] ; R1[000002]
PSW[000] ; R0[000004] ; R1[000002] ; R2[000020] >>> DIV R2,R1 >>>
PSW[000] ; R0[000004] ; R1[000002]
PSW[000] ; R0[000000] ; R1[000002] ; R2[000040] >>> DIV R2,R1 >>>
PSW[000] ; R0[000000] ; R1[000002]
.
Тест ВМ3
.RUN TDIV5
PSW[000] ; R0[177777] ; R1[177777] ; R2[177777] >>> DIV R2,R0 >>>
PSW[000] ; R0[000001] ; R1[000000]
PSW[000] ; R0[177777] ; R1[000000] ; R2[177777] >>> DIV R2,R0 >>>
PSW[004] ; R0[000000] ; R1[000000]
PSW[000] ; R0[177777] ; R1[000001] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[177777] ; R1[000001]
PSW[000] ; R0[177777] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[004] ; R0[000000] ; R1[000000]
PSW[000] ; R0[177777] ; R1[000001] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177777] ; R1[000001]
PSW[000] ; R0[000001] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[000001] ; R1[000000]
PSW[000] ; R0[000001] ; R1[000001] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[000001] ; R1[000001]
PSW[000] ; R0[177774] ; R1[000000] ; R2[177774] >>> DIV R2,R0 >>>
PSW[004] ; R0[000000] ; R1[000000]
PSW[000] ; R0[177774] ; R1[000001] ; R2[177774] >>> DIV R2,R0 >>>
PSW[002] ; R0[177774] ; R1[000001]
PSW[000] ; R0[177774] ; R1[000000] ; R2[000004] >>> DIV R2,R0 >>>
PSW[004] ; R0[000000] ; R1[000000]
PSW[000] ; R0[177774] ; R1[000001] ; R2[000004] >>> DIV R2,R0 >>>
PSW[002] ; R0[177774] ; R1[000001]
PSW[000] ; R0[100001] ; R1[000000] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[100001] ; R1[000000]
PSW[000] ; R0[100001] ; R1[100001] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[100001] ; R1[100001]
PSW[000] ; R0[100001] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[100001] ; R1[000000]
PSW[000] ; R0[100001] ; R1[100001] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[100001] ; R1[100001]
PSW[000] ; R0[077777] ; R1[000000] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[077777] ; R1[000000]
PSW[000] ; R0[077777] ; R1[077777] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[077777] ; R1[077777]
PSW[000] ; R0[077777] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[077777] ; R1[000000]
PSW[000] ; R0[077777] ; R1[077777] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[077777] ; R1[077777]
Прояснилась ситуация с делением нечётного регистра процессором Эл.85 - старшее и младшее слово делимого копируются из указанного в команде нечётного регистра, результат деления помещается в соответствующий чётный регистр, а остаток - в указанный нечётный регистр.
Всё остальное требует дальнейшего тестирования.
В архиве TDIV+++.zip (http://emulator.pdp-11.org.ru/misc/TDIV+++.zip) :
TDIV7.SAV - дополнительный тест деления с переполнением для процессора 1801ВМ3.
Пример работы на PDP-11/83:
.RU TDIV7
PSW[000] ; R0[177776] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[012] ; R0[177776] ; R1[000000]
PSW[000] ; R0[177774] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[012] ; R0[177774] ; R1[000000]
PSW[000] ; R0[177770] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[012] ; R0[177770] ; R1[000000]
PSW[000] ; R0[177760] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[012] ; R0[177760] ; R1[000000]
PSW[000] ; R0[177740] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[012] ; R0[177740] ; R1[000000]
PSW[000] ; R0[177400] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[012] ; R0[177400] ; R1[000000]
PSW[000] ; R0[174000] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[012] ; R0[174000] ; R1[000000]
PSW[000] ; R0[140000] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[012] ; R0[140000] ; R1[000000]
PSW[000] ; R0[110000] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[012] ; R0[110000] ; R1[000000]
PSW[000] ; R0[110000] ; R1[000000] ; R2[070000] >>> DIV R2,R0 >>>
PSW[012] ; R0[110000] ; R1[000000]
PSW[000] ; R0[140000] ; R1[000000] ; R2[040000] >>> DIV R2,R0 >>>
PSW[012] ; R0[140000] ; R1[000000]
PSW[000] ; R0[174000] ; R1[000000] ; R2[004000] >>> DIV R2,R0 >>>
PSW[012] ; R0[174000] ; R1[000000]
PSW[000] ; R0[177400] ; R1[000000] ; R2[000400] >>> DIV R2,R0 >>>
PSW[012] ; R0[177400] ; R1[000000]
PSW[000] ; R0[177740] ; R1[000000] ; R2[000040] >>> DIV R2,R0 >>>
PSW[012] ; R0[177740] ; R1[000000]
PSW[000] ; R0[177760] ; R1[000000] ; R2[000020] >>> DIV R2,R0 >>>
PSW[012] ; R0[177760] ; R1[000000]
PSW[000] ; R0[177770] ; R1[000000] ; R2[000010] >>> DIV R2,R0 >>>
PSW[012] ; R0[177770] ; R1[000000]
.
TDIV8.SAV - дополнительный тест деления на 0 для Эл.85 :
.RU TDIV8
PSW[000] ; R0[100000] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[100000] ; R1[177774]
PSW[000] ; R0[100001] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[100001] ; R1[177774]
PSW[000] ; R0[110000] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[110000] ; R1[177774]
PSW[000] ; R0[170000] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[170000] ; R1[177774]
PSW[000] ; R0[177000] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[177000] ; R1[177774]
PSW[000] ; R0[177700] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[177700] ; R1[177774]
PSW[000] ; R0[177770] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[177770] ; R1[177774]
.
Пример работы на PDP-11/83
Кстати если интересно, могу включить 11/83 и дать доступ к консоли. В RT-11 доступен TCP/IP, так, что файлики гонять легко :)
Тест ВМ3
.RUN HX1:TDIV7
PSW[000] ; R0[177776] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177776] ; R1[000000]
PSW[000] ; R0[177774] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177774] ; R1[000000]
PSW[000] ; R0[177770] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177770] ; R1[000000]
PSW[000] ; R0[177760] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177760] ; R1[000000]
PSW[000] ; R0[177740] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177740] ; R1[000000]
PSW[000] ; R0[177400] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177400] ; R1[000000]
PSW[000] ; R0[174000] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[174000] ; R1[000000]
PSW[000] ; R0[140000] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[140000] ; R1[000000]
PSW[000] ; R0[110000] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[110000] ; R1[000000]
PSW[000] ; R0[110000] ; R1[000000] ; R2[070000] >>> DIV R2,R0 >>>
PSW[004] ; R0[000000] ; R1[000000]
PSW[000] ; R0[140000] ; R1[000000] ; R2[040000] >>> DIV R2,R0 >>>
PSW[004] ; R0[000000] ; R1[000000]
PSW[000] ; R0[174000] ; R1[000000] ; R2[004000] >>> DIV R2,R0 >>>
PSW[004] ; R0[000000] ; R1[000000]
PSW[000] ; R0[177400] ; R1[000000] ; R2[000400] >>> DIV R2,R0 >>>
PSW[004] ; R0[000000] ; R1[000000]
PSW[000] ; R0[177740] ; R1[000000] ; R2[000040] >>> DIV R2,R0 >>>
PSW[004] ; R0[000000] ; R1[000000]
PSW[000] ; R0[177760] ; R1[000000] ; R2[000020] >>> DIV R2,R0 >>>
PSW[004] ; R0[000000] ; R1[000000]
PSW[000] ; R0[177770] ; R1[000000] ; R2[000010] >>> DIV R2,R0 >>>
PSW[004] ; R0[000000] ; R1[000000]
Кстати если интересно, могу включить 11/83 и дать доступ к консоли. В RT-11 доступен TCP/IP, так, что файлики гонять легко :) Было бы интересно загрузить. :)
Прояснилась ситуация у деления с переполнением при выполнении деления процессором 1801ВМ3 - если младшее слово делимого равно нулю, а старшее слово делимого отрицательное и по модулю равно делителю - результат деления обнуляется и вместо признака переполнения V в PSW устанавливается только бит нулевого результата Z.
Это явная ошибка, поскольку переполнение не диагностируется и сообщается об успешном делении.
...
Дальнейшего тестирования требует деление на 0 процессором Эл.85.
В архиве TDIV9.zip (http://emulator.pdp-11.org.ru/misc/TDIV9.zip) :
TDIV9.SAV - дополнительный тест деления на 0 для Эл.85 :
.RU TDIV9
PSW[000] ; R0[100000] ; R1[000004] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[100000] ; R1[000004]
PSW[000] ; R0[100001] ; R1[000004] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[100001] ; R1[000004]
PSW[000] ; R0[177777] ; R1[000004] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[177777] ; R1[000004]
PSW[000] ; R0[077777] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[077777] ; R1[177774]
PSW[000] ; R0[077777] ; R1[000004] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[077777] ; R1[000004]
PSW[000] ; R0[077777] ; R1[177777] ; R2[000000] >>> DIV R2,R0 >>>
PSW[007] ; R0[077777] ; R1[177777]
.
Patron, Есть ли какой нибудь тест для проверки MMU. Интересно различия после 18BIT на процессоре 1801ВМ3.
Patron, Есть ли какой нибудь тест для проверки MMU. Интересно различия после 18BIT на процессоре 1801ВМ3.
А где ты добыл конфиг 18bit на ВМ3? :)
256Kb - это уже 22bit, а меньше вроде не попадалось...
form, Цитата из Вики.
КМ1801ВМ3
Отличается бо́льшим объёмом адресуемой памяти (до 4 МБ), более высоким
быстродействием (сложение регистр/регистр — 1,5 млн оп/с, умножение —
100 тыс. оп/с, деление — 50 тыс. оп/с), а также возможностью
подключения сопроцессора арифметики с плавающей запятой.
Менеджер памяти не полностью совместим с аналогом от DEC.
В случае использования лишь 18-разрядной адресной шины (до 256 кБ) совместимость диспетчера памяти была
достаточна для использования программного обеспечения без переделок, но при использовании полной,
22-разрядной адресной шины (4 МБ) требовалась адаптация программного кода.
Тест Эл.85Наконец, появилась ясность и в вопросе деления на 0 процессором Эл.85 - если 32-разрядное делимое отрицательное, то при делении на ноль содержимое чётного регистра не изменяется, а содержимое нечётного меняет знак.
Есть ли какой нибудь тест для проверки MMUМожет, в XXDP есть..
Цитата не в тему. То что 22bit позволяет адресовать до 4Mb в ВМ3 (что на самом деле неверно - до 4088Kb) никак не означает, что если памяти меньше, то это 18bit ;)
В частности, чтобы адресовать 256Kb памяти требуется 22bit режим...
В XXDP есть разные тесты MMU, но сначала надо придумать как запустить сам XXDP :)
надо придумать как запустить сам XXDPОтвет здесь: XXDP и ТМОС-2 на ДВК и УКНЦ (http://zx-pk.ru/showthread.php?t=24073)
Ответ здесь: XXDP и ТМОС-2 на ДВК и УКНЦ (http://zx-pk.ru/showthread.php?t=24073)
Ну такой вариант я вроде больше года назад еще показывал... С этого и начинал собирать 11/83 ибо форматнуть винт можно было только из XXDP :)
Сделать бы полноценный...
Сделать бы полноценный...В смысле?
Там полноценно грузится на ДВК/УКНЦ родная XXDP - что ещё надо..
В смысле?
Там полноценно грузится родная XXDP - что ещё надо..
Всмысле чтобы весь XXDP залить на диск и грузить с него.
Всмысле чтобы весь XXDP залить на диск и грузить с него.При желании - на эмулируемом TU58 можно и образ DL грузить. Я не стал этого делать лишь потому, что количество тестов, которые имеет смысл запускать на ДВК/УКНЦ - гораздо меньше доступного свободного места на стандартном образе TU58.
Сейчас плагин для TC полностью поддерживает XXDP, поэтому закинуть в образ нужные тесты элементарно просто.
При желании - на эмулируемом TU58 можно и образ DL грузить. Я не стал этого делать лишь потому, что количество тестов, которые имеет смысл запускать на ДВК/УКНЦ - гораздо меньше доступного свободного места на стандартном образе TU58.
Речь не о том.
Речь о том, чтобы сделать драйвер родного диска.
В теории это не так сложно. В XXDP даже прерывания не используются в драйвере.
Речь о том, чтобы сделать драйвер родного диска.Но какой диск роднее - тут владельцы ДВК, УКНЦ и PDP-11 могут не найти общего языка.
Учитывая, что грузить XXDP приходится не так уж часто - загрузка с эмулируемого TU58 выглядит оптимальным и вполне полноценным решением.
Но какой диск роднее - тут владельцы ДВК, УКНЦ и PDP-11 могут не найти общего языка.
Учитывая, что грузить XXDP приходится не так уж часто - загрузка с эмулируемого TU58 выглядит оптимальным и вполне полноценным решением.
Для практических целей вполне. Хотя и тут не всегда все гладко - требуется машина с нормальным COM портом. Большинство USB/PCI к примеру не подойдут - на что и наступил помню. Хорошо был старый 386 и досовский эмулятор TU58 :)
---------- Post added at 00:16 ---------- Previous post was at 00:13 ----------
11/83 ждет... Пока тишина на порту :)
Но какой диск роднее - тут владельцы ДВК, УКНЦ и PDP-11
ИМХО: никогда такое объединение не работало, разные же контроллеры и не только ) лучший вариант для УК-НЦ\ДВК сделать в виде последовательно вставляемых дискет MZ\MY формата (именно в расчёте на 1 дисковод\карман), если такое возможно и нужно. Про PDP-11 я думаю что там с XXDP родным проблем не может быть по определению?
Про тесты (!) тут "забавный" относительно момент :
Есть вот такой эмулятор БК0010(11)(11М)
http://s7.hostingkartinok.com/uploads/images/2014/10/de391b1ddc1e8167861e383ccff62aa8.png
Имеем вот такие результаты для первого и третьей версии второго
тестов от Титуса )
http://s7.hostingkartinok.com/uploads/images/2014/10/23050966486d77068245ec18aee72b0b.png
http://s7.hostingkartinok.com/uploads/images/2014/10/0d5fc04e2302bac7f8e2837518973d4b.png
http://s7.hostingkartinok.com/uploads/images/2014/10/c7e89a8d5b8428c2afdb6d87b6bec06e.png
http://s7.hostingkartinok.com/uploads/images/2014/10/dba197f7aab66b57709358a2fe1c2c4e.png
http://s7.hostingkartinok.com/uploads/images/2014/10/dbae61a5d3dfd11d33909335a9a2d2f3.png
http://s7.hostingkartinok.com/uploads/images/2014/10/e86d6a31e9c4765881947dac1097917e.png
http://s7.hostingkartinok.com/uploads/images/2014/10/ba45fac56835a140a7f3d6ad3c1ecf1c.png
Я по другому вопросу пытался автору писать уже,
но он мне не ответил, может теперь ответит? :redface:
Я по другому вопросу пытался автору писать уже,
но он мне не ответил, может теперь ответит? :redface:
Ответ прост - процессор явно сэмулирован халявно, без отработки каких-то флагов.
Ответ прост - процессор явно сэмулирован халявно, без отработки каких-то флагов.
C тестами не поспоришь, но вот представь, на сегодняшний день это
эмулятор БКашки, который у меня всегда по рукой. То есть он удобный
в плане интерфейса, да и с играми я проблем не замечал. Вот с раскладкой
клавиш там проблемы (я некоторые кнопки БКашки до сих пор не нащупал
там) - по поводу раскладки я и писал автору кстати )
[
А может быть проблема с тестами из за версии монитора, ведь на БК11(11М) 4.1 - система, то есть да же не 5-я,
хотя вряд ли это опять же влияет на результат работы программы на ассемблере (теста в данном случае).
А есть где сейчас скачать актуальный загрузочный образ RT-11 с последними тестами CPU для запуска на Э-85?Вопрос довольно сложный.
Тесты таймингов просто так на Э-85 не пойдут из-за отстуствия прерывания по вектору 0100. Прерывание по вектору 0100 эмулируется монитором SP2, но этот монитор может использовать в качестве системного терминала только порт отладочного терминала Э-85 ( он же порт принтера ).
Скачать загрузочный образ HX с монитором SP2 можно здесь: Pro350_HX_SP2.DSK.zip (http://emulator.pdp-11.org.ru/misc/Pro350_HX_SP2.DSK.zip)
Тесты выполнения команд пойдут с любым монитором RT-11, который можно загрузить на Э-85:
TSTVM2 v0.3a (http://sderni.ru/247758),
TASH.zip (http://emulator.pdp-11.org.ru/misc/TASH.zip),
TASHC.zip (http://emulator.pdp-11.org.ru/misc/TASHC.zip),
TDIV.zip (http://emulator.pdp-11.org.ru/misc/TDIV.zip),
TDIV9.zip (http://emulator.pdp-11.org.ru/misc/TDIV9.zip)
Про RORB в E11 обещали поправить в 7.2, про ASH пока не писал - надо еще немного покрутить в голове все, что накопилось...
Небольшой тестик неоднозначных команд (и не только).
Навскидку нашел разницу между 11/83 и "SET CPU 83" в E11.
11/83:
.RU ZTEST
MOV R3,(R3)+ ;R3=000772->000774, @#772=000774
MOV R3,-(R3) ;R3=000774->000772, @#772=000772
1134: MOV PC,1164 ;PC=001140, @#1164=001140
JMP (R3)+ ;R3=001204->001206, PC=001204
JMP R3 ;TRAPS TO 10
TST @#1 ;TRAPS TO 4
.E11:
.RU ZTEST
MOV R3,(R3)+ ;R3=000772->000774, @#772=000774
MOV R3,-(R3) ;R3=000774->000772, @#772=000772
1134: MOV PC,1164 ;PC=001140, @#1164=001136
JMP (R3)+ ;R3=001204->001206, PC=001204
JMP R3 ;TRAPS TO 10
TST @#1 ;TRAPS TO 4
.
Видно различие в команде с использованием "PC,X". Зато "R,(R)+" и "R,-(R)" поправили - раньше по умолчанию отличалось... Интересно прогнать на всем что есть под рукой...
Тест 1801ВМ3
.ZTEST
MOV R3,(R3)+ ;R3=000772->000774, @#772=000772
MOV R3,-(R3) ;R3=000774->000772, @#772=000774
1134: MOV PC,1164 ;PC=001140, @#1164=001136
JMP (R3)+ ;R3=001204->001206, PC=001204
JMP R3 ;TRAPS TO 4
TST @#1 ;TRAPS TO 4
form, А Charonom ни кто не пользуется что ли.
form, А Charonom ни кто не пользуется что ли.
Он неудобен: требует 32bit систему, не умеет транслировать telnet<>modem, требует установки эмулятора hardlock итд. E11 получается на порядок проще.
Тест эмулятора PDP11. (Патрона)
.RUN HD1:ZTEST
MOV R3,(R3)+ ;R3=000772->000774, @#772=000772
MOV R3,-(R3) ;R3=000774->000772, @#772=000774
1134: MOV PC,1164 ;PC=001140, @#1164=001136
JMP (R3)+ ;R3=001204->001206, PC=001204
JMP R3 ;TRAPS TO 4
TST @#1 ;DOESN'T TRAP
Обновление теста ZTEST (http://zx-pk.ru/showpost.php?p=750904&postcount=1056). Пока новых тестов не добавилось, только добавлена поддержка сборки под RSX-11 и P/OS дабы иметь возможность запускать на всяких MIM'ах да CTAKAH'ах... В комплекте универсальный ZTEST.CMD для сборки в любой из систем, ZTEST.COM на случай если есть RT-11 без IND, библиотека RSXLIB (нужна для сборки в RT-11) и пресобранные варианты.
>SET DCL
$ @ZTEST
$ MAC ZTESTPRE,ZTEST/OBJ
$ LIN ZTEST
$ DEL ZTEST.OBJ;*,ZTESTPRE.MAC;*/NOWAR
$ PUR ZTEST.TSK/NOWAR
$ @ <EOF>
$ SET MCR
>@ZTEST
>MAC ZTEST=ZTESTPRE,ZTEST
>TKB ZTEST=ZTEST
>PIP ZTEST.OBJ;*,ZTESTPRE.MAC;*/DE/NM
>PIP ZTEST.TSK/PU/NM
>@ <EOF>
>RTE /VS
RTEM-11 (RSX-11M) V01.00
RT-11FB V05.07
.SET TT QUIET
.IND ZTEST.CMD
.MAC ZTEST
.LIN/LINK:SY:RSXLIB ZTEST
.DEL/NOQ ZTEST.OBJ
@ <EOF>
.
form, Вам в качестве рекомендации.
1)дописывать версию в названии файла, дабы избежать путаницы.
2)выкладывать дополнительно образ диска где эти тесты, и также дописывать версию теста в названии образа.
3)неплохо бы делать отчет по прохождению/непрохождению результата теста который здесь выкладывается.
Спасибо.
Тест 1801ВМ3
ZTEST
MOV R3,(R3)+ ;R3=000772->000774, @#772=000772
MOV R3,-(R3) ;R3=000774->000772, @#772=000774
1134: MOV PC,1164 ;PC=001140, @#1164=001136
JMP (R3)+ ;R3=001204->001206, PC=001204
JMP R3 ;TRAPS TO 4
TST @#1 ;TRAPS TO 4
1)дописывать версию в названии файла, дабы избежать путаницы.
Ну а директива .IDENT в исходнике на что? ;)
В RSX-11 эту версию видно в образе задачи, в RT-11 для SAV стандартного метода не существует. Можно воспользоваться DEC'овским, но тогда придется дополнительные разборки учинять... Можно конечно еще печатать номер версии при запуске... Подумаю :)
2)выкладывать дополнительно образ диска где эти тесты, и также дописывать версию теста в названии образа.
Это можно.
3)неплохо бы делать отчет по прохождению/непрохождению результата теста который здесь выкладывается.
Здесь нет понятия прохождения/непрохождения. Это тест который показывает стандартное поведение (различное на разных процессорах изначально, о чем компилятор для большинства тестируемых команд отсигналит ошибкой "Z"). Из опубликованных здесь примеров 5 из 6 пунктов уже показали разные результаты на живом железе. Одинаковым для всего что проверялось остался тест JMP (R)+ - везде переходит на неувеличенное значение R.
Подумаю :)
Просто писать не ztest а ztest_v0.1. Так сказать культура программирования. :)
Просто писать не ztest а ztest_v0.1. Так сказать культура программирования. :)
Так файл архива (второй) и так пронумерован ;)
Тест Эл.85
Ну заново можно не перетестировать, суть тестов-то не изменилась, ничего не добавилось. Если только для чистоты эксперимента в P/OS проверить, но раз в RSX работает, то и там будет - прога непривилегированная, никаких хитростей системы не использует...
В плане "чистоты" эксперимента, а есть способ "малой кровью" прогнать тест Titusa для ВМ-2 версии 3
; Тест процессора КР1801ВМ2 для УКНЦ
;
; Версия 0.3a
;
; (c) dr.Titus 2012
на ПП УК-НЦ, перекомпилировать изменив значения констант?
Получить REL файл? Или как вообще?
И ещё момент такой - можно ли (просто теория) при выходе из строя ЦП,
полностью его функции переложить на ПП, "дублирующая" без перекомпиляции всего и вся? Возможно вопросы слегка не корректны технически, но общий смысл ясен.
1. Как протестить не только ЦП, но и ПП указанной программой?
2. Может ли ПП УК-НЦ дублировать ЦП в аварийной ситуации?
1. Как протестить не только ЦП, но и ПП указанной программой?
2. Может ли ПП УК-НЦ дублировать ЦП в аварийной ситуации?
1. Теоретически можно сделать версию, тестирующую ПП, но практически этого не нужно, ибо тест преследует идентификационную и исследовательскую цель. А в УКНЦ для этого достаточно ЦП.
2. Нет.
1. Теоретически можно сделать версию, тестирующую ПП,
ух, там исходник на 83 блока )
2. Нет.
Соответственно и в обратную сторону не о какой аварийной взаимозаменяемости речи нет? )
Тогда ещё вопрос, надо ли и планируется адаптировать тест ВМ2 для КЦГД?
Эмуляцию проверить ) Или виртуально ВМ2 копи-пастом один и тот же внутри программы эмулятора вставляется и смысла большого в этом нет?
Или виртуально ВМ2 копи-пастом один и тот же внутри программы эмулятора вставляется и смысла большого в этом нет?
Именно.
1. Теоретически можно сделать версию, тестирующую ПП
А практически - элементарно сделать одну и ту же прогу и для того и для другого. Пример показывал :)
А практически - элементарно сделать одну и ту же прогу и для того и для другого.
У меня получился REL но он просто запускается и снова системное приглашение,
ничего не кажет, но я в исходнике ничего не менял, просто сделал LIN/FO
запускал пруном конечно, а как ещё? )
У меня получился REL но он просто запускается и снова системное приглашение,
ничего не кажет, но я в исходнике ничего не менял, просто сделал LIN/FO
запускал пруном конечно, а как ещё? )
Ну так чтобы оно запускалось PRUN'ом надо еще чтобы код программы предусматривал работу на ПП.
Исходники IOSCAN предусматривают запуск на ПП, можно посмотреть. Ну и где-то выкладывал пример программы которая и на ПП и под RT-11 работает без пересборки.
А практически - элементарно сделать одну и ту же прогу и для того и для другого. Пример показывал :)
Да у меня изначально так и было, ибо тест вырос из других моих тестов типа TSSPD и подобных, которые сперва запускаются на ЦП, потом на ПП. Только потом, ввиду ненужности и компактности теста, я эту особенность именно для данного теста вырезал.
shattered
15.11.2014, 11:29
Тогда ещё вопрос, надо ли и планируется адаптировать тест ВМ2 для КЦГД?
Эмуляцию проверить ) Или виртуально ВМ2 копи-пастом один и тот же внутри программы эмулятора вставляется и смысла большого в этом нет?
Лучше бы прошивку с тестами КЦГД заполучить, но пока она не всплыла, как я понимаю?
Лучше бы прошивку с тестами КЦГД заполучить, но пока она не всплыла, как я понимаю?
Не совсем понял о чём речь, да и здесь немного не по теме. То есть мне известно о двух вариантах прошивки 181 и 182 для КЦГД, есть ли там встроенные тесты мне не ведомо, но если на этих железках остались не считанные ПЗУ надо срочно бить тревогу и просить счастливых обладателей что то там считать. Другой момент,
что программные тесты для КЦГД всегда были и есть. И вроде бы не зависимо от
прошивки (версии) работают. Надо только капнуть в темах по КЦГД и ПОИСКУ СОФТА, там всё это либо прилеплено, либо прямые ссылки со скринами есть.
Для их запуска нужно загрузить RT-11 естественно )
http://www.youtube.com
shattered
15.11.2014, 21:06
В тех темах про нее уже написано. Это не замена 181/182, а дополнительное пзу -- на него ссылается РЭ.
Исходники IOSCAN предусматривают запуск на ПП
У меня "хочу пива" шпоргалка есть ))) Под prun пример )))
Прогнал тест на плате Mentec M1.
Всё Ок кроме деления.
Команда деления (частичный тест):
DIV (even) - ERROR: 0x9E4A / 0x6572
DIV (odd) - ERROR: 0x43D5 / 0xDFC3
Всё Ок кроме деления.Стандартное деление чётного регистра ( без деления на 0 и без деления с переполнением ) проверяет тест TDIV1.SAV из архива TDIV.zip (http://emulator.pdp-11.org.ru/misc/TDIV.zip) :
Пример работы:
.TDIV1
Тестирование правильности выполнения команд процессора:
Команда деления (частичный тест):
DIV (even) - OK
.
Patron, Понятно что тест от dr. Titusa для процессора ВМ2, однако совместимость системы команд должна быть сверху вниз. (на мой взгляд)
Стандартное деление чётного регистра ( без деления на 0 и без деления с переполнением ) Делить на ноль нельзя, хотя для ВМ2 наверно можно :)
проверяет тест TDIV1.SAV
У меня Ок, как и ожидалось.
Patron, Понятно что тест от dr. Titusa для процессора ВМ2, однако совместимость системы команд должна быть сверху вниз. (на мой взгляд)
Во-первых есть разные реализации и они документрованы в списках изменений (равно как есть и ошибки). Во-вторых ВМ2 и М1 ну никак не относятся к понятию "свкерху вниз" :)
совместимость системы команд должна быть сверху вниз.Как показало тестирование - у разных процессоров совместимо только выполнение команд, а невыполнение - как правило несовместимо.
Например, при делении на 0 - команда деления не выполняется, но при этом с содержимым PSW и содержимым указанных в команде регистров могут происходить довольно неожиданные и весьма оригинальные изменения, радикально отличающиеся у разных процессоров.
Во-вторых ВМ2 и М1 ну никак не относятся к понятию "свкерху вниз" :) Наоборот М1 верх ВМ2 низ.
Наоборот М1 верх ВМ2 низ.
Наоборот - никакой связи ибо не являются процессорами одного производителя :)
form, Я согласен, но я про другое. Система команд в М1 должна соответствовать J11. Если так то J11 должен исполнять код предыдущих процессоров.
И если ВМ2 основан на коде DEC то М1 теоретически и для ВМ2 проги исполнит. В тонкости не вдавался.
Тест от dr. Titusa показал ОК кроме DIV . Но и ВМ3 DIV непроходит.
В целом можно считать.
Как показало тестирование - у разных процессоров совместимо только выполнение команд, а невыполнение - как правило несовместимо.
И если ВМ2 основан на коде DEC
1801ВМ1 и 1801ВМ2 не основаны на коде DEC. Это оригинальная советская разработка, скажем так, "по мотивам". То есть инженеры прочитали описание процессора и сделали свою разработку "с нуля" (если совсем подробно - то приспособили свою готовую систему НЦ для исполнения команд DEC), а не путем копирования топологии. В итоге получилось изделие хоть и поддерживающее ту же самую систему команд, но с рядом особенностей.
Путем копирования топологии пошли в Воронеже - 581-ая серия точная копия LSI-11/03, 1811-ая - F11 (PDP-11/23), 1831-ая - J11 (PDP-11/73).
form, Я согласен, но я про другое. Система команд в М1 должна соответствовать J11. Если так то J11 должен исполнять код предыдущих процессоров.
Система команд и соответствует. А различия в отдельных моментах (не существенных в обычной жизни) были всегда. К примеру если попробовать написать в программе что-нибудь из нижеперечисленного:
MOV R0,(R0)+
MOV R1,-(R1)
JMP (R2)+
MOV PC,LABEL
компилятор MACRO-11 выдаст ошибку Z, означающую, что результат команды непредсказуем и зависит от процессора. Есть и другие различия, я здесь выкладывал официальную таблицу отличий процессоров. И различия эти появлялись часто в результате усовершенствований. Mentec скорее всего не отличается от старших J11 (а первые их версии на нем и были собраны).
form, А как в маш. кодах будет эта программа.
form, А как в маш. кодах будет эта программа.
Это не программа, это отдельные команды, каждая из которых дает неоднозначный результат.
MOV R0,(R0)+ ;010020
MOV R1,-(R1) ;010141
JMP (R2)+ ;000122
MOV PC,LABEL ;010767 XXXXXX
Я выкладывал тест который некоторые из таких особенностей проверяет.
Когда будет запуск RSX на ментеке?
Интересно посмотреть на результат ACF :)
---------- Post added at 14:03 ---------- Previous post was at 13:16 ----------
И результат IOSCAN (или команды MAP загрузчика) интересен...
Когда будет запуск RSX на ментеке?
Интересно посмотреть на результат ACF :)А есть образ с НХ драйвером?
И результат IOSCAN (или команды MAP загрузчика) интересен... МАР есть в биусе, пойдет?
А есть образ с НХ драйвером?
Нет и не может быть - во-первых драйвера нету, во-вторых HX убивает даже функционал RT-11, а в рамках RSX это будет прост смерть системе :)
МАР есть в биусе, пойдет?
Подойдет, хотя обзывать BIOSом язык не поворачивается тем более что общего просто ничего ни в привычном плане ни терминологически :)
---------- Post added at 23:02 ---------- Previous post was at 23:00 ----------
Могу сделать образ RSX с фиксированными в нем нужными задачами с загрузкой из под RT-11 -- я так делал в начале опытов на ДВК-4, разбивая легенту о нерабочести RSX-11 на ВМ3 (а равно и о нерабочести 22бит на ВМ3 [о которой я впрочем тогда не слышал]), только ACF придется переделать - он составной и пишет/читает в/из файла - придется или переделать.
form, Ассоциации остались... :) (по поводу биуса)
Могу сделать образ RSX с фиксированными в нем нужными задачами с загрузкой из под RT-11 -- я так делал в начале опытов на ДВК-4, разбивая легенту о нерабочести RSX-11 на ВМ3 (а равно и о нерабочести 22бит на ВМ3 [о которой я впрочем тогда не слышал]), только ACF придется переделать - он составной и пишет/читает в/из файла - придется или переделать. Я в этой системе не разбираюсь...
form, Ассоциации остались... :) (по поводу биуса)
Я в этой системе не разбираюсь...
Не, у меня таких ассоциаций нет. И форматирование в современном понятии никак не ассоциируется с форматированием :)
form, Не надо всё лепить в одну кучу.
Про биус правда накосячил. :) Имелось ввиду BIOS.
>Я в этой системе не разбираюсь...
Это относится к цитате про RSX.
Mentec M1
Memory Map
Starting at Ending at
00000000 17757776
17772100 17772100
17772200 17772376
17772516 17772516
17773000 17773776
17776500 17776526
17777520 17777520
17777546 17777546
17777560 17777566
17777572 17777676
17777744 17777752
17777766 17777766
17777772 17777772
17777776
Получается так:
172100 Memory CSR
172200-172276 Supervisor I and D PDR/PAR's
172300-172376 Kernel I and D PDR/PAR's
172516 MMR3
173000-173776 CPU ROM
176500-176506 DLV11
176510-176516 DLV11
176520-176526 DLV11
177520 BCSR
177546 Clock CSR
177560-177566 DLV11
177572-177576 MMR0, MMR1, MMR2
177600-177676 User I and D PDR/PAR's
177744-177752 MSER, CCR, MREG, Hit/Miss
177766 CPU Error
177772 PIRQ
177776 PSW
Регистров поменьше чем у меня ;)
Надо диск какой-нибудь :)
Не забываем также запускать тесты TDIV1.SAV и TDIV2.SAV из пакета TDIV.zip (http://emulator.pdp-11.org.ru/misc/TDIV.zip) на процессоре 1801ВМ2.
Тест на плате МС1201.02 (старый вариант на РУ6)
RUN TDIV1
Тестирование правильности выполнения команд процессора:
Команда деления (частичный тест):
DIV (even) - OK
.RUN TDIV2
PSW[000] ; R0[000000] ; R1[000000] ; R2[000000] >>> DIV R2,R0 >>>
PSW[003] ; R0[000000] ; R1[000000]
PSW[000] ; R0[177777] ; R1[177777] ; R2[000000] >>> DIV R2,R0 >>>
PSW[003] ; R0[177777] ; R1[177777]
PSW[000] ; R0[100000] ; R1[000000] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000000]
PSW[000] ; R0[177774] ; R1[000000] ; R2[177774] >>> DIV R2,R0 >>>
PSW[002] ; R0[177774] ; R1[000000]
PSW[000] ; R0[177774] ; R1[000000] ; R2[000004] >>> DIV R2,R0 >>>
PSW[002] ; R0[177774] ; R1[000000]
PSW[000] ; R0[000004] ; R1[000000] ; R2[000004] >>> DIV R2,R0 >>>
PSW[002] ; R0[000004] ; R1[000000]
PSW[000] ; R0[177776] ; R1[177776] ; R2[177774] >>> DIV R2,R0 >>>
PSW[000] ; R0[040000] ; R1[177776]
PSW[000] ; R0[000002] ; R1[000002] ; R2[177774] >>> DIV R2,R0 >>>
PSW[010] ; R0[100000] ; R1[000002]
PSW[000] ; R0[177776] ; R1[177776] ; R2[000004] >>> DIV R2,R0 >>>
PSW[010] ; R0[140000] ; R1[177776]
PSW[000] ; R0[000002] ; R1[000002] ; R2[000004] >>> DIV R2,R0 >>>
PSW[002] ; R0[000002] ; R1[000002]
PSW[000] ; R0[000000] ; R1[000000] ; R2[000000] >>> DIV R2,R1 >>>
PSW[003] ; R0[000000] ; R1[000000]
PSW[000] ; R0[177777] ; R1[177777] ; R2[000000] >>> DIV R2,R1 >>>
PSW[003] ; R0[177777] ; R1[177777]
PSW[000] ; R0[100000] ; R1[100000] ; R2[177777] >>> DIV R2,R1 >>>
PSW[002] ; R0[100000] ; R1[100000]
PSW[000] ; R0[177776] ; R1[177776] ; R2[177774] >>> DIV R2,R1 >>>
PSW[000] ; R0[177776] ; R1[040000]
PSW[000] ; R0[000002] ; R1[000002] ; R2[177774] >>> DIV R2,R1 >>>
PSW[010] ; R0[000002] ; R1[100000]
PSW[000] ; R0[177776] ; R1[177776] ; R2[000004] >>> DIV R2,R1 >>>
PSW[010] ; R0[177776] ; R1[140000]
PSW[000] ; R0[000002] ; R1[000002] ; R2[000004] >>> DIV R2,R1 >>>
PSW[002] ; R0[000002] ; R1[000002]
Тест на плате МС1201.02 (старый вариант на РУ6)Процессор 1801ВМ2 осуществляет нестандартное деление в целом так же, как ВМ3. Разница лишь в том, что ВМ3 имеет ошибку в реализации команды DIV, поэтому контрольная сумма теста у ВМ2 другая.
При делении нечётного регистра - ВМ2 ( как и ВМ3 ) помещает в нечётный регистр не остаток от деления ( как у процессоров DEC ), а результат деления.
...
Было бы полезно также запустить на 1801ВМ2 тесты: TDIV3.SAV (http://emulator.pdp-11.org.ru/misc/TDIV+.zip), TDIV4.SAV (http://emulator.pdp-11.org.ru/misc/TDIV+.zip), TDIV5.SAV (http://emulator.pdp-11.org.ru/misc/TDIV++.zip), TDIV6.SAV (http://emulator.pdp-11.org.ru/misc/TDIV++.zip) и TDIV7.SAV (http://emulator.pdp-11.org.ru/misc/TDIV+++.zip)
...
Разница лишь в том, что ВМ3 имеет ошибку в реализации команды DIV, Интересно, а как тогда в эмуляторе (в далёком будущем) будет реализовано, с ошибкой или без.
Было бы полезно также запустить на 1801ВМ2
Тест TDIV3, TDIV4 на плате МС1201.02 (старый вариант на РУ6)
RUN TDIV3
PSW[000] ; R0[100000] ; R1[000000] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000000]
PSW[000] ; R0[100000] ; R1[000001] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000001]
PSW[000] ; R0[100000] ; R1[000000] ; R2[177776] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000000]
PSW[000] ; R0[100000] ; R1[000006] ; R2[177774] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000006]
PSW[000] ; R0[100000] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000000]
PSW[000] ; R0[100000] ; R1[000000] ; R2[000002] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000000]
PSW[000] ; R0[100000] ; R1[000006] ; R2[000004] >>> DIV R2,R0 >>>
PSW[002] ; R0[100000] ; R1[000006]
PSW[000] ; R0[177776] ; R1[000006] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[177776] ; R1[000006]
PSW[000] ; R0[177776] ; R1[000006] ; R2[177776] >>> DIV R2,R0 >>>
PSW[002] ; R0[177776] ; R1[000006]
PSW[000] ; R0[177776] ; R1[000006] ; R2[177774] >>> DIV R2,R0 >>>
PSW[000] ; R0[077776] ; R1[177776]
PSW[000] ; R0[177776] ; R1[000006] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177776] ; R1[000006]
PSW[000] ; R0[177776] ; R1[000006] ; R2[000002] >>> DIV R2,R0 >>>
PSW[002] ; R0[177776] ; R1[000006]
PSW[000] ; R0[177776] ; R1[000006] ; R2[000004] >>> DIV R2,R0 >>>
PSW[010] ; R0[100002] ; R1[177776]
PSW[000] ; R0[000001] ; R1[000006] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[000001] ; R1[000006]
PSW[000] ; R0[000001] ; R1[000006] ; R2[177776] >>> DIV R2,R0 >>>
PSW[002] ; R0[000001] ; R1[000006]
PSW[000] ; R0[000001] ; R1[000006] ; R2[177774] >>> DIV R2,R0 >>>
PSW[010] ; R0[137777] ; R1[000002]
PSW[000] ; R0[000001] ; R1[000006] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[000001] ; R1[000006]
PSW[000] ; R0[000001] ; R1[000006] ; R2[000002] >>> DIV R2,R0 >>>
PSW[002] ; R0[000001] ; R1[000006]
PSW[000] ; R0[000001] ; R1[000006] ; R2[000004] >>> DIV R2,R0 >>>
PSW[000] ; R0[040001] ; R1[000002]
.RUN TDIV4
PSW[000] ; R0[177777] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[003] ; R0[177777] ; R1[177774]
PSW[000] ; R0[000000] ; R1[177773] ; R2[000000] >>> DIV R2,R0 >>>
PSW[003] ; R0[000000] ; R1[177773]
PSW[000] ; R0[000000] ; R1[000002] ; R2[000000] >>> DIV R2,R0 >>>
PSW[003] ; R0[000000] ; R1[000002]
PSW[000] ; R0[000001] ; R1[000002] ; R2[000004] >>> DIV R2,R1 >>>
PSW[002] ; R0[000001] ; R1[000002]
PSW[000] ; R0[000001] ; R1[000002] ; R2[000010] >>> DIV R2,R1 >>>
PSW[000] ; R0[000001] ; R1[040000]
PSW[000] ; R0[000000] ; R1[000004] ; R2[000004] >>> DIV R2,R1 >>>
PSW[002] ; R0[000000] ; R1[000004]
---------- Post added at 01:23 ---------- Previous post was at 01:16 ----------
Тест TDIV5, TDIV6 на плате МС1201.02 (старый вариант на РУ6)
.RUN TDIV5
PSW[000] ; R0[177777] ; R1[177777] ; R2[177777] >>> DIV R2,R0 >>>
PSW[000] ; R0[000001] ; R1[000000]
PSW[000] ; R0[177777] ; R1[000000] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[177777] ; R1[000000]
PSW[000] ; R0[177777] ; R1[000001] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[177777] ; R1[000001]
PSW[000] ; R0[177777] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177777] ; R1[000000]
PSW[000] ; R0[177777] ; R1[000001] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177777] ; R1[000001]
PSW[000] ; R0[000001] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[000001] ; R1[000000]
PSW[000] ; R0[000001] ; R1[000001] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[000001] ; R1[000001]
PSW[000] ; R0[177774] ; R1[000000] ; R2[177774] >>> DIV R2,R0 >>>
PSW[002] ; R0[177774] ; R1[000000]
PSW[000] ; R0[177774] ; R1[000001] ; R2[177774] >>> DIV R2,R0 >>>
PSW[002] ; R0[177774] ; R1[000001]
PSW[000] ; R0[177774] ; R1[000000] ; R2[000004] >>> DIV R2,R0 >>>
PSW[002] ; R0[177774] ; R1[000000]
PSW[000] ; R0[177774] ; R1[000001] ; R2[000004] >>> DIV R2,R0 >>>
PSW[002] ; R0[177774] ; R1[000001]
PSW[000] ; R0[100001] ; R1[000000] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[100001] ; R1[000000]
PSW[000] ; R0[100001] ; R1[100001] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[100001] ; R1[100001]
PSW[000] ; R0[100001] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[100001] ; R1[000000]
PSW[000] ; R0[100001] ; R1[100001] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[100001] ; R1[100001]
PSW[000] ; R0[077777] ; R1[000000] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[077777] ; R1[000000]
PSW[000] ; R0[077777] ; R1[077777] ; R2[177777] >>> DIV R2,R0 >>>
PSW[002] ; R0[077777] ; R1[077777]
PSW[000] ; R0[077777] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[077777] ; R1[000000]
PSW[000] ; R0[077777] ; R1[077777] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[077777] ; R1[077777]
.RUN TDIV6
PSW[000] ; R0[177773] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[003] ; R0[177773] ; R1[177774]
PSW[000] ; R0[177777] ; R1[177773] ; R2[000000] >>> DIV R2,R0 >>>
PSW[003] ; R0[177777] ; R1[177773]
PSW[000] ; R0[000001] ; R1[000002] ; R2[000000] >>> DIV R2,R0 >>>
PSW[003] ; R0[000001] ; R1[000002]
PSW[000] ; R0[177777] ; R1[000002] ; R2[000010] >>> DIV R2,R1 >>>
PSW[000] ; R0[177777] ; R1[040000]
PSW[000] ; R0[000004] ; R1[000002] ; R2[000020] >>> DIV R2,R1 >>>
PSW[000] ; R0[000004] ; R1[020000]
PSW[000] ; R0[000000] ; R1[000002] ; R2[000040] >>> DIV R2,R1 >>>
PSW[000] ; R0[000000] ; R1[010000]
---------- Post added at 01:30 ---------- Previous post was at 01:23 ----------
Тест TDIV7, TDIV8 на плате МС1201.02 (старый вариант на РУ6)
.RUN TDIV7
PSW[000] ; R0[177776] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177776] ; R1[000000]
PSW[000] ; R0[177774] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177774] ; R1[000000]
PSW[000] ; R0[177770] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177770] ; R1[000000]
PSW[000] ; R0[177760] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177760] ; R1[000000]
PSW[000] ; R0[177740] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177740] ; R1[000000]
PSW[000] ; R0[177400] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[177400] ; R1[000000]
PSW[000] ; R0[174000] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[174000] ; R1[000000]
PSW[000] ; R0[140000] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[140000] ; R1[000000]
PSW[000] ; R0[110000] ; R1[000000] ; R2[000001] >>> DIV R2,R0 >>>
PSW[002] ; R0[110000] ; R1[000000]
PSW[000] ; R0[110000] ; R1[000000] ; R2[070000] >>> DIV R2,R0 >>>
PSW[002] ; R0[110000] ; R1[000000]
PSW[000] ; R0[140000] ; R1[000000] ; R2[040000] >>> DIV R2,R0 >>>
PSW[002] ; R0[140000] ; R1[000000]
PSW[000] ; R0[174000] ; R1[000000] ; R2[004000] >>> DIV R2,R0 >>>
PSW[002] ; R0[174000] ; R1[000000]
PSW[000] ; R0[177400] ; R1[000000] ; R2[000400] >>> DIV R2,R0 >>>
PSW[002] ; R0[177400] ; R1[000000]
PSW[000] ; R0[177740] ; R1[000000] ; R2[000040] >>> DIV R2,R0 >>>
PSW[002] ; R0[177740] ; R1[000000]
PSW[000] ; R0[177760] ; R1[000000] ; R2[000020] >>> DIV R2,R0 >>>
PSW[002] ; R0[177760] ; R1[000000]
PSW[000] ; R0[177770] ; R1[000000] ; R2[000010] >>> DIV R2,R0 >>>
PSW[002] ; R0[177770] ; R1[000000]
.RUN TDIV8
PSW[000] ; R0[100000] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[003] ; R0[100000] ; R1[177774]
PSW[000] ; R0[100001] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[003] ; R0[100001] ; R1[177774]
PSW[000] ; R0[110000] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[003] ; R0[110000] ; R1[177774]
PSW[000] ; R0[170000] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[003] ; R0[170000] ; R1[177774]
PSW[000] ; R0[177000] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[003] ; R0[177000] ; R1[177774]
PSW[000] ; R0[177700] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[003] ; R0[177700] ; R1[177774]
PSW[000] ; R0[177770] ; R1[177774] ; R2[000000] >>> DIV R2,R0 >>>
PSW[003] ; R0[177770] ; R1[177774]
Интересно, а как тогда в эмуляторе (в далёком будущем) будет реализовано, с ошибкой или без.Конечно, с ошибкой.
...
Интересно, какое содержимое имеет память на РУ6 сразу после включения питания. Чтобы это узнать - можно сразу после включения прогнать в пульте следующий скрипт:
0/¬
¬
¬
74/¬
¬
¬
174/¬
¬
¬
274/¬
¬
¬
374/¬
¬
¬
574/¬
¬
¬
774/¬
¬
¬
1374/¬
¬
¬
1774/¬
¬
¬
2774/¬
¬
¬
3774/¬
¬
¬
7774/¬
¬
¬
17774/¬
¬
¬
137774/¬
¬
¬
¬
Конечно, с ошибкой.Тогда надо сделать
опцию "с ошибкой/ без ошибки"
типа
Error correction -Disable
Error correction -Enable
Далее тест КР565РУ6
034723
@/000000
034725/177777
034727/000000
034731/177777
@74/000000
000076/177777
000100/000000
000102/177777
@174/000000
000176/177777
000200/177777
000202/000000
@274/177777
000276/000000
000300/177777
000302/000000
@374/177777
000376/000000
000400/000000
000402/177777
@574/000000
000576/177777
000600/177777
000602/000000
@774/177777
000776/000000
001000/177777
001002/000000
@1374/000000
001376/177777
001400/177777
001402/000000
@1774/000000
001776/177777
002000/000000
002002/177777
@2774/177777
002776/000000
003000/177777
003002/000000
@3774/000000
003776/177777
004000/000000
004002/177777
@7774/000000
007776/177777
010000/000000
010002/177777
@17774/000000
017776/177777
020000/000000
020002/177777
@137774/000000
137776/177777
140000/137777
140002/000000
@
Теперь можно запустить SPEED.SAV, DHRY.SAV (http://zx-pk.ru/attachment.php?attachmentid=46853) и PDPCLK.SAV ( Factor: 4 ).
Patron, Плата восстановлена после покусанных КМок и я не все конденсаторы поставил типа КМ. На времязадающих я поставил какие то бытовые конденсаторы (КМ не было) и скорость процессора может быть недостоверной.
Интересно что адрес высвечивает 034723 после включения, это так и должно быть?
Тест Т0 проходит без проблем.
Тест SPEED
SPEED
ТЕСТ БЫСТРОДЕЙСТВИЯ
КОМАНДА СЛОЖЕНИЯ РЕГИСТР-РЕГИСТР
БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК) 816
КОМАНДА СЛОЖЕНИЯ РЕГИСТР-ПАМЯТЬ
БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК) 344
КОМАНДА УМНОЖЕНИЯ РЕГИСТР-РЕГИСТР
БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК) 88
КОМАНДА ДЕЛЕНИЯ РЕГИСТР-РЕГИСТР
БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК) 64
---------- Post added at 18:13 ---------- Previous post was at 18:02 ----------
Тест DHRY
RUN DHRY
Dhrystone(1.1) time for 5000 passes = 12
This machine benchmarks at 416 dhrystones/second
---------- Post added at 18:18 ---------- Previous post was at 18:13 ----------
Тест PDPCLK
RUN PDPCLK
PDPCLK - Calculate CPU clocks - v1.0
Memory Top: 131072
BUF words: 21313
Factor : 4 > 4
Factor : 4
CPU KHz: 8316
Program completed.
Интересно что адрес высвечивает 034723 после включения, это так и должно быть?Затрудняюсь ответить.
Теперь можно запустить тесты таймингов (http://emulator.pdp-11.org.ru/misc/PDP11_TimingsTests.zip) ( подставляя измеренное с помощью PDPCLK значение CPU KHz: 8300 ) и поместить результаты в теме: Расчёт точного времени выполнения команд различными процессорами архитектуры PDP-11 (http://zx-pk.ru/showthread.php?t=14702) ( из кучи тестов таймингов команд ASH и ASHC можно пока ограничиться тестами ASH.SAV и ASHC.SAV ).
Patron, Переставил переключатели начального запуска на вектор 24 и получилось так.
@17774/000000
017776/177777
020000/125252
020002/177777
@137774/000000
137776/177777
140000/125252
140002/000000
...
Тесты попозже сделаю.
Конечно, с ошибкой.
Оказывается есть не одна ошибка. Читать - Здесь (http://bk0010.org/forum/?id=2192&page=) В частности, топик от 23.03.2009 21:03
Оказывается есть не одна ошибка.Надо бы проверить плату с ВМ2 на "мега-глюк" при помощи следующих тестов:
VM2T5.SAV (http://zx.pk.ru/attachment.php?attachmentid=40980),
VM2T6.SAV (http://zx.pk.ru/attachment.php?attachmentid=40981) ( при нескольких последовательных прогонах иногда могут появляться резко отличающиеся результаты ),
VM2T7.SAV (http://zx.pk.ru/attachment.php?attachmentid=40983),
VM2T18.SAV (http://zx.pk.ru/attachment.php?attachmentid=41084) ( в ответ на вопросы нажимать ВВОД ),
VM2T19.SAV (http://zx.pk.ru/attachment.php?attachmentid=41089) ( в ответ на вопросы нажимать ВВОД ).
Patron, Ну вообще то там речь о ВМ3.
Надо бы проверить плату с ВМ2
Сделал.
RUN VM2T5
1801VM2 MegaBUG test #5
CMP (PC),PC | INC R0 | INC R1 | INC R2 | CMP (PC),PC | INC R3 | INC R4 | INC
R0: 1 R1: 1 R2: 1 R3: 1 R4: 1 R5: 1
CMP (PC),R0 | INC R0 | INC R1 | INC R2 | CMP (PC),R0 | INC R3 | INC R4 | INC
R0: 1 R1: 1 R2: 1 R3: 1 R4: 1 R5: 1
CMP (PC),R0 | INC R0 | INC R1 | CMP (PC),R0 | INC R2 | INC R3 | CMP (PC),R0 |
R0: 1 R1: 1 R2: 1 R3: 1 R4: 1 R5: 1
CMP (PC),R0 | INC R0 | CMP (PC),R0 | INC R1 | CMP (PC),R0 | INC R2 | CMP ...
R0: 1 R1: 1 R2: 1 R3: 1 R4: 1 R5: 1
Program completed.
.RUN VM2T6
1801VM2 MegaBUG test #6
MOV (PC),R0 | 240 | 241 | 242 | MOV (PC),R1 | 243 | 244 | 245 | MOV (PC),R2 |
R0/000240 R1/000243 R2/000246 R3/000251 R4/000254 R5/000257
MOV (PC),R0 | 240 | 241 | MOV (PC),R1 | 242 | 243 | MOV (PC),R2 | 244 | 245 |
R0/000240 R1/000242 R2/000244 R3/000246 R4/000250 R5/000252
CMP (PC),R0 | 240 | 241 | 242 | MOV (PC)+,R0 | 243 | 244 | 245 | MOV (PC)+,
R0/000243 R1/000246 R2/000251 R3/000254 R4/000257 R5/000262
CMP (PC),R0 | 240 | 241 | MOV (PC)+,R0 | 242 | 243 | MOV (PC)+,R1 | 244 |
R0/000242 R1/000244 R2/000246 R3/000250 R4/000252 R5/000254
CMP (PC),R0 .. MOV (PC)+,R0 .. MOV (PC)+,R1 .. CMP (PC),R0 .. MOV (PC)+,R2 ..
R0/000242 R1/000244 R2/000250 R3/000252 R4/000256 R5/000260
Program completed.
.RUN VM2T7
1801VM2 MegaBUG test #7.1
MOV (PC),R0 | TST R0 | TST R1 | TST R2 | MOV (PC),R1 | TST R0 | TST R1 |
R0/005700 R1/005700 R2/005700 R3/005700 R4/005700 R5/005700
MOV (PC),R0 | TST R0 | TST R1 | MOV (PC),R1 | TST R0 | TST R1 | MOV (PC),R2
R0/005700 R1/005700 R2/005700 R3/005700 R4/005700 R5/005700
CMP (PC),R0 | TST R0 | TST R1 | TST R2 | MOV (PC)+,R0 | TST R0 | TST R1 |
R0/005700 R1/005700 R2/005700 R3/005700 R4/005700 R5/005700
CMP (PC),R0 | TST R0 | TST R1 | MOV (PC)+,R0 | TST R0 | TST R1 | MOV (PC)+,R1
R0/005700 R1/005700 R2/005700 R3/005700 R4/005700 R5/005700
CMP (PC),R0 .. MOV (PC)+,R0 .. MOV (PC)+,R1 .. CMP (PC),R0 .. MOV (PC)+,R2 ..
R0/005700 R1/005700 R2/005700 R3/005700 R4/005700 R5/005700
Program completed.
.RUN VM2T18
1801VM2 MegaBUG test #18.2
MTPS : 00340 >
Loops : 10000 >
CMP (PC),R0 Loops: 10000 Bugs: 0
CMPB (PC),R0 Loops: 10000 Bugs: 0
MOV (PC),R0 Loops: 10000 Bugs: 0
MOVB (PC),R0 Loops: 10000 Bugs: 0
ADD (PC),R0 Loops: 10000 Bugs: 0
SUB (PC),R0 Loops: 10000 Bugs: 0
BIT (PC),R0 Loops: 10000 Bugs: 0
BITB (PC),R0 Loops: 10000 Bugs: 0
BIS (PC),R0 Loops: 10000 Bugs: 0
BISB (PC),R0 Loops: 10000 Bugs: 0
BIC (PC),R0 Loops: 10000 Bugs: 0
BICB (PC),R0 Loops: 10000 Bugs: 0
Program completed.
.RUN VM2T19
1801VM2 MegaBUG test #19
MTPS : 00000 >
Loops : 10000 >
CMP (PC),R0 Loops: 10000 Bugs: 0
CMPB (PC),R0 Loops: 10000 Bugs: 0
MOV (PC),R0 Loops: 10000 Bugs: 0
MOVB (PC),R0 Loops: 10000 Bugs: 0
ADD (PC),R0 Loops: 10000 Bugs: 0
SUB (PC),R0 Loops: 10000 Bugs: 0
BIT (PC),R0 Loops: 10000 Bugs: 0
BITB (PC),R0 Loops: 10000 Bugs: 0
BIS (PC),R0 Loops: 10000 Bugs: 0
BISB (PC),R0 Loops: 10000 Bugs: 0
BIC (PC),R0 Loops: 10000 Bugs: 0
BICB (PC),R0 Loops: 10000 Bugs: 0
Program completed.
---------- Post added at 21:13 ---------- Previous post was at 21:02 ----------
при нескольких последовательных прогонах иногда могут появляться резко отличающиеся результаты
Раз 5 прогнал, результаты одинаковы.
Раз 5 прогнал, результаты одинаковы.Всё верно.
Мега-глюк ВМ2 проявляется только при задержке памяти 4 такта и больше, а у тестируемой платы задержка памяти 2 такта ( для вычисления задержки памяти надо из самого короткого тайминга ВМ2 вычесть число 8 ).
Всё верно.
Мега-глюк ВМ2 проявляется только при задержке памяти 4 такта и больше, а у тестируемой платы задержка памяти 2 такта ( для вычисления задержки памяти надо из самого короткого тайминга ВМ2 вычесть число 8 ).
Кстати, вы так и не дали ответа, каково обьяснение мегаглюка.
каково обьяснение мегаглюкаНадо сказать, что мега-глюк пока ещё недостаточно изучен. Его первичные проявления изучены и поняты достаточно хорошо ( см. ЗДЕСЬ (http://zx-pk.ru/showthread.php?postid=594518) ), но когда исполняется пара команд, вроде [ MOV (PC),R0 | NOP ] - диапазон возможных проявлений сильно расширяется.
В частности:
1. Если в этот момент произойдёт прерывание, то переданный по шине вектор может измениться на : a) код команды NOP ( 0240 ) ; b) число 024 ( код команды NOP, сдвинутый на 3 бита ).
2. Вместо кода команды NOP может быть исполнен код 024.
...
Если говорить о возможном объяснении, то (похоже) дело в том, что любое обращение к памяти с адресацией относительно PC производится процессором ВМ2 с автоинкрементом PC, поэтому в тех редких случаях, когда команда использует адресацию (PC) - для компенсации автоинкремента PC перед выполнением следующей команды выполняется микрокод безусловного перехода. При этом предвыборка только что прочитанного кода следующей команды отменяется.
Из-за какой-то ошибки в микропрограмме, при большой задержке памяти следом за микрокодом перехода запускается исполнение считанного блоком перехода кода следующей команды. При задержке памяти от 0 до 3 тактов - считанный код не выполняется, а сразу запускается обычное ( уже третье по счёту ) чтение и выполнение ТОГО ЖЕ САМОГО кода следующей команды.
В результате и когда мега-глюк работает, и когда он "спит" - ситуация на шине совершенно одинакова. Код команды, следующей за MOV (PC),R0 - считывается ТРИ РАЗА подряд ( первый раз - отменённой предвыборкой, второй раз - микрокодом безусловного перехода, третий раз - в ходе обычного выполнения команды ). При активном глюке два последних считывания кода команды дважды завершаются её выполнением, после чего возникает рассинхронизация внутренних указателей следующей команды PC1 и PC2, а при "спящем" глюке - выполняется только последний считанный код и рассинхронизация PC1 и PC2 не возникает.
Если следующая команда относится к группе CCC/SCC ( например NOP ) - при первом (незапланированном) выполнении этой команды процедура выделения из её кода битов признаков происходит "нелегально", когда другие блоки процессора считают используемый внутренний регистр свободным, из-за чего попытка записать туда адрес принятого вектора прерывания или код команды, извлечённый в ходе предвыборки - с некоторой вероятностью приводит к попаданию различных вариантов сдвига кода 0240 на место принятого вектора прерывания или извлечённого в ходе предвыборки кода следующей команды.
Вопрос по плате МС1201.02 - там есть ПЗУ в памяти режима USER по адресу 0173000 ( и дальше ) ?
Как в USER посмотреть, вообще там в 173000 загрузчик DX.
Вопрос по плате МС1201.02 - там есть ПЗУ в памяти режима USER по адресу 0173000 ( и дальше ) ?
Нету. ПЗУ там сидит по адресам 140000-157777 в HALT-режиме.
Как в USER посмотреть, вообще там в 173000 загрузчик DX.USER - это то, что видно в пульте.
Если у МС1201.02 по адресу 0173000 сидит ПЗУ - хотелось бы как-то получить его дамп ( например - можно открыть адрес 173000 в пульте и зажать <ПС>, пока адреса ПЗУ не кончатся и пульт не скажет BUS ERROR )
---------- Post added at 18:43 ---------- Previous post was at 18:38 ----------
Нету.Без этого ПЗУ у МС1201.02 очень плохо с автозагрузкой.
В системном ПЗУ ДВК-2 есть только автозагрузчик с DX, а автозагрузчики с MX и DY ( которые есть в системном ПЗУ ДВК-1 ) - отсутствуют. Зато есть режим начального пуска на адрес 0173000 - типа, все желающие могут сами "приклеить" туда какой-то свой автозагрузчик.
@173000/
BUS ERROR
SA1.1-0
SA1.2-0
При старте 173000G
SA1.1-0
SA1.2-1
000002
@
Как переключатели поставить? С какого адреса стартовать?
Как переключатели поставить? С какого адреса стартовать?Как переключатели на ставь - отсутствующее в ДВК-2 ПЗУ загрузчика на шине не появится.
Настройка для старта платы с адреса 0173000 у МС1201.02 есть, но ПЗУ по этому адресу у МС1201.02 нет.
Скорей всего ПЗУ уже находится на устройстве.
http://s017.radikal.ru/i430/1412/5d/b12dd9a67127.jpg (http://www.radikal.ru)
у МС1201.02 есть ПЗУ-055 и там есть загрузчик (не в юзере) ... Но я не понял - почему эту ПЗУ -055 никто не знает?
Как выяснилось - прошивка -055 поддерживает загрузку со следующих устройств:
Команда CSR
------- ------
L 177550
B MT0 172520
B MX0 177130
B DX0 177170
B RK0 177400
B RM0 167740
Есть ещё команды.
B
$ L (BK) -Ввод программы абсолютного загрузчика с устройства считывания с перфоленты.
$ LA (BK) -Загрузка программы абсолютного загрузчика в память.
$ DY (BK) -Загрузка с накопителя на гибких магнитных дисках с двойной плотностью.
Тест VM2JR.SAV (http://emulator.pdp-11.org.ru/misc/VM2JR.zip) для платы МС1201.02 проверяет, какой вариант Trap_to_04 вызывает команда типа JMP R0 в режиме HALT - по вектору 04 или по вектору 140004.
В первом случае результат запуска выглядит так:
.RU VM2JR
1801VM2 HALT mode test VM2JR v1.0
JMP R0
Trap to 04
.
Во втором случае результат запуска выглядит так:
.RU VM2JR
1801VM2 HALT mode test VM2JR v1.0
JMP R0
HALT Trap to 04
.
Тест VM2JR.SAV (http://emulator.pdp-11.org.ru/misc/VM2JR.zip) для платы МС1201.02 проверяет, какой вариант Trap_to_04 вызывает команда типа JMP R0 в режиме HALT - по вектору 04 или по вектору 140004.
А чего тут проверять? Все уже давно проверено мною на УКНЦ, я даже выкладывал документ по исследованию процессора 1801ВМ2. Это прерывание режима USER, поэтому произойдет прерывание по вектору 4.
Это прерывание режима USER, поэтому произойдет прерывание по вектору 4.Значит в режиме USER команды MOV R0,@#160000 и JMP R0 дадут одинаковый Trap_to_04, а в режиме HALT команды MOV R0,@#140000 и JMP R0 дадут разный результат - первая вызовет HALT_Trap_to_SEL+04, а вторая Trap_to_04 ..
Значит в режиме USER команды MOV R0,@#160000 и JMP R0 дадут одинаковый Trap_to_04, а в режиме HALT команды MOV R0,@#140000 и JMP R0 дадут разный результат - первая HALT_Trap_to_SEL+04, а вторая Trap_to_04 ..
Да, всё верно.
---------- Post added at 02:25 ---------- Previous post was at 02:21 ----------
Ещё добавлю, что хоть TRAP4 и недопустимая команда прерываются по одному вектору в режиме USER, но для процессора это совершенно разные ситуации. Для TRAP4 ещё запоминается признак прерывания, чтобы прерваться по DOUBLE BUS ERROR, если произойдёт ещё TRAP4. Кстати, в 1801ВМ2 этот признак очищается только при успешном прочтении команды из памяти, а не просто прочтении памяти.
Для TRAP4 ещё запоминается признак прерывания, чтобы прерваться по DOUBLE BUS ERROR, если произойдёт ещё TRAP4. Кстати, в 1801ВМ2 этот признак очищается только при успешном прочтении команды из памяти, а не просто прочтении памяти.Т.е. если обработчик TRAP4 указывает на команду MFPT, а обработчик TRAP10 указывает "в пустоту" - вместо обычного зависания получится двойное..
А есть тест, который это проверяет ?
Т.е. если обработчик TRAP4 указывает на команду MFPT, а обработчик TRAP10 указывает "в пустоту" - вместо обычного зависания получится двойное..
Не получится. Команда MFPT будет прочитана, и соответственно флаг сброшен. Далее он установится при попытке прочтения первой команды подпрограммы исполнения TRAP10, произойдет TRAP4, но команда MFPT будет успешно прочитана из памяти. Ну и так до бесконечности, точнее до переполнения стека.
А есть тест, который это проверяет ?
Тесты я не писал, т.к. пультовый отладчик в УКНЦ очень удобный и позволяет запускать код как в режиме USER, так и в HALT. Поэтому все исследования я делал в нём.
А программа довольно простая. Устанавливаем вектор 4 на адрес 0170000, ячейку 6 на 0340, R6 на 01000, RS на 0340. С адреса 01000 заносим команду TST @#170000 и исполняем её.
Происходит TRAP4, в стек успешно заносятся значения 01002 и 0340. А вот далее при чтении команды по адресу 0170000 снова происходит прерывание по зависанию и соответственно DOUBLE BUS ERROR. После всего этого значение R6 станет 0774, т.е. в стек занесено только два слова при первом прерывании TRAP4.
Тест можно усложнить, если сделать так, что ячейку 6 установить в 0, и чтобы было прерывание по таймеру или по терминалу. Их вектор также должен указывать на "пустоту". Соответственно стек заполнится ещё больше, но в итоге опять будет DOUBLE BUS ERROR.
Кстати, не помешало бы проверить это на МС1201.02, т.к. там нет "мегаглюка". Поэтому программу надо написать, а Mix её исполнит.
Тест можно усложнить, если сделать так, что ячейку 6 установить в 0, и чтобы было прерывание по таймеру или по терминалу. Их вектор также должен указывать на "пустоту". Соответственно стек заполнится ещё больше, но в итоге опять будет DOUBLE BUS ERROR.Можно устроить цепочку вложенных прерываний ( включая 014 ). Если флаг BUS_ERROR устанавливается после зависания, а сбрасывается после выборки команды - куча успешных записей в стек и чтений векторов его не очистит.
В первом случае результат запуска выглядит так: Тест на МС1201.02 показывает первый случай. А как надо сделать чтобы получить второй?
Тест VM2DB.SAV (http://zx-pk.ru/attachment.php?attachmentid=50483&d=1420201595) для процессора 1801ВМ2 проверяет генерацию прерывания по двойной ошибке шины - DOUBLE BUS ERROR. В результате исполнения теста должна появится ошибка двойного зависания и произойти выход в пультовый отладчик. Перед исполнением теста желательно включить таймер. После запуска теста выведется приглашение >, надо нажать любую цифру. Для МС1201.02, после выхода в пультовый отладчик, необходимо просмотреть причину перехода по команде M. Просмотреть содержимое регистров R6, R7 и RS, а также содержимое стека от значения в регистре R6 до ячейки 0776 включительно.
Для МС1201.02 выход в RT-11 делается следующим образом: переключатель ПРОГРАММА/ПУЛЬТ перевести в положение ПРОГРАММА, в регистры R7 и RS занести значения 01400 и 0340 соответственно. Запустить командой пультового отладчика P.
Результаты работы теста на реальной УКНЦ видны на миниатюре.
Тест на МС1201.02 показывает первый случай. А как надо сделать чтобы получить второй?
А второй вы никак не получите. Просто у Patron-а были некоторые сомнения и он захотел проверить на реальной МС1201.02.
Тест LDBE.SAV (http://emulator.pdp-11.org.ru/misc/LDBE.zip) - проверяет реакцию процессора на "длинное двойное зависание".
При вылете в пульт надо нажать M. Запускать можно везде, где есть нормальные прерывания от таймера.
При запуске на эмулируемой МС1201.02 результат такой:
.RU LDBE
LDBE - Long DOUBLE BUS ERROR - Test v1.0
160002
@M
DOUBLE BUS ERROR
@
При запуске на эмулируемой МС1201 результат такой:
.RU LDBE
LDBE - Long DOUBLE BUS ERROR - Test v1.0
NOT Found..
.
Patron, Результат такой же. Такой же и с включенным таймером.
Чуть позже сделаю VM2DB.SAV.
---------- Post added at 17:00 ---------- Previous post was at 16:50 ----------
Тест VM2DB.SAV
.RUN VM2DB
> 170042
@
@M
DOUBLE BUS ERROR
@R6/000754
@R7/170042
@RS/000340
@R7/170042 01400
@P
.
Результат такой же.А на ВМ3 и других платах какой результат ?
Ячейки после теста VM2DB.SAV
@754/170030
000756/000000
000760/170020
000762/000000
000764/170010
000766/000000
000770/170000
000772/000020
000774/001242
000776/000340
А на ВМ3 и других платах какой результат ?
KDJ11-BF:
.RU LDBE
LDBE - Long DOUBLE BUS ERROR - Test v1.0
NOT Found..
.
Patron, У меня к Вам Мега просьба. Сделайте пожалуйста в эмуляторе VT52 переключение скоростей СОМ порта, выбор СОМ порта, установку RTS,DTR на передней панели (или сделать дополнительный спойлер "настройки"). А то каждый раз лезть в конфиг очень не удобно. А этими настройками я пользуюсь очень часто.
Спасибо.
переключение скоростей СОМ порта, выбор СОМ портаДля меня это нереально сложно, если бы мог - давно бы сделал.
Тест LDBE на ВМ3
LDBE - Long DOUBLE BUS ERROR - Test v1.0
@ 160000
@M
HALT INSTRUCTION
@G
@ 160000
@P
@ 160000
@
Видно что обратно в RT11 не возвращается.
Тест LDBE на ВМ3
........................................
Видно что обратно в RT11 не возвращается.
Тута надо смотреть регистры R6, R7 и RS, а также содержимое стека.
Кстати, процессор 1801ВМ3 не различает HALT, DOUBLE BUS ERROR и INTERRUPT ERROR. Все исключения начинают исполняться в одной точке, и никаких признаков ни в каких регистрах нет. Все должно было определяться по всяким косвенным признакам, но в ПЗУ 1801РЕ2-134 этого не реализовано.
R6/000674
R7/160000
RS/000000
Как стек посмотреть?
---------- Post added at 18:11 ---------- Previous post was at 18:08 ----------
но в ПЗУ 1801РЕ2-134 этого не реализовано. А как 377 прошивке сделано?
R6/000674
R7/160000
RS/000000
Как стек посмотреть?
Ячейки от содержимого регистра R6, в данном случае 0674, до ячейки 0776 включительно. Вот только значение 0674 вызывает сомнение, это после теста, или после попыток выйти в RT-11?
А как 377 прошивке сделано?
Не знаю, не смотрел, не дизассемблировал.
До теста LDBE на ВМ3
@R6/127026
@R7/173000
@RS/000340
@674/000740
00000676/012702
00000700/000722
00000702/004712
00000704/011100
00000706/000020
00000710/000331
00000712/145414
00000714/156252
00000716/154630
00000720/000047
00000722/000000
00000724/154430
00000726/154004
00000730/145660
00000732/004000
00000734/000000
00000736/000047
00000740/153776
00000742/147664
00000744/145564
00000746/147740
00000750/007314
00000752/177777
00000754/001042
00000756/154546
00000760/145401
00000762/145240
00000764/000000
00000766/000003
00000770/145237
00000772/000120
00000774/143706
00000776/000010
После.
LDBE - Long DOUBLE BUS ERROR - Test v1.0
@ 160000
@M
HALT INSTRUCTION
@R6/000764
@R7/160000
@RS/000000
@674/000740
00000676/012702
00000700/000722
00000702/004712
00000704/011100
00000706/000020
00000710/000331
00000712/145414
00000714/156252
00000716/154630
00000720/000047
00000722/000000
00000724/154430
00000726/154004
00000730/145660
00000732/004000
00000734/000000
00000736/000047
00000740/153776
00000742/147664
00000744/152460
00000746/000061
00000750/151774
00000752/152410
00000754/152346
00000756/001000
00000760/001312
00000762/145414
00000764/001264
00000766/000000
00000770/001256
00000772/000377
00000774/001166
00000776/000340
---------- Post added at 18:54 ---------- Previous post was at 18:49 ----------
Не знаю, не смотрел, не дизассемблировал.
Прошивка Здесь (forum.maxiol.com/index.php?act=Attach&type=post&id=6200)
После.
@R6/000764
00000764/001264
00000766/000000
00000770/001256
00000772/000377
00000774/001166
00000776/000340
Вот, это уже ближе к истине. R6 содержит 0764. Примерно напоминает исполнение на 1801ВМ2, только вот адрес останова равен 0160000, а не 0160002.
Еще бы VM2DB прогнать на 1801ВМ3.
Прошивка Здесь (forum.maxiol.com/index.php?act=Attach&type=post&id=6200)
Она у меня есть. Нету времени, чтобы дизассемблировать и разобрать. Сама -134 у меня дизассемблирована, но только комментарии не написаны.
Тест LDBE на ВМ3
LDBE - Long DOUBLE BUS ERROR - Test v1.0
@ 160000А на МС1201.02 какой адрес при вылете пишет - 160000 или 160002 ?
Давайте так, сначала тесты на ВМ3 потом на ВМ2. Чтоб мне платы не менять как пластинки (корзина одна).
Давайте так, сначала тесты на ВМ3 потом на ВМ2. Чтоб мне платы не менять как пластинки (корзина одна).Пока для ВМ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 закончено?
Тест VM2DB на ВМ3
А вот это уже интересно. Похоже 1801ВМ3 пробует читать код нового процесса, даже не обрабатывая новых прерываний. Ну и адрес останова не PC+2, а PC.
MiX, для выхода в RT-11 надо было установить R7. В команде забыли ввести слэш "/". Т.е. надо было R7/.
---------- Post added at 19:33 ---------- Previous post was at 19:29 ----------
Alex_K, Можно в редакторе найти отличия 134 и 377 и дизассемблировать только отличия. Я думаю там только добавлен автозагрузчик DW и тест ВМ4.
Увы, там же двоичный код. Различаться уже могут смещения при относительной адресации. Так что только дизассемблировать и смотреть.
С ВМ3 закончено?
Наверное да. Да и Patron отлаживает 1801ВМ2 в своем эмуляторе.
Еще раз огромное спасибо.
В команде забыли ввести слэш Да, поторопился. Повторил со слэшем и успешно вышел в RT.
---------- Post added at 19:50 ---------- Previous post was at 19:41 ----------
А на МС1201.02 какой адрес при вылете пишет - 160000 или 160002 ? Пишет 160002.
Тест VM2MEM.SAV (http://emulator.pdp-11.org.ru/misc/VM2MEM.zip) - проверяет распределение памяти в пространстве 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 (http://emulator.pdp-11.org.ru/misc/VM2T20.zip), который полезно запустить и на плате МС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.
.
Для проверки гипотезы о запрете прерываний глючной командой написан тест VM2T20.SAV (http://emulator.pdp-11.org.ru/misc/VM2T20.zip), который полезно запустить и на плате МС1201.02 ( где глюк не активен ), и на УКНЦ ( где глюк активен ).
Редкий результат на 1-й миниатюре, а по большей части, как на 2-й - выводит только надпись и крутится где-то в районе RMON, этим все и кончается. Для второго варианта ещё содержимое стека впридачу.
Прохождение теста такое же как в эмуляторе.
---------- Post added at 19:15 ---------- Previous post was at 18:56 ----------
Alex_K, Раз уж 134 прошивка дезассемблирована то можешь выковырять оттуда загрузчик DW. Мысль какая, этот загрузчик можно прикрутить вторым ПЗУ в эмулятор.
Тогда на команду В $DW пойдёт загрузка с жёсткого диска.
Редкий результат на 1-й миниатюре, а по большей части, как на 2-й - выводит только надпись и крутится где-то в районе RMON, этим все и кончается.Когда глюк не активируется - прерывания проходят как надо, но когда глюк активен - пока непонятно, что происходит..
А как выглядит на УКНЦ запуск тестов VM2T18.SAV (http://zx.pk.ru/attachment.php?attachmentid=41084) и VM2T19.SAV (http://zx.pk.ru/attachment.php?attachmentid=41089) ( в ответ на вопросы нажимать ВВОД ) ?
---------- Post added at 19:39 ---------- Previous post was at 19:32 ----------
Тогда на команду В $DW пойдёт загрузка с жёсткого диска.На команду В $DW загрузка с DW не пойдёт, но если код автозагрузки с DW посадить по адресу 0173000 - ДВК-2 будет автоматически грузиться с DW при SEL = 140006
Запуск VM2T19 (думаю, что везде возможен и результат 10000):
Похоже, удалось найти ошибку в тесте VM2T20.SAV (http://emulator.pdp-11.org.ru/misc/VM2T20.zip) из-за которой он не выдерживал встречи с МЕГА-глюком.
Теперь в указанном архиве уже новая исправленная версия теста.
Результат запуска в эмуляторе такой:
.RU VM2T20
1801VM2 MegaBUG test #20 v1.1
01044 BiS #100, @#TTPS
01046 Mov (PC), R0
01050 >>> Interrupt <<< 064
01050 Mov (PC), R0
01052 Tst R0
01054 BiC #100, @#TTPS
01102 BiS #100, @#TTPS
01104 Mov (PC), R0
01106 >>> Interrupt <<< 064
01106 Mov (PC), R0
01110 BiC #100, @#TTPS
Program completed.
.
Прохождение теста такое же.
Похоже, удалось найти ошибку в тесте VM2T20.SAV (http://emulator.pdp-11.org.ru/misc/VM2T20.zip) из-за которой он не выдерживал встречи с МЕГА-глюком.
Результат запуска в эмуляторе такой:
Аналогично и на УКНЦ, запускал много раз, результат такой же.
Аналогично и на УКНЦ, запускал много раз, результат такой же.В смысле - прерывания проходят штатно и глючные команды их вовсе не запрещают.
В смысле - прерывания проходят штатно и глючные команды их вовсе не запрещают.
Ну как видите, ничто не препятствует. Ведь блок обработки прерываний всё-таки поприоритетнее будет, в этом случае очищается предвыборка, ну и глюка не будет.
Ну как видите, ничто не препятствует. Ведь блок обработки прерываний всё-таки поприоритетнее будет, в этом случае очищается предвыборка, ну и глюка не будет.Мы помним прерывания по вектору 024 после глючного выполнения NOP и вряд ли такие прерывания могут возникнуть в глючном коде при запрещённых прерываниях. Значит - глюк вполне может заменять принимаемый процессором адрес вектора.
Но если глюкогенные команды не запрещают прерывания - не понятно, как длина последовательности таких команд может влиять на вероятность возникновения Trap_to_04 в момент выполнения команды NOP ( при том, что адрес в стеке после прерывания указывает на следующую за NOP команду ).
Друзья, не забываем запускать тест TSTVM2 v0.3a (http://zx-pk.ru/showpost.php?p=749151&postcount=981) на ВМ3 и других машинах. Интересует последняя страница теста, где тест команды MARK.
Прогнал тест на плате М6
Всё ОК кроме операций DIV
Команда деления (частичный тест):
DIV (even) - ERROR: 0x9E4А / 0x9Е46
DIV (odd) - ERROR: 0x43D5 / 0xBAA7
Откровенно говоря, думал что будет как в Эл.85 но оказывается есть различия (http://zx-pk.ru/showpost.php?p=748676&postcount=942).
оказывается есть различияРазличия ( по крайней мере в части эталонной контрольной суммы ) похоже вызваны различным алгоритмом тестирования в применявшихся тестах.
Возможно что в тот раз была версия теста 0.2, но вроде др. Титус в 0.3 добавил только MARK тест.
Возможно что в тот раз была версия теста 0.2, но вроде др. Титус в 0.3 добавил только MARK тест.
Да.
Ну и как тогда у двух тестов могут различаться ВСЕ контрольные суммы - и измеренные, и эталонные ..
---------- Post added at 16:02 ---------- Previous post was at 15:56 ----------
Получается, что на тестируемом процессоре подпрограмма печати 16-ричного значения выводит на экран неизвестно что.
Значит тот тест был версии 0.1.
Прогнал тест 0.3а на Эл.85
результат не отличается от теста 0.3а на плате М6.
Кстати, когда команда RTT снимает бит T и затем происходит "финальное" прерывание по вектору 014, то в какой момент должно происходить это прерывание - до выполнения следующей за RTT команды или после ?
Ответ даёт TTST6.SAV (http://emulator.pdp-11.org.ru/misc/TTST6.zip)
Результаты запуска в эмуляторе следующие :
.RU TTST6
LSI-11 Traps Test #6
Mov #00,-(SP)
Mov #L2,-(SP)
Mov #20,-(SP)
Mov #L1,-(SP)
RTT
L1: RTI
L2:
>>> Trap to 014 <<<
NOP
Mov #00,-(SP)
Mov #L4,-(SP)
Mov #20,-(SP)
Mov #L3,-(SP)
RTT
L3: RTT
L4:
>>> Trap to 014 <<<
NOP
.
Лучше ответить в этой теме, более соответствует. На УКНЦ с процессором 1801ВМ2 результаты аналогичные, потому скриншот и не выкладываю.
---------- Post added at 18:44 ---------- Previous post was at 18:37 ----------
Из описания исполнения RTI на 1801ВМ2:
"...Если при загрузке нового PSW устанавливается бит T в PSW, то отладочное прерывание будет вызвано до исполнения первой команды нового процесса. Если перед исполнением RTI был установлен T-бит, а при загрузке нового PSW он очищается, то в этом случае всё равно будет вызвано отладочное прерывание, но в стеке сохранится уже новое PSW без установленного бита T. ..."
Особенности RTT:
"... Единственным отличием является то, что если при загрузке нового PSW устанавливается бит T, то после исполнения RTT не запускается блок обработки прерываний, и соответственно выполняется команда нового процесса. ..."
Из этой особенности следует, что если при возврате по RTT бит T не был установлен, то блок обработки прерываний не пропускается.
На 11/83:
.BO RT11SB
Foreground loaded; Are you sure? Y
RT-11SB (S) V05.07
.SET TT QUIET
?ETM-I-Date & time - 11-FEB-2015 19:22:55
?ETM-I-Time server - 70-71-BC-50-EB-D0, OpenBSD 5.5 amd64
.R DATE
.AS D10 DK
.RU TTST6
LSI-11 Traps Test #6
Mov #00,-(SP)
Mov #L2,-(SP)
Mov #20,-(SP)
Mov #L1,-(SP)
RTT
L1: RTI
L2:
NOP
Mov #00,-(SP)
Mov #L4,-(SP)
Mov #20,-(SP)
Mov #L3,-(SP)
RTT
L3: RTT
L4:
NOP
.
---------- Post added at 20:43 ---------- Previous post was at 19:24 ----------
А вот интересно, как ВМx ведут себя если в @#16 записать 20 и сделать BPT?
На *J11 процессорах это один из 4 случаев когда придется останавливать проц сигналом BHALT.
А вот интересно, как ВМx ведут себя если в @#16 записать 20 и сделать BPT?У ВМ1 и ВМ2 после выхода указателя стека за пределы памяти возникает двойная ошибка шины.
У ВМ1 и ВМ2 после выхода указателя стека за пределы памяти возникает двойная ошибка шины.
Ну вобщем-то так и предполагал.
На 11/83 все зависает, если остановить вручную - SP будет равен 0 и тот факт, что SP в кернел моде не может безнаказанно пересечь зловещие 400 не спасает :)
---------- Post added at 23:24 ---------- Previous post was at 21:24 ----------
Попутно для общего развития тест прерывания по небольшому переполнению стека.
Выполняет последовательно команды (при SP=400):
BR .
EMT 350
TST -(SP)
CALL @#EXSUB
Первая из них ждет пока таймер вызовет прерывание и тем самым опустит SP ниже 400, остальные команды сами действуют на SP.
.TITLE YELL -- ТЕСТ YELLOW STACK TRAP
.MCALL .EXIT,.PRINT
;+
;ТЕСТ ПОСЛЕДОВАТЕЛЬНО ВЫПОЛНЯЕТ ПРИ SP=400 КОМАНДЫ:
; BR .
; EMT 350
; TST -(SP)
; CALL @#EXSUB
;-
START:: MOV #CODES,R3 ;R3=ТАБЛИЦА КОМАНД
MOV @#4,SAVE ;СОХРАНЯЕМ ВЕКТОР
MOV @#6,SAVE+2 ; 4
MOV #ODINT,@#4 ;УСТАНАВЛИВАЕМ ОБРАБОТЧИК
MOV #340,@#6 ; ПРЕРЫВАНИЯ
DOTST:: MOV #ARGS,R2 ;R2=БЛОК АРГУМЕНТОВ $EDMSG
MOV #INSTR,(R2)+ ;АДРЕС ТЕСТИРУЕМОЙ КОМАНДЫ
ASR SP ;SP=400
INSTR:: BR . ;ТЕСТИРУЕМАЯ КОМАНДА
.WORD EXSUB ;ВТОРАЯ ЧАСТЬ ОТ КОМАНДЫ CALL
PRINT:: MOV #BUFF,R0 ;R0=БУФЕР
MOV #DUMP,R1 ;R1=ФОРМАТНАЯ СТРОКА
MOV #ARGS,R2 ;R2=БЛОК АРГУМЕНТОВ
CALL $EDMSG ;ФОРМАТИРУЕМ СООБЩЕНИЕ
.PRINT #BUFF ;ПЕЧАТАЕМ
MOV (R3)+,INSTR ;СЛЕДУЮЩАЯ ИНСТРУКЦИЯ
BNE DOTST ;ЕСЛИ 0 - ВСЕ
MOV SAVE,@#4 ;ВОССТАНАВЛИВАЕМ ВЕКТОР
MOV SAVE+2,@#6 ;
EXSUB:: .EXIT ;ВЫХОД
ODINT:: MOV SP,R0 ;СОХРАНЯЕМ SP
MOV #START,SP ;ВОССТАНАВЛИВАЕМ
MOV R0,(R2)+ ;SP
MOV (R0)+,(R2)+ ;@SP
MOV @R0,(R2)+ ;2(SP)
CLR -(SP) ;ВОЗВРАТ
MOV #PRINT,-(SP) ; НА
RTI ; ПП ПЕЧАТИ
CODES:: .EXIT ;EMT 350
TST -(SP) ;TST -(SP)
CALL @#0 ;CALL @#EXSUB
SAVE: .BLKW 2
ARGS: .BLKW 4
BUFF: .BLKB 64.
DUMP: .ASCIZ /%P: SP=%P, @SP=%P, 2(SP)=%P/
.END START
Результаты показывают, что в случае возникновения прерывания или вызова подпрограммы, сначала проходит сохранение в стек, потом устанавливается PC/PS, а потом происходит прерывание по 4, что позволяет обработчику прерываний просто вернуться назад по RTI (предварительно проверив в регистре CPUERR, что это yellow stack trap) и тем самым продолжить выполнение в надежде что остатков стека хватит :)
.EX YELL/LINK:SY:RSXLIB
001046: SP=000370, @SP=133014, 2(SP)=000341
001046: SP=000370, @SP=120760, 2(SP)=000000
001046: SP=000372, @SP=001050, 2(SP)=000004
001046: SP=000372, @SP=001122, 2(SP)=000000
.E 30
120760
.E 100
133014
.
CALL @#EXSUB
CALL $EDMSG
Что скрыто за этими вызовами?
Можно ли (имеет ли смысл) например этот тест запустить на УК-НЦ под RT-11?
Каким образом и можно ли RSXLIB использовать? - я наверное пропустил если
есть эта OBJ для RT-11? Есть ли в этой библиотеке (если её можно использовать
под RT-11), что нибудь супер крутое и полезное, описание аналогичное SYSMAC.HLP существует?
Что скрыто за этими вызовами?
Можно ли (имеет ли смысл) например этот тест запустить на УК-НЦ под RT-11?
Каким образом и можно ли RSXLIB использовать? - я наверное пропустил если
есть эта OBJ для RT-11? Есть ли в этой библиотеке (если её можно использовать
под RT-11), что нибудь супер крутое и полезное, описание аналогичное SYSMAC.HLP существует?
RSXLIB я описывал в теме софта, на сайте у меня вроде тоже с описанием лежит, также HELP на CTAKAHе поможет :)
На УКНЦ смысла запускать нет - там нет защиты от переполнения стека и тест просто зависнет на первой же команде.
RSXLIB я описывал в теме софта,
Я у себя нашёл папку в хламнике form_rsxlib
там вот такое вот содержание
Image : rsxlib.dsk
Format : DSK
Size : 400 Kb
Volume ID: ON (OBJECT C
Owner : OUNT)=P/
File Blocks Date Bytes
---------- ------ ----------- ----------
ARITH .MAC 6 14-Mar-2013 3'072
C5TA .MAC 4 14-Mar-2013 2'048
DARITH.MAC 6 14-Mar-2013 3'072
OD2CT .MAC 10 14-Mar-2013 5'120
SAVAL .MAC 4 14-Mar-2013 2'048
SAVRG .MAC 3 14-Mar-2013 1'536
SAVR1 .MAC 2 14-Mar-2013 1'024
SAVVR .MAC 3 14-Mar-2013 1'536
MKLIB .COM 1 14-Mar-2013 512
CBTA .MAC 13 14-Mar-2013 6'656
CDDMG .MAC 4 14-Mar-2013 2'048
CVTUC .MAC 4 14-Mar-2013 2'048
EDDAT .MAC 8 14-Mar-2013 4'096
GTTIM .MAC 4 14-Mar-2013 2'048
CATB .MAC 10 14-Mar-2013 5'120
CAT5 .MAC 6 14-Mar-2013 3'072
CAT5B .MAC 6 14-Mar-2013 3'072
EDTMG .MAC 37 14-Mar-2013 18'944
RSXLIB.OBJ 11 14-Mar-2013 5'632
< UNUSED > 644 329'728
---------- ------ ----------- ----------
19 Files, 142 Blocks
644 Free blocks
Я так понимаю это вариант для RT-11?
Надо бы описание к ней найти и в архив, я похоже начал и отвлёкся.
Поэтому и уточняю.
Здесь (http://zx-pk.ru/showpost.php?p=583946&postcount=303) и здесь (http://zx-pk.ru/showpost.php?p=583948&postcount=304) описание.
Обнаружил интересную вещь:
.TITLE TEST
.MCALL .EXIT,.PRINT ;МАКРОКОМАНДЫ
PSW =: 177776 ;PSW
START:: MOV #PVAL,R0 ;XXX: АДРЕС ДЛЯ .PRINT
MOV #4000,-(SP) ;PS
MOV #10$,-(SP) ;PC
RTI ;КУ!
10$: CLR -(SP) ;PS
MOV #20$,-(SP) ;PC
RTI ;КЮ!
20$: MOV @#PSW,R1 ;КОНВЕРТИМ
MOV #RVAL,R0 ; ЗНАЧЕНИЕ
MOV PC,R2 ; PSW
CALL $CBOMG ; В ASCII
.PRINT #PVAL ;ПЕЧАТАЕМ
.EXIT ;ВЫХОД
PVAL: .ASCII /PS=/
RVAL: .ASCIZ /XXXXXX/
.END START
Тест с помощью команды RTI устанавливает бит дополнительного набора регистров R0'-R5' и снова сбрасывает его, возвращаясь к R0-R5. И в E11 и в SimH бит успешно устанавливается, но сбросить его назад таким способом можно только в режиме ядра (тест под RT-11SB). Если процессор находится в пользовательском режиме (тест под RT-11XM), то бит устанавливается, но не сбрасывается.
.BO RT11SB
RT-11SB V05.07
.RU TEST
PS=000000
.BO RT11XM
RT-11XM V05.07
.RU TEST
PS=144000
.
Пока не знаю правильное это поведение или нет - дома проверю вечером (эх, пора управляемый дистанционный выключатель приделывать к 11/83 :)). Интересно было бы проверить это на ментековских платах.
Вычитал описании KDJ11-B (про усер моду ничего не написано): When executing in kernel mode, either a 1 or a 0 can be stored in PSW bit 11. When executing in supervisor mode, a stored 0 can be changed to a 1, but a stored 1 cannot be changed to a 0.
PS. Для hobot: $CBOMG - в оригинале из RSX, но в RT-11V5 это стандартная подпрограмма SYSLIB (хотя в доках по RT-11 она и не упоминается) ;)
Собираюсь в ближайшее время очередную порцию предложений писать по E11. В связи с этим, может ли кто сформулировать особенности выполнения некоторых команд (ASR/ASH/MUL/DIV итд) которые тут тестировались давеча (чтобы не копаться в истории), попробую кое-какие предложения протолкнуть (интересует ВМ3) :)
Вычитал описании KDJ11-B (про усер моду ничего не написано): When executing in kernel mode, either a 1 or a 0 can be stored in PSW bit 11. When executing in supervisor mode, a stored 0 can be changed to a 1, but a stored 1 cannot be changed to a 0.
Проверил на живом 11/83 - все также как в эмуляторе. Просто в документации не упомянуто, что в усер моде также.
---------- Post added at 18:24 ---------- Previous post was at 17:49 ----------
А вот это совсем не как на живом железе - так и не поправилось, надо снова пнуть :)
.TY RED.MAC
START:: MOV #160004,SP
BR .
.END START
.RU RED
%HALT
?Bad kernel stack
R0/001004 R1/000104 R2/001000 R3/105000 CM=K PM=K PRIO=7
R4/074004 R5/136316 SP/160000 PC/140602 N=0 Z=0 V=0 C=0
140602 rol @#000052
E11>
Должно быть:
.RU RED
?MON-F-Trap to 4 001004
.E 0-2
001004 000010
.
Все модели с номерами от 11/45 и выше имеют двойной набор регистров. Ой! Мне казалось, что это появилось где-нибудь на 73-й. Тогда, должен заметить, со стороны инженеров DEC это глубокий прокол.
К слову, напомню весьма интересный фавкт: официальный PDP-11 выпускался (вместе с системами) аж до 2003 года. VAXы давно померли к тому времени Вместе с какими системами? Которые управлялись посредством этой PDP-11? Неудивительно, ибо "работает - не трожь!" Intel 80386, вроде-бы, и до сих пор выпускают, примерно из тех же соображений.
Вместе с какими системами? Которые управлялись посредством этой PDP-11?
RT, RSX, RSTS...
работает - не трожь!
К сожалению у нас в стране не так :)
form, Кстати, а как пользоваться командой WAIT ? В русской литературе я так и не нашел внятного объяснения. Вот я при закрытых прерываниях проверил все флажки, все пусто, надо ждать. Я разрешаю прерывания, висящее необслуженным прерывание срабатывает. его программа взводит флаг, делает RTI, а у меня тут подоспеет команда WAIT, и все...
Классических решений этого два: либо состояние ожидания вводится одновременно с разрешением прерываний (например, у системы-360 бит ожидания входит в состав PSW и загружается одной командой LPSW вместе с битами разрешения прерываний), чего у нас нет, или команда разрешения прерываний срабатывает отложенно, после выполнения следующей за ней команды, о чем я, как раз, не нашел никаких внятных сведений. Особенно учитывая, что прерывания можно разрешить не одной командой, а несколькими (RTI, MTPS, прямой записью в регистр PS, если он есть на шине...) Так как?
Так как?
Однозначного ответа на вопрос нету. В общем случае, WAIT не предназначен для ожидания конкретного прерывания, а нужен чтобы приостановить выполнение когда делать вообще нечего до любого асинхронного прерывания. В родном софте от DEC есть немало закладок на предположения как что должно работать, что может вызвать много проблем с эмуляторами (в том числе вроде был пример на тему WAIT который никогда не выйдет). В документации по E11 целая глава посвящена этому. Примечательно, что на VAX вроде подобной команды просто нету.
Однозначного ответа на вопрос нету. То есть, похоже на еще один прокол инженеров DEC.
В общем случае, WAIT не предназначен для ожидания конкретного прерывания, а нужен чтобы приостановить выполнение когда делать вообще нечего до любого асинхронного прерывания. Естественно. Вот мой диспетчер задач проверяет все TCB (Task Control Block), все чего-то ждут, делать нечего. Логично уйти на ожидание, то есть разрешить прерывания и сделать WAIT. Однако, пока я проверял свои TCB, пришел запрос на прерывание и ждет, когда их разрешат. Я, не зная об этом, разрешаю прерывания, допустим, делаю MTPS #0, ожидающий запрос сработает, программа отметит в одном из моих TCB, что появилась работа и выйдет по RTI, а у меня следующая команда WAIT. Приплыли. В общем, не зря я ее не использовал в своих многозадачках...
Приплыли
Нет. Читаем внимательно: WAIT предназначен для выполнения когда вообще нечего делать. То есть если мы выполняем команду WAIT, значит мы и должны на ней висеть до упора пока не возникнет прерывание которое должно снять с нее. Если же таковое возникло - оно и снимет с WAIT. Все просто. Главное - не изобретать умных конструкций. Типичная работа с командой WAIT - это WAIT, BR .-2. Все.
---------- Post added at 20:31 ---------- Previous post was at 20:29 ----------
Или если так проще будет: есть процесс который ничего не делает кроме WAIT, BR .-2 который стоит в общем планировании в самом низу. Когда больше нечего делать - он и "выполняется", когда есть чего - он и не получает управления...
когда вообще нечего делать Что-то в этом есть. То есть добавить в список задач задачу NHD (нечего делать), которая всегда активна, но с минимальным приоритетом, с учетом этого всегда найдется готовая к исполнению задача. Что же, тоже вариант...
Что-то в этом есть. То есть добавить в список задач задачу NHD (нечего делать), которая всегда активна, но с минимальным приоритетом, с учетом этого всегда найдется готовая к исполнению задача. Что же, тоже вариант...
Такая задача в классических вытесняющих ОС реального времени всегда есть, называется idle.
Такая задача в классических вытесняющих ОС реального времени всегда есть, называется idle Естественно. Я тут размышляю как бы это дело прикрутить к неклассической самоделке с корпоративной (скорее, кооперативной) многозадачностью. Платформа у меня, конечно, поновее, но красивые идеи не стареют, многое, подсмотренное в недрах ОС тех времен (начиная с ДОС-360/370) легко и удобно применяется и сейчас.
Главное - не изобретать умных конструкций. Типичная работа с командой WAIT - это WAIT, BR .-2. Все. Угу. Во "взрослой" вытесняющей многозадачке, там. где диспетчер задач сам отбирает управление у любой задачи, если появилась более приоритетная. А вот в корпоративной - изба фигвам, там любая задача сама должна вернуть управление диспетчеру в тот момент, когда она считает это возможным. И с применением команды WAIT задача idle в такой системе не получается, не зря я на Э-60 делал бОльшую часть диспетчера задач при открытых прерываниях, а вместо ожидания просто зацикливал эту часть.
Во "взрослой" вытесняющей многозадачке, там. где диспетчер задач сам отбирает управление у любой задачи, если появилась более приоритетная. А вот в корпоративной - изба фигвам, там любая задача сама должна вернуть управление диспетчеру в тот момент, когда она считает это возможным. И с применением команды WAIT задача idle в такой системе не получаетсяЕсли задача idle может получить управление только при отсутствии других активных задач, то вполне очевидно, что любая другая задача может активироваться только в результате прерывания.
Если задача idle может получить управление только при отсутствии других активных задач, то вполне очевидно, что любая другая задача может активироваться только в результате прерывания.
А есть идея как придумать какую-либо причину для активации без появления какого-либо прерывания? :)
---------- Post added at 16:11 ---------- Previous post was at 16:10 ----------
сама должна вернуть управление диспетчеру
А кто мешает именно вернуть ему? :)
А уж диспетчер если надо активирует нуль-задачу которая будет на особых правах - ее сам диспетчер может снять, получив сигнал в виде прерывания (или ему сигнал передадут из хандлеров прерывания).
---------- Post added at 16:14 ---------- Previous post was at 16:11 ----------
На тему активации интересно почитать описание директивы WSIG$ - это директива в RSX-11 системах, ожидающая любого важного события (которое заставит диспетчер задач пересмотреть очередь), обычно используется в случае если не хватает ресурсов на что-нибудь, а отделаться сообщением об ошибке будет неправильно.
А есть идея как придумать какую-либо причину для активации без появления какого-либо прерывания?Об том и речь - если активной осталась только задача idle, то эта ситуация в принципе не может измениться без прерывания, а значит вполне уместно использовать WAIT.
Если задача idle может получить управление только при отсутствии других активных задач, то вполне очевидно, что любая другая задача может активироваться только в результате прерывания. Ага, а Солнце восходит на востоке.
А кто мешает именно вернуть ему? Как кто? Команда WAIT, вестимо.
Люди, вы себе плохо представляете, что такое корпоративная многозадачка. Это же просто банальный перебор таблицы задач и прямой вызов CALL'ом подпрограммы, исполняющей ту или иную задачу. Адрес которой, обычно, задан в той же таблице. Только в системах с детерминированным поведением команды ожидания, обычно, эта часть исполняется при закрытых прерываниях, прерывания разрешаются только перед CALL'ом, а если делать нечего, то вводится состояние ожидания.
На любимой PDP-11, с ее индетерминированным поведением команды WAIT, приходится перебор задач делать при открытых прерываниях, закрываются они только непосредственно перед CALL'ом для пометки "взято на исполнение" в таблице задач, каковую пометку я, обычно, делал командой TRAP.
А программы обслуживания прерываний просто отмечаются в той самой таблице задач, и все.
Люди, вы себе плохо представляете, что такое корпоративная многозадачка. Это же просто банальный перебор таблицы задач и прямой вызов CALL'ом подпрограммы, исполняющей ту или иную задачу.Если в такой системе есть синхронные системные вызовы, то это Вы не вполне представляете, что такое корпоративная многозадачка. Потому что смысл синхронности системного вызова как раз в том, что управление не может быть возвращено в сделавшую вызов задачу до завершения обработки вызова в ядре. В результате рано или поздно складывается ситуация, когда все задачи ждут завершения системных вызовов и не могут быть вызваны. В такой ситуации вызывается задача idle.
В какой бы момент не произошло прерывание - выход из прерывания не может произойти в задачу idle, поэтому использование там команды WAIT совершенно безопасно. Если выход из прерывания может сразу попасть в задачу idle - значит система содержит ошибки. В нормально работающей системе возврат из прерывания сразу в задачу idle без "захода в ядро" абсолютно невозможен при любых раскладах.
Если в такой системе есть синхронные системные вызовы, то это Вы не вполне представляете, что такое корпоративная многозадачка. А если их нет? Да и если есть, то такая система, обычно, планируется так, что все задачи короткие. Получила задача управление, занесла что-то в регистр УСО (устройство сопряжения с объектом), посмотрела что из этого вышло, отметилась где-то и RETURN, назад в диспетчер. Если нужно ждать какое-то время, активируется другая задача, то есть переводится из состояния "не запускать никогда" в состояние "запустить через, допустим, 0.1 сек", а она, будучи запущенной, проверит, что надо, результат куда-то занесет и дезактивируется, т.е. снова поставит себе "не запускать никогда". Да, это делается синхронным системным вызовом, но, опять же, мгновенным, несколько команд при закрытых прерываниях, и все, Return, назад в диспетчер.
Жаль, не сохранилась одна моя программуля, там подобная многозадачка была накручена не на голом железе, а под RT11SJ, работало оно примерно так же, но еще писались на диск и печатались на принтер логи работы, пришлось разобраться и использовать .READC, .WRITC. Довольно забавно смотрелось: кончилась бумага на принтере, на экране у оператора мигает надпись "Заправь бумагу", остальное все весело работает. Вставишь пистон оператору, чтобы не зевал, зарядят бумагу, и полез лог за полчаса, а то и час работы, остальное весело продолжает работать, как будто ничего и не случилось.
Увы, от нее остался только листинг, на бумаге, причем в поганом качестве, страниц 50, из которых половина - комментарии, откомментировал я ее, помню, не хуже, чем откомментирована RT-11 (то, что на бонусных дистрибутивах). Но увы...
все задачи короткие. Получила задача управление, занесла что-то в регистр УСО (устройство сопряжения с объектом), посмотрела что из этого вышло, отметилась где-то и RETURN, назад в диспетчер.Если в системе нет состояния idle, то нет и такой задачи, а значит нет и возможности использовать там команду WAIT. Если же в системе есть состояние idle, то использование команды WAIT в соответствующей задаче совершенно безопасно.
Дело лишь за тем, чтобы прерывания возвращались не в прерванное место, а сначала в проверку состояния - тогда у прерывания не будет возможности ошибочно вернуться в задачу idle ни до выполнения там команды WAIT, ни после.
Дело лишь за тем, чтобы прерывания возвращались не в прерванное место, а сначала в проверку состояния - тогда у прерывания не будет возможности ошибочно вернуться в задачу idle ни до выполнения там команды WAIT, ни после. То есть принудительно отобрать управление у задачи IDLE. Вообще-то, принудительно отбирать управление - это характерно для вытесняющих ОС. То есть, конечно, можно изобрести и такой "гибрид", когда нормальные задачи возвращают управление сами, а у задачи idle управление отбирается принудительно, но это, как я подозреваю, сильно нарушит общую стройность системы. А отбирать управление у любой задачи - это означает свой стек и пр. области сохранения у каждой задачи и прочие усложнения, в итоге получится та же вытесняющая многозадачка, только самодельная...
Ладно, в то время это было неважно, все эти Э-60 и ДВК имели только сетевое питание и состояние ожидания применялось разве что для самоуспокоения - ни на энергопотребление оборудования, ни на надежность, ни на что другое оно не влияло. Это актуально сейчас, на микроконтроллерах с батарейным питанием, где вовремя выданная команда SLEEP может существенно сэкономить расход энергии батареек, но у них поведение команды ожидания строго детерминировано. По крайней мере у тех, с кем я имел дело.
Это пока только пристрелочный вариант... На данном этапе прога временная просто выясняет отличия E11 от реальности (готовлю очередное письмо). В дальнейшем планируется сканировать процессор на всевозможные фичи (в том числе невозможные в реальной жизни) и определять тип процессора полным сравнением всех фич, а не последовательным отсеканием.
На 11/83 результат такой:
.RU CPFEAT
MFPT value : 005
Maintenance register (177750) value : 000445
PS address (177776) implemented : Yes
Stack limit register (177774) : No
PIRQ register (177772) : Yes
Memory management unit : Yes
Supervisor mode : Yes
Split I/D space : Yes
Multiple interrupt levels : Yes
Dual register set : Yes
Odd address trap : Yes
OPR (R)+ increments R for non-existent address : Yes
OPR R,(R)+ uses R+2 as the source operand : Yes
OPR R,-(R) uses R-2 as the source operand : Yes
OPR PC,X(R) uses PC+4 as the source operand : No
JMP (R)+/JSR reg,(R)+ uses R+2 as the new PC value : No
JMP R/JSR reg,R traps to : 010
SWAB clears V bit : Yes
Direct access to PS can load T bit : No
RTI works like RTT : No
SOB/SXT instructions : Yes
MARK instruction : Yes
RTT instruction : Yes
MUL/DIV/ASH/ASHC instructios : Yes
XOR instruction : Yes
FADD/FSUB/FMUL/FDIV instructions : No
SPL instruction : Yes
MFPS/MTPS instructions : Yes
TSTSET/WRTLCK instructions : Yes
Ну и сразу видно, что некоторые отличия от E11 пропали, некоторые еще есть:
form@diag:/tmp$ diff -duN 1183.txt e11.txt |grep -- '^[+-]'
--- 1183.txt 2015-04-21 16:23:18.792107017 +0600
+++ e11.txt 2015-04-21 16:23:39.292275880 +0600
-OPR (R)+ increments R for non-existent address : Yes
+OPR (R)+ increments R for non-existent address : No
form@diag:/tmp$
OPR (R)+ increments R for non-existent address : YesНадо бы проверять еще и @(R)+.
В эмуляторе ДВК долгое время (R)+ отрабатывался при TRAP4 правильно, а @(R)+ отрабатывался неправильно.
Надо бы проверять еще и @(R)+.
Я их специально убрал пока чтобы сократить. В реальной жизни (R)+, @(R)+, -(R), @-(R) реакция совпадает. Также команды сначала раздельно тестировал, потом сгруппировал (не все - к примеру SOB, SXT, MARK, RTT - команды из одного файла, но в E11 они разделены). В окончательном варианте все будет тестироваться раздельно и сниматься этакий слепок опций.
---------- Post added at 20:28 ---------- Previous post was at 20:25 ----------
Ну и вообще принимаются идеи. Официальная таблица отличий есть в приложении к описанию DCJ11 (http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/dec/pdp11/1173/EK-DCJ11-UG-PRE_J11ug_Oct83.pdf). Некоторые моменты также затронуты в описании E11 (в списке опций SET CPU).
...
В ходе исследований V-модели процессора 1801ВМ1 выяснилось, что проверка IRQ в цикле DATIO производится до фазы записи, а в цикле DATO - после. Это означает, что команда MOV #100, @#TTPS должна вызывать прерывание сразу, тогда как команда BIS #100, @#TTPS вызывает прерывание только через одну команду.
Для натурной проверки данного факта написан тест: IRQT1.SAV (http://emulator.pdp-11.org.ru/misc/IRQT1.zip), который надо бы прогнать на процессорах 1801ВМ1, 1801ВМ2 и 1801ВМ3.
Прогон теста в текущей версии эмулятора ДВК даёт такой результат:
.RU IRQT1
Interrupts Test #1
BIS #100, @#TTPS
NOP
>>> Interrupt <<<
MOV #100, @#TTPS
NOP
>>> Interrupt <<<
Program completed.
.
Результат теста на ВМ3 аналогичен результата теста эмулятора.
- - - Добавлено - - -
На ВМ2 аналогично.
Результат аналогиченЭто удачно - не придётся усложнять эмуляцию.
Patron, в одном из эмуляторов BK11M под местной RT-11 (ОСБК которая),
результат теста такой?
http://storage5.static.itmages.ru/i/15/1121/h_1448105472_2411657_69a8489748.png
автору эмулятора сообщить бы, что ВМ1 у него по прежнему не полный?
Хорошо бы ссылку ему кинуть на этот тест с комментарием, что бы сразу.
- - - Добавлено - - -
На Ук-Нц живой я так понял уже нет смысла запускать, MIX, вроде бы ВМ2 прогнал?
в одном из эмуляторов BK11M под местной RT-11 (ОСБК которая),
результат теста такой?
http://storage5.static.itmages.ru/i/15/1121/h_1448105472_2411657_69a8489748.png
автору эмулятора сообщить бы, что ВМ1 у него по прежнему не полный?
А причем тут ВМ1, если в БК нет регистров 177560-177566.
На Ук-Нц живой я так понял уже нет смысла запускатьКак раз есть. Чтобы прерывание возникло сразу после команды MOV #100, @#TTPS - терминал должен выставить IRQ в течении 4 тактов после считывания с шины нового содержимого регистра статуса. Вдруг, в УКНЦ это происходит быстрее, чем в ДВК.
http://storage2.static.itmages.ru/i/15/1121/s_1448110372_7059820_d4b62e8f6d.jpg (http://itmages.ru/image/view/3223360/d4b62e8f)
Съедается левая часть экрана - пока не победил, но планирую.
6105 подрубать лень, в ТВ быстрее подключаться, приходится терпеть неудобства.
Съедается левая часть экрана.Там видно, что в обоих случаях прерывание происходит не сразу, а минимум через одну команду ( так как на самом деле в тесте следующей идёт не команда Nop, а команда Trap 0 с выводом строчки "NOP" в обработчике - то даже отставание выставления IRQ на десять команд не даст другого результата ).
...
Как правильно эмулировать команду MARK, что происходит с R5, R6 и R7, когда команда MARK находится не в стеке, а среди других команд в потоке выполнения.
Ответ даёт тест: MARK.SAV (http://emulator.pdp-11.org.ru/misc/MARK.zip)
Результат запуска на V-модели процессора 1801ВМ1 такой:
.RU MARK
MARK command test.
R5/001044
SP/001000
PC/001036
001036: MARK 1
001040: 123
001042: 456
001044:
R5/000456
SP/001044
PC/001044
Program completed.
.
что происходит с R5, R6 и R7, когда команда MARK находится не в стеке
В сущности то же самое что и когда в стеке. У команды MARK нет абсолютно никаких особенностей касаемо стека - CPU наступает на команду штатным образом через PC независимо от способа применения...
В сущности то же самое что и когда в стеке.Просто, если при эмуляции следовать некоторым описаниям команды MARK - новое значение SP должно получаться из старого значения SP, а на самом деле - старое значение SP выбрасывается, а новое значение SP получается из значения PC в момент выполнения команды MARK.
Когда команда MARK лежит в стеке - значения SP и PC в момент выполнения команды MARK совпадают, поэтому неправильная эмуляция MARK ( на основе неправильного описания ) даёт корректный результат. Но когда команда MARK не в стеке - неправильная эмуляция даёт неправильный результат.
новое значение SP должно получаться из старого значения SP, а на самом деле - старое значение SP выбрасывается
Это какое-то неправильное описание. Новое значение вычисляется как SP=PC+2xNN.
Точнее для полноты картины: SP=PC+2*NN, PC=R5, R5=(SP)+
- - - Добавлено - - -
Результат запуска на V-модели процессора 1801ВМ1 такой
В точности как на 11/83.
...
Известно, что T-trap произойдёт через одну команду после команды RTT, даже если выполненная после RTT команда очистит T-бит.
http://pic.pdp-11.ru/images/rtt.png
Но что случится, если следующая команда - ещё одна RTT, которая снова установит бит T.
Ответ даёт тест: RTT.SAV (http://emulator.pdp-11.org.ru/misc/RTT.zip)
Результат выполнения на V-модели процессора 1801ВМ1 такой:
.RU RTT
RTT command test.
RTT ; 020 -> PSW
RTT ; 020 -> PSW
RTT ; 020 -> PSW
RTI ; 000 -> PSW
>>> Trap to 014 <<<
Program completed.
.
При выполнении последовательности команд RTT, каждая из которых устанавливает бит T - процессор 1801ВМ1 полностью блокирует прерывания и выполняет первый T-trap только через одну команду после завершения последовательности.
Ответ даёт тест: RTT.SAV
.RU RTT
RTT command test.
RTT ; 020 -> PSW
RTT ; 020 -> PSW
RTT ; 020 -> PSW
RTI ; 000 -> PSW
Program completed.
.
На процессоре ВМ2 тесты MARK,RTT аналогичны.
На ВМ3 тест MARK аналогичен, RTT прошел без TRAP to 014.
Кстати, а как соотносятся страница ввода-вывода и последние 8К из 4М мозгов? В смысле, можно ли достучаться до этих последних 8К, или, все-таки, максимальная память при 22-битном адресе не 4096К, а 4088К ?
Кстати, а как соотносятся страница ввода-вывода и последние 8К из 4М мозгов? В смысле, можно ли достучаться до этих последних 8К, или, все-таки, максимальная память при 22-битном адресе не 4096К, а 4088К ?
Специально вопрос не изучал, но возможно к PMI памяти можно достучаться перемапив ее через CSR памяти. К обычной Q-Busной не получится...
Специально вопрос не изучал, но возможно к PMI памяти можно достучаться перемапив ее через CSR памяти. К обычной Q-Busной не получится... Это я вентилирую вопрос об использовании кусочка из этой страницы в качестве halt-mode RAM, в случае самопального изготовления процессорного модуля с ВМ3. А то еще и halt-mode ROM, предварительно загрузив туда сторонними средствами 377-ю прошивку и сделав ее для ЦП Read Only...
самопального изготовления процессорного модуля
Ну при самопальном изготовлении наверное много чего можно сделать :)
.
В ходе изучения документации по процессору 1801ВМ3 возникло подозрение, что могут существовать версии ВМ3 с различным количеством видимых на шине регистров PARH - 4, 2 или 1. Было бы полезно запустить на всех доступных ВМ3 утилиту IOSCAN (http://emulator.pdp-11.org.ru/misc/IOSCAN.zip) ( SAV или BIN - кому как удобнее ) и опубликовать результаты.
регистров PARH - 4, 2 или 1
А это что за регистры такие с таким количеством?
.
могут существовать версии ВМ3 с различным количеством видимых на шине регистров PARH - 4, 2 или 1. Было бы полезно запустить на всех доступных ВМ3 утилиту IOSCAN (http://emulator.pdp-11.org.ru/misc/IOSCAN.zip) ( SAV или BIN - кому как удобнее ) и опубликовать результаты.
Там в сканере какие-то особености есть? Я запускал просто чтение, с проверкой исключения по тайм-ауту шины, на двух 1801ВМ3 1992 года найдены только PARH2 по адресу 17772512. Вот тут (http://zx-pk.ru/showthread.php?t=21192&p=846024&viewfull=1#post846024) полные результаты сканирования. У меня еще есть процессор 1989 года, но он далеко сейчас. Точно было минимум две ревизии кристалла ВМ3, потому что исправлен ряд ошибок, Полетаев на каком-то форуме писал, сохранилось такое:
1. Процессоры выпуска до середины 1989 года (приблизительно - дату точно не
помню) имели ошибку в командах MFPD/MTPD - они отрабатывались как байтовые.
Из-за них не работал TSX. Ошибка обходилась заменой на команды MTPI/MFPI.
Следующие ошибки, насколько мне известно, остались неустраненными.
2. Ошибка в реализации команд MTPI/MTPD. Согласно PDP11 processor handbook
эти команды должны выполняться следующим образом:
(temp) <- (SP)+; (dst) <- (temp).
В 1801ВМ3 команда выполняется без использования промежуточного регистра.
Проявляется в случае выполнения команды MTPI SP при совпадении текущего и
предыдущего режимов работы процессора - значение указателя стека оказывается
на 2 большим. Влияние на программное обеспечение не отмечено.
3. Ошибка в реализации диспетчера памяти. В каком-то из регистров ДП (к
сожалению, сейчас уже не помню - давно это было) зарезервированные биты
>> 017772516 - MMU SR3
читались единицами, а не нулями. Из-за этого не запускался UNIX (ДЕМОС),
обошли корректировкой исходных текстов.
>> в Ultrix достаточно попpавить загpyзчик. Код, пеpедающий тип пpоцессоpа
>> ядpy.
4. Ошибка в реализации диспетчера памяти. При возникновении прерывания от ДП
в регистрах диспетчера фиксировался неправильный адрес команды. Hе шли родные
тесты ДП. Подробности не помню.
Есть 2 базовые модификации 1801ВМ3 - 1986 г. и 1990 г. ( вторая половина года ).
*
Можно ли поконкретней о наличии/отсуствии регистров - какие должны быть их адреса и в каких режимах процессора ?
*
Если в руководстве по процессору написано о разных регистрах - вполне вероятно, там просто перепечатка с СМ4.
( Это как в описании команд RT-11 для БК0011 версии 1988 г. - "щелкните средним переключателем !" ).
читались единицами, а не нулями. Из-за этого не запускался UNIX (ДЕМОС)
Наконец-то найдена та система которая из-за этого неработала!
А то мне пытались всучить мифы - мол RSX из-за этого не работает (почему - объяснить не смогли разумеется ибо даже придумать сложно) :)
- - - Добавлено - - -
в Ultrix достаточно попpавить загpyзчик
Или после его останова записать тип процессора в R0 и нажать P.
- - - Добавлено - - -
Ошибка в реализации диспетчера памяти. При возникновении прерывания от ДП
в регистрах диспетчера фиксировался неправильный адрес команды
А это в принципе так на некоторых процессорах. В списке неоднозначностей в описании DCJ11 есть.
- - - Добавлено - - -
Из-за них не работал TSX
Уточним - вероятно имеется в виду TSX-Plus (причем возможно даже достаточно поздних версий). То, что называлось просто TSX (РАФОС/TS к примеру) понятия не имело о разделении I/D пространства и о командах MxPD.
- - - Добавлено - - -
PARH2 по адресу 17772512
А что за регистр(ы) то?
А что за регистр(ы) то?
Это вроде особенность 1801ВМ3 - регистр базового ядреса для режима пульта. Их там должно было быть четыре штуки, выбираются в режиме пульта старшими битами виртуального адреса VA15-VA14. Но PARH0, PARH1 и PARH3 заменили константами, остался только PARH2.
Там в сканере какие-то особености есть? Я запускал просто чтение, с проверкой исключения по тайм-ауту шины, на двух 1801ВМ3 1992 года найдены только PARH2 по адресу 17772512. Вот тут (http://zx-pk.ru/showthread.php?t=21192&p=846024&viewfull=1#post846024) полные результаты сканирования.Сканер просто ищет адреса на шине - никаких особенностей нет.
регистр базового ядреса для режима пульта
Ага, теперь понял.
Можно ли поконкретней о наличии/отсуствии регистров - какие должны быть их адреса и в каких режимах процессора ?Про младшие версии ВМ3 - не известно ничего.
В старших версиях ВМ3 - на шине всегда есть PARH2 по виртуальному адресу 172512, но в некоторых документах говорится и про доступный PARH3 ( логично предположить, что по адресу 172514 ).
- - - Добавлено - - -
Из описания первой версии процессора 1801ВМ3 похоже, что при разработке для него материнской платы - память режима HALT может быть реализована двумя способами:
1. Только с использованием сигналов шины. В этом случае 8К с адреса 16760000 отводятся под ОЗУ пульта, которое в режиме HALT проецируется через регистр PARH1 в страницы 40000-57777 и 60000-77777, а 8К с адреса 17000000 - под ПЗУ пульта, которое в режиме HALT проецируется через регистр PARH0 в страницы 00000-17777 и 20000-37777.
2. С использованием сигнала SEL. Тогда при активном сигнале SEL младшие 13 битов адреса ( 00000-17777 ) делятся на начальные 6К адресов ПЗУ пульта ( 00000-13777 ) и конечные 2К адресов ОЗУ пульта ( 14000-17777 ).
Код прошивки -134 ( насколько я понял ) удовлетворяет обоим вариантам, занимая только младшие 6К адресов ПЗУ и используя только последние 512 байтов ОЗУ, обращение к которым идёт по виртуальным адресам 77000-77777.
Не исключено, что в старших версиях 1801ВМ3, предусматривающих использование 4М ОЗУ - внутренние регистры PARH0 и PARH1 настроены так, чтобы в режиме HALT проецировать последние не доступные в обычном режиме 8К физических адресов шины 17760000-17777777 в страницы виртуальных адресов 00000-17777, 20000-37777, 40000-57777 и 60000-77777. Тогда разработчик материнской платы может по-прежнему использовать в режиме HALT только сигналы шины и прошивку -134.
PARH0, PARH1 и PARH3 заменили константамиПри организации режима пульта с использованием сигнала SEL - результат работы PARH0 и PARH1 никак не используется, поэтому было бы весьма интересно узнать, какие физические адреса формирует на шине новый ВМ3 при обращении в режиме пульта к виртуальным адресам из диапазонов PARH0 и PARH1.
Не исключено, что в старших версиях 1801ВМ3, предусматривающих использование 4М ОЗУ - внутренние регистры PARH0 и PARH1 настроены так, чтобы в режиме HALT проецировать последние не доступные в обычном режиме 8К физических адресов шины 17760000-17777777 в страницы виртуальных адресов 00000-17777, 20000-37777, 40000-57777 и 60000-77777. Тогда разработчик материнской платы может по-прежнему использовать в режиме HALT только сигналы шины и прошивку -134 ( поскольку память при включении обнуляется, а ПЗУ в старших 2К содержит нули - 8К ОЗУ и 8К ПЗУ могут работать в старшем банке параллельно ).
1. Где-то есть ТО именно 1801ВМ3 ?
2. Посоветую приобрести у меня блок ВМ3А для БК0011/М - это позволит получить ответы на много вопросов, причем весьма неожиданные !
( Могу собрать за 1-2 недели, с зелеными КМ5 ! ).
3. Зона адресов BS7 не проецируется куда-либо во всех режимах, по крайней мере в 1801ВМ3 ( с 1806ВМ5 - неизвестно ).
.
Как выяснилось (http://bk0010.org/forum/?id=4442) - у всех версий 1801ВМ3 стек режима HALT инициализируется константой 020000 ( а не 0100000, как указано в описаниях ), поэтому реализация режима пульта без совмещения ПЗУ и ОЗУ в одном банке 8К в принципе невозможна ( так как стек с вершиной 017776 мапится через PARH0 в те же 8К адресов, что и ПЗУ ).
Тем интереснее узнать, какие физические адреса формируются на шине реального ВМ3 при обращении в режиме пульта к адресам 000000, 020000, 040000, 060000.
Прогнали IOSCAN на ДВК-4 у Andrey_Ak. Тут один регистр.
172140-172142 MY
172300-172316 KISDR0-KISDR7
172340-172356 KISAR0-KISAR7
172512
172516 MMR3
174000-174020 DW
176560-176566 YL
177514-177516 LP
177560-177566 YL
177572-177616 MMR0-MMR2, UISDR0-UISDR7
177640-177656 UISAR0-UISAR7
177776 PSW
.
Как выяснилось (http://bk0010.org/forum/?id=4442) - у всех версий 1801ВМ3 стек режима HALT инициализируется константой 020000 ( а не 0100000, как указано в описаниях ), поэтому реализация режима пульта без совмещения ПЗУ и ОЗУ в одном банке 8К в принципе невозможна ( так как стек с вершиной 017776 мапится через PARH0 в те же 8К адресов, что и ПЗУ ).
Тем интереснее узнать, какие физические адреса формируются на шине реального ВМ3 при обращении в режиме пульта к адресам 000000, 020000, 040000, 060000.
Насчет "100000" - это из фрагментов ТО 1836ВМ3, в реальном на 1801ВМ3 было указано 20000 ( 8 ).
На том же форуме в ветке о блоке ВМ3А господин gid писал о исследовании адресного пространства процессора 1801ВМ3 в некотрых режимах - результаты довольно интересны.
Прогнали IOSCAN на ДВК-4 у Andrey_Ak
Ну и попутно еще раз проверили, что MY работает если ему команды из пульта подавать. Не так давно у кого-то пробовали - там из пульта была ошибка, а если программу запустить - работало, кто-то объяснял это особенностями режима HALT. Я так понимаю это как раз зависит от реализации HALT способами описанными выше...
Кстати, люди, а про прошивку 377 вы не забыли?
Кстати, люди, а про прошивку 377 вы не забыли?Судя по коду прошивки 377 - её авторы не беспокоились об идеологической стройности обращений к памяти. Хотя ОЗУ пульта имеет размер всего 256 слов, но из-за того, что эти 256 слов одинаково откликаются в 16 разных диапазонах адресов - обращаться к каждому слову ОЗУ пульта можно 16-ю разными способами.
В прошивке 134 все обращения к ОЗУ пульта идут через диапазон адресов 77000-77777.
В прошивке 377 обращения к ОЗУ пульта идут через диапазоны 14000-14777 и 77000-77777, а также одно обращение ( скорее всего по оплошности ) идёт через адрес 17006 :
ROM:002022 Mov #3522, @#17006
...
ROM:004732 Mov #3522, @#77006
Тем интереснее узнать, какие физические адреса формируются на шине реального ВМ3 при обращении в режиме пульта к адресам 000000, 020000, 040000, 060000.
@000000/000000
@020000/000000
@040000/000000
@060000/077406
@000000/000000
@020000/000000
@040000/000000
@060000/077406Физические адреса на шине можно посмотреть только логическим анализатором.
Лучше узнать состояние регистров сразу после включения питания, для чего можно после включения питания вставить в терминале следующий скрипт:
R0/
R1/
R2/
R3/
R4/
R5/
R6/
R7/
RS/
M
R0/000000
R1/001122
R2/000000
R3/177000
R4/100003
R5/114000
R6/016770
R7/001000
RS/000344
M
HALT INSTRUCTION
Довольно любопытно, особенно содержимое R6, R7 и RS.
Теперь есть смысл проверить, что находится в памяти сразу после включения, для чего можно использовать такой скрипт:
/
24/
26/
1000/
0/¬
¬
¬
74/¬
¬
¬
174/¬
¬
¬
274/¬
¬
¬
374/¬
¬
¬
574/¬
¬
¬
774/¬
¬
¬
1374/¬
¬
¬
1774/¬
¬
¬
2774/¬
¬
¬
3774/¬
¬
¬
7774/¬
¬
¬
17774/¬
¬
¬
137774/¬
¬
¬
¬
Patron, Честно говоря, я уже не помню как скрипт вставить. Да и как пульт поймет знак "ячейка вверх".
В МС1201.03 с 134-й ПЗУ при стандартном включении питания ( без режима пульта ) в районе 010000 адресов есть изрядный кусок контента 134-й ПЗУ.
Именно он пишет "Доступно х ОЗУ ".
Реально можно посмотреть состояние ДОЗУ МС1201.03 только после пуска в режиме "Пульт", и то 100% уверенности, что туда ничего не записано, нет.
*
По итогам всевозможных экспериментов для МС1201.03/04 с 134 ПЗУ определили, что выполнить программу пользователя в режиме пульта невозможно ( имеется ввиду в СОЗУ платы МС1201.03/04 ). Единственный выход - навесить двухадресное ( в 0 адресе пульта и в районе высших адресов одновременно ) СОЗУ на адреса 0-14000 и эксперементировать с его контентом, переодически выключая колодку ПЗУ 134 ( 23-й ногой ) .
не помню как скрипт вставить. Да и как пульт поймет знак "ячейка вверх".Для вставки из буфера обмена в эмуляторе VT52 надо нажать <Shift><Insert>. Там не "ячейка вверх", а специальный символ, который при вставке из буфера обмена превращается в код <ПС>.
После вставки вот:
@/000000
@6100/000000
@7
00006102/000000
00006104/000000
00006106/000000
@7
00006110/000000
00006112/000000
00006114/000000 4
Где-то надо скорость ввода уменьшить.
После вставкиИдея понятна - ОЗУ платы МС1201.03 после включения обнуляется.
Похоже, что пульт не успевает отрабатывать со скоростью вставки из буфера обмена, поэтому есть смысл вручную проверить после включения следующие адреса:
0/
4/
24/
26/
1000/
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot