Просмотр полной версии : Особенности процессоров и устройств архитектуры PDP-11. Тесты. Диагностика.
Страницы :
1
2
3
4
5
[
6]
7
8
9
10
следующие адреса:
Везде нули.
Везде нули.Получается, что старт процессора 1801ВМ3 при W0 == 0 и при W0 == 1 ( в зависимости от положения переключателя SA1.1 ) отличается только значением, загружаемым в PC ( при обычном включении старт происходит с адреса 776, а при автозагрузке - с адреса 173000 ). В PSW в обоих случаях помещается значение 340.
Patron, При положении переключателя SA1.1 в 1 получается вот:
****
@007732
@0/000000
@4/077004
@24/000000
@26/000000
@1000/000761
Можно проверить, каким будет адрес останова и сохранённое значение PC , если после включения выполнить в пульте запуск с адреса 776:
776G
R7/
- - - Добавлено - - -
При положении переключателя SA1.1 в 1 получается вотПЗУ автозагрузки по адресу 173000 всё равно нет, поэтому там возникает прерывание зависания.
По адресу 4 пульт показал содержимое ПЗУ пульта - похоже на какие-то глюки режима пульта.
выполнить в пульте запуск с адреса 776:
При SA1.1 в 0
@776G
@ 001000
@R7/001000
При SA1.1 в 1
Бесконечная трансляция:
@776G
@ 001000
@G
@ 000002
@G
@ 000002
@G
@ 000002
@G
@ 000002
@G
@ 000002
@G
@ 000002
@G
.......
После на кнопки УСТ,ПУЛЬТ и ТАЙМЕР не реагирует.
При SA1.1 в 1 в пульте после включения можно нажать M, чтобы узнать причину вылета в пульт.
Похоже, что отсутствие ПЗУ автозагрузки по адресу 173000 так огорчает плату при попытке старта с W0 == 1, что плата начинает активно глючить.
Очень интересно, а что предполагается узнать с помощью действий в нескольких вышестоящих постах ?
*
Если необходим экстрим - можно паялом подать "общий" на выв "SEL 35 " 1801ВМ3. По идее, ДОЗУ при этом будет недоступно, но зато появится возможность посмотреть на ПЗУ и СОЗУ вживую. Процессор перенесет это мероприятие.
похоже на какие-то глюки режима пульта.
Да не, для меня пульт это когда "собачка" видна, при этом надо бы указывать на то что нужно ещё и кнопку ПУЛЬТ нажимать. :)
Если включить питание при нажатой кнопке ПУЛЬТ - вход в пульт должен произойти до выполнения команды HALT по адресу 776 и тогда сохранённое значение PC должно быть не 1000, а 776 - это тоже можно проверить.
- - - Добавлено - - -
Да не, для меня пульт это когда "собачка" видна, при этом надо бы указывать на то что нужно ещё надо и кнопку ПУЛЬТ нажимать.Для процессора тоже. Всё предыдущее обсуждение подразумевало, что кнопку ПУЛЬТ нажимать не надо. Процессор переходит в режим пульта после выполнения команды HALT, а поскольку после включения питания командой HALT заполнены все ячейки ОЗУ - избежать попадания в режим пульта процессору нелегко ( единственный шанс - старт в ПЗУ автозагрузки при его наличии ).
С включенной кнопкой пульт.
@776G
@ 000776
@R7/000776
Очень интересно, а что предполагается узнать с помощью действий в нескольких вышестоящих постах ?Предполагается узнать, как происходит штатный старт процессора 1801ВМ3. В документации указано, что при W0 == 0 в PC помещается содержимое ячейки 24, а в PSW - содержимое ячейки 26, но как выяснилось - это чепуха и старт процессора 1801ВМ3 происходит путём загрузки констант в PC и PSW, причём при W0 == 1 в PC грузится 173000, а что грузится в PC при W0 == 0 - как раз и выяснялось выше ( весьма похоже, что это значение 000776 ).
А может быть и так, что при W0 == 0 в PC вообще ничего не грузится и процессор стартует со случайного адреса, но чтобы это уточнить - надо проверить начальное значение PC у нескольких экземпляров 1801ВМ3.
- - - Добавлено - - -
С включенной кнопкой пультНадо просто посмотреть, что напишет плата при старте с нажатой кнопкой ПУЛЬТ и проверить сохранённое значение R7.
Типа такого:
****** ДОСТУПНОЕ ОЗУ - 256 K *
@ 000776
@R7/000776
Предполагается узнать, как происходит штатный старт процессора 1801ВМ3. В документации указано, что при W0 == 0 в PC помещается содержимое ячейки 24, а в PSW - содержимое ячейки 26, но как выяснилось - это чепуха и старт процессора 1801ВМ3 происходит путём загрузки констант в PC и PSW, причём при W0 == 1 в PC грузится 173000, а что грузится в PC при W0 == 0 - как раз и выяснялось выше ( весьма похоже, что 776 ).
Нет, всё происходит в соответсвии с описанием. Я лично проверял это на блоке ВМ3А.
Есть 4 режима пуска :
1. Есть заданный режим "Пульт" ( выключателем ) , сигнал WO установлен на пуск со 173000 адреса ----> произойдет пуск с адреса 000000 пультовой области памяти.
2. Нет заданного режима "Пульт" ( выключателем ), сигнал WO установлен на пуск с адреса 173000 ----> произойдет пуск со 173000 адреса ( загрузчик пользователя )
3. Есть заданный режим "Пульт" ( выключателем ), сигнал WO установлен на пуск с вектора 24 ----> произойдет пуск с вектора 24 пультовой памяти.
4. Нет заданного режима "Пульт" ( выключателем ), сигнал WO установлен на пуск с вектора 24 ----> произойдет пуск с вектора 24 памяти пользователя.
Проверялось хрен знает сколько раз.
Однако, на платах серии МС1201.03/04 могут быть различные ухищрения, но что касается собственно БИС процессора 1801ВМ3 - нет вариантов, см. п.1-п.4.
- - - Добавлено - - -
П.С.
Если в п.2 нет ответа с 173000 адреса - то произойдет трап то 4. ( указатель стека = ? )
Если в п.2. есть ответ от 173000 адреса, но там "000000" - вывалится в пульт.
3. Есть заданный режим "Пульт" ( выключателем ), сигнал WO установлен на пуск с вектора 24 ----> произойдет пуск с вектора 24 пультовой памяти.С прошивкой 377 такое невозможно - адрес 24 пультовой памяти там занят кодом программы пульта. Значит ли это, что процессор 1801ВМ3 не может штатно работать с прошивкой 377 ?
- - - Добавлено - - -
Вообще, при активном сигнале HALT - процессор всегда стартует с адреса 000000 режима HALT, предварительно записав содержимое PSW и PC в стек пульта.
С прошивкой 377 такое невозможно - адрес 24 пультовой памяти там занят кодом программы пульта. Значит ли это, что процессор 1801ВМ3 не может штатно работать с прошивкой 377 ?
П.1...п.4 - это режимы пуска собственно БИС 1801ВМ3. В пультовом адресном пространстве может располагаться всё, что угодно. Например, ПЗУ 377.
Можно, для примера, выложить скриншот эмулятора ДВК с программой DESS, в которой рассматриваются адреса 0-377 прошивки 377 ?
- - - Добавлено - - -
Вообще, при активном сигнале HALT - процессор всегда стартует с адреса 000000 режима HALT, предварительно записав содержимое PSW и PC в стек пульта.
Я могу на днях дополнительно проверить этот момент.
адреса 0-377 прошивки 377 ?Можно посмотреть в файле прошивки: 377.rar (http://forum.maxiol.com/index.php?act=Attach&type=post&id=6200)
Я могу на днях дополнительно проверить этот момент.Заодно можно проверить, какие значения PС и PSW попадают при этом в стек пульта.
http://storage2.static.itmages.ru/i/16/0120/h_1453332335_3208311_3a6b473475.jpg (http://itmages.ru/image/view/3427537/3a6b4734)
А без компресса, в объеме 8 килобайт ( 8192 байт ) никак нельзя выложить, на Облаке Майл.ру ?
А без компресса, в объеме 8 килобайт ( 8192 байт ) никак нельзя выложить?Попробуем ещё разок в архиве, но уже не RAR, а ZIP:
377.zip (http://emulator.pdp-11.org.ru/misc/377.zip)
http://storage6.static.itmages.ru/i/16/0120/h_1453332896_2413433_a9447f0eb9.jpg (http://itmages.ru/image/view/3427541/a9447f0e)
- - - Добавлено - - -
Разумеется, при ( вероятном ) пуске с 24-го вектора пультовой памяти ( т.е. ПЗУ 377 ) произойдет передача на 3606 адрес ПЗУ 377 :
http://storage9.static.itmages.ru/i/16/0120/h_1453333208_5432127_46f9c6bc84.jpg (http://itmages.ru/image/view/3427544/46f9c6bc)
Разумеется, при ( вероятном ) пуске с 24-го вектора пультовой памяти ( т.е. ПЗУ 377 ) произойдет передача на 3606 адрес ПЗУ 377
Ячейка 24 прошивки 377 содержит значение 3604. Адрес 3604 прошивки 377 содержит константу 177564, которая интерпретируется как команда: LdCFD 100406(R4), AC1
Ячейка 24 прошивки 377 содержит значение 3604. Адрес 3604 прошивки 377 содержит константу 177564, которая интерпретируется как команда: LdCFD 100406(R4), AC1 Мне кажется, все просто. Пуск с 24-го вектора имеет смысл только в том случае, если основное ОЗУ - энергонезависимое. То есть или ферритовое, как это было в первых PDP-11, или КМОП с батарейным питанием, ну, или вообще ПЗУха. Платы МС1201.03 и .04 делались для ДВК, ни той, ни другой памяти там нет, места для ПЗУхи тоже нет и не предусмотрено отключение нулевого банка ОЗУ, вот и решили, что раз пуск с 24 вектора смысла не имеет, то не стоит и заморачиваться с обслуживанием 24-го вектора в HALT-MODE. Если кто желающий соберет что-то свое с КМОП-памятью или ПЗУхой, то пусть сам и сочиняет программу Halt-Mode с поддержкой вектора 24, у процессора поддержка этого дела есть. А для ДВК вообще и для МС 1201.03 и.04 в частности, сойдет и так!..
...Я могу на днях дополнительно проверить этот момент.
По итогам испытаний 1801ВМ3 при установленном режиме "пуск по 24 вектору" и "выключатель "пульт" включен" выходит в пульт с адреса 000000.
*
Пишите текст в мышкодах для ВМ3А - наберу в течении часа, в т.ч. в области пульта.
Пишите текст в мышкодах для ВМ3А - наберу в течении часа, в т.ч. в области пульта.Когда ВМ3 входит в пульт - сначала в SP записывается 020000, затем в стек помещаются PSW ( по адресу 17776 ) и PC ( по адресу 17774 ), после чего в PC помещается адрес 000000, с которого и начинается выполнение программы пульта.
На данном этапе - надо узнать значения PSW и PC, которые попадают по адресам 17776 и 17774 в ОЗУ пульта при старте с [ выключатель "пульт" включен ]. Прошивка 134 показывает эти значения, если в пульте дать команды RS/ и R7/ :
@RS/000340
@R7/000776
У меня блок ВМ3А - что набрать в машкодах и посмотреть, можно в адресах 173000 или 0 адресе пульта, не более 200 ( 8 ).
*
Текст пульта с 0 адреса после запуска с адреса 173000 с включенным выключателем пульта ( средний выключатель БПС6-1 "вниз" ) :
http://storage5.static.itmages.ru/i/16/0121/h_1453399279_2815906_88d274c4cf.jpg (http://itmages.ru/image/view/3468292/88d274c4)
Но содержимое адресов ведь можно смотреть. Надо узнать содержимое адресов 17774 и 17776 ОЗУ пульта после старта. Типа - поставить на SEL переключатель на землю и после старта включить его и в пульте проверить содержимое интересующих адресов. Старт производить в режиме "вектор 24" с [ выключатель "пульт" включен ].
Но содержимое адресов ведь можно смотреть. Надо узнать содержимое адресов 17774 и 17776 ОЗУ пульта после старта. Типа - поставить на SEL переключатель на землю и после старта включить его и в пульте проверить содержимое интересующих адресов. Старт производить в режиме "вектор 24" с [ выключатель "пульт" включен ].
Скриншот. Лампочка на UMAP мигала :
http://storage6.static.itmages.ru/i/16/0121/h_1453402248_4473328_8e40d55fc1.jpg (http://itmages.ru/image/view/3468445/8e40d55f)
- - - Добавлено - - -
Пуск производился с выключателем Пульт=0в. и WO=+5в. ( пуск с вектора 24 ). Переход в "Работу" не производился, т.к. был именно приведенный на скриншоте текст пульта. После пуска был произведен останов и перезапуск с нормальными условиями ( 173000 : 000137 140000 ), управление пультом = +5в., пуск с 173000 адреса.
Получается, что старт процессора 1801ВМ3 при W0 == 0 и при W0 == 1 ( в зависимости от положения переключателя SA1.1 ) отличается только значением, загружаемым в PC ( при обычном включении старт происходит с адреса 776, а при автозагрузке - с адреса 173000 ). В PSW в обоих случаях помещается значение 340.Положение переключателя SA1.1 даёт 5в. на 59 ноге процессора в выключенном положении, и 0в. при включенном. В обоих случаях @17777776/000341.
Надо бы посмотреть, что напишет плата при включении с нажатой кнопкой ПУЛЬТ и проверить сохранённые значения PC и PSW :
Типа такого:
****** ДОСТУПНОЕ ОЗУ - 256 K *
@ 000776
@R7/000776
@RS/000340
Надо бы посмотреть, что напишет плата при включении с нажатой кнопкой ПУЛЬТ и проверить сохранённые значения PC и PSW :
С этим надо несколько изменить схему пульта. Дело в том, что магнитоиндуктивные кнопки срабатывают не от положения магнита а от движения. По этому при включении даже нажатой кнопки мгновенно процессор не перевести в пульт а только при отпускании (если предварительно нажата). Скинте схему пульта чтоб можно было перекинуть выходы триггера.
- - - Добавлено - - -
Patron, Откуда 776?
...
С режимом пульт сделал проще. Просто 47 ногу процессора не вставил в колодку.
Результат.
****** ДОСТУПНОЕ ОЗУ - 256 K *
@ 001000
@R7/001000
@RS/000344
- - - Добавлено - - -
Ещё результат.
Получается когда нога висит в воздухе процессор ловит наведённую единицу. Заземлил ногу (не вставленную в колодку), процессор по другому запустился.
****
@ 007732
@R7/007732
@RS/000000
- - - Добавлено - - -
И ещё.
В сообщении 1253,1255 у меня был задействован переключатель SA1.8 вместо SA1.1, так что те результаты не верны. Или верны для SA1.8. За что он отвечает точно не скажу. Вроде переключение с 176560 на 177560.
Заземлил ногу (не вставленную в колодку), процессор по другому запустился.Теперь бы ещё найти настоящий SA1.1 ( или заземлить ногу 59 ) и посмотреть, как запустится с заземлённой ногой 47.
- - - Добавлено - - -
Откуда 776?Чтобы адрес останова после выполнения команды HALT был 001000 - до выполнения команды HALT в PC должно быть 000776.
Теперь бы ещё найти настоящий SA1.1 ( или заземлить ногу 59 )
Я же написал, что SA1.1 даёт 5в. на 59 ноге процессора в выключенном положении, и 0в. при включенном.
и посмотреть, как запустится с заземлённой ногой 47.
****
@ 007732
@
Чтобы адрес останова после выполнения команды HALT был 001000 - до выполнения команды HALT в PC должно быть 000776
РС это RS?
При обоих положениях SA1.1 старт с заземлённой ногой 47 даёт одинаковый результат ?
РС это RS?PC это R7.
Весьма похоже, что при активном сигнале HALT загрузка констант в PC и PSW не производится ( поэтому в стек попадает неизменное для экземпляра случайное начальное значение PC ).
Если сигнал HALT не активен - в PSW грузится 340, при W0=0 в PC грузится 000776, а при W0=1 в PC грузится 173000.
- - - Добавлено - - -
Да.А если убрать заземление ноги 47 - какие значения R7 и RS попадут в стек при старте с W0=1 ?
при старте с W0=1
Это как? С учетом инверсии или нет?
SA1.1 в 1 (ОN) = 0в (59 нога) = W0=1
Так?
SA1.1 в 1 (ОN) = 0в (59 нога) = W0=1 Так?Да. Автозагрузка - это старт с заземлённой ногой 59.
Вот.
****** ДОСТУПНОЕ ОЗУ - 256 K *
@ 001000
@R7/001000
@RS/000344
Вот.Т.е. при обоих положениях SA1.1 результат одинаковый ?
Да.Очень интересно. Такое впечатление, что если при входе в программу пульта прошивка 134 выполняет проверку объёма памяти - сохранённые значения PC и PSW заменяются на 001000 и 000344. Если активен сигнал HALT - проверка объёма памяти не производится и тогда сохранённое при входе случайное начальное значение PC не заменяется. Или программа проверки объёма памяти при активном сигнале HALT просто так вылетает, что в стек всегда попадают R7/007732 и RS/000000.
Да надо найти описание всех переключателей МС1201.03 тогда будет проще. Ещё могу вставить плату загрузчика (от ЧПУ) с адресом 173000 и посмотреть регистры. Правда она 16бит, не знаю пойдет она или нет.
Ещё могу вставить плату загрузчика (от ЧПУ) с адресом 173000 и посмотреть регистры. Правда она 16бит, не знаю пойдет она или нет.Подойдёт. Можно будет проверить старт с адреса 173000 при W0=1. Но только если этот загрузчик может как-то дать понять, что его вызывали ( на экран, например, что-то вывести ). Ведь прошивка 134, как мы уже поняли - при первом входе заменяет сохранённые значения PC и PSW на свои.
Для начала посмотрим загрузчик, чтобы знать что будет в регистрах.
***** ДОСТУПНОЕ ОЗУ - 256 K *
@ 001000
@173000/012706
00173002/017776
00173004/012702
00173006/000200
00173010/106402
00173012/005005
00173014/012725
00173016/000002
00173020/005025
00173022/012725
00173024/000006
00173026/005025
00173030/012725
00173032/000012
00173034/005025
00173036/012701
00173040/173000
00173042/005002
00173044/012703
00173046/000377
00173050/062102
00173052/005502
00173054/077303
00173056/021102
00173060/001401
00173062/000000
00173064/012701
00173066/007772
00173070/005025
00173072/001401
00173074/000000
00173076/077104
00173100/005037
00173102/017000
00173104/012700
00173106/177000
00173110/005060
00173112/000020
00173114/012760
00173116/177777
00173120/000020
00173122/016001
00173124/000020
00173126/010102
00173130/042702
00173132/177760
00173134/001403
00173136/052737
00173140/000400
00173142/017000
00173144/010102
00173146/042702
00173150/177417
00173152/001403
00173154/052737
00173156/001000
00173160/017000
00173162/010102
00173164/042702
00173166/170377
00173170/001403
00173172/052737
00173174/002000
00173176/017000
00173200/032737
00173202/003400
00173204/017000
00173206/001001
00173210/000000
00173212/012701
00173214/000010
00173216/005020
00173220/077102
00173222/012737
00173224/173600
00173226/000004
00173230/012700
00173232/177760
00173234/012701
00173236/000010
00173240/005020
00173242/077102
00173244/012737
00173246/000006
00173250/000004
00173252/012737
00173254/000140
00173256/177400
00173260/105737
00173262/177560
00173264/100006
00173266/022737
00173270/000334
00173272/177562
00173274/001002
00173276/000137
00173300/120002
00173302/032737
00173304/000001
00173306/177560
00173310/001363
00173312/000240
00173314/000240
00173316/012737
00173320/000017
00173322/177402
00173324/000411
00173326/000000
00173330/000000
00173332/012706
00173334/017776
00173336/005016
00173340/010705
00173342/062705
00173344/000116
00173346/000407
00173350/022737
00173352/107417
00173354/020000
00173356/001002
00173360/000137
00173362/020002
00173364/000000
00173366/005000
00173370/004715
00173372/105303
00173374/001374
00173376/004715
00173400/004767
00173402/000104
00173404/010402
00173406/024242
00173410/022702
00173412/000002
00173414/001443
00173416/004767
00173420/000066
00173422/061604
00173424/010401
00173426/004715
00173430/002011
00173432/105700
00173434/001754
00173436/105737
00173440/177564
00173442/100375
00173444/112737
00173446/000077
00173450/177566
00173452/000726
00173454/110321
00173456/000763
00173460/012703
00173462/177550
00173464/105213
00173466/105713
00173470/100376
00173472/116303
00173474/000002
00173476/060300
00173500/042703
00173502/177400
00173504/005302
00173506/000207
00173510/004715
00173512/010304
00173514/004715
00173516/000303
00173520/050304
00173522/000207
00173524/004767
00173526/177760
00173530/004715
00173532/105700
00173534/001340
00173536/006204
00173540/103673
00173542/006304
00173544/061604
00173546/000114
00173550/052737
00173552/000140
00173554/177400
00173556/012700
00173560/120000
00173562/012701
00173564/020000
00173566/005020
00173570/077102
00173572/000137
00173574/173330
00173576/000240
00173600/012716
00173602/173244
00173604/000002
00173606/000000
00173610/010346
00173612/005003
00173614/005703
00173616/001373
00173620/012703
00173622/000001
00173624/005000
00173626/004767
00173630/000122
00173632/077303
00173634/005005
00173636/005200
00173640/004767
00173642/000106
00173644/062700
00173646/000005
00173650/020102
00173652/101030
00173654/010204
00173656/160104
00173660/020427
00173662/000047
00173664/101402
00173666/012704
00173670/000047
00173672/060400
00173674/005200
00173676/004767
00173700/000050
00173702/010100
00173704/004767
00173706/000042
00173710/112100
00173712/004767
00173714/000036
00173716/005304
00173720/100373
00173722/005405
00173724/110500
00173726/004767
00173730/000022
00173732/000730
00173734/004767
00173736/000012
00173740/012600
00173742/004767
00173744/000004
00173746/005203
00173750/000764
00173752/004717
00173754/105737
00173756/177554
00173760/100375
00173762/110037
00173764/177556
00173766/060005
00173770/000300
00173772/000207
00173774/000240
00173776/054233
Автозагрузки не произошло. Patron, Вы уверены что автозагрузка зависит только от SA1.1?
Смотрим регистры.
***** ДОСТУПНОЕ ОЗУ - 256 K *
@ 001000
@R7/001000
@RS/000344
@173000G
@ 000000
@R7/000000
@RS/000010
Вы уверены что автозагрузка зависит только от SA1.1?Когда нога 59 заземлена - процессор 1801ВМ3 начинает выполнение программы с адреса 173000. Если разместить по адресу 173000 код, который что-то куда-то пишет, то по наличию/отсутствию результатов такой записи можно будет сделать вывод, выполнился ли этот код при старте процессора.
- - - Добавлено - - -
Когда прошивка 134 выводит надпись про "ДОСТУПНОЕ ОЗУ" - сохранённые значения регистров ( похоже ) изменяются, поэтому по содержимому регистров вывод сделать нельзя.
Когда прошивка 134 выводит надпись про "ДОСТУПНОЕ ОЗУ" - сохранённые значения регистров ( похоже ) изменяются, поэтому по содержимому регистров вывод сделать нельзя. И автозагрузка не идет. Где сказано в описании что плата умеет автозагрузку?
Можно будет проверить старт с адреса 173000 при W0=1.
На моем модуле ВМ3 стартует с 173000 однозначно, нога 59 (W0) заземлена.
И автозагрузка не идет. Где сказано в описании что плата умеет автозагрузку?
Посмотрел текст по адресу 173000 платы от ЧПУ - он острозаточен под железо ЧПУ :
http://storage8.static.itmages.ru/i/16/0124/h_1453594235_4260660_015157f018.jpg (http://itmages.ru/image/view/3514431/015157f0)
Более того :
http://storage9.static.itmages.ru/i/16/0124/h_1453594392_1508100_d5f31ac29f.jpg (http://itmages.ru/image/view/3514432/d5f31ac2)
Т.е. максимум, что может этот текст - выпасть в пульт не со 173000, а с др. точки, которые имеются по тексту загрузчика. Кроме того, он предусматривает какие-то ПЗУ по адресам типа 120000 - см. текст выше.
Коллеги, вам не кажется, что вы занимаетесь немножко не тем? Если на системном терминале что-то появилось, то уже выполнена не одна сотня команд из 134-й (или 377-й) ПЗУхи, и что там было вначале, никто точно не скажет. Тут надо цеплять логический анализатор, или запоминающий многоканальный осциллоскоп и разглядывать первые несколько десятков тактов после установки К ПОСТН В или К ПИТН В (BDCOK H, BPOK H). Точнее, сначала после К ПОСТН В, затем, если внятных результатов не будет, после К ПИТН В.
- - - Добавлено - - -
В крайнем случае годится даже простой осциллоскоп на ЭЛТ, но тогда надо воспользоваться приемом, изложенном на 65 стр. книжки Захарова, а именно - подать на К ПОСТН В серию с постороннего генератора (частоту подобрать), её же подать на внешнюю синхронизацию осциллоскопу и щупать по очереди SYNC, DA и т.д., результаты зарисовывать, а потом вникать. Помню, пару раз таки довелось вот так поразвлекаться... Конечно, анализатор гораздо лучше, но тогда у меня его не было.
Коллеги, вам не кажется, что вы занимаетесь немножко не тем? Если на системном терминале что-то появилось, то уже выполнена не одна сотня команд из 134-й (или 377-й) ПЗУхи, и что там было вначале, никто точно не скажет.Прошивка написана так, что при любом попадании в пульт первым делом сохраняет все регистры, чтобы восстановить их, если пользователь захочет продолжить выполнение программы командой P. Именно эти значения ( а отнюдь не текущие ) можно просматривать и изменять в пульте.
Но у прошивки 134 есть одна особенность - если с момента включения питания прошивка ещё ни разу не выполняла начальное тестирование памяти - при первом же входе в пульт запускается программа тестирования и сохранённые значения регистров изменяются. Поэтому, если прошивка после входа в пульт вывела сообщение про "ДОСТУПНОЕ ОЗУ", то это означает, что сохранённые значения регистров испорчены.
Но у прошивки 134 есть одна особенность - если с момента включения питания прошивка ещё ни разу не выполняла загрузочное тестирование памяти - при первом же входе в пульт запускается программа тестирования и сохранённые значения регистров изменяются. Поэтому, если прошивка после входа в пульт вывела сообщение про "ДОСТУПНОЕ ОЗУ", то это означает, что сохранённые значения регистров испорчены. Так и я о том же. То есть, или логический анализатор, или специально оборудованный стенд, который будет "подсовывать" процессору заранее запланированное содержимое Halt-Mode ROM и ОЗУ всех видов, протоколируя при этом всё, что происходит.
Кстати, а какая минимальная тактовая частота у ВМ3? 100 кГц, как и у остальных? Я что-то не нашел...
Прошивка написана так, что при любом попадании в пульт первым делом сохраняет все регистры
Дело не в прошивке, дело в том что в процессоре не соблюдены приоритеты. Вместо того чтобы безусловно перейти на адрес 173000 он таки всё равно лезет в прошивку. Даже моде Halt он успевает напечатать четыре звёздочки а потом только останавливается.
Так и я о том же. То есть, или логический анализатор, или специально оборудованный стенд, который будет "подсовывать" процессору заранее запланированное содержимое Halt-Mode ROM и ОЗУ всех видов, протоколируя при этом всё, что происходит.Самое интересное - поместить в HALT-ROM по адресу 000000 команду TST @#40000 и посмотреть на какие физические адреса будут мапиться обращения к диапазонам PARH0 и PARH1. Дело в том, что аппаратная реализация режима пульта в ДВК использует для адресов 000000..077777 только младшие биты адреса, поэтому никто не знает, какие 22-разрядные адреса при этом на самом деле выставляются на шину.
Кстати, а какая минимальная тактовая частота у ВМ3? 100 кГц, как и у остальных?ВМ2 без проблем работает на частоте 0 Гц ( с ручным тактированием ), можно предположить, что и ВМ3 тоже.
- - - Добавлено - - -
Дело не в прошивке, дело в том что в процессоре не соблюдены приоритеты. Вместо того чтобы безусловно перейти на адрес 173000 он таки всё равно лезет в прошивку.Если бы было так, то при старте с PC=173000 - именно это значение сохранялось бы при входе в пульт и было видно при просмотре R7/.
Дело не в прошивке, дело в том что в процессоре не соблюдены приоритеты. Вместо того чтобы безусловно перейти на адрес 173000 он таки всё равно лезет в прошивку. Даже моде Halt он успевает напечатать четыре звёздочки а потом только останавливается. Что лишний раз подчеркивает бесполезность всех манипуляций с 1201.03/04. Похоже, придется делать стенд. В принципе, могу попробовать, правда не уверен, что смогу справиться быстро. Я прикидывал сделать его на каком-нибудь STM32, заказывая с Али пробную платку я учитывал, в том числе, и эту задачку, но она (платка) приползет, дай Бог, через месяц. Однако, учитывая отсутствие ограничения вниз по тактовой частоте ВМ3, туда можно сунуть что угодно, лишь бы ног хватило. Так, что буду думать...
AFZ, А тесты прогнать на МС1201.01 есть желание?
MiX, а в каком положении у вас находится переключатель SA2.2? В замкнутом состоянии он перетранслирует сигнал ACLO(ПИТ) на вход HLT(ОСТ) процессора.
Alex_K, Сейчас в замкнутом. Но положение его не влияет на старт.
.
Дополнительное изучение документации по ВМ3 позволило сделать вывод, что есть два варианта процессора 1801ВМ3.
1. У раннего варианта ВМ3 есть 4 регистра PARH, причём - PARH0 инициализируется значением 170000, а PARH1 инициализируется значением 167600. Сколько из регистров PARH доступно программно - неизвестно.
2. У позднего варианта ВМ3 есть 2 регистра PARH, из которых программно доступен только PARH2, а скрытый PARH3 имеет неизменное значение 177600. Адреса из диапазонов PARH0 ( 000000..037777 ) и PARH1 ( 040000..077777 ) выдаются на шину без трансляции. При активном сигнале SEL старшие 6 разрядов 22-разрядного адреса всегда нулевые.
- - - Добавлено - - -
Также можно предположить, что именно ранний вариант ВМ3 устанавливает стек HALT-моды на 100000, потому что прошивка 134 рассчитана как раз на это. Поздний вариант ВМ3 устанавливает стек HALT-моды на 020000.
При активном сигнале SEL старшие 6 разрядов 22-разрядного адреса всегда нулевые. А когда оно из пультовой программы куда-то стучится через PARH2, SEL снимается, да?
Также можно предположить, что именно ранний вариант ВМ3 устанавливает стек HALT-моды на 100000, потому что прошивка 134 рассчитана как раз на это. Поздний вариант ВМ3 устанавливает стек HALT-моды на 020000. Вообще-то, 377 - прямая замена 134-й. В частности, ту 377-ю, которая стоит в ДВК у СуперМакса, я лично сунул в панельку, которую запаял на место выдранной 134-й. И ДВК весело работал, как до замены, так и после.
- - - Добавлено - - -
И, вспоминая, как я пытался дизасмить 377-ю, похоже, 017776, 037776, 057776 и 077776 в Halt-Mode мапятся в одно и то же место. Очень похоже, хотя 100% гарантии не дам.
А когда оно из пультовой программы куда-то стучится через PARH2, SEL снимается, да?SEL снимается, если программа пульта обращается в диапазон PARH2 ( 100000..137777 ) или в диапазон PARH3 ( 140000..177777 ).
Вообще-то, 377 - прямая замена 134-й. В частности, ту 377-ю, которая стоит в ДВК у СуперМакса, я лично сунул в панельку, которую запаял на место выдранной 134-й. И ДВК весело работал, как до замены, так и после.В ДВК любая прошивка для ВМ3 будет работать с любым процессором ВМ3 - так плата сделана.
И, вспоминая, как я пытался дизасмить 377-ю, похоже, 017776, 037776, 057776 и 077776 в Halt-Mode мапятся в одно и то же место.Эти адреса вообще не мапятся - просто плата ДВК в режиме SEL сначала обрезает у адреса все биты, кроме BIT_12 .. BIT_0, а если (BIT_12 | BIT_11)==014000, то выбирается микросхема HALT-ОЗУ и у адреса дополнительно отрезаются все биты, кроме BIT_8 .. BIT_0 - в результате, если на шине (например) адрес: 14000, 15000, 16000, 17000, 34000, 35000, 36000, 37000, 54000, 55000, 56000, 57000, 74000, 75000, 76000, 77000 - то обращение будет идти к одной и той же ячейке HALT-ОЗУ с нулевым адресом.
...
При очередном эксперименте с другой платой выяснилось что при переключателе SA1.1 в 1 происходит штатный запуск ЦП. Если после этого нажать кнопку УСТ то получается переход на адрес 173000. Думаю что если поставить на ногу INIT (33) конденсатор на землю, и в разрыв цепи от кнопки сопротивление (классическая схема сброса ) то старт процессора будет на это адрес.
***** ДОСТУПНОЕ ОЗУ - 256 K *
@ 001000
@
@ 173000
@R7/173000
@RS/000340
Думаю что если поставить на ногу INIT (33) конденсатор на землю, и в разрыв цепи от кнопки сопротивление (классическая схема сброса ) то старт процессора будет на этот адрес.Процессор всегда стартует одинаково, просто в первый раз сохранённые значения были испорчены программой тестирования ОЗУ, а после нажатия кнопки УСТ - сохранённые значения остались неизменными. Если на адрес 173000 повесить ПЗУ с любой нормальной программой, то эта программа будет запущена сразу после включения.
- - - Добавлено - - -
Кстати, если переключить SA1.1 на старт с вектора 24, то какие значения R7 и RS будут сохранены после нажатия кнопки УСТ ?
Процессор всегда стартует одинаково
Когда я вставил плату загрузчика то пошла программа именно загрузчика ! Без всяких "звёздочек и ДОСТУПНОГО ОЗУ" и без нажатия кнопки Уст. А если на шине нет загрузчика то старт обычный. Вывод такой, что эта плата корректно работает. До сообщения 1309 была другая плата.
Кстати, если переключить SA1.1 на старт с вектора 24, то какие значения R7 и RS будут сохранены после нажатия кнопки УСТ ?
После нажатия кнопки переход на 000002.
получается
R7/000002
RS/000000
После нажатия кнопки переход на 000002.Это адрес останова после выполнения команды HALT по адресу 000000, который был загружен в PC из вектора 24.
Надо бы запустить IOSCAN.SAV (http://emulator.pdp-11.org.ru/misc/IOSCAN.zip) на обеих платах.
Если на адрес 173000 повесить ПЗУ с любой нормальной программой, то эта программа будет запущена сразу после включения.
Да! Это так!
В моём случае когда на плате загрузчика 173000 была некорректная программа, то и не давала нормальных результатов. Теперь сменив загрузчик загружается обе платы. То есть дело было не плате а в загрузчике.
- - - Добавлено - - -
Надо бы запустить IOSCAN.SAV на обеих платах.
Плата загрузчика стоит.
172300-172316
172340-172356
172512
172516
173000-173776
176560-176566
177514-177516
177560-177566
177572-177616
177640-177656
177776
На моем модуле ВМ3 стартует с 173000 однозначно, нога 59 (W0) заземлена.Надо бы выяснить, как процессор ВМ3 отрабатывает прерывание зависания ( TrapTo_4 ) в режиме HALT.
Для этого можно в режиме старта по вектору 24 записать в ячейку 24 значение 26, а с адреса 0 расположить код из прошивки 134, проверяющий чтение отсутствующего адреса:
MOV #177600, @#172512
TST @#100000
Для меня это актуально?Нет - нужно видеть циклы шины, чтобы узнать, что куда пишется и что откуда читается при обработке прерывания зависания в режиме HALT.
У меня сейчас на работе запара, а процессоры и платы заныканы под елкой (тумбочка за ней), надеюсь что в ближайшее время я немного разгребусь на работе, вынесу елку (да-да, для этого не обязательно майских праздников ждать :)) и смогу потестить ВМ3 с анализатором. Возможно что найдется и проц 88 года. Если можно - то нельзя ли собрать все желаемые тесты с описанием в одно сообщение или в личку/на мыло прислать, а то я ориентацию в ветке уже потерял?
Эти адреса вообще не мапятся - просто плата ДВК в режиме SEL сначала обрезает у адреса все биты, кроме BIT_12 .. BIT_0, а если (BIT_12 | BIT_11)==014000, то выбирается микросхема HALT-ОЗУ и у адреса дополнительно отрезаются все биты, кроме BIT_8 .. BIT_0 О, вот это я забыл давно и прочно. Этот угол схемы 1201.03/04 я если и разглядывал, то лет, так, 20 назад, не менее, поскольку не помню совсем.
- - - Добавлено - - -
173000. Думаю что если поставить на ногу INIT (33) конденсатор на землю, и в разрыв цепи от кнопки сопротивление (классическая схема сброса ) то старт процессора будет на это адрес.Вообще-то INIT - это выходной сигнал процессора для сброса периферии, как при включении питания, так и по машинной команде RESET в произвольный момент. А сбросом для процессора является DCLO, получаемый из К ПОСТН В (BDCOK H), который генерится в БП, а также выдается по кнопке "УСТ". Сигнал ACLO (К ПИТН В, BPOK H), во время работы (при активном К ПОСТН В) должен быть запросом на прерывание по вектору 24, а вот как оно там ведет себя при включении, когда К ПОСТН В уже появился, а К ПИТН В появится через 70 мс, ИМХО, тоже должно быть предметом выяснения, чем там занимается ЦП эти 70 мс?
Впрочем, все это безусловно верно для Э-60, а насколько точно это скопировано при разработке процессоров 1801, в общем-то, тоже предмет выяснения.
нельзя ли собрать все желаемые тесты с описанием в одно сообщениеЖелания прибавляются по мере успехов эмуляции. Главное на данный момент - разобраться, как ВМ3 отрабатывает зависание в HALT-моде ( признаком наличия/отсутствия HALT-моды является состояние ноги 55 ).
Также - можно при входе в HALT-моду выполнить команду: MOV SP, @#2 - чтобы узнать значение SP. Прошивка 377 якобы сохраняет несколько вариантов SP - это тоже можно проверить.
В итоге код получается такой:
.ASect
. = 0
Br Next // Точка входа пульта.
. = 24
.Word Start // Адрес старта.
.Word 340
Start:
Mov #2, R1
Mov #177776, R2 // Адрес PSW
Mov #140340, (R2) // Установить USER-моду
Mov SP, (R1) // Какой стек ?
Mov #4444, SP // Стек USER-моды
Mov #340, (R2) // Установить KERNEL-моду
Mov SP, (R1) // Какой стек ?
Mov #2222, SP // Стек KERNEL-моды
HALT // Установить HALT-моду
Next:
Mov (R2), (R1) // Прочитать PSW
Mov SP, (R1) // Какой стек ?
Mov #140340, (R2) // Выбрать стек USER
Mov SP, (R1) // Какой стек ?
Mov #340, (R2) // Выбрать стек KERNEL
Mov SP, (R1) // Какой стек ?
Mov #177600, @#172512 // PARH2 -> IO Page
Tst @#100000 // Чтение 17760000 вызовет зависание
Nop
Главное на данный момент - разобраться, как ВМ3 отрабатывает зависание в HALT-моде
Через виртуальный вектор 4 в HALT-режиме. В 134-ой прошивке там 77004, 340. А всякие фатальные ситуации осуществляют переход на нулевой адрес HALT-режима с сохранением в HALT-стеке значений PC и PSW.
Через виртуальный вектор 4 в HALT-режиме.Вот код тестирования зависания в режиме HALT из прошивки 134 :
006440 [000344] MOV #3400., @#77006 ; 006442:006510 -> 077006:004566
006446 [000340] CALL 013104 ; R7 :006452 -> 017770
013104 [000340] TSTB @#177564 ; 177564: 200
013110 [000350] BPL 013104
013112 [000350] MOV #42., @#177566 ; 013114:000052 -> 177566:000000
013120 [000340] RETURN ; 017770:006452 -> R7
006452 [000340] MOV #-128., @#172512 ; 006454:177600 -> 172512:007777
006460 [000350] TST @#100000 ; 100000:000000
Как видно - первым делом дефолтный обработчик TrapTo_4 заменяется на специальный, который при срабатывании выводит сообщение об ошибке. Если настроить эмулятор на обработку прерывания зависания в режиме HALT по вектору 4, то старт прошивки 134 выглядит так:
****
ОшИБКА ВЕКТОРА 4 *
ОшИБКА ВЕКТОРА 4 *
ОшИБКА ВЕКТОРА 4 *
ОшИБКА ВЕКТОРА 4 *
ОшИБКА ВЕКТОРА 4 *
ОшИБКА ВЕКТОРА 4 *
ОшИБКА ВЕКТОРА 4
@ 000002
@
Как видно - первым делом дефолтный обработчик TrapTo_4 заменяется на специальный, который при срабатывании выводит сообщение об ошибке. Если настроить эмулятор на обработку прерывания зависания в режиме HALT по вектору 4, то старт прошивки 134 выглядит так:
При вызове по этому вектору в стеке вроде ничего не сохраняется, только из вектора загружается PC и PSW.
При вызове по этому вектору в стеке вроде ничего не сохраняется, только из него загружается PC и PSW.Обработка TrapTo_4 в прошивке 134 организована так - при входе в HALT-моду первым делом настраивается обработчик TrapTo_4 в HALT-ОЗУ, адрес которого находится в ячейке 000004 HALT-ПЗУ :
ROM:000000 Jmp loc_5710
ROM:000004 .Word 77004
ROM:000006 .Word 340
ROM:005710 Mov SP, @#77114
ROM:005714 Mov #137, @#77004
ROM:005722 Mov #4566, @#77006
ROM:004566 Inc @#77054
ROM:004572 Return
Кстати, из этого кода можно сделать вывод, что TrapTo_4 в режиме HALT отрабатывается процессором через CALL @Word04. Но для обработчика TrapTo_4 из теста зависания разницы нет - он в любом случае просто выводит сообщение об шибке.
Кстати, из этого кода можно сделать вывод, что TrapTo_4 в режиме HALT отрабатывается процессором через CALL @Word04. Но для обработчика TrapTo_4 из теста зависания разницы нет - он в любом случае просто выводит сообщение об шибке.
При вызове в стек ничего не ложится, т.к. если бы ложилось, то после вызова вектора по RETURN возвращалось бы в тоже место. Т.е. после TST @#100000 всегда была бы ошибка вектора 4.
Я уже дизассемблировал 134-ю прошивку, можно почитать здесь (http://zx-pk.ru/showthread.php?t=2348&page=185&p=484657&viewfull=1#post484657).
Эксперимент : пуск процессора с 173000 адреса с включенным выключателем "пульт" и выполнением обращения к несуществующему адреса из области пульта :
http://storage4.static.itmages.ru/i/16/0125/h_1453739574_4983713_9ab740b788.jpg (http://itmages.ru/image/view/3540772/9ab740b7)
http://storage5.static.itmages.ru/i/16/0125/h_1453739617_4778962_b655618860.jpg (http://itmages.ru/image/view/3540773/b6556188)
По итогам прохождения теста лампочка "UMAP" мигала.
При вызове в стек ничего не ложится, т.к. если бы ложилось, то после вызова вектора по RETURN возвращалось бы в тоже место. Т.е. после TST @#100000 всегда была бы ошибка вектора 4.Понятно, что зависание в режиме HALT отрабатывается процессором ВМ3 не как прерывание ( или HALT-прерывание, сохраняющее только PC ) по вектору 4 - это прямо следует из работы прошивки 134. Потому и надо узнать, что делает процессор 1801ВМ3 после обращения к несуществующему адресу в режиме HALT.
Понятно, что зависание в режиме HALT отрабатывается процессором ВМ3 не как прерывание ( или HALT-прерывание, сохраняющее только PC ) по вектору 4 - это прямо следует из работы прошивки 134. Потому и надо узнать, что делает процессор 1801ВМ3 после обращения к несуществующему адресу в режиме HALT.
Только загружает PC и PSW из вектора 4 режима HALT, т.е. в случае 134-й прошивки, это 77004 и 340.
Только загружает PC и PSW из вектора 4 режима HALT, т.е. в случае 134-й прошивки, это 77004 и 340.Если процессор делает так - прошивка 134 сообщает о неисправности процессора, поэтому логично предположить, что на самом деле происходит что-то другое.
Если процессор делает так - прошивка 134 сообщает о неисправности процессора, поэтому логично предположить, что на самом деле происходит что-то другое.
Это в каком месте?
Это в каком месте?В неправильно написанном мною эмуляторе.
Если при возникновении зависания в режиме HALT ничего не помещать в стек и просто загрузить новые значения PC и PSW из вектора 4, то прошивка не ругается.
Елку выкинул, откопал процессор ВМ3, но он, увы, с датой 89/10. Пока посканировал, никаких новых регистров нет, есть некоторые отличия в содержимом регистров, но непонятно, является ли это особенностью маски процессора. Полетаев писал что маску поменяли в середине 89 года, так что может быть это уже новая ревизия.
89/10
172300/034016
172302/070512
172304/055412
172306/076516
172310/033512
172312/070410
172314/065412
172316/026514
172340/005471
172342/005663
172344/006261
172346/005323
172350/005513
172352/004755
172354/005565
172356/004072
172512/007367
172516/177717
177572/000000
177574/000000
177576/001760
177600/037012
177602/073114
177604/063416
177606/065412
177610/072516
177612/037516
177614/015516
177616/032516
177640/001621
177642/007677
177644/007773
177646/007775
177650/003263
177652/003375
177654/007267
177656/005777
177714/160007
177716/000000
177776/000004
92/01
172300/077516
172302/077516
172304/077516
172306/077516
172310/077516
172312/077516
172314/077516
172316/037516
172340/007777
172342/007777
172344/007777
172346/007777
172350/007777
172352/007777
172354/007777
172356/007677
172512/007777
172516/177717
177572/000000
177574/000000
177576/001760
177600/077516
177602/077516
177604/077516
177606/077516
177610/077516
177612/077516
177614/077516
177616/077516
177640/007777
177642/007777
177644/007777
177646/007777
177650/007777
177652/007777
177654/007777
177656/007777
177714/160007
177716/000000
177776/000004
- - - Добавлено - - -
Выполнил такой фрагмент:
309 001330 012701 000002 entry: mov #2, R1 ;
310 001334 012702 177776 mov #177776, R2 ; Адрес PSW
311 001340 012712 140340 mov #140340, (R2) ; Установить USER-моду
312 001344 010611 mov SP, (R1) ; Какой стек ?
313 001346 012706 004444 mov #4444, SP ; Стек USER-моды
314 001352 012712 000340 mov #340, (R2) ; Установить KERNEL-моду
315 001356 010611 mov SP, (R1) ; Какой стек ?
316 001360 012706 002222 mov #2222, SP ; Стек KERNEL-моды
317 001364 012711 001372 mov #ehalt, (R1) ;
318 001370 000000 halt ; Установить HALT-моду
319 ;
320 001372 005712 ehalt: tst (R2) ; Прочитать PSW
321 001374 010611 mov SP, (R1) ; Какой стек ?
322 001376 012712 140340 mov #140340, (R2) ; Выбрать стек USER
323 001402 010611 mov SP, (R1) ; Какой стек ?
324 001404 012712 000340 mov #340, (R2) ; Выбрать стек KERNEL
325 001410 010611 mov SP, (R1) ; Какой стек ?
326
327 001412 012737 177600 172512 mov #177600, @#172512 ; PARH2 -> IO Page
328 001420 005737 100000 tst @#100000 ; Чтение 17760000 вызовет зависание
329 001424 000240 nop ;
330 001426 000777 br . ;
Получилось такое: [http://i072.radikal.ru/1601/27/d687a41f390ct.jpg (http://i072.radikal.ru/1601/27/d687a41f390c.png)]
Почему-то в HALT режиме SP равен установленному значению 22228, хотя PSW и PC при переходе в HALT сохранились в стеке 200008
Транзакции по 177776 на внешней шине процессора не отображаются, хотя адрес 177776 мелькает.
Елку выкинул, откопал процессор ВМ3, но он, увы, с датой 89/10. Пока посканировал, никаких новых регистров нет, есть некоторые отличия в содержимом регистров, но непонятно, является ли это особенностью маски процессора. Полетаев писал что маску поменяли в середине 89 года, так что может быть это уже новая ревизия.
http://storage1.static.itmages.ru/i/16/0125/h_1453764669_2057721_a6f693cb88.jpg (http://itmages.ru/image/view/3541826/a6f693cb)
"Ёлка" была от БКшки ? :v2_dizzy_christmas:
"Ёлка" была от БКшки ? :v2_dizzy_christmas:
Нет, от Деда Мороза :) Скво и мучачос без ёлки Новый Год считают неполноценным, искуственная их тоже не устраивает (ну звери, да), приходится папе c деревом мордоваться. За деревом находился шкафчик, в котором все ретро было сложено - не подобраться. Адреса 177714 и 177716 я просто из листинга забыл выкинуть, они у меня в ПЛИС реализованы, используются для отладки, к ВМ3 и БК отношения не имеют.
... Полетаев писал что маску поменяли в середине 89 года, так что может быть это уже новая ревизия.
Зная специфику НЦ, могу предположить, что цеховые могли использовать старые шаблоны, пока у них не кончится "моторесурс" ( по русски - пока не загадят ). Таким образом, как я писал сильно выше, реально новодел мог пойти от ~ 1 года после помпезной замены логического брака.
А для камней производства после 12.1991. вааще ничего неопределено - ни тип шаблонов, ни буква, ни к-во грязи на корпусе БИС... Это происходило от того, что датой 12.1991. маркировали примерно до осени 1992 ( иначе Заказчик не хотел покупать, зная цеховые повадки ), а датой 01.1992 могли маркировать, пока линию не пустили на металл - года так до 1994-1995.
Получилось такоеПохоже, что на картинке не первый прогон теста после включения питания, потому что исходные значения SP таинственным образом оказались равны тем значениям, которые были записаны в них далее по тесту. Надо как-то узнать, какие значения имеют регистры SP у обоих процессоров сразу после включения питания.
Почему-то в HALT режиме SP равен установленному значению 22228, хотя PSW и PC при переходе в HALT сохранились в стеке 200008Я ожидал этого, потому что судя по всему - если в раннем ВМ3 режим пульта был организован через специальный режим включённого MMU ( поэтому там мапятся все адреса и есть свой указатель стека ), то в позднем ВМ3 режим пульта организован через специальный режим выключенного MMU ( поэтому там мапятся только некоторые адреса, нет собственного указателя стека, а PSW и PC сохраняются при входе по фиксированным адресам ).
- - - Добавлено - - -
Картинка обрывается на адресе 01410 - отработку зависания в режиме HALT не видно. Ожидается, что при отработке зависания в режиме HALT процессор ВМ3 ничего никуда не пишет, загружая новые значения PC и PSW из вектора 04 - это так ?
- - - Добавлено - - -
Показ содержимого PSW на шине ( как выяснилось ) надо производить командой: Mov (R2), (R1)
- - - Добавлено - - -
Но с другой стороны, при входе в прошивку 377 - первым делом для сохранения регистров делается вызов CALL. При произвольном значении SP такое невозможно ( да и сохранить исходное значение SP после вызова CALL можно только в том случае, когда вызов CALL не использует SP ). Может статься, что в режиме HALT, использующие стек команды - используют особый скрытый регистр, недоступный для чтения и записи через обращение к SP.
Для проверки этого предположения можно в начале обработчика HALT вызвать последующий код через CALL и посмотреть, куда сохранится адрес возврата :
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 24
.Word Start // Адрес старта.
.Word 340
Start:
Mov #2, R1
Mov #177776, R2 // Адрес PSW
Mov #140340, (R2) // Установить USER-моду
Mov SP, (R1) // Какой стек ?
Mov #4444, SP // Стек USER-моды
Mov #340, (R2) // Установить KERNEL-моду
Mov SP, (R1) // Какой стек ?
Mov #2222, SP // Стек KERNEL-моды
Mov #Next, (R1)
HALT // Установить HALT-моду
Next:
Mov (R2), (R1) // Прочитать PSW
Call Next2 // Где сохранит PC ?
Next2:
Mov SP, (R1) // Какой стек ?
Mov (SP), (R1) // Откуда прочитает ?
Mov #140340, (R2) // Выбрать стек USER
Mov SP, (R1) // Какой стек ?
Mov #340, (R2) // Выбрать стек KERNEL
Mov SP, (R1) // Какой стек ?
Mov #Next3, (R1)
Mov #177600, @#172512 // PARH2 -> IO Page
Tst @#100000 // Чтение 17760000 вызовет зависание
Nop
Next3:
Br .-2.
- - - Добавлено - - -
Любопытно - прошивка 134 написана так, что если запись в SP изменяет указатель стека HALT-моды, то прошивка входит в бесконечный цикл, а это означает, что во всех версиях 1801ВМ3 указатель стека HALT-моды не доступен через обращение к SP.
Приняты специальные меры:
- на процессор подается низкий DCLO
- включается питание
- загружается ПЛИС
- появляется тактовая частота
- устанавливается низкий ACLO
- запускается анализатор
- снимается DCLO, потом ACLO
Результат: [http://s020.radikal.ru/i708/1601/fd/eadd99677f75t.jpg (http://s020.radikal.ru/i708/1601/fd/eadd99677f75.png)]
Как видно - записываются нулевые значения обоих стеков. Маловероятно что это специальные осмысленные значения, просто так триггеры установились по включению. Если бы был реализован сброс по DCLO, то мы наблюдали бы их и в предыдущем тесте. В-общем, при включении питания в указателях стека мусор, микрокод их не инциализирует, значения этих регистов переживают сброс, все как в ВМ1.
Выполнение всего теста в анализатор не влазит - не хватает памяти в ПЛИС, я попытался поднять тактовую частоту процессора, и тут выявился сюрприз - после команды HALT еще один цикл шины выполняется предвыборки следующей команды - по адресу 1370 HALT, читался адрес 1372, потом только начинали выполняться операции по адресам 17776/17774. А при повышенной частоте (я пробовал 6.25/7.2) предвыборка почему-то выполняется уже по адресу 150472: [http://s019.radikal.ru/i605/1601/b7/87983b7dbd4et.jpg (http://s019.radikal.ru/i605/1601/b7/87983b7dbd4e.png)]
Там возникает зависание, в итге весь тест опять не влез. Интересно поведение HLTM - он активируется именно в момент исполнения HALT, и предвыборка уже выполняется с этим активным сигналом. Число Пи процессор считает правильно на 6.25/7.2МГц, точек на корпусе нет, не греется, вероятно это ВМ3А, уж на 6МГц должен работает, сбой маловероятен, поэтому факт предвыборки по транслированному адресу странный.
Чтобы посмотреть обработку зависания в пульте, я тест чуток укоротил и синхронизировал анализатор по срезу HLTM: [http://s011.radikal.ru/i316/1601/cf/1f8deab5f943t.jpg (http://s011.radikal.ru/i316/1601/cf/1f8deab5f943.png)]
Видно что висит долго, не выходит из зависания не менее 200 тактов, результата опять нет, увы.
Как видно - записываются нулевые значения обоих стеков. Маловероятно что это специальные осмысленные значения, просто так триггеры установились по включению.А уменя, наборот - есть подозрение, что R0..R6 у ВМ3 при включении питания обнуляются. Узнать ответ легко - последовательность MOV Rx,(PC)+ нас рассудит.
Выполнение всего теста в анализатор не влазитНе проблема - сделаем два теста:
1. Тест стеков :
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 24
.Word Start // Адрес старта.
.Word 340
Start:
Mov #2, R1
Mov #177776, R2 // Адрес PSW
Mov #140340, (R2) // Установить USER-моду
Mov #4444, SP // Стек USER-моды
Mov #340, (R2) // Установить KERNEL-моду
Mov #2222, SP // Стек KERNEL-моды
HALT // Установить HALT-моду
Next:
Mov (R2), (R1) // Прочитать PSW
Call Next2 // Где сохранит PC ?
Next2:
Mov SP, (R1) // Какой стек ?
Tst (SP) // Откуда прочитает ?
Mov #140340, (R2) // Выбрать стек USER
Mov SP, (R1) // Какой стек ?
Mov #340, (R2) // Выбрать стек KERNEL
Mov SP, (R1) // Какой стек ?
Br .-2.
2. Тест зависания :
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 24
.Word Start // Адрес старта.
.Word 340
Start:
HALT // Установить HALT-моду
Next:
Mov #177600, @#172512 // PARH2 -> IO Page
Tst @#100000 // Чтение 17760000 вызовет зависание
Nop
Br .-2.
Похоже никакого стека в режиме пульта нет:
- mov R0, -(SP) в обработчике HALT использует значение SP режима ядра
- повторный HALT вызывает сохранение PSW/PC по тем же адресам 17776/17774
То есть - вместо стека имеется просто пара ячеек памяти для сохранения значений.
Похоже никакого стека в режиме пульта нетЕсли команды CALL и RETURN в режиме HALT используют SP - прошивка 134 зависает.
Если команды CALL и RETURN в режиме HALT используют SP - прошивка 134 зависает.
Есть у меня такое предположение, что специальный регистр указателя стека SP для режима HALT используется только для команд CALL, RETURN и RTI. А для обычной адресации используется SP текущей моды. Ибо нигде в 134-й прошивке при работе в режиме HALT не используются адресации (SP)+ и -(SP).
Гляньте в Поиск Файлов ДВК УКНЦ, я там выложил доку к 377-й
А уменя, наборот - есть подозрение, что R0..R6 у ВМ3 при включении питания обнуляются. Узнать ответ легко - последовательность MOV Rx,(PC)+ нас рассудит.
Бессмыслено делать в микрокоде отдельную обоработку случаев включения питания и аппаратного сброса. Мусор в регистрах после сброса/включения питания никого не интересует, поэтому преднамеренный аппаратный/микропрограммный сброс маловероятен. тест подтверждает: [http://s017.radikal.ru/i407/1601/ae/8ec4657c13dct.jpg (http://s017.radikal.ru/i407/1601/ae/8ec4657c13dc.png)]
После подачи питания:
R0 - 042400
R1 - 000000
R2 - 000000
R3 - 000200
R4 - 040401
R5 - 100000
Тест стеков: [http://s015.radikal.ru/i331/1601/ee/712bc4d0c732t.jpg (http://s015.radikal.ru/i331/1601/ee/712bc4d0c732.png)]
А вот тут засада - адрес возврата сохранился по адресу 17772. То есть таки стек пульта есть, но не повторно входимый - новый HALT его реинициализирует, и можно сохранять только адреса возврата и, вероятно, PSW/PC прерывания. По (SP) оно недоступно получается (mov (SP), (R1) использует стек ядра), ну и как с этим работать?
Тест зависания, тайм-аут завершился, но стал большой - примерно 240 тактов. Далее просто переход на адрес 4 (не по значению вектора) - [http://s017.radikal.ru/i416/1601/51/c89d67af4a92t.jpg (http://s017.radikal.ru/i416/1601/51/c89d67af4a92.png)] (не влезло, тест переделал)
Update: переход таки не на 4, а по @4 (переделал тест, положил в @4 осмысленный адрес), но читается только первое слово вектора, PSW игнорируется, о как.
стек пульта есть, но не повторно входимый
Подобное бывает и на обычных процах, причем в рядовой kernel mode проца. На моем 11/83 например или на CM1420 у BYTEMAN. Возможно тут подобное сделано для перехода в режим HALT.
ну и как с этим работать?Как это делает прошивка - через CALL вызывает подпрограмму сохранения/восстановления всех регистров, включая SP.
Update: переход таки не на 4, а по @4, но читается только первое слово вектора, PSW игнорируется, о как.Ходят слухи, что прерывания в режиме HALT сохраняют только PC, но сначала лучше проверить, как в HALT-моде ВМ3 выполнится команда IOT.
- - - Добавлено - - -
От ВМ3 можно ждать любых подвохов, поэтому следующий тест проверяет работу команд JSR и RTS :
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 24
.Word Start // Адрес старта.
.Word 340
Start:
Mov #2222, SP
Mov #2, R1
HALT // Установить HALT-моду
L1:
Mov R0, (R1)
RtS R0
Next:
JSR R0, L1
Nop
От ВМ3 можно ждать любых подвохов, поэтому следующий тест проверяет работу команд JSR и RTS :
Работает со стеком пультового режима - сохраняет-извлекает адрес по 17772: [http://s020.radikal.ru/i717/1601/b4/a09b6958b224t.jpg (http://s020.radikal.ru/i717/1601/b4/a09b6958b224.png)]
По IOT вообще непонятки - [http://s017.radikal.ru/i426/1601/cf/01c056791debt.jpg (http://s017.radikal.ru/i426/1601/cf/01c056791deb.png)]
Считывает 16, потом 14, и переходит на 0, выходит IOT не используется в пульте?
skoroxod
26.01.2016, 20:16
Приветствую!
Мне тут один знакомый подсказал что здесь выясняется чем отличаются ранние ВМ3 от выпущенных с 89 года.
Сам-то я железом не увлекаюсь, но имеются в коллекции пара экземпляров возможно представляющих интерес
для сообщества. Продать их конечно не могу, камушки редкие, особенно тот что ОП, но дать на время могу.
У раннего крашеный алюминиевый радиатор по типу 1107ПВ2 и у него отломана одна нога, таким уж достался
около 5 лет назад от человека которому тот попал с ПЗУ-хой 573РФ3 от опытной платы МС1201.03
Сама плата и ему не досталась. Он хотел их запустить в обычной плате но что-то не получилось, возможно
и проц дохлый. Хотя чел и предполагал что такой ВМ3 не должен нормально работать с серийных платах.
С его слов, по идее такой ВМ3 не выполнял часть команд, которые эмулировались программно затычкой в ПЗУ
К остаткам контакта от недостающей ноги в принципе можно что-то приколхозить, при большом желании
Фоты:
http://itmages.ru/image/view/3566059/5a297aed
http://itmages.ru/image/view/3566060/ab042f81
http://itmages.ru/image/view/3566062/d5df8700
По IOT вообще непонятки - Считывает 16, потом 14, и переходит на 0, выходит IOT не используется в пульте?Там всё хитрее - в режиме HALT команда IOT записывает текущие значения PC и PSW в вектор 14 и переходит на адрес 0000000.
Приветствую!
Продать их конечно не могу, камушки редкие, особенно тот что ОП, но дать на время могу.
ОП 86 года - это, конечно, редкость, посылать его куда-то, вставлять в схему - не стоит.
А вот 1988 год выпуска - вполне можно в России найти, я бы такой купил, если кто из камрадов поможет.
Там всё хитрее - в режиме HALT команда IOT записывает текущие значения PC и PSW в вектор 14 и переходит на адрес 0000000.
А другие SST как себя ведут?
Там всё хитрее - в режиме HALT команда IOT записывает текущие значения PC и PSW в вектор 14 и переходит на адрес 0000000.
Это да, запись я проморгал. А как в обработчике отличить - это был IOT или HALT?
.
Следующий тест проверяет отработку TrapTo_10 и TrapTo_4 ( без зависания ) в режиме HALT :
.ASect
. = 0
Jmp (R1)+ // Точка входа пульта.
. = 24
.Word Start // Адрес старта.
.Word 340
Start:
Mov #2222, SP
Mov #Next, R1
HALT // Установить HALT-моду
Next:
MFPT
Jmp R0
Nop
Br .-2.
- - - Добавлено - - -
А как в обработчике отличить - это был IOT или HALT?Насколько я понял - любые прерывания в HALT-моде ВМ3 крайне нежелательны, но если кто-то очень хочет - может попробовать воспользоваться имеющимися возможностями.
Насколько я понял - любые прерывания в HALT-моде ВМ3 крайне нежелательны, но если кто-то очень хочет - может попробовать воспользоваться имеющимися возможностями.
Об этом писалось, что в HALT-режиме нельзя употреблять прерывания, и почему-то команды EIS (MUL, DIV, ASH, ASHC).
Получается прерывание в HALT-режиме ложит в вектор текущие PC и PSW HALT-режима.
и почему-то команды EIS (MUL, DIV, ASH, ASHC).Код прошивки 377 заставляет в этом усомниться :
ROM:000122 Mov @#14016, R3
ROM:000126 Mov @#14014, R2
ROM:000132 AShC #3, R2
ROM:000136 Add R4, R3
ROM:000140 Mov R2, @#14014
ROM:000144 Mov R3, @#14016
Код прошивки 377 заставляет в этом усомниться :
В 134-й также употребляется ASH и ASHC, но передаю то, что писали.
Также большая просьба к Vslav добавить к диаграммам вывод SEL(35). По данному выводу можно судить к какой памяти идет обращение - к основной или пультовой.
Получается прерывание в HALT-режиме ложит в вектор текущие PC и PSW HALT-режима.Команда IOT сохранила PC и PSW не в своём векторе, а в векторе BPT, поэтому есть смысл проверить и остальные программные прерывания :
.ASect
. = 0
Jmp (R1)+ // Точка входа пульта.
. = 24
.Word Start // Адрес старта.
.Word 340
Start:
Mov #2222, SP
Mov #Next, R1
HALT // Установить HALT-моду
Next:
EMT 0
Trap 0
BPT
Call Next2
Next2:
Mov SP, (PC)+
Nop
Nop
Br .-2
поэтому есть смысл проверить и остальные программные прерывания
И до кучи - значение SP после прерывания.
Команда IOT сохранила PC и PSW не в своём векторе, а в векторе BPT, поэтому есть смысл проверить и остальные программные прерывания
Вроде понятно. Произошла фатальная ситуация. Надо было читать из вектора 20. В HSP попало 20 и осуществился перезапуск HALT-режима и вместо ячеек 17776 и 17774 текущие PC и PSW положились в 16 и 14.
И до кучи - значение SP после прерывания.Или итоговое значение SP после всех прерываний.
Или итоговое значение SP после всех прерываний
Это и имел в виду. На случай если все происходит как при red stack abort к примеру: SP устанавливается принудительно в 4, потом происходит обычный trap to 4. Также насчет перехода в 0 - предположение, что вектор в HALT режиме берется из другого места - фиксированного или расчетного (как например при включенном MMU на все процах).
Вроде понятно. Произошла фатальная ситуация. Надо было читать из вектора 20. В HSP попало 20 и осуществился перезапуск HALT-режима и вместо ячеек 17776 и 17774 текущие PC и PSW положились в 16 и 14.Мне (на данный момент) представляется, что всё ещё проще - если в HALT-моде возникает прерывание, то оно отрабатывается по специальной схеме - в указатель стека помещается адрес вектора, в стек помещаются PSW и PC, а из скрытого вектора загружаются новые значения PC=0 и PSW=340. Таким образом команда HALT просто устанавливает HALT-моду и выполняет прерывание по вектору 020000.
Таким образом команда HALT просто устанавливает HALT-моду и выполняет прерывание по вектору 020000.
Смелое предположение, только вот в HALT-режиме по данному адресу ничего нет. Да и после сохранения PC и PSW после IOT все равно выходит на исполнение на нулевой адрес.
после IOT все равно выходит на исполнение на нулевой адрес
Так может потому что вектор в этом случае или другой или по другому вычисляется?
Так может потому что вектор в этом случае или другой или по другому вычисляется?
Вектор-то тот, 020 получается ложится в HSP, а потом в этом стеке сохраняются текущие PC и PSW. Если Vslav запустит последний тест Patron-а и выведет в диаграмму сигнал SEL, то многое станет понятно.
то многое станет понятно
Я просто не знаю почти ничего о структуре ВМ3, пытаюсь предположить варианты. Чтобы далеко за примером не ходить - возьмем тот же ВМ3. В обычном режиме стоит нам включить MMU и вектор IOT перестанет соответствовать адресу 20. Может при переходе в HALT режим происходит то же самое...
Смелое предположение, только вот в HALT-режиме по данному адресу ничего нет. Да и после сохранения PC и PSW после IOT все равно выходит на исполнение на нулевой адрес.Если предположение верно, то все возражения ошибочны.
1. По аресу HALT-вектора ничего нет
HALT-прерывание по вектору 020000 должно выполняться следующим образом: 20000 -> HSP ; PSW -> -(HSP) ; PC-> -(HSP) ; 000 -> PC ; 340 -> PSW
HALT-прерывание по вектору 000020 должно выполняться следующим образом: 00020 -> HSP ; PSW -> -(HSP) ; PC-> -(HSP) ; 000 -> PC ; 340 -> PSW
Оба случая полностью подтверждены тестами.
2. IOT все равно выходит на исполнение на нулевой адрес
Именно так и должны отрабатываться HALT-прерывания - загрузка PC и PSW производится из скрытого вектора, содержащего 000 и 340.
Я просто не знаю почти ничего о структуре ВМ3, пытаюсь предположить варианты. Чтобы далеко за примером не ходить - возьмем тот же ВМ3. В обычном режиме стоит нам включить MMU и вектор IOT перестанет соответствовать адресу 20. Может при переходе в HALT режим происходит то же самое...
Но на диаграмме не было даже попыток чтения памяти по другим адресам после IOT. По адресу 1352 считался IOT, затем в рамках конвеера по 1354 считался JSR R0,LABEL (4067). Длинная пауза, потом по 16 и 14 записывается 340 и 1354, снова пауза, ну и потом пошло всё исполняться с нулевого адреса.
Возникает предположение, что по совместительству регистр HSP в обычном режиме используется как временный, например для чтения вектора.
- - - Добавлено - - -
Если предположение верно, то все возражения ошибочны.
Под вектором подразумевается чтение из памяти новых значений PC и PSW. А так это точка начального пуска. В качестве примера запуск по питанию 1801ВМ1, а вот 1801ВМ2 в данном случае имеет полноценный вектор.
Под вектором подразумевается чтение из памяти новых значений PC и PSW. А так это точка начального пуска.Это константы, загружаемые в PC и PSW при отработке HALT-прерывания. Если программно недоступный регистр можно назвать: "указатель стека режима HALT", то и программно недоступные ячейки "скрытого вектора" можно назвать: "скрытый вектор".
Это константы, загружаемые в PC и PSW при отработке HALT-прерывания. Если программно недоступный регистр можно назвать: "указатель стека режима HALT", то и программно недоступные ячейки "скрытого вектора" можно назвать: "скрытый вектор".
Это константы, да, но не вектор.
Программно HSP не прочесть это так. А вот какой SP будет использоваться при исполнении команды JSR SP,... в HALT-режиме?
А вот какой SP будет использоваться при исполнении команды JSR SP,... в HALT-режиме?Наверняка - текущий "официальный" SP, в зависимости от бита 15 PSW ( 0 - KSP, 1 - USP ).
Наверняка - текущий "официальный" SP, в зависимости от бита 15 PSW ( 0 - KSP, 1 - USP ).
А ведь в стек ложит по HSP.
.
Последовательность действий ( скорее всего ) будет такой: SP -> -(HSP) ; PC -> SP
- - - Добавлено - - -
Соответственно, при выполнении команды RTS SP последовательность действий будет такой : SP -> PC ; (HSP)+ -> SP
Исполнение различных инструкций в HALT-моде (SEL добавлено):
EMT: [http://s019.radikal.ru/i603/1601/23/15a7113e4455t.jpg (http://s019.radikal.ru/i603/1601/23/15a7113e4455.png)] (сохранение по 26/24)
TRAP: [http://s018.radikal.ru/i511/1601/5c/ed089bcbc4dbt.jpg (http://s018.radikal.ru/i511/1601/5c/ed089bcbc4db.png)] (сохранение по 32/30)
BPT: [http://s61.radikal.ru/i174/1601/7a/f6b9a7a3dbd6t.jpg (http://s61.radikal.ru/i174/1601/7a/f6b9a7a3dbd6.png)] (сохранение по 12/10)
JSR/RTS SP: [http://s019.radikal.ru/i620/1601/7f/27727f5d64a4t.jpg (http://s019.radikal.ru/i620/1601/7f/27727f5d64a4.png)] (использует HSP для обращения к стеку, SP просто регистр адреса возврата)
Исполнение различных инструкций в HALT-модеА как ведут себя в HALT-моде прерывания по вектору 10 ( например, от команды MFPT ) и по вектору 04 ( например, от команды JMP R0 ) ?
jmp R0: [http://s020.radikal.ru/i704/1601/b0/421d1dc6b371t.jpg (http://s020.radikal.ru/i704/1601/b0/421d1dc6b371.png)]
mfpt: [http://s019.radikal.ru/i600/1601/1a/58be6ebfc3fbt.jpg (http://s019.radikal.ru/i600/1601/1a/58be6ebfc3fb.png)]
То, что должно выпадать по вектору 4, действует туповато - оно сохраняется в 2/0, тем самым перезатирая точку входа в HALT.
То, что должно выпадать по вектору 4, действует туповато - оно сохраняется в 2/0, тем самым перезатирая точку входа в HALT. То есть, как я понимаю, в реальном ДВК (1201.03/04), где от ПЗУ по младшим адресам не дождешься RPLY на DOUT, возникнет новое такое же прерывание, на чем оно благополучно и зациклит! Это так?
То есть, как я понимаю, в реальном ДВК (1201.03/04), где от ПЗУ по младшим адресам не дождешься RPLY на DOUT, возникнет новое такое же прерывание, на чем оно благополучно и зациклит! Это так?Нет - зависание в режиме HALT ничего в память не пишет, а только загружает в PC содержимое ячейки 000004.
- - - Добавлено - - -
То, что должно выпадать по вектору 4, действует туповато - оно сохраняется в 2/0, тем самым перезатирая точку входа в HALT.Уже понятно, что ради возможности обрабатывать команду HALT, как обычное программное прерывание - разработчики пожертвовали в режиме HALT всеми нормальными прерываниями без исключения.
...
Было бы полезно узнать, как реагирует процессор ВМ3 в режиме HALT на команды INC PC и TST @#1.
...
Логика подсказывает, что внешние прерывания в режиме HALT невозможны, но проверить не мешает:
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 24
.Word Start // Адрес старта.
.Word 340
Start:
Mov #2222, SP
HALT // Установить HALT-моду
Next:
Clr @#177776
BiS #100, @#177564
Wait
- - - Добавлено - - -
Из команд, неявно использующих SP, осталась не проверенной команда MARK - восполним этот пробел :
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 24
.Word Start // Адрес старта.
.Word 340
Start:
Mov #2222, SP
HALT // Установить HALT-моду
Next:
Mov #Next2, R5
Mark 0
Nop
Next2:
Call Next3 // Проверить HSP
Next3:
Mov SP, (PC)+ // Проверить SP
Nop
Wait
То, что должно выпадать по вектору 4, действует туповато - оно сохраняется в 2/0, тем самым перезатирая точку входа в HALT.
Нет - зависание в режиме HALT ничего в память не пишет, а только загружает в PC содержимое ячейки 000004.
Эти два высказывания противоречат друг другу. И, как я понял, Vslav получил свои данные на лог. анализаторе?..
То, что должно выпадать по вектору 4, действует туповато - оно сохраняется в 2/0, тем самым перезатирая точку входа в HALT.
На самом деле очень напоминает способ каким работает red stack abort на машинах с ограничением стека (11/70, 11/73, 11/[89][34]): в случае если во время прерывания из-за кривого значения кернелного стека туда не удается ничего положить, SP выставляется принудительно в 4, после чего происходит обычный trap to 4 (у этих процов есть регистр CPUERR в котором можно выяснить причину возникновения trap to 4)...
Эти два высказывания противоречат друг другу. И, как я понял, Vslav получил свои данные на лог. анализаторе?..
Не противочречат. Данные былт получены на логическом анализаторе на реальном процессоре ВМ3, но он у меня установлен на модуле, который подключен к плате Terasic DE0, а там в FPGA уже собрана система с 16К ОЗУ с адреса 000000, контроллером векторных прерываний, системным таймером 50Гц и UART типа 065. Поскольку по адресу 000000 у меня в любом режиме ОЗУ (при программировании FPGA в него загружена начальная программа), то запись в него возможна, в отличие от реальной 1201.03.
Данные былт получены на логическом анализаторе на реальном процессоре ВМ3, но он у меня установлен на модуле, который подключен к плате Terasic DE0, а там в FPGA уже собрана система с 16К ОЗУ с адреса 000000, контроллером векторных прерываний, системным таймером 50Гц и UART типа 065. Поскольку по адресу 000000 у меня в любом режиме ОЗУ (при программировании FPGA в него загружена начальная программа), то запись в него возможна, в отличие от реальной 1201.03. Так и я о том же. На анализаторе - да, запись возможна. А на реальной 1201.03/04 - нет. Соответственно, проц по TRAP TO 4 пытается записать что-то в ячейки 2-0, RPLY от записи не получает, что вызывает новый TRAP TO 4 и так до снятия DCLO.
Не противочречат. А Патрон утверждает, что зависание в Halt-Mode ничего не пишет, просто загружает адрес из 4 вектора, и все.
В принципе, это элементарно проверяется на 1201.03/04 с 377-й прошивкой (СуперМакс, ау!). Программа из 377-й прошивки при запуске с нулевого адреса первым делом сравнивает содержимое ячейки 100000 с константой 31764 (oct) и, если оно совпадает, уходит на адрес 100002. Прямо в пультовом режиме пишем в ячейку 100002 команду, вызывающую Trap to 4, потом 31764 в 100000 и запускаем программу Halt-Mode с нулевого адреса. То есть убираем сигнал К ОСТ Н (переключатель программа/пульт ставим в "программа"), заносим куда-нибудь вроде 1000 ноль (команда HALT) и запускаем с этого адреса (1000G).
А Патрон утверждает, что зависание в Halt-Mode ничего не пишет, просто загружает адрес из 4 вектора, и все.
Правильно Patron утверждает. Уже выше с этим разобрались. Если процессор в HALT-моде, то при возникновении зависания, в PC просто загружается содержимое ячейки по адресу 4 памяти пультового режима. При этом вектор прерываемого процесса не сохраняется.
Да, с тайм-аутом шины в пульте разобрались несколько страниц назад (http://zx-pk.ru/showthread.php?t=18184&p=853667&viewfull=1#post853667)
Внешнее аппаратное прерывание: [http://s019.radikal.ru/i621/1601/98/6446e095e13dt.jpg (http://s019.radikal.ru/i621/1601/98/6446e095e13d.png)]
Выполнение команды MARK: [http://s017.radikal.ru/i433/1601/3d/a4a4b4b4afb7t.jpg (http://s017.radikal.ru/i433/1601/3d/a4a4b4b4afb7.png)]
Update: ссылки поправлены
Выполнение команды MARKКоманда MARK изменяет содержимое HSP.
Здесь ссылка на ту же картинку с тестом команды MARK, что и ниже.
Поправил, хорошо что файлы не успел у себя удалить.
Гы-гы - слетели настройки DHCP в роутере роутера, и смартфон жены по беспроводке получил IP-шник совпадающий с фиксированным IP моего рабочего компа. А я то думаю, чего это пинг полсекунды и интернет еле ползает. На радикал картинки предыдущие еле смог загрузить :)
ПоправилЭто круто. В HALT-моде процессора ВМ3 запрещено только прерывание HALT. Обычные внешние прерывания контролируются через PSW обычным образом, но при их возникновении отрабатываются в таком же "стиле HALT", как и программные прерывания HALT-моды.
...
Было бы ещё полезно узнать, как реагирует процессор ВМ3 в режиме HALT на команды INC PC и TST @#1.
- - - Добавлено - - -
Типа такого:
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 24
.Word Start // Адрес старта.
.Word 340
Start:
HALT // Установить HALT-моду
Next:
Inc PC
Nop
Nop
Wait
Было бы ещё полезно узнать, как реагирует процессор ВМ3 в режиме HALT на команды INC PC и TST @#1.
Аналогичная реакция должна быть и на нечетный SP. Можно также проверить и переполнение стека, наверное здесь проверяется только KSP и USP, на переполнение стека HSP 1801ВМ3 не реагирует.
Было бы ещё полезно узнать, как реагирует процессор ВМ3 в режиме HALT на команды INC PC и TST @#1.
inc PC: [http://i017.radikal.ru/1601/c7/00df06fa987ft.jpg (http://i017.radikal.ru/1601/c7/00df06fa987f.png)]
tst @#1: [http://s018.radikal.ru/i527/1601/76/51bbfe1942dbt.jpg (http://s018.radikal.ru/i527/1601/76/51bbfe1942db.png)]
Самое забавное то, что нечетный адрес на шину всё-таки выставляется и даже читается.
inc PCСловное чтение по нечётному адресу отрабатывается в HALT-моде как зависание.
...
Следующий тест проверяет работу в HALT-моде команд MFPI, MFPD, RETURN и RTI :
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 24
.Word Start // Адрес старта.
.Word 340
Stop:
Wait
Start:
HALT // Установить HALT-моду
Ret3: Return // Возврат на адрес из 17776
Next:
Mov #Ret4, @#17776
Mov #Stop, @#20000
Mov #340, @#20002
MFPI (PC)+ // Запись следующего слова в стек
.Word Ret2
MFPD (PC)+ // Запись следующего слова в стек
.Word Ret1
Return // Возврат на Ret1
Ret1: Return // Возврат на Ret2
Ret2: Return // Возврат на Ret3
Ret4: RTI // Выход из HALT-моды на метку Stop
Результат: [http://s020.radikal.ru/i713/1601/16/2067fc35a00bt.jpg (http://s020.radikal.ru/i713/1601/16/2067fc35a00b.png)]
MFPI/MFPD используют HSP. Но раньше немного видна странная вещь - адреса от 20000 транслируются в 00000. 20000->00000, 20002->00002. То есть, записи @#2000x отображаются в 0000x.
То есть, записи @#2000x отображаются в 0000x.
Так это правильная реакция по идее - PAR'ы же никто не настраивал, и в них скорее всего нули. Аналогично должно быть и для 40000 и для 60000 итд..
Так это правильная реакция по идее - PAR'ы же никто не настраивал
Так мы в пульте, а в пульте утверждается что есть всего 4 PARH. То есть в новой ревизии ВМ3 еще и работу диспетчера в пульте поменяли, фвно PARH0 котрый должен содержать базу 170000 не используется.
Так мы в пульте, а в пульте
А какая разница?
всего 4 PARH
Речь не про них. Речь про MMU page address registers. Чтобы 20000 было 20000 нужно записать 200 в 172342 (kernel space) и 172642 (user space).
записи @#2000x отображаются в 0000x.Это значит, что первая половина адресного пространства всё же мапится через PARH0 и PARH1.
PARH0 (судя по тесту) содержит ноль, поэтому виртуальные адреса 020000..037777 мапятся на физические адреса 000000..017776.
Чтобы узнать содержимое PARH1 - надо выполнить TST @#40000 и TST @#60000
...
На картинке теста видно, что следом за командой HALT вместо команды RETURN шла команда WAIT, поэтому тест не выполнился до конца - не был проверен выход из HALT-моды по команде RTI
Это значит, что первая половина адресного пространства всё же мапится через PARH0 и PARH1
Или через MMU регистры, что было бы логично - речь же о MxPx командах. Для теста предлагаю записать 20 в 172342 и 21 в 172642 и попробовать адрес 20000. Впрочем достаточно и кернелного - пространство-то уж поди всяко из PSW берется :)
Речь не про них. Речь про MMU page address registers. Чтобы 20000 было 20000 нужно записать 200 в 172342 (kernel space) и 172642 (user space).
В 1801ВМ3 они используются в обычном режиме работы. А при работе в пульте используются PARH.
При включенном MMU существует 8 страниц по 8 КБ, а PARH-регистров только четыре. Весьма вероятно, что страниц в пульте также восемь, но 20000-37777 перетранслируется в 0-17777. Также небось и 40000-57777 и 60000-77777 перетранслируются в 0-17777. Интересно, а по PARH2 и PARH3 также две одинаковые 8-Кбайтные страницы в окне 16 кБайт?
А при работе в пульте используются PARH
Они используются именно для команд MFPx/MTPx или для текущего пространства HALT?
Или через MMU регистры, что было бы логично - речь же о MxPx командах.Команды MFPx в режиме HALT используют HSP и мапятся через PARH. Все обращения к памяти в режиме HALT ( как теперь выяснилось ) мапятся через 4 регистра PARH, причём каждые вторые 8К виртуальных адресов мапятся туда же, куда и каждые первые ( т.к. регистров PARH не 8, а только 4 ).
А какая разница?
Речь не про них. Речь про MMU page address registers.
Та документация что имеется в Сети (на старую ревизию ВМ3), уверяет что в пульте для трансляции используются ЧЕТЫРЕ PARH* вместо ВОСЬМИ PAR*/PDR*. Если бы использовалось 4 PARH*, то трансляция изменилась бы с 040000, а не с 020000, то есть покрывалась бы страница размером 16К, так записано в документации - для выбора PARH используются VA15 и VA14. Уже очевидно что в имеющемся процессоре новой ревизии 89 года, ситуация отличается.
Команды MFPx в режиме HALT используют HSP и мапятся через PARH
То есть команды служат просто для прямой адресации памяти, а не для адресации пространства предыдущего режима?
Они используются именно для команд MFPx/MTPx или для текущего пространства HALT?
Используются при работе процессора в HALT-режиме, индикатором которого служит активный низкий уровень на выводе HLTM.
Интересно, а по PARH2 и PARH3 также две одинаковые 8-Кбайтные страницы в окне 16 кБайт?Да, должно быть именно так - в следующем тесте можно будет прочитать регистр терминала по адресу 157560.
- - - Добавлено - - -
для выбора PARH используются VA15 и VA14Каждый PARH мапит 8К, поэтому, из-за игнорирования бита VA13 - каждая вторая страница дублирует каждую первую.
Используются при работе процессора в HALT-режиме
Так опять таки - при работе процессора для текущей адресации или именно для адресации через команды предыдущего пространства?
То есть команды служат просто для прямой адресации памяти, а не для адресации пространства предыдущего режима?Точно так же, как в режиме MMU16 - там тоже MFPI (PC)+ прочитает следующее слово.
как в режиме MMU16 - там тоже MFPI (PC)+ прочитает следующее слово
Это зависит от проца - в некоторых процах и при выключенном MMU эти команды продолжают использовать PARы соответствующего пространства. См. описание различий процов которое я выкладывал, но раз говорим про ВМ3, то тут полагаюсь на сказанное.
Это зависит от проца - в некоторых процах и при выключенном MMU эти команды продолжают использовать PARы соответствующего пространства.И PDR тоже используются или можно без прерывания по 250 прочитать нерезидентную память ?
раз говорим про ВМ3, то тут полагаюсь на сказанное.Это было моё предположение, которое подтвердилось для режима HALT ( и наверняка подтвердится для режима MMU16 ).
А как эти регистры PAR/PDR (и вообще все регистры MMU) у DEC правильно называются, чтобы я сразу определения забил?
А что такое режим MMU16?
- - - Добавлено - - -
Установка 200 в UPAR1/KPAR1 проигнорирована, 20006 оттранслировался в 00006, то есть - таки PARH0 используется. Итого - адрес VA13 в режиме пульта игнорируется, нечетные 8К совпадают с четными 8К, и PARH0 фиксирован на 0.
В режиме пульта:
000000..017777 -> 000000..017777
020000..037777 -> 000000..017777
- - - Добавлено - - -
157560 отобразилось в 177560, PARH3 со значением 170000? в работе?
А как эти регистры PAR/PDR (и вообще все регистры MMU) у DEC правильно называются, чтобы я сразу определения забил?Так и называются :
Kernel Active Page Registers User Active Page Registers
No. PAR PDR No. PAR PDR
0 172340 172300 0 177640 177600
1 172342 172302 1 177642 177602
2 172344 172304 2 177644 177604
3 172346 172306 3 177646 177606
4 172350 172310 4 177650 177610
5 172352 172312 5 177652 177612
6 172354 172314 6 177654 177614
7 172356 172316 7 177656 177616
А что такое режим MMU16?Это режим мапинга при "выключенном" MMU.
- - - Добавлено - - -
157560 отобразилось в 177560, PARH3 со значением 170000? в работе?Со значением 177600 - ничего другого там быть и не могло.
Так и называются :
Меня интересовало как оно в исходниках - PARU/PARK или UPAR/KPAR, я пока выбрал первый вариант.
А что, поле ACF в PDR* у ВМ3 отличается от DEC-овского? В PDP-11 Processor Handbook задекларировано 3-битное поле, в доке на ВМ3 - 2-битное, и значения другие.
Так опять таки - при работе процессора для текущей адресации или именно для адресации через команды предыдущего пространства?
По диаграмме видно что во время работы активен сигнал SEL, а это значит, что выбрана память пультового режима, так что получается, что в HALT-моде команды MFPI/MFPD/MTPI/MTPD не используют понятие предыдущей моды.
Меня интересовало как оно в исходниках - PARU/PARK или UPAR/KPAR, я пока выбрал первый вариант.Меня тоже интересовало, но во всей документации DEC упоминаются только PAR и PDR. По аналогии с PARH мне приходится использовать обозначения PARU/PARK.
А что, поле ACF в PDR* у ВМ3 отличается от DEC-овского? В PDP-11 Processor Handbook задекларировано 3-битное поле, в доке на ВМ3 - 2-битное, и значения другие.Во всей известной мне дековской документации поле ACF содержит 2 бита.
- - - Добавлено - - -
Не используемый в PDR бит 0 формально не входит в ACF, но для простоты иногда при проверке просто берут младшие 3 бита PDR без сдвига вправо.
- - - Добавлено - - -
По диаграмме видно что во время работы активен сигнал SEL, а это значит, что выбрана память пультового режима, так что получается, что в HALT-моде команды MFPI/MFPD/MTPI/MTPD не используют понятие предыдущей моды.Используют, но ( скорее всего ) "в стиле MMU16", т.е. только при непосредственной адресации к SP.
А как эти регистры PAR/PDR (и вообще все регистры MMU) у DEC правильно называются, чтобы я сразу определения забил?
DEC обычно называет KISAR/UISAR/SISAR и KISDR/UISDR/SISDR, встречаются названия KPAR/UPAR/SPAR, KPDR/UPDR, SPDR...
.
Следующий тест проверяет работу команды MFPD SP и выход из HALT-моды ВМ3 по команде RTI :
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 24
.Word Start // Адрес старта.
.Word 340
Start:
Mov #140340, @#177776 // Установить USER-моду
Mov #Stop, SP // Стек USER-моды
Mov #340, @#177776 // Установить KERNEL-моду
Mov #2222, SP // Стек KERNEL-моды
HALT // Установить HALT-моду
Wait
Next:
MFPI (PC)+ // Запись следующего слова в стек
.Word 340
MFPD SP // Запись USP в стек
RTI // Выход из HALT-моды на метку Stop
Nop
Stop:
Wait
- - - Добавлено - - -
Также не мешает проверить, откуда прочитаются данные в командах TST @#40000 и TST @#60000.
А что, поле ACF в PDR* у ВМ3 отличается от DEC-овского? В PDP-11 Processor Handbook задекларировано 3-битное поле, в доке на ВМ3 - 2-битное, и значения другие.
Всегда 2 бита было.
.
Следующий тест проверяет работу команды MFPD SP и выход из HALT-моды ВМ3 по команде RTI :
MFPD SP выполнил KSP->@HSP (а не USP как ожидалось) и возврат произошел на 22228
В тесте занес в KSP нормальный адрес возврата (не 2222): [http://s017.radikal.ru/i402/1601/20/d658b247d229t.jpg (http://s017.radikal.ru/i402/1601/20/d658b247d229.png)]
.
Также не мешает проверить, откуда прочитаются данные в командах TST @#40000 и TST @#60000.
TST @# 40000/60000 отобразились на адрес 000000
- - - Добавлено - - -
Всегда 2 бита было.
Странно, я смотрел Handbook от 1979 года, там юнибасные машины оказались. А в F-11 и 11/34, да, два бита ACF, так их усерс мануалы говорят. В-общем, к ним ВМ3 ближе всего выглядит.
А как RSХ-11 обходит единичные значения в младших битах SR3? Не пытается режим супервизора включать? Там патчить нужно было?
- - - Добавлено - - -
Я в барахолке сделал запрос на старый ВМ3, 1988 года, посмотрим, может быть у кого найдется такой, интересно будет потестить.
А как RSХ-11 обходит единичные значения в младших битах SR3?
Да они как бы просто ничем не мешают.
MFPD SP выполнил KSP->@HSP (а не USP как ожидалось)Это означает, что в режиме HALT предыдущая мода вообще не используется командами MFPI ; MFPD ; MTPI ; MTPD - позже проверим это и для режима MMU16.
В тесте занес в KSP нормальный адрес возврата Команды RTI и RTT принудительно завершают режим HALT в любом случае - как и предполагалось.
TST @# 40000/60000 отобразились на адрес 000000Значит, PARH1 тоже содержит 000000.
Там патчить нужно было?
Ни одна из известных до сих пор проблем даже теоретически не может помешать RSXу никаким боком и не мешает :)
Прочитал про 1801ВМ4 такое - "содержит 50 тысяч транзисторов, из которых только 3500 не входят в регулярные структуры и не получены путем мультиплицирования. Это дает надежду на осиливаемый реверс 1801ВМ4 ))
.
Тест разрядности HSP ( куда пойдёт пуш при HSP = 000000 ) и тест MFPI SP в режиме MMU16 :
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 24
.Word Start // Адрес старта.
.Word 340
. = 112
Trap:
Jmp R0 // Записать код 114 [ Jmp (R4) ] по адресу 000000
Start:
Mov #2222, SP
MFPI SP // Какой SP запишется при MMU16 ?
HALT // Установить HALT-моду
Wait
Next:
Mov #Next1, R4
Br Trap
Next1:
MFPI SP // Куда запишется KSP при HSP = 000000 ?
Wait
.
Тест разрядности HSP ( куда пойдёт пуш при HSP = 000000 ) и тест MFPI SP в режиме MMU16 :
Я не понимаю как этот тест работает, там опечатка на jmp R0?
Смысл в чем - вызвать исключения по неверной команде или HALT-ы непрерывно?
Я не понимаю как этот тест работает, там опечатка на jmp R0?
Смысл в чем - вызвать исключения по неверной команде или HALT-ы непрерывно?Смысл в том, что команда JMP R0 находится по адресу 112, поэтому в момент прерывания значение PC будет совпадать с кодом команды JMP (R4), который и запишется по адресу 000000.
HSP переставился на 177776 и обратилось к PSW (на шине не видно транзакции) [http://s020.radikal.ru/i723/1601/c3/c763cae7adc4t.jpg (http://s020.radikal.ru/i723/1601/c3/c763cae7adc4.png)]
HSP переставился на 177776 и обратилось к PSW (на шине не видно транзакции)Значит - HSP реализован, как стандартный 16-битный регистр.
Команда MFPI SP в режиме MMU16 записала 002222 по адресу 002220.
- - - Добавлено - - -
Следующий тест проверяет, происходит ли запись до прерывания при словном обращении по нечётному адресу в режимах MMU16 и HALT :
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 4
.Word L1
.Word 0
. = 24
.Word Start // Адрес старта.
.Word 340
Start:
Mov #177777, R0
Mov #6, R4
Mov #7, R5
Mov #2222, SP
Mov R0, (R5)
L1:
Tst (R4) // Что по адресу 000006 ?
HALT // Установить HALT-моду
Wait
Next:
Mov #Next1, @#4
Clr (R4) // Очистить ячейку 000006
Mov R0, (R5)
Nop
Next1:
Tst (R4) // Что по адресу 000006 ?
RTT
А как RSХ-11 обходит единичные значения в младших битах SR3? Не пытается режим супервизора включать? Там патчить нужно было?
Разобрал в профильной теме (http://zx-pk.ru/showthread.php?t=18420&p=854498&viewfull=1#post854498) по пунктам почему с RSX-11 проблем на ВМ3 нет.
Перенесем сюда результаты, касающиеся данной темы.
Программа MTPS.SAV (http://pdp-11.org.ru/~form/files/pdp-11/cm1420/mtps.sav) включает MMU, сохранив до-MMUшный маппинг страниц с полным доступом для user и kernel mode и проверяет что будет если из пользовательского режима выполнить MTPS #347 при разрешенном и запрещенном доступе к I/O page. Большинству процессоров (по идее все кроме 11/34) пофигу отображен ли PSW на странице ввода-вывода, а MTPS из пользовательского режима может менять только CVZN. В 11/34 и на СМ1420 ситуация другая:
.MTPS
UISDR7=077406, PSW=170000, MTPS #347, PSW=170347
UISDR7=077400, PSW=170000, MTPS #347, PSW=170000, MMU FAULT
Чисто формально можно проверить ВМ3 (раз уж RESORC его тоже обзывает 11/34, хотя общего у него с ним мало) :)
На ВМ3.
UISDR7=077506, PSW=170000, MTPS #347, PSW=170347
UISDR7=077400, PSW=170000, MTPS #347, PSW=170011, MMU FAULT
Следующий тест проверяет, происходит ли запись до прерывания при словном обращении по нечётному адресу в режимах MMU16 и HALT :
Анализатор всю диаграмму за один проход не захватывает, разбил на две (синхро по фронту ACLO и срезу HLTM):
Часть1: [http://s013.radikal.ru/i323/1601/de/5d314a7f0d97t.jpg (http://radikal.ru/fp/045f529c2095471c886c2a6de77b0dcb)]
Часть2: [http://s018.radikal.ru/i502/1601/1b/938e421517b7t.jpg (http://radikal.ru/fp/1533272a1ae34ebe912bff4e02a64451)]
Пожалуй надо кое-что добавить в тест для разрешения неясности.
- - - Добавлено - - -
Пожалуй надо кое-что добавить в тест для разрешения неясности.
Обновил прогу, хотя неоднозначности похоже не было. Но так хуже не будет.
- - - Добавлено - - -
На 1/83 привычный результат...
.RU MTPS
UISDR7=077406, PSW=170000, MTPS #357, PSW=170017
UISDR7=077400, PSW=170000, MTPS #357, PSW=170017
.
Обновил прогу, хотя неоднозначности похоже не было. Но так хуже не будет.
Кидайте исходник, я пропатчу для голого ВМ3 и запущу у себя, будет видно в подробностях, что происходит.
Меня интересовало как оно в исходниках - PARU/PARK или UPAR/KPAR, я пока выбрал первый вариант. В исходниках RT-11 так:
MMSR0 = 177572
MMSR1 = 177574
MMSR2 = 177576
MMSR3 = 172516
UISDR0 = 177600
UISDR7 = 177616
UISAR0 = 177640
UISAR7 = 177656
KISDR0 = 172300
KISDR7 = 172316
KISAR0 = 172340
KISAR1 = 172342
KISAR7 = 172356
Выдернуто из текста VM.MAC, такой же таблицы в RMONFB.MAC и в XMSUBS.MAC я наскоком не нашел, но имена KISARn, KISDRn и остальные встречаются в них повсеместно.
Похоже выявлен ище один косяк ВМ3. Не страшный, но тем не менее :)
- - - Добавлено - - -
Кидайте исходник, я пропатчу для голого ВМ3 и запущу у себя, будет видно в подробностях, что происходит.
Выложил там же.
- - - Добавлено - - -
PARU/PARK
Так никто не называет. KPAR/KISAR, KPDR/KISDR. KPAR/KPDR - старый вариант когда не было разделения I&D и режима супервизора. Для ВМ3 впрочем это в силе.
- - - Добавлено - - -
будет видно в подробностях, что происходит.
Подозреваю, что совсем в подробностях не будет - обращения к PSW как я понимаю идут внутри проца и внаружу не светятся.
Интересно еще раз проверить обновленный тест, в частности PSW после команды которая вызывает сбой.
2 вариант MTPS на ВМ3.
UISDR7=077506, PSW=170000, MTPS #357, PSW=170357
UISDR7=077400, PSW=170000, MTPS #357, PSW=170011, MMU FAULT
2 вариант MTPS на ВМ3.
Получается интересная картина: команда вызывает прерывание MMU, попутно меняя биты C и N в PSW.
Также судя по первой операции, MTPS отмечается в MMU как запись в 7 страницу. На СМ1420 такого не наблюдалось.
- - - Добавлено - - -
Еще интересен такой тест (последней прогой):
.SIPP MTPS.SAV/A
Base?
Offset? 1316
Base Offset Old New?
000000 001316 000357 17
000000 001320 104400 ^Y
.RU MTPS
Если используется советский SL, его нужно предварительно отключить - не дружит он с SIPP и некоторыми другии прогами :)
form, Что за SIPP? С ним прога не идет.
Что за SIPP? С ним прога не идет.
В чем проявляется что она не идет? SIPP редактирует файлы. Циферки совпадают с теми что в сообщении?
- - - Добавлено - - -
Можно и без SIPP чтобы не ломать оригинал:
.GE MTPS
.E 1316 ! ПРОВЕРЯЕМ, ЧТО ПИШЕМ ТУДА
000357
.D 1316=17
.ST
UISDR7=077406, PSW=170000, MTPS #357, PSW=170017
UISDR7=077400, PSW=170000, MTPS #357, PSW=170017
.
?UCL-F-Command does not exist
Анализатор всю диаграмму за один проход не захватывает, разбил на две (синхро по фронту ACLO и срезу HLTM)Удивительное дело - в режиме MMU16 при словной записи по нечётному адресу - процессор не произвёл запись, но до входа в прерывание успел выполнить следующую команду. В режиме HALT такого не случилось и всё отработало как надо.
- - - Добавлено - - -
?UCL-F-Command does not existНа системном диске отсутствует файл SIPP.SAV
Можно и без SIPP чтобы не ломать оригинал:
.GE MTPS
.E 1316
000357
.D 1316=17
.ST
UISDR7=077506, PSW=170000, MTPS #357, PSW=170017
UISDR7=077400, PSW=170000, MTPS #357, PSW=170001, MMU FAULT
Вроде картина прояснилась, еще оден тест для очистки совести: все как выше, только вместо 17 записать 0.
Удивительное дело - в режиме MMU16 при словной записи по нечётному адресу - процессор не произвёл запись, но до входа в прерывание успел выполнить следующую команду. В режиме HALT такого не случилось и всё отработало как надо.
Да не выполнил он следующую команду. Сначала прочелся PSW нового вектора по адресу 6, затем в стек положился старый вектор, а уж затем прочелся новый PC по адресу 4, ну и далее стало исполняться прерывание по зависанию.
?UCL-F-Command does not exist DESS'ом её! Задача: заменить в первом (считая с нуля) блоке по смещению 316 код 000357 на 000017.
Есть ещё один момент, который можно проверить про работу с PSW. На всех дековских процессорах, при записи по адресу 177776 - там сначала устанавливаются биты признаков по итогам операции и только потом производится запись.
Каким будет содержимое PSW сразу после записи туда 000000 :
Mov #000000, @#177776
Mov @#177776, @#100
сначала устанавливаются биты признаков по итогам операции и только потом производится запись.
Похоже с MTPS на ВМ3 та же ситуация судя по тесту выше. Если происходит сбой MMU, то признаки так и остаются в согласии с байтом который он пытался записать (а C устанавлиается всегда [или при сбое, хотя это врядли]).
Да не выполнил он следующую команду. Сначала прочелся PSW нового вектора по адресу 6, затем в стек положился старый вектор, а уж затем прочелся новый PC по адресу 4, ну и далее стало исполняться прерывание по зависанию.Точно! Надо учесть эту последовательность при эмуляции.
Вроде картина прояснилась, еще оден тест для очистки совести: все как выше, только вместо 17 записать 0.
.GE MTPS
.E 1316
000357
.D 1316=0
.ST
UISDR7=077506, PSW=170000, MTPS #357, PSW=170000
UISDR7=077400, PSW=170000, MTPS #357, PSW=170005, MMU FAULT
PSW=170005
Ну вроде картина подтвердилась. Для 357 было N+C, для 17 - C, для 0 - Z+C
Если происходит сбой MMU, то признаки так и остаются в согласии с байтом который он пытался записать (а C устанавлиается всегда [или при сбое]).Проще говоря - ВМ3 при всех операциях записи сначала устанавливает биты признаков и только затем производит запись.
Но откуда берётся бит C ?
Верно ли, что если замапить адрес 177776 в пустоту и выполнить MOV #000000, @#177776, то бит C не установится, а если выполнить MTPS #000 - установится ..
Но откуда берётся бит C ?
А черт его знает. Фича MTPS?
Вроде бита V который сбрасывается командой SWAB везде кроме 11/10 и 11/20...
А если модифицировать тест так, чтобы при записи в PSW возникало не прерывание 250, а зависание - как тогда отработает MTPS ?
Верно ли, что если замапить адрес 177776 в пустоту и выполнить MOV #000000, @#177776, то бит C не установится
Ну это легко проверить. С тем же тестом выше - места хватит (CCC там просто так - реально не нужна):
.GE MTPS
.D 1312=12737,0,177776
.ST
UISDR7=077406, PSW=170000, MTPS #357, PSW=000000
UISDR7=077400, PSW=170000, MTPS #357, PSW=170000, MMU FAULT
.
- - - Добавлено - - -
А если модифицировать тест так, чтобы при записи в PSW возникало не прерывание 250, а зависание - как тогда отработает MTPS ?
Можно так попробовать:
.GE MTPS
.D 42=160004
.ST
mov #2, R1 ;
mov #000000, @#177776 ;
mov @#177776, (R1) ;
ВМ3 сохранил по 000002 нулевое значение: [http://s019.radikal.ru/i606/1601/1f/aff2f6f5b70et.jpg (http://s019.radikal.ru/i606/1601/1f/aff2f6f5b70e.png)]
Получается что сначала поставил флаги, и только потом записал значение.
Ну это легко проверить.
GE MTPS
.D 1312=12737,0,1777776
.ST
UISDR7=077506, PSW=170000, MTPS #357, PSW=000000
UISDR7=077400, PSW=170000, MTPS #357, PSW=170000, MMU FAULT
Хотя нет, не сильно ясно что получится - проще ввести фактор явно в программе.
Можно так попробоватьНадо свой обработчик на вектор 04 ставить, чтобы как и при прерывании 250 - вместо MMU FAULT выводил BUS ERROR
PSW=170000
Подтвердилось - MOV C не трогает.
- - - Добавлено - - -
Надо свой обработчик на вектор 04 ставить, чтобы как и при прерывании 250 - вместо MMU FAULT выводил BUS ERROR
Сейчас сделаю. У меня правда номер не пройдет, но на ВМ3 должен упасть.
Можно так попробовать:
.GE MTPS
.D 42=160004
.ST
@ 001054
Сейчас сделаю
Надо отбежать, как вернусь - сделаю...
Подтвердилось - MOV C не трогает.А Z где ?
Что-то логика действий не вполне понятна - если при выполнении MOV сначала в PSW устанавливаются биты признаков, то почему бит Z не установился..
Patron, я так понимаю, что в скором времени можно будет попробовать попросить вас сделать эмуляцию процессора СМ2420? :D
эмуляцию процессора СМ2420? :D
А схем процессора там не сохранилось? Может мы попробуем и на Верилоге его реализовать?
PS. Я бы вообще съездил, посмотрел на работающую СМ-ку, в тетрис на ней поиграл бы, может тусовку на майские замутим?
Судя по вот этой штуке, у СМ довольно шустрый проц...
ТЕСТ БЫСТРОДЕЙСТВИЯ
КОМАНДА СЛОЖЕНИЯ РЕГИСТР-РЕГИСТР
БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК) 1064
КОМАНДА СЛОЖЕНИЯ РЕГИСТР-ПАМЯТЬ
БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК) 408
КОМАНДА УМНОЖЕНИЯ РЕГИСТР-РЕГИСТР
БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК) 136
КОМАНДА ДЕЛЕНИЯ РЕГИСТР-РЕГИСТР БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК) 336
- - - Добавлено - - -
Vslav, у меня только текстовое техописание на полтыщи страниц. Схемы надо тормошить dk_spb
Архитектурные особенности УВК СМ 1420 определяются параметрами процессора СМ 2420. Система команд включает в себя базовый набор команд (команды СМ-3), а также дополнительно 4 команды с фиксированной запятой, 46 команд с плавающей запятой, 2 команды диспетчера памяти, 7 команд общего применения и 1 команду диагностики. В комплексе реализован режим работы в реальном масштабе времени по временным меткам аппаратного таймера при частоте счетных импульсов 50+1 Гц. Оперативная память емкостью 124 Кслов конструктивно и функционально встроена в процессор; емкостью до 1920 Кслов — автономная. В автономной памяти предусмотрен блок преобразования адреса, обеспечивающий преобразование 18-разрядных адресов устройств прямого доступа в 22-разрядные адреса ОП.
;-)
А Z где ?
Здесь штатный MMU abort, а с MTPS он скрытый.
;-)
Чтобы "воплотить дух 2420 в ПЛИС" нужны "Инструкция по эксплуатации 2420", "Комплект схем 2420" и "Программа-эмулятор пульта", и хорошо бы общий сборосный чертеж со схемами. Там сканировать - не пересканировать.
я так понимаю, что в скором времени можно будет попробовать попросить вас сделать эмуляцию процессора СМ2420?
Она судя по всему не отличается от обычного 11/34 :)
;-)
Чтобы "воплотить дух 2420 в ПЛИС" нужны "Инструкция по эксплуатации 2420", "Комплект схем 2420" и "Программа-эмулятор пульта", и хорошо бы общий сборосный чертеж со схемами. Там сканировать - не пересканировать.
Про замутить движ в мае - реально, МБ к этому моменту уже музей будет физически существовать...
Про сканирование - программа эмулятор пульта уже есть вычитана в топике про запуск комплекса, РЭ там небольшое, пусконаладка тоже небольшая книга, монтажный чертёж я сегодня вечером отфоткаю, забрал домой чтобы разобраться с разведкой питания. Тех описание жирное, ещё есть описание контроллеров внешних ус-в, книга с описанием общей шины, куча книг с листингами тестов с комментариями...
Выложил новую программу (http://pdp-11.org.ru/~form/files/pdp-11/cm1420/mtps.sav). Теперь по идее можно вызвать double bus error в момент MTPS. Написанное серым делать не нужно - это чтобы у меня трапнулось. Ну понятно у меня вместо DBE получается RSA.
.GE MTPS
.D 1402=6506,12746,160004,6606
.D 1416=6606
.D 1412=5737,1
.ST
*** TRAP TO 4, PC=001416, PSW=140010 ***
.
Выложил новую программу
GE MTPS
.D 1402=6506,12746,160004,6606
.D 1416=6606
.ST
@ 001416
.
Когда какой-то тест ВМ3 вылетает в пульт - можно сразу нажать M и узнать причину вылета.
Ну по адресу вроде как раз там где надо вылетело - должно быть double bus error. Или там есть отдельно для kernel stack ошибка?
Когда какой-то тест ВМ3 вылетает в пульт - можно сразу нажать M и узнать причину вылета.
HALT INSTRUCTION
Судя по вот этой штуке, у СМ довольно шустрый проц... Не знаю, сильно ли отличались разные выпуски СМ1420, или нет. Я году, так, в 96-м (плюс-минус год - не помню уже) имел дело с 1420 одного из последних выпусков, с тремя дисками DM. На ней, под ДИАМСом работала АСУ птицефабрики. Так вот, зарплата там считалась 2 часа с лишним. Говорили, что когда была исправна кэш-память, зарплата считалась минут 15-20. Потом кэш-память сдохла, ее отключили и начались тормоза... (В скобках замечу, что AMD 5x86-133, после того, как я перенес бухгалтерию этой птицефабрики с DSM-11 на MSM-PC, посчитал ту же зарплату за 30 сек, бухгалтера обалдели!..)
Так вот, к чему это я. Перечисленное в листинге быстродействие, похоже, без кэша. С работающим кэшем, по крайней мере сложения R-R и R-Mem должны быть намного быстрее. Не знаю, может не все СМ-ки комплектовались кэш-памятью, может ее отключили (в связи со смертью), как и на птицефабрике... В общем, глянь, может она просто выключена.
Когда какой-то тест ВМ3 вылетает в пульт - можно сразу нажать M и узнать причину вылета.
В 1801ВМ3 причину вылета вы не узнаете. После любой фатальной ситуации или HALT исполнение всегда начинается с нулевого адреса HALT-режима. Узнать можно по косвенным данным, например если SP больше 160000, то наверняка это DOUBLE BUS ERROR, если перед PC команда с кодом 0 - то исполнение HALT.
Или там есть отдельно для kernel stack ошибка?В пульт ошибка kernel stack не выходит - трапается по 04, причём есть ли там градации на YELLOW и RED - неизвестно, надо тестировать.
- - - Добавлено - - -
В 1801ВМ3 причину вылета вы не узнаете.Но в прошивке 134 есть код, выводящий сообщения на все варианты причин вылета.
Не знаю, сильно ли отличались разные выпуски СМ1420, или нет. Я году, так, в 96-м (плюс-минус год - не помню уже) имел дело с 1420 одного из последних выпусков, с тремя дисками DM. На ней, под ДИАМСом работала АСУ птицефабрики. Так вот, зарплата там считалась 2 часа с лишним. Говорили, что когда была исправна кэш-память, зарплата считалась минут 15-20. Потом кэш-память сдохла, ее отключили и начались тормоза... (В скобках замечу, что AMD 5x86-133, после того, как я перенес бухгалтерию этой птицефабрики с DSM-11 на MSM-PC, посчитал ту же зарплату за 30 сек, бухгалтера обалдели!..)
Так вот, к чему это я. Перечисленное в листинге быстродействие, похоже, без кэша. С работающим кэшем, по крайней мере сложения R-R и R-Mem должны быть намного быстрее. Не знаю, может не все СМ-ки комплектовались кэш-памятью, может ее отключили (в связи со смертью), как и на птицефабрике... В общем, глянь, может она просто выключена.
Мне сильно кажется, что тут кэша не было... Машина у меня вроде как 87-го.
Но в прошивке 134 есть код, выводящий сообщения на все варианты причин вылета.
Код есть, но он нигде не вызывается. Есть дизассемблированный вариант (правда без комментариев). Внимательно посмотрите и проанализируйте, нигде вызова этого кода нет. Так что причина там всегда одна - HALT INSTRUCTION.
В пульт ошибка kernel stack не выходит - трапается по 04, причём есть ли там градации на YELLOW и RED - неизвестно, надо тестировать.
Так в данном случае он именно останавливается и именно по кернел stack (попытка трапнуться при KSP=160004). А вот у меня он трапается по RSA в этом случае.
Так в данном случае он именно останавливается и именно по кернел stackПросится на выполнение следующий тест :
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 4
.Word Trap4
.Word 340
. = 24
.Word Start // Адрес старта.
.Word 340
Trap4:
RtI
Start:
Mov #400, SP
Call L1
L1:
Mov #364, SP
Call L2
L2:
Mov #200, SP
Call L3
L3:
Mov #2, SP
Call Next
Next:
Wait
Классическая зачистка памяти:
MOV #160000,SP
MOV #4747,@#0
CLR PC
Вызывает YSA там где он есть. Где нет - чистит память и штатно останавливается.
Просится на выполнение следующий тест :
Трапнулся после mov #364, SP, команда не выполнилась: [http://s020.radikal.ru/i703/1601/c4/3f8646d0c5bet.jpg (http://s020.radikal.ru/i703/1601/c4/3f8646d0c5be.png)]
Трапнулся после mov #364, SP, команда не выполниласьСитуация получилась очень интересная.
Mov #400, SP
Call L1
L1:
Call L1 отработал и адрес возврата сохранился по адресу 0376
...
Mov #364, SP
Call L2
L2:
При первом выполнении - команда Mov #364, SP трапнулась, сохранив в стеке свой адрес, возврат по RTI произошёл обратно и при втором исполнении команда Mov #364, SP отработала без проблем, установив стек на 0364. Сразу следом отработала и команда Call L2, сохранив адрес возврата в ячейке 0362.
...
Mov #200, SP
Call L3
L3:
При первом выполнении - команда Mov #200, SP трапнулась, сохранив в стеке свой адрес, возврат по RTI произошёл обратно и при втором исполнении команда Mov #200, SP отработала без проблем, установив стек на 0200. Сразу следом отработала и команда Call L3, но тут картинка кончилась.
Надо бы после CALL вставить NOP для чистоты эксперимента, тогда будет видно при заносе в SP это выполняется или при заносе в стек. Т.е. первой командой на метке будет NOP, а не MOV.
но тут картинка кончилась.
Получилось переключить анализатор в transitional mode - теперь захват значений идет по каждому изменению CPU_CLK (та которая подается на реальный 1801ВМх), но уродский Quartus не может нормально экспортировать такой файл в картинку. Нормальный просмотровщик .vcd я не нашел - бОльшая часть из них глючит и файл не открывает. Выложил .csv, .tbl, .vcd тут (http://u.zeptobars.ru/yuot/MISC/Wave)
C .vcd у меня отработал только GTKWave но с большим скрипом.
Update: надо бы на Перле написать скрипт, который преобразует один из форматов во вменяемый лог транзакций.
- - - Добавлено - - -
Надо бы после CALL вставить NOP для чистоты эксперимента, тогда будет видно при заносе в SP это выполняется или при заносе в стек. Т.е. первой командой на метке будет NOP, а не MOV.
Понадобилось добавить два nop, чтобы убедиться что причиной исключения является инструкция call, то есть - call исполняется, потом проверяется стек и возникает исключение. Вставил несколько nop после mov #200, SP - никаких исключений mov не вызвал.
Понадобилось добавить два nop, чтобы убедиться что причиной исключения является инструкция call, то есть - call исполняется, потом проверяется стек и возникает исклоючение. Вставил несколько nop после mov #200, SP - никаких исключений не возникло.
А адрес какой команды заносится в стек при исключении?
Вставил несколько nop после mov #200, SP - никаких исключений mov не вызвал.Но на выложенной картинке в стек при прерывании попадает именно адрес MOV и после RTI команда MOV выполняется второй раз.
- - - Добавлено - - -
Для проверки прерывания при команде CALL можно прогнать такой тест:
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 4
.Word Trap4
.Word 340
. = 24
.Word Start // Адрес старта.
.Word 340
Trap4:
RtI
Start:
Mov #400, SP
Mov #10., R4
L2:
Call L1
L1:
Nop
SOB R4, L2
Next:
Wait
Но на выложенной картинке в стек при прерывании попадает именно адрес MOV и после RTI команда MOV выполняется второй раз.
Она не выполняется второй раз, первый раз просто произошла предвыборка, собственно команда не выполнилась - это видно по тому что стек не изменился, и при добавлении nop-ов просто происходит предвыборка nop-ов. Сохраняемый адрес возврата - на точку куда передала управление call.
Она не выполняется второй разТогда можно проверить, как отработает IOT после MOV #2, SP :
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 4
.Word Trap4
.Word 340
. = 20
.Word Trap4
.Word 340
.Word Start // Адрес старта.
.Word 340
Trap4:
Mov SP, @#100
Wait
Start:
Mov #2, SP
Nop
Nop
IOT
Nop
Nop
Next:
Wait
и при добавлении nop-ов просто происходит предвыборка nop-ов.
А при одном NOP-е происходит и предвыборка команды MOV с параметром или без параметра?
Для проверки прерывания при команде CALL можно прогнать такой тест:
[http://s017.radikal.ru/i407/1601/e8/5a3645785d9bt.jpg (http://s017.radikal.ru/i407/1601/e8/5a3645785d9b.png)]
Итого:
- выбирается инструкция call
- выбирается смещение call
- выбирается следующее слово смещением
- в стек записывается адрес возврата (слово следующее за call)
- выбирается инструкция по новому значению PC (адрес вызванной процедуры)
- выбирается следующее слово инструкции вызванной процедуры PC+2
- возникает исключение
- выбирается PSW по адресу 000006
- old PSW-> -(SP)
- old PC (равный первой инструкции вызванной процедуры) -> -(SP)
- выбирается PC по адресу 000004
- выбирается первая инструкция обработчика исключения (rti)
- выбираетсмя следующее слово за rti
- (SP)+ -> PC
- (SP)+ -> PSW
- возобновляется исполнение первой инструкции вызванной процедуры (nop)
- - - Добавлено - - -
А при одном NOP-е происходит и предвыборка команды MOV с параметром или без параметра?
Без, это просто предвыборка двух слов на входе новой вызванной процедуры, эти инструкции не исполняются до возврата из исключения, только предвыбираются.
- - - Добавлено - - -
Тогда можно проверить, как отработает IOT после MOV #2, SP :
[http://s008.radikal.ru/i306/1601/c8/d6c212b99c38t.jpg (http://s008.radikal.ru/i306/1601/c8/d6c212b99c38.png)]
Процессор шизанулся, mov #2, SP, исключения не вызвала, IOT отработал как обычно, за исключением того что сохранил PC по 177776, предвыбрал первую и инструкцию обработчика, но тут же попытался трапнуться по 4 вектору (выбрал PSW по 000006) и завис на сохранении в стеке по 177774.
.
В общем ситуация ясна, при любом значении SP меньше 402 ( или меньше 404 в случае прерываний ) - прерывания и вызовы подпрограмм приводят к YELLOW TRAP после выполнения команды.
и завис на сохранении в стеке по 177774
Интересно, почему он не попытался перейти в HALT-режим, или ситуация двойного зависания не возникла?
.
Осталось узнать, произойдёт ли YELLOW TRAP при возникновении прерываний по вектору 4 :
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 4
.Word Trap4
.Word 340
. = 10
.Word Trap4
.Word 340
. = 24
.Word Start // Адрес старта.
.Word 340
Trap4:
RtI
Start:
Mov #400, SP
MFPT // Начнём с TrapTo_10
Nop
Jmp R0
Nop
Tst @#1
Nop
Next:
Wait
- - - Добавлено - - -
Но и ситуацию с аппаратными прерываниями тоже полезно уточнить :
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 4
.Word Trap4
.Word 340
. = 24
.Word Start // Адрес старта.
.Word 340
.=62
.Word Trap4
.Word 340
Trap4:
Nop
RtI
Start:
Mov #400, SP
BiS #100, @#177564
Nop
Nop
Nop
Next:
Wait
- - - Добавлено - - -
Ещё одна "пушащая" команда: MFPI, но не стоит забывать и про RETURN :
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 4
.Word Trap4
.Word 340
. = 24
.Word Start // Адрес старта.
.Word 340
Trap4:
Nop
RtI
Start:
Mov #200, SP
Nop
MFPI (PC)+
Nop
Nop
Mov #Next, -(SP)
Nop
Nop
Return
Nop
Next:
Nop
Wait
То есть на ВМ3 получается недозащита стека как в E11 ошибочно сделано для процов где есть защита стека: при падении ниже 400 - трап, при невозможности записать в стек - падает.
.
Осталось узнать, произойдёт ли YELLOW TRAP при возникновении прерываний по вектору 4 :
По mfpt возникает дополнительное исключение по 000004, сразу перед первой инструкцией обработчика
[http://s010.radikal.ru/i314/1602/68/709f6c38afcat.jpg (http://s010.radikal.ru/i314/1602/68/709f6c38afca.png)]
По jmp R0 тоже возникает дополнительное исключение по 000004, любопытно что не повторяется бесконечно
[http://s019.radikal.ru/i607/1602/84/61c2eb93ed5ct.jpg (http://s019.radikal.ru/i607/1602/84/61c2eb93ed5c.png)]
По нечетному адресу также возникает одно дополнительное исключение 000004
[http://s017.radikal.ru/i428/1602/f2/afffc15e5616t.jpg (http://s017.radikal.ru/i428/1602/f2/afffc15e5616.png)]
По аппаратному прерыванию тоже возникает исключение 000004
[http://s019.radikal.ru/i620/1602/70/1c431e455c7ft.jpg (http://s019.radikal.ru/i620/1602/70/1c431e455c7f.png)]
MFPI вызывает исключение 000004
[http://s019.radikal.ru/i622/1602/9e/f11620b7284ft.jpg (http://s019.radikal.ru/i622/1602/9e/f11620b7284f.png)]
Обращение к стеку через -(SP) вызывает исключение 000004
[http://s017.radikal.ru/i410/1602/e1/a2d51b3090b5t.jpg (http://s017.radikal.ru/i410/1602/e1/a2d51b3090b5.png)]
Обращение к стеку через -(SP) вызывает исключение 000004А такое мы можем устроить и в HALT-моде :
.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 4
.Word Trap4
.Word 340
. = 24
.Word Start // Адрес старта.
.Word 340
Trap4:
RtI
Nop
Start:
Mov #400, SP
HALT // Установить HALT-моду
Nop
Wait
Next:
Clr -(SP)
Nop
Nop
Wait
А такое мы можем устроить и в HALT-моде :
Можем и устроим, только вечером - сейчас работу работаем, хобби пока в коробку убрал и стол освободил :)
.
Запуск прошивки 377 вскрыл пласт проблем в эмуляции контроллера DW - 1) никак не эмулируется влияние обращений к 174006 на текущую позицию в буфере данных ; 2) никак не эмулируется влияние чтения по адресу 174016 на текущую позицию в буфере данных.
Для установления истины написан тест TDW1.SAV (http://emulator.pdp-11.org.ru/misc/TDW1.zip)
Результат первого запуска в эмуляторе ДВК такой:
.RU TDW1
0
1
2
3
4
5
6
7
8
9
10
11
0
1
2
Результат повторного запуска такой:
.RU TDW1
0
1
2
3
4
5
6
7
8
9
10
11
253
254
255
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot