Просмотр полной версии : Особенности процессоров и устройств архитектуры PDP-11. Тесты. Диагностика.
Страницы :
[
1]
2
3
4
5
6
7
8
9
10
Без долгих вступлений - протестируем влияние бита T в PSW на обслуживание запросов IRQ от таймера и порта терминала.
В приложении - дополненный вариант теста PDP-11 Interrupts Test #1c (http://zx.pk.ru/attachment.php?attachmentid=33138)
В кернел пока не перключается, соответственно MTPS не работает итд.
Из под FB:
.RU PDPT1C
PDP-11 Interrupts Test #1c
MTPS #340
...Press Key...
BIS #100,@#TTPS
Set T x3
RTI | NOP | WAIT | NOP | NOP | NOP
>>> Trap to 014 <<< ; 001234
>>> Interrupt <<< 100 ; 001234
>>> Trap to 014 <<< ; 001234
>>> Trap to 014 <<< ; 001234
>>> Interrupt <<< 060 ; 001234
>>> Interrupt <<< 064 ; 001234
NOP
NOP
NOP
NOP
MTPS #340
...Press Key...
BIS #100,@#TTPS
Set T x3
RTT | NOP | WAIT | NOP | NOP | NOP
>>> Interrupt <<< 100 ; 001432
>>> Trap to 014 <<< ; 001432
>>> Trap to 014 <<< ; 001432
>>> Trap to 014 <<< ; 001432
>>> Interrupt <<< 060 ; 001432
>>> Interrupt <<< 064 ; 001432
NOP
NOP
NOP
NOP
MTPS #340
BIS #100,@#TTPS
...Press Key...
Set T x3
RTT | NOP | NOP | NOP | NOP | NOP
>>> Interrupt <<< 100 ; 001630
>>> Trap to 014 <<< ; 001630
>>> Trap to 014 <<< ; 001630
>>> Trap to 014 <<< ; 001630
>>> Interrupt <<< 060 ; 001630
>>> Interrupt <<< 064 ; 001630
NOP
NOP
NOP
NOP
NOP
Program completed.
.
---------- Post added at 17:01 ---------- Previous post was at 16:59 ----------
Кстати в доке по KDJ11B про T-бит написано просто NM (non maskable) и перечислен в списке с остальными прерываниями. Для EMT/BPT итд статус просто не пишется.
Странно, как это после RTT в обработчике Т-трапа не выполняются никакие команды (и все прерывания возникают "на одном месте")..
Странно, как это после RTT в обработчике Т-трапа не выполняются никакие команды (и все прерывания возникают "на одном месте")..
Ничего странного - про это чуть ли не ты же и упоминал вчера, что если есть что готовое для прерывания, оно сразу и сработает. Вот если бы IRQ* не были выставлены на момент RTT, тогда бы провалился на команду.
Ну вот и тест на реальном УКНЦ.
Ничего странного - если есть что готовое для прерывания, оно сразу и сработает. Вот если бы IRQ* не были выставлены на момент RTT, тогда бы провалился на команду.А вот и нет!
Как же тогда в этом куске:
MTPS #340
...Press Key...
BIS #100,@#TTPS
Set T x3
RTT | NOP | WAIT | NOP | NOP | NOP
>>> Interrupt <<< 100 ; 001432
>>> Trap to 014 <<< ; 001432
>>> Trap to 014 <<< ; 001432
>>> Trap to 014 <<< ; 001432
>>> Interrupt <<< 060 ; 001432
>>> Interrupt <<< 064 ; 001432
NOP
NOP
NOP
NOP
три Т-трапа происходят НА ОДНОМ МЕСТЕ и ни одна из команд программы не выполняется, хотя обработчики Т-трапа заканчиваются командой RTT.
...
тест на реальном УКНЦ.Вот это мне гораздо больше нравится!
Очевидно, что у formа "нереальный УКНЦ" :)))
Кстати, весьма похоже, что на 1801ВМ2 бит Т просто вводит дополнительную блокировку прерываний, которую нейтрализует команда WAIT, ожидающая и обслуживающая одно прерывание.
три Т-трапа происходят НА ОДНОМ МЕСТЕ[/b] и ни одна из команд программы не выполняется, хотя обработчики Т-трапа заканчиваются командой RTT
Ну положим я все еще не уверен в правильности теста :)
Свой же тест я приводил и результат в нем был однозначный - RTT дает шанс прерыванию и никаких гвоздей.
К примеру я не сильтно уверен в результатах прерывания по 64 так как мы одновременно трогаем устройство которое его должно дать.
Кстати, весьма похоже, что на 1801ВМ2 бит Т просто вводит дополнительную блокировку прерываний, которую нейтрализует команда WAIT, ожидающая и обслуживающая одно прерывание.
Бит T блокирует прерывания просто в силу своего приоритета. Блок прерываний в 1801ВМ2 при своей работе просматривает все незамаскированные прерывания на данный момент и выбирает самое приоритетное. У T-бита приоритет равен 3, у таймера (EVNT) - 6, VIRQ - 7.
А команда WAIT блокирует прерывание по T-разряду, поэтому и выполняется прерывание по таймеру.
И еще в тесте хорошо видна особенность 1801ВМ2 (а может и не только его), когда происходит возврат по RTT без установки бита T, то блок прерываний не запрещается на один шаг. Это видно на последних шагах, когда сохраненный в стеке счетчик команд оказывается одним и тем же.
Ну положим я все еще не уверен в правильности тестаИменно поэтому так важен результат теста на реальной УКНЦ. Ведь там запускался тот же самый код, а результаты гораздо более логичные - после каждой команды RTT гарантированно выполняется одна команда программы.
Возможно, как-то влияют прерывания от таймера. Дело в том, что во время работы программы они случаются примерно по одному на каждую строчку вывода на экран.
Если наша попытка перехвата V100 была как-то пресечена операционкой и перед нашим обработчиком V100 или после него выполняется код операционки - тогда это может как-то влиять.
Есть возможность запустить этот тест с гарантированно выключенным таймером?
Именно поэтому так важен результат теста на реальной УКНЦ. Ведь там запускался тот же самый код, а результаты гораздо более логичные - после каждой команды RTT гарантированно выполняется одна команда программы.
Возможно, как-то влияют прерывания от таймера. Дело в том, что во время работы программы они случаются примерно по одному на каждую строчку вывода на экран.
Если наша попытка перехвата V100 была как-то пресечена операционкой и перед нашим обработчиком V100 или после него выполняется код операционки - тогда это может как-то влиять.
Есть возможность запустить этот тест с гарантированно выключенным таймером?
Не забываем только, что на УКНЦ есть только один IRQ, а у меня их 4 :)
---------- Post added at 17:36 ---------- Previous post was at 17:36 ----------
Сейчас отключим.
---------- Post added at 17:38 ---------- Previous post was at 17:36 ----------
.GET PDPT1C
.E 40
001000
.D 10000=5037,177546,137,1000
.ST 10000
PDP-11 Interrupts Test #1c
MTPS #340
...Press Key...
BIS #100,@#TTPS
Set T x3
RTI | NOP | WAIT | NOP | NOP | NOP
>>> Trap to 014 <<< ; 001234
>>> Interrupt <<< 060 ; 001234
>>> Trap to 014 <<< ; 001234
>>> Interrupt <<< 064 ; 001234
>>> Trap to 014 <<< ; 001234
NOP
(зависон - WAIT видимо, клавишу тык)
MTPS #340
...Press Key...
BIS #100,@#TTPS
Set T x3
RTT | NOP | WAIT | NOP | NOP | NOP
>>> Interrupt <<< 060 ; 001432
>>> Trap to 014 <<< ; 001432
>>> Interrupt <<< 064 ; 001432
>>> Trap to 014 <<< ; 001432
NOP
>>> Trap to 014 <<< ; 001434
(зависон - WAIT видимо, клавишу тык)
NOP
>>> Trap to 014 <<< ; 001434
NOP
NOP
NOP
MTPS #340
BIS #100,@#TTPS
...Press Key...
Set T x3
RTT | NOP | NOP | NOP | NOP | NOP
>>> Interrupt <<< 060 ; 001630
>>> Trap to 014 <<< ; 001630
>>> Interrupt <<< 064 ; 001630
>>> Trap to 014 <<< ; 001630
NOP
>>> Trap to 014 <<< ; 001632
NOP
NOP
NOP
NOP
Program completed.
.
Бит T блокирует прерывания просто в силу своего приоритета. Блок прерываний в 1801ВМ2 при своей работе просматривает все незамаскированные прерывания на данный момент и выбирает самое приоритетное. У T-бита приоритет равен 3, у таймера (EVNT) - 6, VIRQ - 7.
А команда WAIT блокирует прерывание по T-разряду, поэтому и выполняется прерывание по таймеру.
И еще в тесте хорошо видна особенность 1801ВМ2 (а может и не только его), когда происходит возврат по RTT без установки бита T, то блок прерываний не запрещается на один шаг. Это видно на последних шагах, когда сохраненный в стеке счетчик команд оказывается одним и тем же.Согласен. Просто, при абстрактной эмуляции данных особеностей - моя интерпретация (что бит Т вводит дополнительную блокировку прерываний) позволяет "одним махом" учесть их все, без каких-либо нежелательных "побочных эффектов" и усложнения процесса эмуляции.
---------- Post added at 13:43 ---------- Previous post was at 13:39 ----------
Сейчас отключим.Круто!
Весьма похоже, что микропрограмма команды RTT считает, что ожидающий запрос IRQ ничем не хуже, чем например, ожидающая команда IOT (или тот же NOP) - поэтому вместо очередной команды обслуживается очередное прерывание.
Есть возможность запустить этот тест с гарантированно выключенным таймером?
Сейчас выключим. И вот результат.
Кстати в эмуляторе UKNCBTL результаты тестов аналогичные.
Весьма похоже, что микропрограмма команды RTT считает, что ожидающий запрос IRQ ничем не хуже, чем например, ожидающая команда IOT (или тот же NOP) - поэтому вместо очередной команды обслуживается очередное прерывание.
Ну так это вчера еще выяснили: если есть готовое прерывание - оно происходит и PC не движется. Поскольку одна (и даже не одна) инструкция у нас выполнилась после RTT (внетри обработчика прерываний), то и нет причин еще откладывать.
Ну так это вчера еще выяснили: если есть готовое прерывание - оно происходит и PC не движется. Поскольку одна (и даже не одна) инструкция у нас выполнилась после RTT (внетри обработчика прерываний), то и нет причин еще откладывать.А вкупе с тем, что приоритет у T-трапа выше, чем у любого IRQ - получается, что при установленном бите Т - после любого RTI всегда будет Т-трап, а после любого RTT - или прерывание (и выборка "следующей команды" уже в обработчике прерывания), или просто выборка следующей команды.
А вкупе с тем, что приоритет у T-трапа выше, чем у любого IRQ - получается, что при установленном бите Т - после любого RTI всегда будет Т-трап, а после любого RTT - или прерывание (и выборка "следующей команды" уже в обработчике прерывания), или просто выборка следующей команды.
Можно упростить до "при RTT выборка следующей команды" так как после возникновения прерывания эта выборка как раз и происходит :)
form, насколько я понял после RTT в KDJ-11 запрещается на один шаг прерывание по T-биту, остальные (в отличие от 1801ВМ2) разрешены. Поэтому и неудивительно, что первый тест начинает топтаться на одном месте. Но потом идут друг за другом два T-трапа с топтанием на одном месте. Такое ощущение, что возникает какое-то неучтенное в тесте прерывание с приоритетом больше, чем у регистров терминала.
Можно упростить до "при RTT выборка следующей команды" так как после возникновения прерывания эта выборка как раз и происходитНо не следует забывать, что у процессоров ВМ1 и ВМ2 прерывание после RTT может произойти только при очищенном бите T или при выполнении команды WAIT.
form, насколько я понял после RTT в KDJ-11 запрещается на один шаг прерывание по T-биту, остальные (в отличие от 1801ВМ2) разрешены. Поэтому и неудивительно, что первый тест начинает топтаться на одном месте. Но потом идут друг за другом два T-трапа с топтанием на одном месте. Такое ощущение, что возникает какое-то неучтенное в тесте прерывание с приоритетом больше, чем у регистров терминала.
Просто такие тесты надо чистыми делать после RESET, а не под системой.
Ну и разумеется исключать из теста прерывания от устройства которое мы параллельно еще и дергаем (64).
У меня здесь вообще простор богатый: PIRQ, TT1-TT4, LPV11 :)
На УКНЦ можно С2 задействовать.
form, насколько я понял после RTT в KDJ-11 запрещается на один шаг прерывание по T-биту, остальные (в отличие от 1801ВМ2) разрешены. Поэтому и неудивительно, что первый тест начинает топтаться на одном месте. Но потом идут друг за другом два T-трапа с топтанием на одном месте. Такое ощущение, что возникает какое-то неучтенное в тесте прерывание с приоритетом больше, чем у регистров терминала.Там постоянно идут прерывания от таймера, просто сообщение ">>> Interrupt <<< 100" выводится только при первом из них (время вывода этого сообщения больше, чем 1/50 секунды).
Там постоянно идут прерывания от таймера, просто сообщение ">>> Interrupt <<< 100" выводится только при первом из них (время вывода этого сообщения больше, чем 1/50 секунды).
Ну без таймера я выкладывал тест :)
Там постоянно идут прерывания от таймера, просто сообщение ">>> Interrupt <<< 100" выводится только при первом из них (время вывода этого сообщения больше, чем 1/50 секунды).
Весьма возможно, на УКНЦ порты терминала быстрые, поэтому это и не чувствуется. Может сделать тест, который будет накапливать результаты в буфере, а потом этот буфер выводить. Естественно в буфере должны быть не строки для вывода, а какие-то двоичные данные, которые потом п/п вывода будет соответствующим образом интерпретировать.
Еще мысль кстати - вообще ничего не выводить с interrupt level, а только сохранять контекст, а выводить по окончании всех тестов.
Выдержка из описания. Про прерывания как и ожидалось ничего не говорится. Что касается прерываний - это надо описание прерываний смотреть :)
Про WAIT касаемо T бита тоже ничего не говорится, но это и логично так как ожидание на нем - это и есть выполнение этой самой инструкции, которое согласно описанию команды RTT должно быть.
Еще мысль кстати - вообще ничего не выводить с interrupt level, а только сохранять контекст, а выводить по окончании всех тестов.Достаточно просто выводить сообщения по ходу теста не на экран, а в буфер. Ведь огромные задержки возникают только при выводе на экран.
А пока - второй тест прерываний (http://zx.pk.ru/attachment.php?attachmentid=33152&stc=1&d=1329565402), проверяющий, может ли MFPS прочитать бит Т и как быстро происходит прерывание после BIS #100,@#TTPS.
.RU PDPT2
PDP-11 Interrupts Test #2
MTPS #177
MFPS R5
R5/000157
Set T
RTT
MFPS R5
>>> Trap to 014 <<< ; 001224
R5/000177
BIS #100,@#TTPS
NOP
>>> Interrupt <<< 064 ; 001310
Program completed.
.
[CODE]На ВМ1 и ВМ2 - точно так же.
Про WAIT касаемо T бита тоже ничего не говорится ...
Говорится в таблице различий. Пункт 13.
Говорится в таблице различий. Пункт 13.
На то она и таблица различий, а для конкретного проца достаточно просто писать как оно есть в нем :)
PDPT2 на реальной УКНЦ. Результаты не отличаются.
На эмуляторе UKNCBTL есть различия, т.к. еще не учитывается задержка на одну команду при выдаче VIRQ после установки бита разрешения прерывания.
Если команда RTI/RTT очищает бит Т - после неё всё равно будет Т-трап. А как поведут себя при этом "ожидающие на шине" запросы IRQ..
Ответ должен дать следующий тест прерываний: PDP-11 Interrupts Test #3 (http://zx.pk.ru/attachment.php?attachmentid=33157)
Кстати, здесь во время теста - сообщения идут уже не на экран, а в буфер, поэтому прерываний от таймера (скорее всего) можно не опасаться.
Если команда RTI/RTT очищает бит Т - после неё всё равно будет Т-трап.
Если команда RTI/RTT очищает бит T - никакого Т-трапа не будет.
А тест сейчас запустим...
Если команда RTI/RTT очищает бит T - никакого Т-трапа не будет.
А тест сейчас запустим...А у нас (на ВМ1 и ВМ2) БУДЕТ :)
.RU PDPT3
PDP-11 Interrupts Test #3
BIS #100,@#TTPS x6
>>> Interrupt <<< 064 ; 001114
>>> Interrupt <<< 064 ; 001130
>>> Interrupt <<< 064 ; 001144
MTPS #340
...Press Key...
BIS #100,@#TTPS
Set T x3
RTI | RTI | NOP | NOP
>>> Trap to 014 <<< ; 001346
>>> Interrupt <<< 100 ; 001346
>>> Trap to 014 <<< ; 001346
>>> Interrupt <<< 060 ; 001346
>>> Trap to 014 <<< ; 001346
>>> Interrupt <<< 064 ; 001346
NOP
NOP
MTPS #340
...Press Key...
BIS #100,@#TTPS
Set T x3
RTT | RTT | NOP | NOP
>>> Interrupt <<< 100 ; 001562
>>> Trap to 014 <<< ; 001562
>>> Interrupt <<< 060 ; 001562
>>> Trap to 014 <<< ; 001562
>>> Interrupt <<< 064 ; 001562
>>> Trap to 014 <<< ; 001562
NOP
NOP
Program completed.
.D 10000=5037,177546,137,1000
.ST 10000
PDP-11 Interrupts Test #3
BIS #100,@#TTPS x6
>>> Interrupt <<< 064 ; 001114
>>> Interrupt <<< 064 ; 001130
>>> Interrupt <<< 064 ; 001144
MTPS #340
...Press Key...
BIS #100,@#TTPS
Set T x3
RTI | RTI | NOP | NOP
>>> Trap to 014 <<< ; 001346
>>> Interrupt <<< 060 ; 001346
>>> Trap to 014 <<< ; 001346
>>> Interrupt <<< 064 ; 001346
>>> Trap to 014 <<< ; 001346
NOP
NOP
MTPS #340
...Press Key...
BIS #100,@#TTPS
Set T x3
RTT | RTT | NOP | NOP
>>> Interrupt <<< 060 ; 001562
>>> Trap to 014 <<< ; 001562
>>> Interrupt <<< 064 ; 001562
>>> Trap to 014 <<< ; 001562
NOP
NOP
Program completed.
.
---------- Post added at 19:46 ---------- Previous post was at 19:46 ----------
А у нас (на ВМ1 и ВМ2) БУДЕТ :)
И как же там непатченные отладчики работают?
[CODE]И как же там непатченные отладчики работают?Немного терпения - скоро всё станет ясно :)))
Упс.. Не учёл я, что на 11/80 IRQ "идёт за команду" - щас увеличу счётчик "заказанных" Т-трапов и отменю ожидание прерываний от таймера и клавиатуры..
Немного терпения - скоро всё станет ясно :)))
Упс.. Не учёл я, что на 11/80 IRQ "идёт за команду" - щас увеличу счётчик "заказанных" Т-трапов и отменю ожидание прерываний от таймера и клавиатуры..
Так и так все ясно: T бит для того и предназначен чтобы генерить прерывание когда он установлен и не генерить когда сброшен :)
---------- Post added at 19:58 ---------- Previous post was at 19:52 ----------
Или ты имеешь в виду когда RTI/RTT - команда которой дали шанс выполниться перед T-бит трапом?
Результаты на реальной УКНЦ PDPT3.
Немного об особенностях :)
.RU TEST
000024
.RU TEST
000025
.RU TEST
000026
.RU TEST
000027
.DIR/OUT:NL: SY:
.COP/SY/NOLOG SY: NL:
(можно пол дня поработать)
.RU TEST
000030
.RU TEST
000031
.TY TEST.MAC
.MCALL .PRINT,.EXIT
START: MOV #10$,@#14
MOV #4000,@#16
BPT
MOV #123456,R5
.PRINT #TEXT
.EXIT
10$: MOV R5,R1
INC R5
MOV #TEXT,R0
MOV PC,R2
CALL $CBOMG
RTI
TEXT: .ASCIZ /XXXXXX/
.END START
.
Результаты на реальной УКНЦЛюбопытно, что хотя после "крайнего" RTT бит Т уже сброшен - запросы IRQ всё равно не могут "пролезть" вперёд Т-трапа.
Ситуция с точки зрения бита Т и команды RTT - та же, что и когда все IRQ выполнялись сразу после команды RTT, сбросившей бит Т и до любой другой команды, следующей за командой RTT, а поведение процессора другое.
...
Вот модификация теста специально для 11/80: PDP-11 Interrupts Test #3a (http://zx.pk.ru/attachment.php?attachmentid=33160)
.RU PDPT3A
PDP-11 Interrupts Test #3a
MTPS #340
BIS #100,@#TTPS
Set T x5
RTI | RTI | NOP | NOP
>>> Trap to 014 <<< ; 001214
>>> Interrupt <<< 100 ; 001214
>>> Trap to 014 <<< ; 001214
>>> Interrupt <<< 064 ; 001214
>>> Trap to 014 <<< ; 001214
>>> Trap to 014 <<< ; 001214
NOP
NOP
MTPS #340
BIS #100,@#TTPS
Set T x5
RTT | RTT | NOP | NOP
>>> Interrupt <<< 100 ; 001372
>>> Trap to 014 <<< ; 001372
>>> Interrupt <<< 064 ; 001372
>>> Trap to 014 <<< ; 001372
NOP
NOP
Program completed.
.D 10000=5037,177546,137,1000
.ST 10000
PDP-11 Interrupts Test #3a
MTPS #340
BIS #100,@#TTPS
Set T x5
RTI | RTI | NOP | NOP
>>> Trap to 014 <<< ; 001214
>>> Interrupt <<< 064 ; 001214
>>> Trap to 014 <<< ; 001214
NOP
NOP
MTPS #340
BIS #100,@#TTPS
Set T x5
RTT | RTT | NOP | NOP
>>> Interrupt <<< 064 ; 001372
>>> Trap to 014 <<< ; 001372
NOP
NOP
Program completed.
.
[CODE]
MTPS #340
BIS #100,@#TTPS
Set T x5
RTT | RTT | NOP | NOP
>>> Interrupt <<< 064 ; 001372
>>> Trap to 014 <<< ; 001372
NOP
NOP
Вот здесь видно, что когда вторая команда RTT очищает бит Т - Т-трап после неё всё равно происходит ( но в отличие от процессоров ВМ - вперёд него успевает пролезть обычное прерывание ).
Или нет..
Щас глянем в листинг..
102 000350 012746 000000 Mov #0, -(SP)
103 000354 012746 000374' Mov #LLL2a,-(SP)
104
105 000360 012746 000020 Mov #20, -(SP)
106 000364 012746 000372' Mov #LLL2, -(SP)
107 000370 000006 RTT
108 000372 LLL2:
109 000372 000006 RTT
110 000374 LLL2a:
111 000374 Nop
112 000376 Nop
Нифига!
У 11/80 Т-трап после второго RTT не возникает.
Если ты имеешь в виду, что RTT (которая устанавливает T-бит) передает управление на RTI/RTT которая его очищает, то да. Аналогично - если это RTI/RTT прерывания которое произошло перед T-бит трапом. Если же речь про сам хандлер Т-бита то нет - если он очистит, то это насовсем.
Если ты имеешь в виду, что RTT (которая устанавливает T-бит) передает управление на RTI/RTT которая его очищает, то да. Аналогично - если это RTI/RTT прерывания которое произошло перед T-бит трапом. Если же речь про сам хандлер Т-бита то нет - если он очистит, то это насовсем.
102 000350 012746 000000 Mov #0, -(SP)
103 000354 012746 000374' Mov #LLL2a,-(SP)
104
105 000360 012746 000020 Mov #20, -(SP)
106 000364 012746 000372' Mov #LLL2, -(SP)
107 000370 000006 RTT
108 000372 LLL2:
109 000372 000006 RTT
110 000374 LLL2a:
111 000374 Nop
112 000376 Nop
У 11/80 Т-трап после второго RTT не возникает.
Здесь ВМ1 и ВМ2 ведут себя принципиально иначе.
Все-таки предлагаю тестировать вчистую без системы. А также не надеяться, что вывод в буфер быстрый. DEC советует не больше 10 чтоли инструкций выполнять на интеррупт лежеле, а дальше - форк :)
Все-таки предлагаю тестировать вчистую без системы.Из системных вызовов я выполняю только EMT 350.
Обработчики всех прерываний в начале программы переключаются на внутренние.
...
Тест PDP-11 Interrupts Test #4 (http://zx.pk.ru/attachment.php?attachmentid=33166) ищет ответ на вопрос, что случится, если выполнить подряд следующие команды:
BiS #100, @#TTPS
BiC #100, @#TTPS
На ДВК-1 результат такой:
.RU PDPT4
PDP-11 Interrupts Test #4
BIS #100,@#TTPS
BIC #100,@#TTPS
001130
@M000011
@P
Program completed.
Для продолжения работы программы после вылета в пульт - на ДВК нужно нажать <P>.
Команда пульта <M> докладывает, что произошло прерывание зависания при приёме вектора прерывания.
Из системных вызовов я выполняю только EMT 350.
Системные вызовы непричем.
Обработчики всех прерываний в начале программы переключаются на внутренние.
Что никак не мешает прерываниям незапланированным возникать :)
В любом случае чем меньше неизвестных тем лучше.
Тест PDP-11 Interrupts Test #4 (http://zx.pk.ru/attachment.php?attachmentid=33166) ищет ответ на вопрос, что случится, если выполнить подряд следующие команды:
BiS #100, @#TTPS
BiC #100, @#TTPS
Собственно этого и следовало ожидать. Реальная УКНЦ.
.RU PDPT4
PDP-11 Interrupts Test #4
BIS #100,@#TTPS
BIC #100,@#TTPS
Program completed.
.D 10000=5037,177546,137,1000
.ST 10000
PDP-11 Interrupts Test #4
BIS #100,@#TTPS
BIC #100,@#TTPS
Program completed.
.
Собственно этого и следовало ожидать. Реальная УКНЦ.Это только первый этап - дальше интереснее.
Например, мало кто знает, что если при обработке прерывания происходит TrapTo4 из-за плохого стека, то до запроса вектора прерывания дело не доходит, а значит и реакция процессора будет другой.
Если же стек при этом указывает на что-то типа 0160004, то программа даже в пульт не вылетит.
Нас же в первую очередь интересует, как такая последовательность команд дружит с битом Т и командой RTT :)
Это проверяет следующая модификация теста: PDP-11 Interrupts Test #4a (http://zx.pk.ru/attachment.php?attachmentid=33170).
[CODE]Похоже, что процессор 11/80 не испытывает проблем при снятии IRQ до приёма вектора.
Похоже, что процессор 11/80 не испытывает проблем при снятии IRQ до приёма вектора.
Или оно еще не успевает выставиться.
Есть еще такое понятие - passive release.
---------- Post added at 21:55 ---------- Previous post was at 21:55 ----------
Сейчас в описании посмотрим есть ли что-нибудь на эту тему.
Или оно еще не успевает выставиться.Хитрость тут (насколько понимаю) в том, что когда у устройства обнуляют бит РП - оно сразу теряет способность ответить на запрос передачи вектора, тогда как на то, чтобы снять IRQ, и чтобы этот обратный фронт успел дойти по шине до процессора - требуется время, поэтому при последовательном выполнении команд установки и сброса бита РП - процессор успевает запросить у устройства вектор, но устройство к тому моменту уже "забывает о чём речь".
Хитрость тут (насколько понимаю) в том, что когда у устройства обнуляют бит РП - оно сразу теряет способность ответить на запрос передачи вектора, тогда как на то, чтобы снять IRQ, и чтобы этот обратный фронт успел дойти по шине до процессора - требуется время, поэтому при последовательном выполнении команд установки и сброса бита РП - процессор успевает запросить у устройства вектор, но устройство к тому моменту уже "забывает о чём речь".
Отход с IRQ без прерывания - стандартная фича.
Но не факт, что в данном случае оно вообще выставлялось.
Тут вариантов много может быть - без нормальной лаборатории на дому трудно :)
Вот еще пример где УКНЦа наверное свалится, а KDJ11 нет.
.E 0-2
040000 104350
.RU RED
?MON-F-Trap to 4 001004
.E 0-2
001004 000004
.TY RED.MAC
START: CLR SP
WAIT
.END START
.
---------- Post added at 22:33 ---------- Previous post was at 22:28 ----------
Кстати по этой причине мой любимый способ зачистки нижней памяти с чистым остановом не работает - останутся недочистки в 0-2 :)
А как это так? Каким образом стек так перемещается? Или это особенность KDJ-11?
А УКНЦ будет так.
А как это так? Каким образом стек так перемещается? Или это особенность KDJ-11?
А УКНЦ будет так.
На KDJ11 двойная защита стека. Первый уровень - yellow trap - если SP упал ниже 400 происходит прерывание по 4 (причина берется из cpuerr регистра). Второй уровень red stack abort - когда вызов прерывыния не позволяет в кернелный стек записать - тогда KSP принудительно ставится на 4 и делается трап по 4.
На KDJ11 двойная защита стека. Первый уровень - yellow trap - если SP упал ниже 400 происходит прерывание по 4 (причина берется из cpuerr регистра). Второй уровень red stack abort - когда вызов прерывыния не позволяет в кернелный стек записать - тогда KSP принудительно ставится на 4 и делается трап по 4.
Это только с включенным менеджером памяти, или даже с выключенным так работает (в незащищенном режиме)?
PDPT4A на УКНЦ.У ВМ1 точно так же.
Есть ещё один момент, про который не мешает знать - как поведёт себя пара BIS-BIC, если BIC идёт сразу после BIS, но не по ходу программы, а как первая команда обработчика прерывания, выполняющегося с разрешёнными прерываниями.
Ответ даёт следующий тест: PDP-11 Interrupts Test #4b (http://zx.pk.ru/attachment.php?attachmentid=33174).
Это только с включенным менеджером памяти, или даже с выключенным так работает (в незащищенном режиме)?
В любом варианте.
При включенном MMU только для kernel mode, при выключенном - оно и есть kernel mode.
---------- Post added at 22:44 ---------- Previous post was at 22:41 ----------
.RU PDPT4B
PDP-11 Interrupts Test #4b
060 Handler:
001364: BIC #100,@#TTPS
001372: NOP
...Press Key...
BIS #100,@#TTKS
BIS #100,@#TTPS
060 Handler:
>>> Interrupt <<< 064 ; 001364
NOP
NOP
Program completed.
.D 10000=5037,177546,137,1000
.ST 10000
PDP-11 Interrupts Test #4b
060 Handler:
001364: BIC #100,@#TTPS
001372: NOP
...Press Key...
BIS #100,@#TTKS
BIS #100,@#TTPS
060 Handler:
>>> Interrupt <<< 064 ; 001364
NOP
NOP
Program completed.
.
PDPT4B на УКНЦ.В этом вопросе у ВМ1, ВМ2 и 11/80 разногласий нет :)
Перечень причин входа в ступор...
А вот и случай с невыставлением вектора описан.
А вот и случай с невыставлением вектора описан.
Значит просто игнорирует. А я вот слышал, что некоторые процессоры PDP-11 при неполучении вектора трапались по нулевому вектору.
Значит просто игнорирует. А я вот слышал, что некоторые процессоры PDP-11 при неполучении вектора трапались по нулевому вектору.
Надо младшие модели посмотреть - те же 11/03 к примеру.
Мы забыли проверить, как процессоры ВМ1 и ВМ2 осуществляют байтовую запись в стек при нечётных значениях SP.
Чтобы закрыть этот пробел - здесь три новых теста. Все тесты используют команду MOVB #xx, (SP)+, но в одном случае SP дополнительно декрементируется, а в другом - инкрементируется.
Запись осуществляется в массив по адресу 03700, заполненный 0177777
Вот содержательные части тестов и результаты прогонов на моей модели ВМ1:
PDPT5.SAV (http://zx.pk.ru/attachment.php?attachmentid=33444)
Mov #FTst1, SP
MovB #60001, (SP)+
MovB #50002, (SP)+
Nop
Mov SP, R1
MovB #6003, (SP)+
MovB #7004, (SP)+
Mov SP, R2
Nop
Mov SP, R3
MovB #20005, (SP)+
MovB #10006, (SP)+
Mov SP, R4
.RU PDPT5
PDP-11 Interrupts Test #5
R1/003704
R2/003710
R3/003710
R4/003714
003700/177401
003702/177402
003704/177403
003706/177404
003710/177405
003712/177406
003714/177777
003716/177777
Program completed.
...
PDPT5A.SAV (http://zx.pk.ru/attachment.php?attachmentid=33442)
Mov #FTst1, SP
MovB #60001, (SP)+
MovB #50002, (SP)+
Dec SP
Mov SP, R1
MovB #6003, (SP)+
MovB #7004, (SP)+
Mov SP, R2
Dec SP
Mov SP, R3
MovB #20005, (SP)+
MovB #10006, (SP)+
Mov SP, R4
.RU PDPT5A
PDP-11 Interrupts Test #5a
R1/003703
R2/003707
R3/003706
R4/003712
003700/177401
003702/001402
003704/002377
003706/177405
003710/177406
003712/177777
003714/177777
003716/177777
Program completed.
...
PDPT5B.SAV (http://zx.pk.ru/attachment.php?attachmentid=33443)
Mov #FTst1, SP
MovB #60001, (SP)+
MovB #50002, (SP)+
Inc SP
Mov SP, R1
MovB #6003, (SP)+
MovB #7004, (SP)+
Mov SP, R2
Inc SP
Mov SP, R3
MovB #20005, (SP)+
MovB #10006, (SP)+
Mov SP, R4
.RU PDPT5B
PDP-11 Interrupts Test #5b
R1/003705
R2/003711
R3/003712
R4/003716
003700/177401
003702/177402
003704/001777
003706/002377
003710/177777
003712/177405
003714/177406
003716/177777
Program completed.
А как поведут себя в этих тестах реальные процессоры ?
А как поведут себя в этих тестах реальные процессоры ?
Сейчас проверим.
Выполняется надеюсь на SLP7? :)
А то
MovB #60001, (SP)+
MovB #50002, (SP)+
Может дать вообще левый результат :)
---------- Post added at 16:52 ---------- Previous post was at 16:50 ----------
.RU PDPT5
PDP-11 Interrupts Test #5
R1/003704
R2/003710
R3/003710
R4/003714
003700/177401
003702/177402
003704/177403
003706/177404
003710/177405
003712/177406
003714/177777
003716/177777
Program completed.
.RU PDPT5A
PDP-11 Interrupts Test #5a
R1/003703
R2/003707
R3/003706
R4/003712
003700/177401
003702/001402
003704/002377
003706/177405
003710/177406
003712/177777
003714/177777
003716/177777
Program completed.
.RU PDPT5B
PDP-11 Interrupts Test #5b
R1/003705
R2/003711
R3/003712
R4/003716
003700/177401
003702/177402
003704/001777
003706/002377
003710/177777
003712/177405
003714/177406
003716/177777
Program completed.
.
YES!
Даже удивительно, что моя модель ВМ1 ведёт себя в этом случае правильно..
У меня на ВМ2 в EmuStudio такие же результаты.
Ещё удивительнее то, что написав правильную модель - я сам был уверен, будто при MOVB #1,-(SP) не только записывается 1 в младший байт слова-приёмника, но и что старший байт очищается.
Думая так, я сплошь и рядом пытался избавиться от расширения знака в старший байт регистра-приёмника следующим образом:
MovB @#TKB, R0
MovB R0, -(SP)
Add (SP)+, CheckSumm
И только сейчас понял, почему те мои программы так дико глючили :)
http://savepic.net/2543868.jpghttp://savepic.net/2534652.jpghttp://savepic.net/2531580.jpg
[spoiler]Да, в этом аспекте наши процессоры "в точности как PDP-11/83" :)
Да, в этом аспекте наши процессоры "в точности как PDP11/80" :)
Особенно с учетом того, что такой модели нет :)
В UKNCBTL аналогичные результаты.
А тесты на Double Bus error будут?
А тесты на Double Bus error будут?Какого примерно содержания?
Какого примерно содержания?
1. Указатель стека указывает на несуществующую память.
2. Программа обработки TRAP4 начинается в несуществующей памяти, а указатель стека нормальный
При этом сама программа обработки TRAP4 начинается с разрешенными прерываниями, а обработка таймера также начинается в несуществующей памяти.
1. Указатель стека указывает на несуществующую память.
2. Программа обработки TRAP4 начинается в несуществующей памяти, а указатель стека нормальный
При этом сама программа обработки TRAP4 начинается с разрешенными прерываниями, а обработка таймера также начинается в несуществующей памяти.
Первое у меня вполне обрабатываемая ситуация.
Второе в разных вариантах будет sunset loop который остановить можно только через BHALT. На ВМ2 реакция вроде одинаковая на все это - прерывание в HALT mode.
Есть еще много вариантов пакостей. Для ВМ проца можно попробовать такое: в @#16 записать 20 :)
1. Указатель стека указывает на несуществующую память.
2. Программа обработки TRAP4 начинается в несуществующей памяти, а указатель стека нормальный
При этом сама программа обработки TRAP4 начинается с разрешенными прерываниями, а обработка таймера также начинается в несуществующей памяти.Правильнее, наверно говорить: "вектор 04 и вектор 0100 содержат несуществующие адреса"..
Вряд ли реально написать программу, которая такое тестирует и нормально завершает работу выходом в KMON (кроме первого пункта в случае, когда SP == 0160002 или SP == 0160004 - тогда ничего страшного не происходит - обычный "TrapTo_04"), поэтому тесты осуществляются в "ручном режиме".
Если SP > 0160004, то происходит двойная ошибка шины.
Если стек нормальный, а вектор 04 "указывает в пустоту", то при возникновении TrapTo_04 по любой причине ( не обязательно ждать таймера - можно просто выполнить TST @#160000 ) - у ВМ1 происходит зацикливание входа в прерывание до выхода указателя стека за пределы памяти, после чего следует двойная ошибка шины.
Вряд ли реально написать программу, которая такое тестирует и нормально завершает работу выходом в KMON
На ВМ2 все эти события - обычные прерывания в режиме HALT. Если есть доступ к памяти режима HALT и она записываемая - вполне решаемо.
Но об универсальности тут уже речь не идет...
---------- Post added at 00:26 ---------- Previous post was at 00:24 ----------
Вообще подобные тесты лучше делать не с выходом в KMON, а с проверкой можно ли его вообще делать (foreground loaded?) и если можно - снять загрузчик с SY:, переключиться на кернел с ресетом и там уже воротить что угодно, после чего - перезагрузка. Если еще есть из чего :)
---------- Post added at 00:29 ---------- Previous post was at 00:26 ----------
Ну а если все-таки пытаться вернуться в RT-11, то опять таки сначала надо переключиться на кернел, а там уже воротить что угодно.
Вряд ли реально написать программу, которая такое тестирует и нормально завершает работу выходом в KMON (кроме первого пункта в случае, когда SP == 0160002 или SP == 0160004 - тогда ничего страшного не происходит - обычный "TrapTo_04"), поэтому тесты осуществляются в "ручном режиме".
Естественно о выходе в KMON и не говорится. А по поводу SP==160002 и SP==160004 тоже интересный момент - уменьшается ли SP на 4, если прерывание TRAP4 произошло при заносе первого слова в стек (PSW прерванного процесса) или на 2. И если при 160002 уменьшается на 4, то что будет в 157776?
Т.к. будет вылет в пульт, то естественно результаты смотреть только с помощью команд пультового отладчика.
Хотя в принципе тесты не очень сложные, можно выполнить и в пультовом отладчике.
Если стек нормальный, а вектор 04 "указывает в пустоту", то при возникновении TrapTo_04 по любой причине ( не обязательно ждать таймера - можно просто выполнить TST @#160000 ) - у ВМ1 происходит зацикливание входа в прерывание до выхода указателя стека за пределы памяти, после чего следует двойная ошибка шины.
Вот и интересен этот момент у разных процессоров, у ВМ2 будет по другому.
Я был не совсем прав, если SP >= 0160002, то при TrapTo_04 произойдёт двойная ошибка шины. Ничего страшного не будет при входе в прерывание с плохим стеком при SP <= 0160004 только в том случае, если это прерывание НЕ по вектору 04.
Попробовал вписать в 4 несуществующий адрес. После останова вручную остановился по этому самому адресу (не +2), KSP дошел до нуля (был 1000).
0 содержит 160000
2 - 340
(последствия попытки восстановиться после сбоя KSP).
И если при 160002 уменьшается на 4, то что будет в 157776?Это я забыл проверить - сейчас напишу тест. Для простого прерывания - там ничего в пульт не вылетает.
Вот и интересен этот момент у разных процессоров, у ВМ2 будет по другому.Когда пользователю грозит обнуление памяти циклическим входом в прерывание - лучше чтобы он сам набрал в пульте эти команды :)
Всего-то и надо - записать 160000 по адресу 04, проверить значение SP, записать в R0 160000, занести в память код TST (R0) и выполнить эту команду.
Вот тест, проверяющий, что находится по адресу 157776 до и после входа в прерывание с SP == 160002.
Вот тест, проверяющий, что находится по адресу 157776 до и после входа в прерывание с SP == 160002.
Первый тест из серии для которого перегружаться не потребовалось :)
.RU PDPT6
PDP-11 Interrupts Test #6
SP/160002
157776/000000
001176: IOT SP/160002
157776/000000
Program completed.
.
Первый тест из серии для которого перегружаться не потребовалосьТ.е. SP == 160002 на 11/83 прерываниям не мешает..
А есть на 11/83 такое значение SP, при котором вход в прерывание будет с плохим стеком ?
Т.е. SP == 160002 на 11/83 прерываниям не мешает..
А есть на 11/83 такое значение SP, при котором вход в прерывание будет с плохим стеком ?
На 11/83 кернелный стек защищен. Если в стек ничего нельзя положить, KSP принудительно устанавливается в 4, после чего трап по 4 (и причина в CPUERR).
---------- Post added at 01:38 ---------- Previous post was at 01:28 ----------
Еще тест :)
.TY TEST.MAC
.MCALL .EXIT
START: MOV #340,@#16
MOV #10$,@#14
BPT
10$: MOV SP,R5
MOV @#4,R4
MOV #20$,@#4
MOV #177570,SP
MTPS #340
TST @#1
20$: MOV R5,SP
MOV R4,@#4
.EXIT
.END START
.RU TEST
Ю
.`
Символ "`" автовводится с клавиатуры :)
Вот тест, проверяющий, что находится по адресу 157776 до и после входа в прерывание с SP == 160002.
Тест на УКНЦ.
http://zx.pk.ru/attachment.php?attachmentid=33463&d=1330455408
Ну и славно!
У меня в эмуляторе результат такой:
.RU PDPT6
PDP-11 Interrupts Test #6
SP/160002
157776/153764
001176: IOT
>>> Trap to 004 <<< ; 001200
SP/157776
157776/153764
Program completed.
Никто не помнит точную ссылку где про ВМ3 и MMU написано?
Вот всё, что у меня есть по ВМ3: VM3.zip (http://emulator.pdp-11.org.ru/misc/VM3.zip)
...
В приложении - всё, что у меня есть по ВМ3.
Ну это как я понял описания всякие. Интересны различия какие там с MMU были. Никак найти не могу.
Ну это как я понял описания всякие. Интересны различия какие там с MMU были. Никак найти не могу.
Вот здесь (http://bk0010.org/forum/?id=4442&page=5) разговаривали про это.
Вот здесь (http://bk0010.org/forum/?id=4442&page=5) разговаривали про это.
Посмотрим.
Первое на что наткнулся на страничке - описание правил выставления IRQ устройством. Утверждается, что устройство должно выставлять все приоритеты начиная со своего и ниже на шине. На самом деле не так. Требуется выставлять приоритет 4 (для совместимости) и свой приоритет. Исключение - BIRQ7 для которого также требуется выставить BIRQ6. Таким образом:
4 - BIRQ4
5 - BIRQ4, BIRQ5
6 - BIRQ4, BIRQ6
7 - BIRQ4, BIRQ6, BIRQ7
но вобщем-то вреда не будет если и остальное выставить ниже себя.
А собственно по вопросу о MMU:
Все регистры ВМ3, кроме MMSR3, полностью соответствуют регистрам процессора PDP11/34, MMSR3, отсутствующий в 34, однако имеет ошибку при чтении зарезервированных бит, они должны читаться как "0", а читаются "1", из-за этого на ВМ3 без пропатчивания не работают Ultrix, Unix v5-v7 и RSX11, они неверно определяют тип процессора и пытаются использовать моду супервизора, за включение которой отвечает установка в "1" трех младших бит MMSR3.
Утверждение насчет RSX-11 сомнительное. RSX-11M и RSX-11S понятия не имеют ни о каких I/D пространствах и supervisor mode и никак не могут по ошибке пытаться их запользовать. RSX-11M-PLUS поддерживает и то и другое, но если все это было выбрано при генерации, то оно и работать будет только на процессоре который это все поддерживает и, соответственно, с тем же успехом не будет работать на настоящем PDP-11 который не поддерживает эти фичи. Так, что с RSX по-моему все упирается только в то, что придется написать драйверы для системы и сделать загрузчик для SAV/BOOT (для RSX-11S впрочем и это не бязательно). Вобщем надо попробовать :)
А так - суть вобщем понятна: MMSR3 сигналит, что D-Space для всех режимов (K, U, S) включен и CSM разрешен :)
Еще вчера почитал описание процессора, он за каким-то хреном поддерживает команды MFPD/MTPD, хотя работают они, разумеется, аналогично MFPI/MTPI.
Еще вчера почитал описание процессора, он за каким-то хреном поддерживает команды MFPD/MTPD, хотя работают они, разумеется, аналогично MFPI/MTPI.
Вот еще одно обсуждение (http://bk0010.org/forum/?id=2192&page=). Кстати полезно прошерстить этот форум по слову "ВМ3".
Еще про MFPD/MTPD/MFPI/MTPI слышал то, что команды с установленным старшим битоv в коде (MFPD/MTPD) работали как байтовые, и системы приходилось патчить с заменой на MFPI/MTPI.
Вот еще одно обсуждение (http://bk0010.org/forum/?id=2192&page=). Кстати полезно прошерстить этот форум по слову "ВМ3".
Еще про MFPD/MTPD/MFPI/MTPI слышал то, что команды с установленным старшим битоv в коде (MFPD/MTPD) работали как байтовые, и системы приходилось патчить с заменой на MFPI/MTPI.
По идее системы используют команды по назначению и там где используется MFPD/MTPD вряд-ли удастся чем-то помочь в принципе :)
Надо будет Andrey_Ak потрясти, посмотреть на его ДВК4 что там и как, попробовать RSX-11S запустить - он не требует драйверов для этого. Ну и тесты разные поделаем :)
По идее системы используют команды по назначению и там где используется MFPD вряд-ли удастся чем-то помочь в принципе :)
M*PD отличаются от M*PI только в процессорах, которые поддерживают разделение на пространство инструкций и данных. 1801ВМ3 этого не поддерживает, поэтому M*PI исполняются как M*PD.
Было еще одно отличие, вспомню - напишу.
M*PD отличаются от M*PI только в процессорах, которые поддерживают разделение на пространство инструкций и данных. 1801ВМ3 этого не поддерживает, поэтому M*PI исполняются как M*PD.
Было еще одно отличие, вспомню - напишу.
Процессоры которые не поддерживают разделение просто не поддерживают эти команды. Даже советская Э100-25 :)
И уж во всяком случае когда систему делают, никто не будет в ней писать MxPD ради доступа к пространству инструкций :)
Еще слышал, что при прерывании по ДП, регистр MMSR2 содержал не адрес прерванной инструкции, а адрес на 2 больший.
В MMSR0 не всегда устанавливался режим включения MMU (бит 0). После установки надо было считывать, включился или нет.
Но все это естественно надо проверять на практике.
---------- Post added at 10:50 ---------- Previous post was at 10:47 ----------
Процессоры которые не поддерживают разделение просто не поддерживают эти команды. Даже советская Э100-25 :)
И уж во всяком случае когда систему делают, никто не будет в ней писать MxPD ради доступа к пространству инструкций :)
Но вот в 1801ВМ3 сделано так. MFPI работает как MFPD, а MTPI как MTPD. Ну естественно надо проверить насчет байтового доступа.
Еще слышал, что при прерывании по ДП, регистр MMSR2 содержал не адрес прерванной инструкции, а адрес на 2 больший.
Родные процы есть такие тоже.
В MMSR0 не всегда устанавливался режим включения MMU (бит 0). После установки надо было считывать, включился или нет.
Но все это естественно надо проверять на практике.
Попробую Andrey_Ak растрясти. Давненько мы telnetом не связывались :)
---------- Post added at 13:52 ---------- Previous post was at 13:50 ----------
Но вот в 1801ВМ3 сделано так. MFPI работает как MFPD, а MTPI как MTPD. Ну естественно надо проверить насчет байтового доступа.
Проверим, но реально это не относится к несовместимостям даже буде оно так.
По описанию вчера смотрел - написано, что работают аналогично, но мог и просмотреть - поздно (или скорее рано) уже было :)
Попробую Andrey_Ak растрясти. Давненько мы telnetом не связывались :)
Тоже будет интересно узнать. Кстати RT11XM грузится на 1801ВМ3 нормально, испробуйте. А вот RSX-11 в советское время на ДВК так и не перенесли, хотя может какой в этом смысл, если только только мультитерминальный режим через КТЛК-6 сделать.
Тоже будет интересно узнать. Кстати RT11XM грузится на 1801ВМ3 нормально, испробуйте. А вот RSX-11 в советское время на ДВК так и не перенесли, хотя может какой в этом смысл, если только только мультитерминальный режим через КТЛК-6 сделать.
XM уже грузили - без проблем, но ему и не на что наступить особо: он не знает ни про режим супервизора ни про разделение I/D и восстановления после page fault там не бывает :)
RSX перенести сложнее. Там в отличие от RT-11 система - это слепок памяти с привязкой к носителю, причем до первого сохранения жестко и на этом этапе диск не загрузочный. Загрузочным его можно сделать только из уже загруженного этого самого RSXа, который нужно сделать загрузочным. При этом недостаточно написать драйвер для нового устройства, надо еще переделать как минимум две программы - тогда удастся хотя бы загрузить. А на ДВК как правило все носители нестандартные :)
Ну и смысла особого наверное нет в переносе.
Попробуем 11S для начала - ему драйвера вообще пофигу.
---------- Post added at 14:05 ---------- Previous post was at 14:02 ----------
Многотерминальность на проце с MMU кстати и в RT-11 весьма помогает :)
Я у себя весьма активно 4 терминала пользую и доволен. Точнее два из них терминалы, один - связь с AlphaServer и один - связь с PC через E11 или эмулятор TU58 на выбор.
---------- Post added at 14:42 ---------- Previous post was at 14:05 ----------
Кстати у меня почему-то в голове еще отложилось, что ВМ4 вроде не только сопроцессор, но еще что-то добавляет в тот же MMU. Надо будет почитать вечером.
Кстати у меня почему-то в голове еще отложилось, что ВМ4 вроде не только сопроцессор, но еще что-то добавляет в тот же MMU. Надо будет почитать вечером.
Полный бред, однако! Посмотрите по выводам ВМ4, нет там ничего, связанного с расширенным адресом. Некоторое время это даже висело в Википедии. Откуда такие слухи пошли, мне тоже было бы интересно знать.
А кстати RT11XM работает с 22-разрядным адресом? И если да, то проблем нет?
Полный бред, однако! Посмотрите по выводам ВМ4, нет там ничего, связанного с расширенным адресом. Некоторое время это даже висело в Википедии. Откуда такие слухи пошли, мне тоже было бы интересно знать.
А кстати RT11XM работает с 22-разрядным адресом? И если да, то проблем нет?
Если не ошибаюсь - из советской книги по микропроцессорам :)
Работает. Проблем нет - 22bit на ВМ3 самый обыкновенный.
ZB/ZM работать не будут - им нужен режим супервизора и разделение I/D.
Если не ошибаюсь - из советской книги по микропроцессорам :)
Хотелось бы узнать, что это за книга. А то такие слухи я уже читал в разных местах в инете, но никто конкретных аргументов не приводит, мол слышали и все.
Хотелось бы узнать, что это за книга. А то такие слухи я уже читал в разных местах в инете, но никто конкретных аргументов не приводит, мол слышали и все.
Посмотрю дома. Если такое и правда было, то она у меня есть так как никаких слухов про советские процы я в принципе не знаю ибо никогда они меня не интересовали. Остается один вариант - в армии когда нефиг делать было - читал :)
Хотелось бы узнать, что это за книга.
Сергей Вакуленко aka Vak Описание процессоров серии 1801-1806 (http://www.vak.ru/doku.php/proj/bk/1801vm-series#%D0%BA%D0%BC1801%D0%B2%D0%BC3)
Вот этой ссылкой аргументировали то что в ВМ4 находиться часть ДП
Сергей Вакуленко aka Vak Описание процессоров серии 1801-1806 (http://www.vak.ru/doku.php/proj/bk/1801vm-series#%D0%BA%D0%BC1801%D0%B2%D0%BC3)
Вот этой ссылкой аргументировали то что в ВМ4 находиться часть ДП
Там тоже только сама фраза что половина мму мол туда вынесена и больше ничего. А мне почему-то запомнилось, что читал конкретику.
Но по давности лет могу перепутать с другой парой процессор-сопроцессор.
---------- Post added at 17:38 ---------- Previous post was at 17:34 ----------
Книжки какие попали под руку ничего не сказали. Еще есть вариант МПСС - у нас он постоянно был под рукой.
Сергей Вакуленко aka Vak Описание процессоров серии 1801-1806 (http://www.vak.ru/doku.php/proj/bk/1801vm-series#%D0%BA%D0%BC1801%D0%B2%D0%BC3)
Вот этой ссылкой аргументировали то что в ВМ4 находиться часть ДП
Где бы еще достать, описываемый там файлик INTERF.HLP.
Я когда спрашивал anonymous`a на форуме http://bk0010.org мне ответили следующее:
1. В некоторых источниках указано что часть диспетчера памяти вынесли в ВМ4, но в доступной документации на 1836ВМ4 об этом ни слова, более того там указано что на ВМ4 из старших разрядов адреса заводиться только А21/NS. Понятно что верить стоит документации, но все же...
1. Регистры для процессора плавающей запятой, 6 64-битовых и дополнительные регистры состояния, в родном DECовском исполнении находятся в ДП, о них и говорилось.
ИМХО, кто-то перепутал, больше я на этом внимания не заострял :)
ИМХО, кто-то перепутал, больше я на этом внимания не заострял :)
Скорее всего так и есть. Просто помню, что попадалось такое в советское время когда интернета еще в демосе наверное не было даже :)
Где бы еще достать, описываемый там файлик INTERF.HLP.
Как альтернатива http://www.npofizika.ru/pdf/1806vm2.pdf
Если такое и правда было, то она у меня есть
Книжки какие попали под руку ничего не сказали.
А какие попались? Есть по теме pdp или отечественных систем интересное что-нибудь? Я вот свою синенькую брошурку "руководство к ДВК" и "Макро-11" посеял искал нигде не нашёл - супер были книжки !!! Жаль пропали - в Зеленоградских библиотеках "списаны" уже давно, есть ещё библиотека МГИЭТ, но мне туда в ближайшее время не попасть и уж тем более не взять там ничего на вынос )))
Есть по теме pdp или отечественных систем интересное что-нибудь?
Есть много чего, но касаемо процессоров они все отрывочные какие-то даже если это целая серия где один том посвящен одному набору :)
Вот к примеру часть коллекции на картинке.
Сергей Вакуленко aka Vak Описание процессоров серии 1801-1806 (http://www.vak.ru/doku.php/proj/bk/1801vm-series#%D0%BA%D0%BC1801%D0%B2%D0%BC3)
Вот этой ссылкой аргументировали то что в ВМ4 находиться часть ДП
Информация для этой статьи взята из этого файла (http://pdp-11.ru/mybk/doc/1801VM.TXT), который гулял по дискетам, а потом и в интернете.
Естественно, все что там изложено, не всегда вызывает доверие. Судить могу по описанию 1806ВМ2, который является функциональным аналогом 1801ВМ2. Так что и про 1801ВМ1 и 1801ВМ3 могли не то описать.
А по поводу книжек могу сказать то, что очень часто авторы, не являясь хорошими специалистами по процессорам, описывали все процессоры вместе взятые, информация тискалась с разных мест, часто для того, чтобы сделать короткое описание, вырезалось много важной информации.
Есть еще здоровая книга - том 3 эксплоатационной документации по Э100-25 ;)
---------- Post added at 17:55 ---------- Previous post was at 17:54 ----------
очень часто авторы, не являясь хорошими специалистами по процессорам, описывали все процессоры вместе взятые, информация тискалась с разных мест, часто для того, чтобы сделать короткое описание, вырезалось много важной информации.
Не просто часто, а других вариантов просто не видел. Даже одни и те же ошибки иной раз повторяют друг за другом :)
---------- Post added at 17:58 ---------- Previous post was at 17:55 ----------
Точнее есть у меня неплохая книга, но там процессоры на втором плане, а на первом средства диагностики аппаратуры. А все эти описания процессоров обычно на трех-четырех страницах укладываются все три ВМ1,2,3, про ВМ4 в лучшем случае упомянуто в одной строчке и примерно столько же страниц - система команд :)
А все эти описания процессоров обычно на трех-четырех страницах укладываются все три ВМ1,2,3, про ВМ4 в лучшем случае упомянуто в одной строчке и примерно столько же страниц - система команд :)
У Шахнова тоже описан 1801ВМ3, упомянуто, что мол поддерживает подключение сопроцессора плавающей запятой, но про 1801ВМ4, увы ни слова. Ну хоть нет и бреда по недостающую часть MMU.
У Шахнова тоже описан 1801ВМ3, упомянуто, что мол поддерживает подключение сопроцессора плавающей запятой, но про 1801ВМ4, увы ни слова. Ну хоть нет и бреда по недостающую часть MMU.
Вот сегодня 4 книги просмотрел - все на одно лицо, хотя авторы разные :)
Ну и про мму ничего не видел.
---------- Post added at 18:05 ---------- Previous post was at 18:04 ----------
Я кстати подумал - может речь шла не о ВМ4, а о теоретической возможности расширения мму снаружи процессора. Там вроде какой-то бит даже есть кхе-кхе, смахивающий на унибусное управление :)
Я кстати подумал - может речь шла не о ВМ4, а о теоретической возможности расширения мму снаружи процессора. Там вроде какой-то бит даже есть кхе-кхе, смахивающий на унибусное управление :)
Да, есть там вывод UMAP, включается установкой бита 5 в MMSR3. Хотелось бы в общем плане узнать, что это. Вроде 256-кбайтное окно при работе в 22-разрядном адресном режиме? Unibus вроде только поддерживает 18-разрядный адрес?
Да, есть там вывод UMAP, включается установкой бита 5 в MMSR3. Хотелось бы в общем плане узнать, что это. Вроде 256-кбайтное окно при работе в 22-разрядном адресном режиме? Unibus вроде только поддерживает 18-разрядный адрес?
Там какой-то кусок I/O page вроде выделяется под маппинговые регистры, но что с ними делают я не знаю - как-то из унибусных в основном сидел на Э100-25, а когда появился СМ-2420 уже не до того было, чтобы копаться.
Можно посмотреть драйвер UM из RT-11 V5.
---------- Post added at 18:47 ---------- Previous post was at 18:41 ----------
Из серии "идиотские программы" :)
.TY TEST.MAC
.MCALL .EXIT,.PRINT
.WORD MESG
START: MOV #10$,R0
JMP @#177564
10$: .PRINT
.EXIT
MESG: .ASCIZ /XA-XA-XA/
.END START
.RU TEST
XA-XA-XA
.
Вот что значит не выспался :)
"идиотские программы"
А как доработать что-бы "Гомерический смех" вылезал после окончания работы любой программы??? Ну типа как RS-shell со своим "ЖМИ НА КНОПКУ НЕ БОИСЬ", только просто смех и всё потом системное приглашение, потом отработка команды оператора
заупск всего чего нужно было и снова XA-XA-XA и приглашение монитора продолжать работу ??? Вот это бы очень помогло !!! )))
Из серии "идиотские программы" :)
Главное, чтобы не стоял бит разрешения прерывания ;)
Главное, чтобы не стоял бит разрешения прерывания ;)
Или не выполнялся бряк :)
Впрочем в этом случае вряд-ли удалось бы что-то вообще увидеть :)
Думаю вот - какую бы хрень замутить из того факта, что у меня можно clock поднять до 800 прерываний в секунду :)
Вот к примеру часть коллекции на картинке.
У меня книжечка №2 из этой серии есть :)
Первые попытки посмотреть что и как. Сильно пока не баловался.
Исходные данные:
только что включен ДВК4
RT-11SB V5.7, драйвера VM нет в системе
консоль переключена на терминальный порт 176560/360 откуда я и сижу телнетом
.RU VDT
VDT V05.07
*172516/177717
Итак, сразу видим то, о чем так долго говорили большевики: все биты в MMR3 которые не используются на ВМ3 установлены в 1. Таким образом, если не знать предыстории и тупо смотреть на биты, констатируем:
разрешен мапинг data space для усера
разрешен мапинг data space для супервизора
разрешен мапинг data space для кернела
разрешена команда CSM
выключен 22битный режим
выключен UM
*177572/000016
177574 /000000
177576 /003572
*172340/000000
172342 /000200
172344 /000400
172346 /000600
172350 /001000
172352 /001200
172354 /001400
172356 /007600
*177640/000000
177642 /000200
177644 /000400
177646 /000600
177650 /001000
177652 /001200
177654 /001400
177656 /007600
177660 /
?MON-F-Trap to 4 003572
Все PARы заполнены чтобы адресовать нижнюю память и I/O page при включении MMU из расчета 18битной адресации.
.ru vdt
VDT V05.07
*
*177776/000012
У ВМ3 есть адресуемый PSW! Это просто праздник! :)
*172300/077506
Кернелу можно читать, писать, страница расширяется вверх. О, чудо! Хоть здесь два reserved бита идут нулями ;)
В страницу писали, опять reserved 0...
Страница в полную длину.
Cache bypass не включен ;)
*177572/000016 1
ХРЯСЬ!
*177600/077406
177602 /077406
177604 /077406
Мы еще живы ;)
Усеру все можно!
*177776/000012 140000
.
Видать не все. А и хрен с ним - лень думать.
.RU VDT
VDT V05.07
*
*
*177776/030012
*172300/077506
172302 /077406
172304 /077406
172306 /077406
172310 /077506
172312 /077506
*172340/000000
172342 /000200
172344 /000400
От меня так просто не отстанешь! Сейчас как напечатаю буковку 'A' на своем терминале, добравшись к нему через задницу...
172346 /000600 7600
*76566/000360 101
A
*172346/007600 600
*177572/000001 0
То-то же!
*172516/177717 0
*/177717 70
*/177777 0
*/177717
*^C
.
---------- Post added at 23:01 ---------- Previous post was at 22:33 ----------
Определяется RT-11 как 11/34. Оттого и настроен видимо под 18бит -
это поди BSTRAP память мерял.
.SH CONF
RT-11SB (S) V05.07
Booted from MY0:RT11SB
USR is set SWAP
EXIT is set SWAP
KMON is set NOIND
MODE is set NOSJ
TT is set NOQUIET
ERROR is set ERROR
SL is set OFF
EDIT is set KED
FORTRAN is set FORTRA
KMON nesting depth is 3
CLI is set DCL, CCL, UCL, NO UCF
PDP 11/34 Processor
256KB of memory
Extended Instruction Set (EIS)
Memory Management Unit
Multi-terminal support
SB timer support
.
---------- Post added at 23:03 ---------- Previous post was at 23:01 ----------
Хотя 11/34 не смог бы адресовать 256Kb памяти :)
И, возвращаясь к громкому утверждению насчет работы "RSX-11" при таких условиях...
Тест #1, RSX-11M при таких условиях...
Позже подумаю как вручную RSX-11S загрузить на ДВК4 и проверить в 22bit mode - в эмуляторе этого сделать не получится если только не брать какой-нибудь simh и переписывать.
Хе-хе.
Все готово к эксперименту.
Ждем вечера...
RT-11SB (S) V05.07
.SET TT NOTAB,NOFORM
.R DATE
Date? 02-MAR-2012
.DIR
02-Mar-2012
SWAP .SYS 28P 07-Apr-2011 RT11SB.SYS 101P 01-Mar-2012
DW .SYS 7P 08-Mar-1990 MY .SYS 3P 19-Feb-1980
SL .SYS 17 01-Mar-2012 DIR .SAV 20P 31-Oct-1998
PIP .SAV 30P 31-Oct-1998 DUP .SAV 52P 31-Oct-1998
RESORC.SAV 35P 31-Oct-1998 MACRO .SAV 63P 24-Apr-2011
LINK .SAV 59P 31-Oct-1998 SYSMAC.SML 92P 31-Oct-1998
SYSLIB.OBJ 84P 31-Oct-1998 KED .SAV 85P 31-Oct-1998
K52 .SAV 81P 07-Apr-2011 VDT .SAV 8P 01-Mar-2012
DATE .SAV 4P 29-Feb-2012 IOSCAN.SAV 3P 18-Sep-2011
RSX11S.SYS 498 02-Mar-2012 MMUT1 .SAV 2 02-Mar-2012
STRTSB.COM 1 01-Mar-2012 SLOAD .SAV 2 02-Mar-2012
22 Files, 1275 Blocks
311 Free blocks
.RU SLOAD
LOADING 00740000
RSX11S V4.6 BL56
>
>ATL
MCR... 116750 MCRPAR 117064 203700-221677 PRI - 150. DPRI - 150.
STATUS - -CHK FXD -PMD PRV CLI
TI - CO0: IOC - 0. EFLG - 000001 000000 PS - 170017 PC - 120432
REGS 0-6 000000 050712 131574 157476 140700 000000 000766
>
Вопреки распостранившейся через статью в МПСС информации, реализована поддержка пультового режима у ВМ3 вся в младшем банке, однако у плат МС1201.03 и .04 старшие адреса игнорируются, таким образом адресация ячеек 077000..077777, к которым производится обращение в пультовом пзу, транслируется в адреса 017000..017777 - это сделано в расчете, что на плату могут устанавливаться процессоры и с пультовым стеком с адреса 0100000, и с адреса 020000, однако в серии 1801 стек с адреса 0100000 не был реализован.
Можно ещё это проверить? :)
Можно ещё это проверить? :)
Посмотрим вечером.
---------- Post added at 15:47 ---------- Previous post was at 15:45 ----------
Правда написано как обычно так, что не сильно понятно о чем речь :)
Можно ещё это проверить? :)
Увы, нельзя. У пультового режима отдельное адресное пространство, которое не пересекается с основным адресным пространством.
Конечно можно попытаться просканировать все адресное пространство в 22-разрядном адресном режиме, мало ли что. Но думаю ничего не будет.
Увы, нельзя. У пультового режима отдельное адресное пространство, которое не пересекается с основным адресным пространством.
Конечно можно попытаться просканировать все адресное пространство в 22-разрядном адресном режиме, мало ли что. Но думаю ничего не будет.
То есть это нечто абстрактное и ни на чем реально (например на открытии памяти из под @) не сказывается?
То есть это нечто абстрактное и ни на чем реально (например на открытие памяти из под @) не сказывается?
У ВМ3 есть вывод HLTM. При входе в пультовый режим на нем выставляется активный низкий уровень. А уже поэтому уровню 1801ВП1-119 подключает по заданным адресам статическое ОЗУ и ПЗУ. Кстати на -119 поступают только старшие разряды адреса, так что предположения от том что стат.ОЗУ в HALT-режиме висит по адресам 17000-17777 вполне обосновано. Но надо смотреть схему. С помощью старших разрядов адреса процессор и указывает -119, с чем он хочет работать в HALT-режиме - с ПЗУ, стат.ОЗУ, ОЗУ платы или страницей ввода-вывода.
Кстати RSX-11S который подготовил для теста специально собрал с 22bit.
---------- Post added at 16:06 ---------- Previous post was at 16:04 ----------
У ВМ3 есть вывод HLTM. При входе в пультовый режим на нем выставляется активный низкий уровень. А уже поэтому уровню 1801ВП1-119 подключает по заданным адресам статическое ОЗУ и ПЗУ. Кстати на -119 поступают только старшие разряды адреса, так что предположения от том что стат.ОЗУ в HALT-режиме висит по адресам 17000-17777 вполне обосновано. Но надо смотреть схему. С помощью старших разрядов адреса процессор и указывает -119, с чем он хочет работать в HALT-режиме - с ПЗУ, стат.ОЗУ, ОЗУ платы или страницей ввода-вывода.
Мне бы по русски, с точки зрения того может ли оно отразиться как-то на том, что можно "пощупать" :)
Кстати RSX-11S который подготовил для теста специально собрал с 22bit.
А плата - это МС 1201.04 с метром памяти? И она вся видится?
А плата - это МС 1201.04 с метром памяти? И она вся видится?
Там 256 kB памяти и это у меня не вызвало ничего кроме смеха. Ибо вся 22битность заключается в доступе к дополнительным 8kB памяти против 18bit :)
Я впрочем как раз этот кусочек памяти запользовал - я туда запихиваю загрузчик который потом сидя там читает из MY прямо в физическую память от 0 до 775776 образ системы, а он после загрузки сам уже расширит главный раздел до упора.
Мне бы по русски, с точки зрения того может ли оно отразиться как-то на том, что можно "пощупать" :)
Ну не знаю как сказать, просканируйте все адресное пространство, есть ли там чего кроме ОЗУ и страницы ввода-вывода. Но свою программу в HALT-режиме не исполнить, так что и не узнать, откуда у стека ноги растут - 20000 или со 100000.
Судя по схеме МС 1201.03 там два 537РУ8 стоят для пульта... значит нет способа посмотреть значение SP в пультовом режиме?
Там 256 kB памяти и это у меня не вызвало ничего кроме смеха. Ибо вся 22битность заключается в доступе к дополнительным 8kB памяти против 18bit :)
Значит это МС 1201.03. Там действительно 256К памяти. Но ведь есть еще МС 1201.04. Там же стоит уже цельный метр. Вот здесь 22битность и может пригодится.
Ну не знаю как сказать, просканируйте все адресное пространство, есть ли там чего кроме ОЗУ и страницы ввода-вывода. Но свою программу в HALT-режиме не исполнить, так что и не узнать, откуда у стека ноги растут - 20000 или со 100000.
А-а, ну в этом плане и так ясно что нету. Если память HALTа как-то и доступна, то через отдельные механизьмы, но вроде левых регистров когда сканилистраницу не наблюдали.
---------- Post added at 16:13 ---------- Previous post was at 16:11 ----------
Судя по схеме МС 1201.03 там два 537РУ8 стоят для пульта... значит нет способа посмотреть значение SP в пультовом режиме?
Значения SP (их два) я так думаю все-таки можно. Речь я так понимаю идет о какой-то хрени режима HALT, а оно нам мало интересно :)
Судя по схеме МС 1201.03 там два 537РУ8 стоят для пульта... значит нет способа посмотреть значение SP в пультовом режиме?
Для пультового режима там свой SP, как и для USER и KERNEL. Вопрос в том, что в пультовый режим не втиснешься. Все вектора пультового режима сидят в ПЗУ, да и попасть в это стат.ОЗУ даже из режима KERNEL нереально.
Значит это МС 1201.03. Там действительно 256К памяти. Но ведь есть еще МС 1201.04. Там же стоит уже цельный метр. Вот здесь 22битность и может пригодится.
Ну главное - есть на чем проверить именно 22битный режим с участием памяти за пределами 18 бит :)
---------- Post added at 16:15 ---------- Previous post was at 16:14 ----------
Для пультового режима там свой SP, как и для USER и KERNEL. Вопрос в том, что в пультовый режим не втиснешься. Все вектора пультового режима сидят в ПЗУ, да и попасть в это стат.ОЗУ даже из режима KERNEL нереально.
Ну нам он, пультовый, вроде как погоды не делает ибо стандартный софт про все это знать не знает :)
Но свою программу в HALT-режиме не исполнить
Понял...
А-а, ну в этом плане и так ясно что нету. Если память HALTа как-то и доступна, то через отдельные механизьмы, но вроде левых регистров когда сканилистраницу не наблюдали.
Из левых регистров должен быть PARH2, но вот только я не знаю, доступен он только в HALT, или в USER/KERNEL тоже.
Просканировать остается только адресное пространство, ведь дырка большая - почти 3.75 Мб.
Из левых регистров должен быть PARH2, но вот только я не знаю, доступен он только в HALT, или в USER/KERNEL тоже.
Просканировать остается только адресное пространство, ведь дырка большая - почти 3.75 Мб.
Для очистки совести можно просканироровать вообще все, но не думаю, что все так плохо :)
Пока по сути вообще никакого особого криминала не вижу.
Для очистки совести можно просканироровать вообще все, но не думаю, что все так плохо :)
Пока по сути вообще никакого особого криминала не вижу.
Весьма интересно, может что нибудь и обнаружиться. А кстати есть чего-нибудь по адресу 173000 и 177512?
Весьма интересно, может что нибудь и обнаружиться. А кстати есть чего-нибудь по адресу 173000 и 177512?
Вечером запустим ioscan, посмотрим.
Тест всего пространства памяти тоже сделаю.
Но если там что-то появится - это будет нарушением самой работы MMU (в том числе с точки зрения описания ВМ3).
Единственно, можно еще попробовать включить этот загадочный UM бит и посмотреть что будет :)
К слову, у меня на KDJ11-BF этот бит значится как неиспользуемый, но можно менять. Это при том, что модуль используется как в QBUS так и в UNIBUS конфигурации.
Единственно, можно еще попробовать включить этот загадочный UM бит и посмотреть что будет :)
К слову, у меня на KDJ11-BF этот бит значится как неиспользуемый, но можно менять. Это при том, что модуль используется как в QBUS так и в UNIBUS конфигурации.
А ведь UNIBUS, если я не ошибаюсь, имеет только 18-разрядную адресную шину. Видно как-то через этот бит подсоединяют UNIBUS на шину QBUS в определенное 256-кбайтное окно.
Раньше мы уже обсуждали "реверсивный глюк" SJ-монитора RT-11, при котором последовательно поступающие на терминальный вход байты попадают в буфер ввода в обратном порядке, если между прерываниями процессор успевает выполнить меньше некоторого "магического" числа команд ( ~ 120 ).
Даже процессор ВМ1, имеющий среднее быстродействие 180 команд/байт казалось бы "вписывается" в это ограничение. И действительно, при эмуляции с достоверной скоростью выполнения команд - ВМ1 не имеет проблем в большинстве программ.
Но нашлась программа, которая внесла свою ложку дёгтя - это DESS.
При нажатии на любую стрелку, DESS выводит на экран кучу информации:
«033»HBlock=000000/00000. Adres=000006 Type=Word Edit Memory
«033»Y cSize=00112.
«033»Y4*«033»KSWAB -(R0)
«033»Y5*
И вот что происходит. Когда нажаты две стрелки подряд - двойной код второго нажатия (например: '\033' 'B') приходит в тот момент, когда буфер вывода RMON заполнен и регулярно обрабатываются прерывания вывода на экран.
Поэтому, обычное быстродействие ВМ1 в 180 команд на байт уменьшается на длину обработчика вывода и ..результат плачевен.
С вероятностью ~ 5% - двойной код нажатой клавиши попадёт во входной буфер в обратном порядке.
...
Неспроста, наверное, строка автоответа идентификации терминалов VT передаётся ими не со скоростью порта, а со скоростью кадровой развёртки 60 Гц.
А что насчёт скорости передачи многобайтовых кодов клавиш у терминалов VT..
А как обстоит с этим дело у 15ИЭ-0013 ?
Мне нетрудно перевести терминал на передачу многобайтовых кодов клавиш со скорости порта на скорость 60 CPS, но насколько это будет адекватно реальному оборудованию..
Мне нетрудно перевести терминал на передачу многобайтовых кодов клавиш со скорости порта на скорость 60 CPS, но насколько это будет адекватно реальному оборудованию..
Могу померять реальный VT220. Стандартные клавиши там вроде до 4 символов шлют, а строка автоответа на ESC/Z и CSI/c - это целая поэма :)
---------- Post added at 17:29 ---------- Previous post was at 17:27 ----------
Можно еще посмотреть в системе механизм отличия ESC последовательностей от ESC с теми же символами.
Могу померять реальный VT220. Стандартные клавиши там вроде до 4 символов шлют, а строка автоответа на ESC/Z и CSI/c - это целая поэмаЭто было бы очень кстати!
Можно еще посмотреть в системе механизм отличия ESC последовательностей от ESC с теми же символами.Используя экранные редакторы под RT-11 на машинах не с теми терминалами, на коды клавиш которых были настроены редакторы - я имитировал многобайтовые коды клавиш при помощи клавиши <Ctrl>, так что те системы, которые я использовал - совершенно точно не отличали "родную" многобайтовую последовательность от её "ручной имитации" :)
Это было бы очень кстати!
Используя экранные редакторы под RT-11 на машинах не с теми терминалами, на коды клавиш которых были настроены редакторы - я имитировал многобайтовые коды клавиш при помощи клавиши <Ctrl>, так что те системы, которые я использовал - совершенно точно не отличали "родную" многобайтовую последовательность от её "ручной имитации" :)
Честно скажу, что на DECовских системах в принципе никогда не знал что такое - редактор не справился с esc последовательностью. А вот на пресловутом vi ничего со времен 2.9BSD не изменилось. Если хочешь быстро работать в нем с текстом, про стрелочки забудь и пользуюся буковками :)
Итак, как и предполагалось, миф о нерабочести RSX-11 без перелопачивания на ВМ3 развенчан. 22-битный RSX-11S отлично загрузился и работает. Это автоматически означает работоспособность RSX-11M если сделать ему нужные драйвера устройств и загрузки-сохранения.
На расплывчатой картинке видна консоль RSX-11S загруженного из под RT-11. Второй терминал торчит в мою сторону телнетом, на нем запустил RSD... Заодно проверил программку которая грузит обратно RT-11 - пашет... Пользуясь случаем, ioscan и тест MxPx команд. Проверка показала, как и написано в документации, MFPD/MTPD, MFPI/MTPI просто работают одинаково.
Осталось побороть лень и дописать драйверы.
Попробовали загрузить BRUSYS от RSX-11M-PLUS V4.6 (это RSX-11M V4.8 с программками для backup-restore-diag-format). Загрузилось.
Это уже 18битная система.
Пользуясь случаем, ioscan ...
Собственно кто есть кто.
172140-172142 КМД (MY)
172300-172316 KERNEL PDR
172340-172356 KERNEL PAR
172512 PARH2
172516 SR3
174000-174020 НЖМД (винчестер)
176560-176566 ИРПС (последовательный порт)
177514-177516 ИРПР (принтер)
177560-177566 Терминал (КЦГД)
177572-177576 SR0,SR1,SR2
177600-177616 USER PDR
177640-177656 USER PAR
177776 PSW
Вот он и PARH2.
Джентльменский набор который использовался для баловства.
rsx11s.rar - RSX-11S V4.6, сгенеренный без каких-либо устройств кроме двух терминалов на 177560/60 и 176560/360, 22bit
rsx11s.map.txt - карта памяти от него
bootmy.mac.txt - загрузчик с MY0: - фиксится в образе RSX-11S
sload.mac.txt - загрузчик несохраненных образов RSX-11.
Особо до ума не доводил - цель была просто проверить работоспособность, а дальше куда полезнее будет направить усилия на создание нужных драйверов :)
SLOAD умеет грузить несохраненный образ RSX с MY0:, грузит всегда 124KW и никак иначе ;)
$STACK = 776 ;Стек
;$INITL = 30140 ;$INITL - точка входа в систему
$INITL = 22612 ;$XDT - точка входа в отладчик системы
BLKN = 786. ;Начальный номер блока файла на диске
Номер блока файла берется из команды DIR/BL. Точка входа, начальный стек берутся из карты памяти RSX. Если система собрана с отладчиком (XDT), можно взять в качестве стартового адреса символ $XDT, в этом случае система стартует с отладчика и после в него можно зайти командой BRK.
Загрузчик включает 22bit режим, переносится в адрес 760000 и грузит с диска образ в адреса 0-757776.
Программа BOOTMY делает аппаратную загрузку с MY0: из под RSX.
Собирается командами:
>MAC BOOTMY=LB:[11,10]RSXMC/PA:1,SY:[]BOOTMY
>TKB BOOTMY/PR:5=BOOTMY
Можно обойтись без RSXMC.MAC, в этом случае вместо
CALL $SWSTK,10$
должно быть
EMT 376
.WORD 10$
Программа должна быть зафиксирована в образе системы с помощью VMR.
>VMR
Enter filename: RSX11S
VMR>INS BOOTMY/FIX=YES
VMR>^Z
>
Подоспели фотки от загрузки BRUSYS...
Собственно кто есть кто.
Теперь уже как-то и непри(вы,ли)чно смотрится :)
I/O page Map
Starting Ending
Address address
17765000 - 17765776 CPU ROM or EEPROM
17772100 Memory CSR
17772150 - 17772152
17772200 - 17772276 Supervisor I and D PDR/PAR's
17772300 - 17772376 Kernel I and D PDR/PAR's
17772516 MMR3
17773000 - 17773776 CPU ROM
17774440 - 17774456
17774500 - 17774502
17776500 - 17776536
17777514 - 17777516
17777520 - 17777524 BCSR, PCR, BCR/BDR
17777546 Clock CSR
17777560 - 17777566 Console SLU
17777572 - 17777576 MMR0,1,2
17777600 - 17777676 User I and D PDR/PAR's
17777744 - 17777752 MSER, CCR, MREG, Hit/Miss
17777766 CPU Error
17777772 PIRQ
17777776 PSW
---------- Post added 03.03.2012 at 00:17 ---------- Previous post was 02.03.2012 at 23:31 ----------
Это было бы очень кстати!
Пиши тест - у меня уже сегодня сил нет :)
Дополнительная информация по местным условиям (не особо нужна, но мало ли):
BIS #100,@#177546 ;РАЗРЕШИТЬ ПРЕРЫВАНИЯ ТАЙМЕРА
BIS #6000,@#177520 ;800Hz
Пиши тестА вот и тест:
MCPS.SAV CHECK TERMINAL INPUT SPEED - V1.0 (http://zx.pk.ru/attachment.php?attachmentid=33593)
После приглашения "PRESS EXTENDED KEYS FOR TEST OR OTHER FOR EXIT.." нужно нажимать стрелки или клавиши доп. клавиатуры - для их тестирования или пробел - для завершения работы.
У меня прогон выглядит так:
1. Быстрая скорость генерации многобайтовых посылок ( скорость порта )
.RU MCPS
MCPS - CHECK TERMINAL INPUT SPEED - V1.0
CPU SPEED: 39
TERMINAL ID : <033> .. 14 ms .. '/' .. 1 ms .. 'Z'
AUTOANSWER : <003> .. 15 ms .. <003>
PRESS EXTENDED KEYS FOR TEST OR OTHER FOR EXIT..
MULTIBYTE KEY: <033> .. 15 ms .. 'D'
MULTIBYTE KEY: <033> .. 1 ms .. 'C'
MULTIBYTE KEY: <033> .. 1 ms .. '?' .. 1 ms .. 'p'
MULTIBYTE KEY: <033> .. 16 ms .. '?' .. 1 ms .. 'n'
MULTIBYTE KEY: <033> .. 1 ms .. '?' .. 1 ms .. 'M'
PROGRAM COMPLETED
2. Медленная скорость генерации многобайтовых посылок ( ~ 50 CPS )
.RU MCPS
MCPS - CHECK TERMINAL INPUT SPEED - V1.0
CPU SPEED: 39
TERMINAL ID : <033> .. 16 ms .. '/' .. 14 ms .. 'Z'
AUTOANSWER : <003> .. 31 ms .. <003>
PRESS EXTENDED KEYS FOR TEST OR OTHER FOR EXIT..
MULTIBYTE KEY: <033> .. 16 ms .. 'A'
MULTIBYTE KEY: <033> .. 15 ms .. 'B'
MULTIBYTE KEY: <033> .. 16 ms .. '?' .. 31 ms .. 'p'
MULTIBYTE KEY: <033> .. 15 ms .. '?' .. 20 ms .. 'n'
MULTIBYTE KEY: <033> .. 11 ms .. '?' .. 31 ms .. 'M'
PROGRAM COMPLETED
Для начала собственно терминал эмулятор в котором работаю...
.SET SL KED
.SET SL OFF
.SET SL ON
.RU MCPS
MCPS - CHECK TERMINAL INPUT SPEED - V1.0
CPU SPEED: 199
TERMINAL ID : <033> .. 0 ms .. '[' .. 0 ms .. '?' .. 0 ms .. '6' .. 0 ms .. '2' .. 0 ms .. ';' .. 0 ms .. '1' .. 0 ms .. ';' .. 8 ms .. '2' .. 0 ms .. ';' .. 1 ms .. '6' .. 1 ms .. ';' .. 1 ms .. '7' .. 1 ms .. ';' .. 1 ms .. '8' .. 1 ms .. ';' .. 1 ms .. '9' .. 1 ms .. 'c'
PRESS EXTENDED KEYS FOR TEST OR OTHER FOR EXIT..
MULTIBYTE KEY: <033> .. 1 ms .. 'O' .. 1 ms .. 'w'
MULTIBYTE KEY: <033> .. 1 ms .. 'O' .. 1 ms .. 'x'
MULTIBYTE KEY: <033> .. 1 ms .. 'O' .. 1 ms .. 'y'
PROGRAM COMPLETED
.
PS. А алгоритм измерения ms у тебя какой? (лень лезть в сорцы)
Ох как плохи дела у реального УКНЦ. :v2_dizzy_facepalm:
Но вот проблем в DESS-е не испытываю.
http://zx.pk.ru/attachment.php?attachmentid=33594&d=1330792509
Patron, спасибо за включение режима ДКЛ. Очень предусмотрительно.
Для начала собственно терминал эмулятор в котором работаю...
form, а что такого зашифровано в идентификаторе терминала?
form, а что такого зашифровано в идентификаторе терминала?
Да наверное вообще все параметры терминала :)
Я не силен в VT100 кодах которые он возвращает. Всегда обходился тем, что если после <CSI> дождался "c", то это оно и было :)
алгоритм измерения msСразу после зупуска нормируется циклический 32-разрядный счётчик. По каждому прерыванию ввода - его текущие значения сохраняются в массиве. При выводе результатов - из каждого текущего значения вычетается предыдущее (если оно есть), затем осуществляется деление на нормированное значение счётчика, набегающее за одну миллисекунду.
Сразу после зупуска нормируется циклический 32-разрядный счётчик. По каждому прерыванию ввода - его текущие значения сохраняются в массиве. При выводе результатов - из каждого текущего значения вычетается предыдущее (если оно есть), затем осуществляется деление на нормированное значение счётчика, набегающее за одну миллисекунду.
У меня в принципе можно сетевой таймер поставить в разрешение до 1.25ms - для расчетов поди сойдет :)
проблем в DESS-е не испытываюГлавное, что проблемы в принципе могут возникнуть только при работе с минитором SJ.
Ни Рафос, ни Фодос, ни FB, ни SB - "реверсивной" проблемы не имеют.
Не исключено также, что скорость процессора играет более важную роль при абстрактной эмуляции, когда эмулятор регулярно "засыпает" на 15 ms, а потом быстренько "разгребает" накопившиеся прерывания.
В реале, когда прерывания идут более регулярно, вполне возможно, что даже быстродействия Э-60/LSI-11 может хватить.
---------- Post added at 19:59 ---------- Previous post was at 19:56 ----------
У меня в принципе можно сетевой таймер поставить в разрешение до 1.25ms - для расчетов поди сойдетТут чем меньше прерываний от таймера - тем точнее измерения. Главное, чтобы число прерываний таймера в секунду было целым. Очень хорошо подошёл бы режим 1 Гц :)
Кстати, ячейки в начале программы содержат основные "явки и пароли", влючая число прерываний таймера в секунду.
Главное, что проблемы в принципе могут возникнуть только при работе с минитором SJ.
Ни Рафос, ни Фодос, ни FB, ни SB - "реверсивной" проблемы не имеют.
Не исключено также, что скорость процессора играет более важную роль при абстрактной эмуляции, когда эмулятор регулярно "засыпает" на 15 ms, а потом быстренько "разгребает" накопившиеся прерывания.
В реале, когда прерывания идут более регулярно, вполне возможно, что даже быстродействия Э-60/LSI-11 может хватить.
Для эмулятора весьма важен параметр задержки прерывания на заданное число инструкций процессора. DEC частенько писал драйверы исходя из этого. В документации на E11 целая глава посвящена этому вопросу.
Если хочется увидеть результаты в микросекундах - нужно найти в программе нормирующее деление на 1000 и заменить его делением на 1'000'000.
Если хочется увидеть результаты в микросекундах - нужно найти в программе нормирующее деление на 1000 и заменить его делением на 1'000'000.
А не проще тупо написать прогу для виндовса или униха и подключить терминал к PC? :)
Нет, на миллион делить нельзя - для большинства процессоров получится 0 или 1..
---------- Post added at 20:07 ---------- Previous post was at 20:05 ----------
А не проще тупо написать прогу для виндовса или униха и подключить терминал к PC?Предложенная утилита измеряет промежутки времении с разрешением, равным суммарной продолжительности трёх команд процессора.
Это очень точные измерения.
Главное, что проблемы в принципе могут возникнуть только при работе с минитором SJ.
Ни Рафос, ни Фодос, ни FB, ни SB - "реверсивной" проблемы не имеют.
Не исключено также, что скорость процессора играет более важную роль при абстрактной эмуляции, когда эмулятор регулярно "засыпает" на 15 ms, а потом быстренько "разгребает" накопившиеся прерывания.
В реале, когда прерывания идут более регулярно, вполне возможно, что даже быстродействия Э-60/LSI-11 может хватить.
UKNCBTL тоже засыпает, а потом, при следующем просыпании, также все разгребает. SJ мониторы бывают разные - с поддержкой таймера и без, у них различаются обработчики прерываний клавиатуры. По этому поводу даже писали, что на МС1201.02 на процессоре 1801ВМ2 при активном использовании инструкций FIS и нажатии на клавиши в это время часто программа вываливалась в пультовый отладчик, но эта проблема наблюдается только в SJ-мониторе без поддержки таймера, в мониторе с поддержкой таймера эта проблема отсутствует.
Кстати на реальной УКНЦ также проблемы нет. Зажал стрелку вниз и в режиме автоповтора клавиши происходило пролистывание страниц.
Вот вариант, выводящий результаты не в миллисекундах, а в сотнях микросекунд:
MCPS.SAV v1.1 - CHECK TERMINAL INPUT SPEED (http://zx.pk.ru/attachment.php?attachmentid=33598)
.RU MCPS
MCPS - CHECK TERMINAL INPUT SPEED - V1.1
CPU SPEED: 50
TERMINAL ID : <033> .. 137 ms*10 .. '/' .. 77 ms*10 .. 'Z'
AUTOANSWER : <003> .. 144 ms*10 .. <003>
PRESS EXTENDED KEYS FOR TEST OR OTHER FOR EXIT..
MULTIBYTE KEY: <033> .. 153 ms*10 .. 'A'
MULTIBYTE KEY: <033> .. 161 ms*10 .. 'B'
MULTIBYTE KEY: <033> .. 153 ms*10 .. '?' .. 73 ms*10 .. 'p'
MULTIBYTE KEY: <033> .. 83 ms*10 .. '?' .. 73 ms*10 .. 'n'
MULTIBYTE KEY: <033> .. 161 ms*10 .. '?' .. 71 ms*10 .. 'M'
PROGRAM COMPLETED
эта проблема наблюдается только в SJ-мониторе без поддержки таймераСкорее всего именно так, потому что ядро с поддержкой таймера (насколько я понимаю) близко к FB, а у FB реверсивной проблемы нет.
Скорее всего именно так, потому что ядро с поддержкой таймера (насколько я понимаю) близко к FB, а у FB реверсивной проблемы нет.
Попробуй в SJ сделать ввод-вывод с VM (или к слову с HD наверное) с использованием подпрограммы завершения, посмотрим насколько оно близко к FB будет :)
Скорее всего именно так, потому что ядро с поддержкой таймера (насколько я понимаю) близко к FB, а у FB реверсивной проблемы нет.
Совершенно верно. Обработчик прерывания клавиатуры у SJ-монитора с поддержкой таймера и FB-монитора одинаковый. Особняком стоит SJ-монитор без поддержки таймера. Собственно проблема эта решалась перестановкой местами двух команд в RMON, эта проблема и ее решение были описаны в одном из журналов МПСС.
эта проблема и ее решение были описаны в одном из журналов МПСС.Интересно бы узнать подробнее, чтобы самому не искать это место в RMON.
Интересно бы узнать подробнее, чтобы самому не искать это место в RMON.
Поищу в сканах журналов. Но эта проблема была в процедуре завершения прерывания.
Суть ее в том, что смотрелось во время завершения два условия. Один аргумент находился вроде в регистрах, а второй в теле программы, адрес смотрелся через стек. Так вот обработчик FIS написан таким образом, что если при его вызове прерывания были разрешены, то он разрешал аппаратные прерывания и при обработке FIS. Естественно при прерывании в стеке сохранялся адрес, больший 160000. Возврат по RTI/RTT в 1801ВМ2 происходит нормально, это предусмотрено. Но вот процедура завершения лезет соответственно по адресу большему чем 160000 в USER-режиме, ну и соответственно получает TRAP4.
А решение проблемы в том, чтобы сначала проверялось условие в регистре, а потом в памяти программы.
Описана в журнале № 5 за 1989 год, страница 92. Называется "Ошибка в операционной системе для ДВК3".
А вот собственно и кусок кода:
http://zx.pk.ru/attachment.php?attachmentid=33599&d=1330796467
В SJ-мониторе без поддержки таймера используется одна и та же процедура завершения как для обработчика EMT, так и для обработчика прерываний клавиатуры. Естественно сначала проверяется не было ли у нас EMT 375, для обработчика клавиатуры это бессмысленно, поэтому если прервалось при эмуляции FIS, то попадаем в отсутствующую память (выше 160000).
Проблема решалась тем, что сначала проверялось ASL R2/BEQ NOPOP, а затем CMPB #374,-2(R3)/BLOS NOPOP.
Ну вот наконец подоспел и тест версии 1.1 на УКНЦ.
http://zx.pk.ru/attachment.php?attachmentid=33600&d=1330797108
Вот версия, котрая должна выводить результаты нормально:
MCPS - CHECK TERMINAL INPUT SPEED - V1.2 (http://zx.pk.ru/attachment.php?attachmentid=33607)
.RU MCPS
MCPS - CHECK TERMINAL INPUT SPEED - V1.2
CPU SPEED: 3
TERMINAL ID : <033> [ 20.6 ms ] '/' [ 1.6 ms ] 'Z'
AUTOANSWER : <003> [ 18.2 ms ] <003>
PRESS EXTENDED KEYS FOR TEST OR OTHER FOR EXIT..
MULTIBYTE KEY: <033> [ 1.6 ms ] 'A'
MULTIBYTE KEY: <033> [ 1.6 ms ] 'B'
MULTIBYTE KEY: <033> [ 20.8 ms ] '?' [ 1.6 ms ] 'r'
MULTIBYTE KEY: <033> [ 1.6 ms ] '?' [ 1.6 ms ] 'M'
MULTIBYTE KEY: <033> [ 1.6 ms ] '?' [ 1.6 ms ] 'u'
MULTIBYTE KEY: <033> [ 1.6 ms ] '?' [ 1.6 ms ] 't'
PROGRAM COMPLETED
MCPS 1.2 на УКНЦ.
http://zx.pk.ru/attachment.php?attachmentid=33608&d=1330799885
Понял я, почему TERMINAL ID у formа кривовато обработался - приёмный буфер программы рассчитан только на 10 байтов.
Оказалось, что этого может быть мало..
Сейчас исправлю.
Вот версия, которая может "переварить" TERMINAL ID длиной до 60 байтов.
MCPS - CHECK TERMINAL INPUT SPEED - V1.2a (http://zx.pk.ru/attachment.php?attachmentid=33609)
...
Собственно УКНЦ имеет 25 программируемых клавиш, на которые можно назначить любые комбинации.
Итак, исходные данные: реальный УКНЦ и RT-11 V05.01 без поддержки таймера. При загрузке грузится и активизируется драйвер SL V08.00 от Строжевых.
Назначаем на клавишу К1 вот такую комбинацию: <33>[1,2,3,4,5,6,7,8,9,10,11,12c. Вроде вполне достаточно.
Выходим из программы назначения клавиш в ОС. Жмем К1, видим вполне внятный результат, комбинацию <33>[1 съел SL и пропищал, остальное вывел. Нажмем <Enter> и получим вполне нормальное сообщение о неправильной команде.
Далее выключаем SL командой SET SL OFF и после нажмем К1. Видим довольной ужасный результат. Еще можно заметить, что под курсором находится еще запятая. А далее самое интересное - жмем <Enter> и получаем страшное сообщение о невозможности считать систему. Таким образом сказался эффект реверсивного буфера, данные заносятся не только в сам буфер, но и за его пределы, портя код RMON.
Мои выводы. При работе SL ввод клавиш осуществляется без эхо-печати и подпрограмма обработки прерываний клавиатуры только заносит прочтенный код в буфер. При отключенном SL ввод осуществляется с эхо-печатью, а вот здесь уже не хватает скорости обработки, эффект как говорится налицо.
Мои выводы. При работе SL ввод клавиш осуществляется без эхо-печати и подпрограмма обработки прерываний клавиатуры только заносит прочтенный код в буфер. При отключенном SL ввод осуществляется с эхо-печатью, а вот здесь уже не хватает скорости обработки, эффект как говорится налицо.
А практические выводы? Чего использовать, чего нет?
При работе SL ввод клавиш осуществляется без эхо-печати и подпрограмма обработки прерываний клавиатуры только заносит прочтенный код в буфер. При отключенном SL ввод осуществляется с эхо-печатью, а вот здесь уже не хватает скорости обработки, эффект как говорится налицо.При включенном SL для нормальной работы RT-11 хватает где-то 12 команд процессора на байт ввода, при выключенном ( и при вводе в программах через .TTYIN [???] ) нужно ~ 120.
Напомните, что такое SL, а то я забыл, и не знал)
Напомните, что такое SL, а то я забыл, и не знал)SL - Single Line Editor - редактор командной строки KMON (запускается командой SET SL ON), позволяющий (например) вернуть последнюю введённую строку нажатием клавиши [Up]
SL - Single Line Editor - редактор командной строки KMON (запускается командой SET SL ON), позволяющий (например) вернуть последнюю введённую строку нажатием клавиши [Up]
Вещь нужная.
SL - Single Line Editor - редактор командной строки KMON (запускается командой SET SL ON), позволяющий (например) вернуть последнюю введённую строку нажатием клавиши [Up]
Редактор командной строки KMON он только если это родной SL и включен командой SET SL KMON. В противном случае это редактор любого строчного ввода :)
Редактор командной строки KMON он только если это родной SL и включен командой SET SL KMON. В противном случае это редактор любого строчного ввода Да, точно. SL - верное лекарство от реверсивной болезни.
Чтобы не выключая SL быстро проверить операционку "на реверс" - я запускаю Бэйсик, там SL уже помочь не может :)
Попробовал тест с длинной комбинацией в системе RT-11SJ с обработкой таймера. Все нормально, при выключенном SL, и соответственно с эхо-печатью все нормально выводится и не теряется.
---------- Post added at 00:33 ---------- Previous post was at 00:32 ----------
А практические выводы? Чего использовать, чего нет?
А практические выводы заключаются в том - используйте SJ-монитор с обработкой таймера, или SB/FB-мониторы, где этой проблемы нет.
Попробовал тест с длинной комбинацией в системе RT-11SJ с обработкой таймера. Все нормально, при выключенном SL, и соответственно с эхо-печатью все нормально выводится и не теряется.И что самое прикольное - в советских клонах RT-11 этого нет. Наверное, и в старых версиях RT-11 тоже.
Да, точно. SL - верное лекарство от реверсивной болезни.
Чтобы не выключая SL быстро проверить операционку "на реверс" - я запускаю Бэйсик, там SL уже помочь не может :)
Вообще есть бит в JSW который запрещает SL, но советскому наверное пофигу :)
Кстати в эмуляторе UKNCBTL этого глюка не наблюдается, наверное коды клавиш там приходят с интервалом в 1мс, а не в 0.6мс, как в оригинале.
---------- Post added at 00:47 ---------- Previous post was at 00:39 ----------
И что самое прикольное - в советских клонах RT-11 этого нет. Наверное, и в старых версиях RT-11 тоже.
У меня есть только наш ФОДОС В03.00, но он с поддержкой обработки таймера.
У меня есть только наш ФОДОС В03.00, но он с поддержкой обработки таймера.Да, точно - если найти аналог "чистого SJ" - может ещё и заглючит..
Вот: 4-я версия RT-11 (http://emulator.pdp-11.org.ru/misc/RT-11v4.0C_RK.dsk.zip), может её проверить..
Проверил в RT-11SJ V04.00 - эффект реверсивного буфера есть. В конце строки вообще вывелся знак процента %, ну и по нажатию <Enter> сообщение о невозможности считать систему с выходом в пульт.
Кстати в эмуляторе UKNCBTL этого глюка не наблюдается, наверное коды клавиш там приходят с интервалом в 1мс, а не в 0.6мс, как в оригинале.
А у меня в эмуле?
У меня коды приходят сразу же друг за другом.
Т.е. если нажал 10 клавиш, то сразу 10 кодов и придут)
А у меня в эмуле?
У меня коды приходят сразу же друг за другом.
Т.е. если нажал 10 клавиш, то сразу 10 кодов и придут)
Вот и проверь. Разговор идет не о 10 нажатых клавишах, а о клавише, которая при своем нажатии посылает несколько кодов.
Вот и проверь. Разговор идет не о 10 нажатых клавишах, а о клавише, которая при своем нажатии посылает несколько кодов.
А я не понимаю, как работает тест)
А я не понимаю, как работает тест)
Проверил, приходят с интервалом 0.3мс. Соответственно при выключенном SL эффект проявляется в полной мере. Если на реальной машине прямо выводится каждый нечетный символ, а четные потом в обратном порядке, то в EmuStudio прямо выводится только первый символ, а все остальные в обратном порядке.
Проверил, приходят с интервалом 0.3мс. Соответственно при выключенном SL эффект проявляется в полной мере. Если на реальной машине прямо выводится каждый нечетный символ, а четные потом в обратном порядке, то в EmuStudio прямо выводится только первый символ, а все остальные в обратном порядке.
Откуда берется 0.3мс? Что задает это время?
Откуда берется 0.3мс? Что задает это время?
Это время измеряется в программе Patron-а. Если на клавишу назначена строка символов, то ПП посылает их друг за другом. Все зависит в данном случае от быстродействия программы в ПП. В UKNCBTL, судя по измерениям этой программы, ЦП работает с такой же скорость, как и на реале. А так в UKNCBTL команды в ПП выполняются в 1,28 раз медленнее чем в ЦП, то и получается 1мс. Но в ПП в ПЗУ команды выполняются быстрее, чем в ОЗУ ЦП, поэтому на реале 0.6мс.
Это время измеряется в программе Patron-а. Если на клавишу назначена строка символов, то ПП посылает их друг за другом. Все зависит в данном случае от быстродействия программы в ПП. В UKNCBTL, судя по измерениям этой программы, ЦП работает с такой же скорость, как и на реале. А так в UKNCBTL команды в ПП выполняются в 1,28 раз медленнее чем в ЦП, то и получается 1мс. Но в ПП в ПЗУ команды выполняются быстрее, чем в ОЗУ ЦП, поэтому на реале 0.6мс.
А у меня пока что ЦП и ПП работает с одной скоростью.
На реале ПП еще медленнее ЦП, чем в 1.28, т.к. шина ПП 8-битная.
А у меня пока что ЦП и ПП работает с одной скоростью.
На реале ПП еще медленнее ЦП, чем в 1.28, т.к. шина ПП 8-битная.
Шина 8-битная только для ОЗУ. А для ПЗУ и регистров внешних устройств полные 16 бит. Да и из ПЗУ выборка идет за 2-3 такта.
Это время измеряется в программе Patron-а.Точность измерения пропорциональна параметру CPU SPEED, который измеряется первым.
Именно на это число делится значение циклического счётчика.
Когда CPU SPEED == 5 - это означает, что точность измерения ~ 20% ( 1/5 ).
Когда у меня в эмуляторе получается CPU SPEED == 4, то задержка, измеренная при CPU SPEED == 3 как 1.6 ms - превращается в 1.2 ms
Хе.
RSX-11M-PLUS V4.6 BL87 1024.KW System:"KOPOBA"
>RED DU:=SY:
>RED DU:=LB:
>RED DU:=SP:
>MOU DU0:"RSX11MPBL87"
>@DU:[1,2]STARTUP
>; PLEASE NOTE
>;
>; If you have not yet read the system release notes, please do so
>; now before attempting to perform a SYSGEN or to utilize the new
>; features of this system.
>;
>;
>* Please enter time and date (Default:04-MAR-2012 15:25) [S]: ^Z
>@ <EOF>
>LOA MY:/VEC
>CON ONL ALL
>ALL MY
ALL -- MY0: Now allocated
>MOU MY:/FOR
>INI MY:TEST
Searching for bad block descriptor file
INI -- Failed to read bad block file
>DMO MY:
15:25:33 *** MY0: -- Dismount complete
DMO -- TT0: dismounted from MY0: *** Final dismount initiated ***
>MOU MY:TEST
>DEV /MA
DU0: Public Mounted Loaded Label=RSX11MPBL87 Type=RA60
MU0: Loaded Type=TU81
MY0: TT0: - Private Mounted Loaded Label=TEST Type=UNKN
MY1: Loaded Type=UNKN
MY2: Loaded Type=UNKN
MY3: Loaded Type=UNKN
>PIP MY:/FR
MY0: has 1573. blocks free, 27. blocks used out of 1600.
Largest contiguous space = 798. blocks
92. file headers are free, 5. headers used out of 97.
>
Относительно перехода процессора 11/83 в режим KERNEL и обратно у меня сложилось следующее впечатление:
1. При любом запуске блока прерываний - устанавливается режим KERNEL и если предыдущим режимом был режим USER - запоминается значение SP.
2. Если в результате любой последующей команды значение SP становится больше запомненного - устанавливается режим USER.
Относительно перехода процессора 11/83 в режим KERNEL и обратно у меня сложилось следующее впечатление:
1. При любом запуске блока прерываний - устанавливается режим KERNEL и если предыдущим режимом был режим USER - запоминается значение SP.
2. Если в результате любой последующей команды значение SP становится больше запомненного - устанавливается режим USER.
Если в векторе прерывания PSW задан с очищенными двумя старшими битами - устанавливается режим KERNEL. При этом прошлый режим записывается в два следующих бита ниже старших. SP для каждого режима свой и значение его никакого влияния на режим не оказывает. Адрес/PSW для возврата пишется в стек режима который включается.
---------- Post added at 11:26 ---------- Previous post was at 11:24 ----------
Еще насчет режимов - есть такая ошибка некогда распространенная - при возврате из прерывания установить режим 140000 (пользователь, прошлый - кернел). Почему ошибка - думаю объяснять не нужно :)
Но давно не встречал.
---------- Post added at 11:32 ---------- Previous post was at 11:26 ----------
То есть подводя итоги: режим процессора задается двумя старшими битами PSW, SP в каждом режиме свой.
---------- Post added at 11:35 ---------- Previous post was at 11:32 ----------
Ну и попутно раз пошла такая пьянка...
В усерском режиме команда HALT вызывает трап по 4 или 10 (зависит от проца), на 11/83 по 4.
Команды WAIT, RESET, SPL выполняются как NOP.
В усерском режиме нельзя трогать приоритет процессора и биты режима.
С усерского режима нельзя соскочить через RTI - биты режима установятся снова в USER.
---------- Post added at 11:39 ---------- Previous post was at 11:35 ----------
Ну и еще для информации - вектора прерываний - это не адреса 0-774, а адреса, которые в кернелном режиме отображаются в это место. Но обычно они совпадают.
---------- Post added at 11:59 ---------- Previous post was at 11:39 ----------
Вот собственно для демонстрации :)
.TY TEST.MAC
.TITLE TEST
.MCALL .PRINT,.EXIT
START: MOV #10$,@#14
CLR @#16 ;ПЕРЕХОДИМ В КЕРНЕЛ
BPT
10$: CALL MODE
MOV #20$,@#14
MOV #140000,@#16 ;ПЕРЕХОДИМ В УСЕР
BPT
CALL MODE
.EXIT
20$: CALL MODE
RTI ;ОСТАЕМСЯ В УСЕР
MODE: MOV @#177776,-(SP)
MOV 2(SP),R1
MOV #SPC,R0
MOV PC,R2
CALL $CBOMG
MOV SP,R1
CMP (R1)+,(R1)+
MOV #SSP,R0
MOV PC,R2
CALL $CBOMG
MOV (SP)+,R1
MOV #SPS,R0
MOV PC,R2
CALL $CBOMG
.PRINT #STATE
RETURN
STATE: .ASCII /PC=/
SPC: .ASCII /XXXXXX SP=/
SSP: .ASCII /XXXXXX PS=/
SPS: .ASCIZ /XXXXXX/
.END START
.RU TEST
PC=001020 SP=155204 PS=030000
PC=001050 SP=000774 PS=140000
PC=001042 SP=001000 PS=170010
.
---------- Post added at 13:10 ---------- Previous post was at 11:59 ----------
в режим KERNEL
Никак об эмуляции ВМ3 подумываешь? :)
Теперь информации хватает, недостающие мелочи дотестить можно всегда.
Готовимся к следующему опыту...
Образы двух дискет подготовлены :)
... Адрес/PSW для возврата пишется в стек режима который включается.
Т.е. сначала получается вектор прерывания, читается из KERNEL-режима значение вектора, а потом в соответствии с новым PSW старые PC и PSW пишутся в стек нового режима?
У ВМ1 и ВМ2 наоборот. Сначала сохраняется в стеке старые PC и PSW, и если не удалось сохранить (из-за четвертого трапа), то до запроса вектора и не доходит.
Еще насчет режимов - есть такая ошибка некогда распространенная - при возврате из прерывания установить режим 140000 (пользователь, прошлый - кернел). Почему ошибка - думаю объяснять не нужно :)
Но давно не встречал.
А можно поподробнее. А то я пока не очень с защищенными режимами.
Ну и еще для информации - вектора прерываний - это не адреса 0-774, а адреса, которые в кернелном режиме отображаются в это место. Но обычно они совпадают.
Т.е. вектора прерываний - это виртуальные адреса 0-477 режима KERNEL?
Никак об эмуляции ВМ3 подумываешь? :)
Теперь информации хватает, недостающие мелочи дотестить можно всегда.
Много тонкостей в режиме HALT. Есть два источника информации, но как-то противоречиво там написано. Долбаю сейчас прошивку 134, так вот в одном из источников утверждается, что в HALT нельзя использовать EIS (MUL, DIV, ASH, ASHC), но в прошивке употребляются ASH и ASHC.
Т.е. сначала получается вектор прерывания, читается из KERNEL-режима значение вектора, а потом в соответствии с новым PSW старые PC и PSW пишутся в стек нового режима?
У ВМ1 и ВМ2 наоборот. Сначала сохраняется в стеке старые PC и PSW, и если не удалось сохранить (из-за четвертого трапа), то до запроса вектора и не доходит.
У ВМ1/ВМ2 нет режима USER. Точнее режим есть, но означает он совсем другое.
Потому сравнение несколько некорректно. Мы обсуждаем режимы MMU. Режим KERNEL соответствует тому, что на ВМ2 называется "USER" :)
А можно поподробнее. А то я пока не очень с защищенными режимами.
Т.е. вектора прерываний - это виртуальные адреса 0-477 режима KERNEL?
Да.
Точнее 0-777 традиционно. Это RT-11 выше 477 не пользует как вектора.
А в принципе вектор можно и выше сделать.
Много тонкостей в режиме HALT. Есть два источника информации, но как-то противоречиво там написано. Долбаю сейчас прошивку 134, так вот в одном из источников утверждается, что в HALT нельзя использовать EIS (MUL, DIV, ASH, ASHC), но в прошивке употребляются ASH и ASHC.
Режим HALT это особая песня скрытая от нас. В большинстве процессоров этот режим если вообще и есть, область его никак не доступна для программ.
У ВМ1/ВМ2 нет режима USER. Точнее режим есть, но означает он совсем другое.
Потому сравнение несколько некорректно. Мы обсуждаем режимы MMU. Режим KERNEL соответствует тому, что на ВМ2 называется "USER" :)
По данному поводу я хотел узнать последовательность действий, которые делает KDJ-11 при возникновении аппаратного прерывания. Поэтому я попытался прокрутить логически, что он должен сделать, если старые PC и PSW сохраняются в стеке нового режима, а для этого уже надо получить вектор и прочесть его значение.
Режим HALT это особая песня скрытая от нас. В большинстве процессоров этот режим если вообще и есть, область его никак не доступна для программ.
Ну на ВМ1 как такового HALT и нету, есть пара битиков в PSW, изменяющая реакцию на прерывания, да и команды START и STEP, да и завязка на ячейки 177674 и 177676, являющиеся копиями PC и PSW при обработке HALT и фатальных ситуаций. Влезть не представляет труда.
На ВМ2 сложнее, все зависит от архитектуры компьютера. На УКНЦ это сущая ерунда. А вот на МС 1201.02 посложнее, но реально.
Про МС 1201.03 и МС 1201.04 ничего пока сказать не могу, может и нереально.
По данному поводу я хотел узнать последовательность действий, которые делает KDJ-11 при возникновении аппаратного прерывания. Поэтому я попытался прокрутить логически, что он должен сделать, если старые PC и PSW сохраняются в стеке нового режима, а для этого уже надо получить вектор и прочесть его значение.
Ну как бы логично, что когда возникает прерывание, первым делом читается вектор. Также логично, что адрес возврата и старый PSW пишется в стек того режима который включается - иначе вернуться обратно не получится стандартным способом.
Хе.
RSX-11M-PLUS V4.6 BL87 1024.KW System:"KOPOBA"
......................
MY0: has 1573. blocks free, 27. blocks used out of 1600.
Largest contiguous space = 798. blocks
92. file headers are free, 5. headers used out of 97.
>
Готовимся к следующему опыту...
Образы двух дискет подготовлены :)
Как я понимаю, будет предпринята практическая попытка загрузить RSX-11M с MY:?
Как я понимаю, будет предпринята практическая попытка загрузить RSX-11M с MY:?
Не совсем. Пока только загрузить систему так, чтобы MY был системным диском после этого. То есть программы все установлены с MY, не фиксированы в памяти и подгружаются динамически.
Для полноценной загрузки нужно написать драйвер загрузки-сохранения и пересобрать соответствующие программы.
---------- Post added at 16:08 ---------- Previous post was at 16:02 ----------
Цель собственно до конца проверить работоспособность на ДВК полноценного RSXа (разумеется сгенерированного без поддержки D-Space и SupMode) - это базовая RSX-11M-PLUS которая грузится с дистрибного кита без каких-либо изменений.
В общем и целом, с MMU несмотря на слухи проблем быть не должно. Мелкие проблемы могут выскочить в другом месте: ВМ3 наиболее близок к 11/23, но у 11/23 есть команда MFPT которая возвращает код модели, здесь же команды такой нет. Отсюда может возникнуть две проблемы:
проц может определиться как 11/35-подобный - в этом случае система подумает, что 22бита не поддерживается и собственно все (вероятность мала - 22битный 11M загрузился, думаю и M+ загрузится)
проц может определиться как какой-нибудь 11/70-подобный и соответственно имеющий управляемый таймер, а регистра-то и нету на шине -> таймера тоже нету
В остальном проблем быть не должно.
Ну собственно вот и все.
Никаких проблем не возникло.
И 22bit понял и таймер работает.
Помучили с Andrey_Ak напару с двух терминалов :)
Так что остается только сделать драйверы винта ДВКшного и загрузки-сохранения с/на него.
>PAR
SECPOL 117734 00120000 00100000 SEC POOL
SYSPAR 117670 00220000 00174300 MAIN
117624 00220000 00050700 RO COM !DIR11M!
117440 00270700 00004300 TASK <...LDR>
117240 00275200 00033500 TASK <MCR...>
117040 00330700 00010500 TASK [TKTN ]
116760 00341400 00006000 RO COM !TTEXT !
116674 00347400 00035100 DRIVER (TT:)
116044 00404500 00000500 DRIVER (MY:)
115514 00405200 00004000 DRIVER (DD:)
115234 00411200 00001300 DRIVER (LP:)
115024 00412500 00000100 DRIVER (NL:)
114760 00412600 00001500 DRIVER (RD:)
GEN 114714 00414300 01363500 MAIN
114440 00414300 00040000 RO COM !FCSRES!
061214 00454300 00042000 TASK <RMDT0 >
061140 00516300 00040300 TASK <PART1 >
062054 00564100 00011100 TASK <F11ACP>
061314 00612100 00042500 TASK <HRC...>
114650 00654600 00034000 RO COM +F11ACP+
>ATL
...LDR 117504 SYSPAR 117440 00270700-00275200 Pri - 248. Dpri - 248.
Status: -CHK STP -PMD PRV NSD DFB XHR FXD
TI - CO0: IOC - 0. BIO - 0. Eflg - 000001 000000 PS - 170000
PC - 120474 Regs 0-6 000222 007156 177777 061170 061140 061704 120166
RMDT0 061564 GEN 061214 00454300-00516300 Pri - 225. Dpri - 225.
Status: -CHK WFR -PMD REM PRV MCR CMD DFB XHR
TI - TT0: IOC - 0. BIO - 0. Eflg - 000021 040000 PS - 170010
PC - 125544 Regs 0-6 000000 140313 132422 000000 140355 136610 121172
MCR... 117304 SYSPAR 117240 00275200-00330700 Pri - 160. Dpri - 160.
Status: -CHK STP -PMD PRV CLI NSD DFB XHR FXD
TI - TT1: IOC - 0. BIO - 0. Eflg - 000001 000000 PS - 170000
PC - 122744 Regs 0-6 160021 050712 122022 120772 053320 054070 120402
ATLT1 061704 GEN 061140 00516300-00556600 Pri - 160. Dpri - 160.
Status: -CHK -PMD REM PRV MCR CMD DFB XHR
TI - TT1: IOC - 0. BIO - 0. Eflg - 000001 040000 PS - 170000
PC - 122504 Regs 0-6 000000 131574 050712 140544 140060 000000 001274
F11ACP 114504 GEN 062054 00564100-00575200 Pri - 149. Dpri - 149.
Status: -CHK STP ACP PRV NSD DFB MUT XHR
TI - CO0: IOC - 0. BIO - 0. Eflg - 000002 000001 PS - 170000
PC - 130500 Regs 0-6 116164 123256 000000 116164 062230 061444 120330
HRC... 114300 GEN 061314 00612100-00654600 Pri - 140. Dpri - 140.
Status: STP -PMD PRV NSD DFB XHR
TI - CO0: IOC - 0. BIO - 0. Eflg - 000001 040000 PS - 170000
PC - 130614 Regs 0-6 114312 000000 000000 061444 054070 061444 126406
>DEV
VF0: Offline Unloaded Type=unknown
VF1: Offline Unloaded Type=unknown
TT0: [200,200] [200,200] - Logged in Loaded
TT1: [200,200] [,] - Logged in Loaded
TT2: Offline Loaded
TT3: Offline Loaded
TT4: Offline Loaded
TT5: Offline Loaded
TT6: Offline Loaded
TT7: Offline Loaded
TT10: Offline Loaded
TT11: Offline Loaded
TT12: Offline Loaded
TT13: Offline Loaded
TT14: Offline Loaded
TT15: Offline Loaded
TT16: Offline Loaded
TT17: Offline Loaded
TT20: Offline Loaded
TT21: Offline Loaded
TT22: Offline Loaded
TT23: Offline Loaded
TT24: Offline Loaded
TT25: Offline Loaded
TT26: Offline Loaded
TT27: Offline Loaded
TT30: Offline Loaded
TT31: Offline Loaded
TT32: Offline Loaded
TT33: Offline Loaded
TT34: Offline Loaded
TT35: Offline Loaded
VT0: Offline Unloaded
RD0: Loaded
MY0: Public Mounted Loaded Label=RSX11MPBL87 Type=unknown
MY1: Offline Loaded Type=unknown
MY2: Offline Loaded Type=unknown
MY3: Offline Loaded Type=unknown
DD0: Offline Loaded Type=unknown
DD1: Offline Loaded Type=unknown
LP0: Offline Loaded
NL0: Offline Loaded
TI0:
CO0: TT0:
CL0: TT0:
SP0: MY0:
LB0: MY0:
SY0: MY0:
>TAS
...LDR 12.00 SYSPAR 248. 00004300 LB0:-00000001504 FIXED
TKTN 07.01 SYSPAR 248. 00010500 LB0:-00000002456 FIXED
RMDT0 05.00 GEN 225. 00042000 LB0:-00000002476
MCR... 07.00 SYSPAR 160. 00033500 LB0:-00000001563 FIXED
TAST1 07.00 GEN 160. 00040300 LB0:-00000001621
F11ACP 07.00 GEN 149. 00011100 LB0:-00000001514
HRC... 05.00 GEN 140. 00042500 LB0:-00000002257
...RMD 05.00 GEN 225. 00042000 LB0:-00000002476
...MCR 07.00 GEN 160. 00040300 LB0:-00000001621
...MOU 26.06 GEN 160. 00045600 LB0:-00000002127
...CON 05.00 GEN 50. 00135600 LB0:-00000002332
>
Драйвер MY: для RSX-11M-PLUS и Micro/RSX.
Сильно не доводил до ума (не предусматривает случая когда контроллер завис).
Поддерживает несколько контроллеров.
Драйвер векторизован (переносится между системами без пересборки).
Опробован вживую на ДВК4.
MYPRE.MAC - файл параметров
MYTAB.MAC - таблицы драйвера
MYDRV.MAC - драйвер
MYCMD.RAR - командные файлы для MAC и TKB
Некоторые DECовские утилиты критичны к имени устройства.
FLX к примеру категорически возражает, что на устройстве с именем
MY: может быть файловая структура RT-11.
Приходится через виртуальные диски с альтернативными именами делать. По идее можно альтернативные имена и напрямую делать в самом драйвере, только не знаю как...
>DEV MY:
MY0: Public Mounted Loaded Label=RSX11MPBL87 Type=UNKN
MY1: Public Mounted Loaded Foreign Type=UNKN
MY2: Loaded Type=UNKN
MY3: Loaded Type=UNKN
>DIR MY:[0,0]
Directory MY0:[0,0]
6-MAR-12 18:30
INDEXF.SYS;1 100. 05-MAR-12 13:15
BITMAP.SYS;1 2. 05-MAR-12 13:15
BADBLK.SYS;1 0. 05-MAR-12 13:15
000000.DIR;1 1. C 05-MAR-12 13:15
CORIMG.SYS;1 0. 05-MAR-12 13:15
001054.DIR;1 1. C 05-MAR-12 13:15
003054.DIR;1 1. C 05-MAR-12 13:15
Total of 105./105. blocks in 7. files
>FLX MY1:/RT/LI
FLX -- Invalid device
>VCP CON MY1:/DRV:DU
VCP - Device VF0: (DU1:) has been assigned.
>FLX DU1:/RT/LI
Directory DU1:
06-MAR-12
SWAP .SYS 28. 07-APR-11
RT11SB.SYS 101. 01-MAR-12
DW .SYS 7. 08-MAR-90
MY .SYS 3. 19-FEB-80
SL .SYS 17. 01-MAR-12
DIR .SAV 20. 31-OCT-98
PIP .SAV 30. 31-OCT-98
DUP .SAV 52. 31-OCT-98
RESORC.SAV 35. 31-OCT-98
MACRO .SAV 63. 24-APR-11
LINK .SAV 59. 31-OCT-98
SYSMAC.SML 92. 31-OCT-98
SYSLIB.OBJ 84. 31-OCT-98
KED .SAV 85. 31-OCT-98
K52 .SAV 81. 07-APR-11
VDT .SAV 8. 01-MAR-12
DATE .SAV 4. 29-FEB-12
IOSCAN.SAV 3. 18-SEP-11
MMUT1 .SAV 2. 02-MAR-12
STRTSB.COM 1. 01-MAR-12
SLOAD .SAV 2. 05-MAR-12
RSX11M.SYS 498. 05-MAR-12
< Unused > 311.
311. Free blocks
Total of 1275. blocks in 22. files
>
Вот версия, которая может "переварить" TERMINAL ID длиной до 60 байтов.
MCPS - CHECK TERMINAL INPUT SPEED - V1.2a (http://zx.pk.ru/attachment.php?attachmentid=33609)
...
Собственно тест...
Собственно тест...Можно отметить следующее:
1. Компьютер, на котором запускался тест, выполняет команду ADС Memory в 5 раз быстрее, чем 1801ВМ1, работающий на частоте 5 МГц, и в 4 раза быстрее, чем 1801ВМ2, работающий на частоте 8 МГц.
2. Как и ожидалось - родные терминалы фирмы DEC генерят многобайтовые посылки гораздо медленнее, чем позволяет максимальная скорость порта ( в данном случае со скоростью ~ 120 CPS ).
И неспроста - ведь совсем недавно мы убедились, что если посылать многобайтовые коды "расширенных" клавиш со скоростью 9600 BPS в компьютер, имеющий быстродействие LSI-11 ( ~ 0.120 MIPS == 125 команд/байт ), то возникновение "реверсивного глюка" при работе с SJ-монитором весьма вероятно.
Кстати, в описании мониторов DEC говорится, что скорости порта на приём и передачу никак не связаны и могут настраиваться отдельно.
Отсюда вопрос - на какую скорость настроен в нашем случае выходной порт терминала VT220 ?
Можно отметить следующее:
1. Компьютер, на котором запускался тест, выполняет команду ADС Memory в 5 раз быстрее, чем 1801ВМ1, работающий на частоте 5 МГц, и в 4 раза быстрее, чем 1801ВМ2, работающий на частоте 8 МГц.
Тут еще кэш может влиять на скорость работы с памятью.
И неспроста - ведь совсем недавно мы убедились, что если посылать многобайтовые коды "расширенных" клавиш со скоростью 9600 BPS в компьютер, имеющий быстродействие LSI-11 ( ~ 0.120 MIPS == 125 команд/байт ), то возникновение "реверсивного глюка" при работе с SJ-монитором весьма вероятно.
Тут есть еще вот какой нюанс: если слать со скоростью порта с PC на эти терминалы - много чего потеряется. Особенно на CM7209. А на реальных машинах лупи во всю дурь - ни одного символа не потеряешь. Так, что возникновение глюка в SJ по весей видимости вероятно только для не-DECовского железа :)
Кстати, в описании мониторов DEC говорится, что скорости порта на приём и передачу никак не связаны и могут настраиваться отдельно.
Отсюда вопрос - на какую скорость настроен в нашем случае выходной порт терминала ?
Терминалы вроде не бывают с раздельной скоростью. Это на модемы расчитано.
Скорости DL*11 не настраиваются в принципе. Они могут конфигуриться перемычками, но раздельно вод и выход не поддерживают. DLV11-E возможно умеет - он под модем заточен. У меня выбор до 38400. Ни в одном из режимов если лупить во всю дурь в порт с PC нельзя добиться переворота буфера в SJ, но потери гарантированы при скоростях выше 9600.
На мультиплексорах (как минимум DZ*11) программно можно настроить скорость раздельно на вход и выход и в RSX есть еще параметр - скорость на которой модем отвечать будет.
Терминалы вроде не бывают с раздельной скоростью.У меня устойчивое впечатление, что информация про возможность раздельной настройки скорости входного и выходного портов содержится в прочитанных мною фирменных описаниях терминалов DEC.
Вопрос лишь в том, кому не лень их ещё раз перечитать..
:)
У меня устойчивое впечатление, что информация про возможность раздельной настройки скорости входного и выходного портов содержится в прочитанных мною фирменных описаниях терминалов DEC.
Вопрос лишь в том, кому не лень их ещё раз перечитать..
:)
Ну до VT220 включительно можно не перечитывать я думаю :)
Тут есть еще вот какой нюанс: если слать со скоростью порта с PC на эти терминалы - много чего потеряется.Это (скорее всего) зависит от настройки параметров DCB.fRtsControl и DCB.fDtrControl порта PC и разводки сигналов RTS/CTS и DTR/DSR в соединительном кабеле. Если порт PC продолжает посылать байты, когда терминал сбросил бит готовности - байты будут потеряны.
Это (скорее всего) зависит от настройки параметров DCB.fRtsControl и DCB.fDtrControl порта PC и разводки сигналов RTS/CTS и DTR/DSR в соединительном кабеле. Если порт PC продолжает посылать байты, когда терминал сбросил бит готовности - байты будут потеряны.
Какой RTS, CTS, DSR, DTR? У меня DLV-11 порты :)
---------- Post added at 17:20 ---------- Previous post was at 17:19 ----------
Кстати посмотрел, сейчас у меня в E11 просто сказано скорость 9600, FIFO не заполнять больше чем на 1 символ.
---------- Post added at 17:22 ---------- Previous post was at 17:20 ----------
Собственно вот - из списка загрузчиков можно получить названия DLV11 портов которые умеют CTSить-DSRить...
Commands are Help, Boot, List, Setup, Map and Test.
Type a command then press the RETURN key: L
Device Unit
name numbers Source Device type
DU 0-255 CPU ROM RDnn, RXnn, RC25, RAnn
DL 0-3 CPU ROM RL01, RL02
DX 0-1 CPU ROM RX01
DY 0-1 CPU ROM RX02
DD 0-1 CPU ROM TU58
DK 0-7 CPU ROM RK05
MU 0-255 CPU ROM TK50, TU81
MS 0-3 CPU ROM TK25, TS05
XH 0-1 CPU ROM DECNET ETHERNET
NU 0-15 CPU ROM DECNET DUV11
NE 0-15 CPU ROM DECNET DLV11-E
NF 0-15 CPU ROM DECNET DLV11-F
Commands are Help, Boot, List, Setup, Map and Test.
Type a command then press the RETURN key:
Ну а мультиплексоры все вроде умеют.
Ну до VT220 включительно можно не перечитывать я думаюВ меню SETUP VT100 есть такие пункты:
http://zx.pk.ru/attachment.php?attachmentid=33706
В меню SETUP VT100 есть такие пункты:
http://zx.pk.ru/attachment.php?attachmentid=33706
Уговорил, сейчас снова достану клавиатуру и залезу в сетуп :)
Да, есть у меня на VT220 раздельная настройка.
Но для со стороны компа нету :)
DZQ11 есть, но надо починить в нем выбор вектора - на векторе 300 он мне нафиг не нужен :)
Ну вот - с твоей подачи увидел еще одну интересную настройку. Лови новый тест :)
Да, есть у меня на VT220 раздельная настройка.Причём, как видим - выходной порт настроен на скорость передачи 960 CPS ( 9600 BPS / 10 BPC ), но терминал шлёт многобайтовые посылки со скоростью всего 120 CPS.
А более старые терминалы DEC шлют многобайтовые посылки ещё медленнее - со скоростью кадровой развёртки ( 60 CPS ).
Думаю всем, кто эмулирует терминалы DEC, есть смысл иметь это в виду.
Какой RTS, CTS, DSR, DTR? У меня DLV-11 портыТ.е. и при включённом, и при выключенном терминале - содержимое всех 4-х регистров ( TKS, TKB, TPS, TPB ) неизменно.
Проверим?
Т.е. и при включённом, и при выключенном терминале - содержимое всех 4-х регистров ( TKS, TKB, TPS, TPB ) неизменно.
Проверим?
А чего проверять - там всего три провода для связи - TX, RX, GND :)
Вся разница может заключаться в том, что терминал посмертно может BREAK послать - CM7209 например так делает. VT220 вроде не делает.
Ну вот - с твоей подачи увидел еще одну интересную настройку.Типа Limited Transmit :)
У DLV11-E/F есть дополнительные сигналы.
А чего проверять - там всего три провода для связи - TX, RX, GNDТогда потеря байтов при недостаточной скорости их обработки принимающей стороной - не должна удивлять..
---------- Post added at 13:55 ---------- Previous post was at 13:54 ----------
Или терминалы иcпользуют XON/XOFF для управления передачей принимаемых ими байтов ?
Тогда потеря байтов при недостаточной скорости их обработки принимающей стороной - не должна удивлять..
Вообще поддерживается XON/XOFF управление обычно.
Но кроме всего прочего в RT-11 да и в RSX-11 в принципе работа с терминалами организована не особо удачно. В этом плане TSX отличается в хорошую сторону. Для примера, TRANSF, висящий в системных задачах почти ложит намертво BG JOB, а в TSX можно пустить TRANSF на высоком приоритете и вполне себе параллельно работать многоусерно :)
---------- Post added at 17:58 ---------- Previous post was at 17:57 ----------
Тогда потеря байтов при недостаточной скорости их обработки принимающей стороной - не должна удивлять..
---------- Post added at 13:55 ---------- Previous post was at 13:54 ----------
Или терминалы иcпользуют XON/XOFF для управления передачей принимаемых ими байтов ?
CM7209 в принципе использует (что не спасает его при подключении к живому PC с эмулятором). VT220 настраивается, умеет и доп сигналы пользовать.
Просто DL/KL - самый примитивный вид интерфейса и только поздние развития заточенные под линии связи поддерживают аппаратный контроль.
---------- Post added at 17:59 ---------- Previous post was at 17:58 ----------
У CM7209 кстати в описании еще написано сколько нулей-заполнителей надо слать при переводах строки :)
Получается, что если к DL11-W ничего не подключено, то это никак не помешает выводить туда байты в любых количествах.
Так?
Получается, что если к DL11-W ничего не подключено, то это никак не помешает выводить туда байты в любых количествах.
Так?
Да.
---------- Post added at 21:08 ---------- Previous post was at 20:52 ----------
Это кстати касается и DLV11-E и DLV11-H, а ткже LPV11. Бит готовности выставляется независимо от любого состояния. Но у LPV11 есть бит который говорит, что принтер выключен, а у DLV11-E/F есть всякие дополнительные биты по которым определяется состояние. Но есть такой факт: когда модем разрывает связь, система не видит этого до первого обращения к устройству. Мгновенная реакция на разъединение - фича E11 :)
Все.
Можно пробовать на живом ДВК полноценную загрузку.
Пора браться за ДВКшный винт. Кто там в нем хорошо разбирается? :)
>BOO MY:[1,54]
RSX-11M-PLUS V4.6 BL87
>
>TIM 22:24:55 08-Mar-2012
>SAV /WB
RSX-11M-PLUS V4.6 BL87 1024.KW System:"Baseline"
>RED MY:=SY:
>RED MY:=LB:
>RED MY:=SP:
>MOU MY0:"RSX11MPBL87"
>@MY:[1,2]STARTUP
MCR -- Task not in system
>CON ONL ALL
>MOU DU:/OVR
>INS DU:$BOO
>BOO DU:[1,54]
RSX-11M-PLUS V4.6 BL87 1024.KW System:"KOPOBA"
>RED DU:=SY:
>RED DU:=LB:
>RED DU:=SP:
>MOU DU0:"RSX11MPBL87"
>@DU:[1,2]STARTUP
>; PLEASE NOTE
>;
>; If you have not yet read the system release notes, please do so
>; now before attempting to perform a SYSGEN or to utilize the new
>; features of this system.
>;
>;Z
>* Please enter time and date (Default:08-MAR-2012 22:25) [S]: ^Z
>@ <EOF>
>
В архиве последняя версия драйвера MY для RSX-11M-PLUS и модуль SAVMY для загрузки/сохранения.
Сборка драйвера:
>MAC @MYASM
>TKB @MYBLD
После чего положить файлы MYDRV.TSK и MYDRV.STB в LB:[1,54].
Драйвер векторный и должен грузиться с опцией /VEC.
Для добавки поддержки MY в BOO и SAV нужно откомпилировать файл SAVMY.MAC:
>MAC SAVMY=LB:[1,1]EXEMC/ML,SY:[]SAVMY
полученный SAVMY.OBJ вставить в библиотеку LB:[1,24]SAV.OLB:
>LBR SAV/IN/-EP=SAVMY
отредактировать файлы [1,24]SAVBLD.ODL и [1,24]BOOBLD.ODL (последний создается только при пересборке BOO с помощью SYSGEN), добавив модуль SAVMY среди списка модулей устройств, пересобрать SAV и BOO:
>CHD 1 24
>ASN NL:=MP:
>TKB @SAVBLD
>TKB @BOOBLD
не забудем про образ существующей системы:
>CHD 1 54
>RUN $VMR
Enter filename: RSX11M
VMR>REM SAV
VMR>REM BOO
VMR>INS SAV
VMR>INS [3,54]BOO
VMR>^Z
>
Образ MY: с RSX-11M-PLUS V4.6 для загрузки на ДВК-4 ;)
Получше образ RSX. Второй терминал настроен на ДВКшные 176560/360.
В задачах есть HEL и BYE. Заведен пользователь SYSTEM без пароля. Вполне себе мультиусерная система ;)
Чего не хватает - можно на другой дискете поместить :)
>TAS
...LDR SYSPAR 248. 00004300 LB0:-00000000000 FIXED
TKTN SYSPAR 248. 00010500 LB0:-00000000000 FIXED
MCR... SYSPAR 160. 00033500 LB0:-00000000000 FIXED
TAST0 07.00 GEN 160. 00040300 LB0:-00000001607
F11ACP 07.00 GEN 149. 00011100 LB0:-00000001216
HRC... 05.00 GEN 140. 00042500 LB0:-00000002160
...MCR 07.00 GEN 160. 00040300 LB0:-00000001607
...MOU 26.06 GEN 160. 00045600 LB0:-00000001265
...DMO 04.02 GEN 160. 00017300 LB0:-00000002530
...SAV 11.00 GEN 100. 00071100 LB0:-00000001112
...INS 16.00 GEN 100. 00053200 LB0:-00000001352
...AT. 10.0 GEN 64. 00056700 LB0:-00000002357
...CON 05.00 GEN 50. 00135600 LB0:-00000002233
...PIP 21.00 GEN 50. 00036400 LB0:-00000002552
...BOO 03.10 GEN 50. 00047500 LB0:-00000002653
...HEL 06.00 GEN 50. 00031600 LB0:-00000002745
...BYE 05.01 GEN 50. 00021700 LB0:-00000003031
>
Еще образы...
RSXMP.DSK - RSX-11M-PLUS V4.6, сгенеренный под ДВК-4, ничего лишнего
RSXDVK.DSK - Baseline RSX-11M-PLUS V4.6
RSXUTL.DSK - Дополнительные утилиты (втыкается в MY1)
Все заточено под запуск в 256Kb памяти.
RSXDVK просто не пытается ничего делать из стартового файла - все руками. RSXMP подключает checkpoint file 180. блоков на MY0: ;)
RSXDVK требует входа в систему на втором терминале (SYSTEM без пароля), RSXMP просто запускает программку которая логинит второй терминал.
Обновленный вариант образа RSXUTL. Содержит правильно собранные ACFы как для baseline так и для специально собранной (образ RSXMP) системы. Интересно бы посмотреть что он наопределяет на ДВК :)
Это пожалуй последнее сообщение здесь по теме RSX на ВМ3. Тема немного переросла вопросы совместимости и пора ее выносить в отдельную :)
RSX-11M-PLUS V4.6 BL87 128.KW System:"RSXMPL"
>RED MY:=SY:
>RED MY:=LB:
>RED MY:=SP:
>MOU MY0:"RSX11MPBL87"
>@MY:[1,2]STARTUP
>ACS LB:/BLKS=180.
>CON ONLINE ALL
>RUN [1,127]FIXSYS
>* Please enter time and date (HH:MM DD-MMM-YYYY) [S]: 16:14:00 10-MAR-2012
>TIM 16:14:00 10-MAR-2012
>* Do you want to mount RSX11UTILS volume? [Y/N]: Y
>MOU MY1:RSX11UTILS/PUB
>ASN MY1:=LB1:/GBL
>INS LB1:$COTRES
>INS LB1:$PIPRES
>INS LB1:$RMD
>INS LB1:$BOO
>INS LB1:$DMPRES
>INS LB1:$VFYRES
>INS LB1:$BRO
>INS LB1:$BRU
>INS LB1:$DSC
>INS LB1:$ACO
>INS LB1:$ACF
>@ <EOF>
>ACF
>ACO SHO
Processor Type: 11/24 Memory Size: 128. Kw
Options:
Floating Point Processor (FP11)
Extended Instruction Set (EIS)
Extended (22-Bit) Addressing
Switch Register (SWR)
Display Register
Name Vector CSR Unit Type Remark
DMA 210 177440
0 RK07
1 RK07
DUA 154 172150
0 RA60
MUA 260 174500
0 TU81
LPA 200 177514
YLA 060 177560
>
Это пожалуй последнее сообщение здесь по теме RSX на ВМ3. Тема немного переросла вопросы совместимости и пора ее выносить в отдельную
все файлы с описаниями из последних постов по теме RSXDVK от forma пришпилены вот тут (https://archive.pdp-11.org.ru/ukdwk_archive/dwkwebcomplekt/RSXDVK/)
Контроллер последовательного порта выставляет бит готовности передатчика в тот момент, когда передаваемый байт поступает из ругистра данных в сдвиговый регистр и начинает передаваться в линию.
А сколько команд NOP уcпеет выполниться между отправкой первого байта в регистр данных и возникновением первого прерывания готовности вывода..
Ответ на этот вопрос должны дать тесты: PORT.SAV ( для стандартного порта терминала PDP-11 ) и PORT2.SAV ( для порта С2 УКНЦ ) (http://zx.pk.ru/attachment.php?attachmentid=39325).
В эмуляторе ДВК порт пока эмулируется неправлильно и выдаёт первое прерывание только после завершения передачи байта:
.RU PORT
Check SERIAL PORT 0177566 1st & 2nd Print INTERRUPT DELAY - v1.0
NOPs: 396
NOPs: 396
Program completed.
Контроллер последовательного порта выставляет бит готовности передатчика в тот момент, когда передаваемый байт поступает из ругистра данных в сдвиговый регистр и начинает передаваться в линию.
А сколько команд NOP уcпеет выполниться между отправкой первого байта в регистр данных и возникновением первого прерывания готовности вывода..
В УКНЦ программа PORT выдает и в первом и во втором случае около 30. Но тут стоит заметить, что терминальные порты не являются последовательными, а это один и тот же регистр, если со стороны ЦП доступный на запись, то со стороны ПП - на чтение. Быстродействие в данном случае определяется быстродействием программы в ПП.
А вот программа PORT2 выдала более интересные результаты. Если в первом случае колеблется от 3 до 7, то во втором - 600. Подтверждается теория, что буферный регистр и сдвиговый регистр - разные вещи. Если сдвиговый свободен, то буферный сразу же копируется в сдвиговый, после этого ставится бит готовности, и в буферный можно писать очередной байт.
Собственно объектами исследований были 1801ВП1-120 (терминальные порты 177560-177567) и 1801ВП1-065 (последовательные порты 176570-176577).
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot