Просмотр полной версии : Особенности процессоров и устройств архитектуры PDP-11. Тесты. Диагностика.
Страницы :
1
[
2]
3
4
5
6
7
8
9
10
Не нашел ни одной однотерминальной системы. Так, что могут быть ошибки.
Тест KDJ11-BF console SLU.
.RU PORT
Check SERIAL PORT 0177566 1st & 2nd Print INTERRUPT DELAY - v1.0
NOPs: 50
NOPs: 980
Program completed.
.
Хотя скорее всего не успеет :)
Тест KDJ11-BF console SLUВсё чётко!
Видно, что первое прерывание устанавливается посередине стартового бита первой посылки.
Всё чётко!
Видно, что первое прерывание устанавливается посередине стартового бита первой посылки.
Если там одно прерывание то поди не должно быть проблем. В многотерминальной по таймеру просто еще тест и фикс состояния регистров делается. Можно обойти - я где-то выкладывал способ универсальной работы с терминалом по регистрам независимо от системы, в том числе и независимо от SET TT CONSOL :)
Интересно, при любой ли скорости порта первое прерывание будет через 50 NOPов, или при сокращении продолжительности стартовго бита будет сокращаться и задержка первого прерывания..
Интересно, при любой ли скорости порта первое прерывание будет через 50 NOPов, или при сокращении продолжительности стартовго бита будет сокращаться и задержка первого прерывания..
Сейчас попробую разные скорости. Найду только описание как их выставлять...
В многотерминальной по таймеру просто еще тест и фикс состояния регистров делается.В первый интервал прерыванию таймера влезть сложно. В любом случае - несколько запусков теста легко позволит определить максимальные интервалы.
Максимальные - потому что считается разница указателя счётчика команд после пересылки байта в регистр и после прерывания, а "влезшие" прерывания эту разницу уменьшат.
Console SLU 38400.
.RU PORT
Check SERIAL PORT 0177566 1st & 2nd Print INTERRUPT DELAY - v1.0
NOPs: 13
NOPs: 227
Program completed.
.RU PORT
Check SERIAL PORT 0177566 1st & 2nd Print INTERRUPT DELAY - v1.0
NOPs: 14
NOPs: 227
Program completed.
.RU PORT
Check SERIAL PORT 0177566 1st & 2nd Print INTERRUPT DELAY - v1.0
NOPs: 13
NOPs: 227
Program completed.
.
---------- Post added at 22:51 ---------- Previous post was at 22:49 ----------
Можно еще ради интереса кэш отключить :)
Только читать придется документацию - никогда кэш не мучил.
Середина стартового бита ~ = [второе значение] / 20 ( отображаемое второе значение меньше общего числа команд из-за обработки первого прерывания ).
Можно еще ради интереса кэш отключитьСмысла большого нет - только точность измерения снизится.
Смысла большого нет - только точность измерения снизится.
Будет ближе к УКНЦам - NOPы будут из памяти читаться :)
программа PORT2 выдала более интересные результаты. Если в первом случае колеблется от 3 до 7, то во втором - 600. 1801ВП1-065 (последовательные порты 176570-176577).Получается, что ВП1-065 не в середине стартового бита готовность выставляет (как DL11-W), а в начале.
Тест прерываний из ТМОС, (насколько помню) тоже проверяет задержку между копированием байта в регистр данных терминала и прерыванием готовности вывода и сообщает об ошибке если эта задержка меньше заданной (какой именно - надо будет уточнить).
как DL11-W.
А ты где-то видел живой DL11-W? :)
На самом деле тест прерываний из ТМОС делает так:
MOV #0, 177566 ; 012226:000000 -> 177566
TSTB 177564 ; 177564: 000
BPL 012232
MOV #0, 177566 ; 012242:000000 -> 177566
BIS #64., 177564 ; 012250:000100 -> 177564:000000
CLR 013076 ; 013076:000000
MTPS 013076 ; 013076: 000 -> PSW :000004
WAITЕсли прерывание готовности вывода произойдёт до команды WAIT - тест сообщит об ошибке.
Т.е. на самом деле как раз учитывается, что первое прерывание происходит почти сразу - и задержка проверяется только после отправки в порт второго байта.
Похерилось сообщение...
Повторим результат:
Для очистки совести без многотерминальности:
.RU PORT
Check SERIAL PORT 0177566 1st & 2nd Print INTERRUPT DELAY - v1.0
NOPs: 48
NOPs: 980
Program completed.
.RU PORT
Check SERIAL PORT 0177566 1st & 2nd Print INTERRUPT DELAY - v1.0
NOPs: 53
NOPs: 982
Program completed.
.
И DLV11-J на всякий случай:
.RU PORT3
Check SERIAL PORT 0176506 1st & 2nd Print INTERRUPT DELAY - v1.0
NOPs: 1
NOPs: 960
Program completed.
.RU PORT3
Check SERIAL PORT 0176506 1st & 2nd Print INTERRUPT DELAY - v1.0
NOPs: 3
NOPs: 961
Program completed.
.RU PORT3
Check SERIAL PORT 0176506 1st & 2nd Print INTERRUPT DELAY - v1.0
NOPs: 6
NOPs: 961
Program completed.
.RU PORT3
Check SERIAL PORT 0176506 1st & 2nd Print INTERRUPT DELAY - v1.0
NOPs: 6
NOPs: 962
Program completed.
.
Более продвинутый контроллер последовательного порта начинает передачу стартового бита сразу после того, как процессор помещает выводимый байт в регистр данных. Пока передаётся стартовый бит - байт успевает скопироваться в сдвиговый регистр, поэтому готовность выставляется контроллером не в начале передачи стартового бита, а в середине.
Более простой контроллер сначала копирует байт из регистра данных в сдвиговый регистр и только затем начинает передавать стартовый бит. Из-за этого передача байта продолжается дольше (т.к. стартовый бит начинает передаваться не сразу), но прерывание готовности происходит раньше.
Казалось бы, что сложного может быть в контроллере последовательного порта.
Однако, какие удивительные открытия и тайные глубины..
Поправьте меня если где накосячил... Прога писалась после пары суток бессонницы и пива, а настроения пересматривать пока нет - есть уже другая задача ;)
Итак, решил проверить: сколько нопов успевает выполнить проц при разрешении прерываний экрана (в момент когда приемник готов принять символ) и после вывода символа до появления следующего прерывания. Я так понял, мы считали именно это.
Развесистые проги писать не стал, сделал все тупо и просто. Результаты совсем другие. Причем тест на E11 показывает, что количество нопов после вывода символа до прерывания в точности равно значению настройки количества инструкций на которые прерывание откладывается.
PS. На PDP-11 и E11 RESET останавливает таймер, на УКНЦ нужно отключать - прога не заботится о нем и в случае возникновения прерывания от таймера, оно въедет прямо в NOPы перед самым концом :)
.TITLE ITEST -- DL(V)11 INTERRUPT TEST
.IDENT /V01.00/
TKS == 177560 ;РЕГИСТРЫ КЛАВИАТУРЫ И ЭКРАНА
TKB == TKS+2 ;
TPS == TKS+4 ;
TPB == TPS+2 ;
CSR == 177564 ;ТЕСТИРУЕМЫЙ РЕГИСТР
VEC == 64 ;ЕГО ВЕКТОР
;CSR == 176504
;VEC == 304
START:: MOV #340,@#16 ;ПЕРЕКЛЮЧАЕМСЯ В РЕЖИМ ЯДРА
MOV #KERNL,@#14 ;...НА МЕТКЕ KERNL
BPT ;
;ПЕРВОЕ ПРЕРЫВАНИЕ (ПРИ РАЗРЕШЕНИИ ПРЕРЫВАНИЯ ГОТОВОМУ УСТРОЙСТВУ)
;
INT1:: MOV #INT2,@#VEC ;ПЕРЕКЛЮЧАЕМ ISR
MOV @SP,R5 ;СОХРАНЯЕМ PC C МЕСТА ПРЕРЫВАНИЯ
MOV #112737,TEST ;МЕНЯЕМ СТАРТОВЫЙ КОД НА
MOV #0,TEST+2 ;...MOVB #0,@#CSR+2
MOV #CSR+2,TEST+4 ;
MOV #TEST,@SP ;ПЕРЕХОДИМ КО ВТОРОМУ ТЕСТУ
RTI ;
;ВТОРОЕ ПРЕРЫВАНИЕ (ПОСЛЕ ВЫВОДА СИМВОЛА В ГОТОВОЕ УСТРОЙСТВО)
;
INT2:: MOV @SP,R4 ;СОХРАНЯЕМ PC С МЕСТА ПРЕРЫВАНИЯ
CLR @#CSR ;ЗАПРЕЩАЕМ ПРЕРЫВАНИЯ
CLR @#CSR+2 ;ОБНУЛЯЕМ УСТРОЙСТВО (НЕ ОСОБО НУЖНО)
SUB #NOPS,R4 ;СЧИТАЕМ КОЛИЧЕСТВО NOPОВ
SUB #NOPS,R5 ;
ASR R4 ;
ASR R5 ;
MOV R5,R1 ;ПЕЧАТАЕМ ПЕРВОЕ ЧИСЛО
CALL PRINT ;
MOV R4,R1 ;ПЕЧАТАЕМ ВТОРОЕ ЧИСЛО
CALL PRINT ;
CALL OUCHR ;ПЕЧАТАЕМ ДОПОЛНИТЕЛЬНЫЙ LF
TSTB @#TKS ;ЖДЕМ НАЖАТИЯ КЛАВИШИ
BPL .-4 ;
TSTB @#TKB ;ВЫЧИТЫВАЕМ КЛАВИШУ
BR KERNL ;ПЕРЕЗАПУСКАЕМ ТЕСТ
PRINT:: CLR R2 ;ПЕЧАТАЕМ ДЕСЯТИЧНОЕ ЧИСЛО
10$: CLR R0 ;...ИЗ R1
DIV #10.,R0 ;
ADD #'0,R1 ;
MOV R1,-(SP) ;
INC R2 ;
MOV R0,R1 ;
BNE 10$ ;
20$: MOV (SP)+,R0 ;
CALL OUCHR ;
SOB R2,20$ ;
MOV #15,R0 ;CR
CALL OUCHR ;
MOV #12,R0 ;LF
OUCHR:: TSTB @#TPS ;ЖДЕМ ГОТОВНОСТИ
BPL .-4 ;
MOVB R0,@#TPB ;ПЕЧАТАЕМ СИМВОЛ ИЗ R0
RETURN ;ВОЗВРАТ
KERNL:: RESET ;СБРОС ЖЕЛЕЗА
MOV #START,SP ;ВОЗВРАЩАЕМ СТЕК НА МЕСТО
MTPS #0 ;РАЗРЕШАЕМ ПРЕРЫВАНИЯ
MOV #52737,TEST ;ИНИЦИАЛИЗИРУЕМ СТАРТОВУЮ КОМАНДУ
MOV #100,TEST+2 ;...BIS #100,@#CSR
MOV #CSR,TEST+4 ;
MOV #NOPS,R0 ;ЗАПОЛНЯЕМ ПАМЯТЬ ОТ КОНЦА ПРОГРАММЫ
10$: MOV #240,(R0)+ ;...ДО 160000 NOPАМИ
CMP #160000,R0 ;
BNE 10$ ;
CLR -(R0) ;СТАВИМ HALT В КОНЦЕ НА ВСЯКИЙ СЛУЧАЙ
MOV #INT1,@#VEC ;УСТАНАВЛИВАЕМ ISR
MOV #340,@#VEC+2 ;...И ЕГО ПРИОРИТЕТ
TSTB @#CSR ;ЖДЕМ ГОТОВНОСТИ
BPL .-4 ;
TEST:: .BLKW 3 ;ЗАПУСК ТЕСТА:
;...1 ПРОХОД BIS #100,@#CSR
;...2 ПРОХОД MOVB #0,@#CSR+2
NOPS:: ;ДАЛЬШЕ ИДУТ NOPЫ
.END START
решил проверить: сколько нопов успевает выполнить проц при разрешении прерываний экрана (в момент когда приемник готов принять символ) и после вывода символа до появления следующего прерывания. Я так понял, мы считали именно это.PORT.SAV (http://zx.pk.ru/attachment.php?attachmentid=39325) первую позицию не считает ( её считают другие тесты - PDP-11 Interrupts Test #3 (http://zx.pk.ru/attachment.php?attachmentid=33157) и 1801VM1 Interrupts Test #1 (http://zx.pk.ru/attachment.php?attachmentid=24985) ).
Он считает вторую и "третью" позиции ( количество нопов после вывода первого и второго символов ).
Он считает вторую и "третью" позиции ( количество нопов после вывода первого и второго символов ).
Тогда все понятно.
Переделал слегка тест, вполне те же результаты.
---------- Post added at 20:31 ---------- Previous post was at 20:18 ----------
Проделал тест который хотел - запретил кэш.
Разница заметна.
Кэш запрещен. Console SLU:
.RU ITEST2
35
700
35
700
35
700
Кэш запрещен. DLV11-J:
.EX ITEST2
1
700
2
700
4
699
5
699
Кэш включен. Console SLU:
.EX ITEST2
52
990
54
990
52
990
54
990
52
990
Кэш включен. DLV11-J:
.EX ITEST2
4
970
6
971
6
970
6
971
6
971
Переделал слегка тестВыводить все три позиции тоже полезно - особенно для авторов эмуляторов, у которых чаще всего в первой позиции ноль (а значит - ошибка приёма вектора прерывания не эмулируется).
Выводить все три позиции тоже полезно - особенно для авторов эмуляторов, у которых чаще всего в первой позиции ноль (а значит - ошибка приёма вектора прерывания не эмулируется).
Сейчас придумаем что-нибудь поуниверсальнее и по информативнее.
Это была пристрелка :)
Лень приличную прогу делать - может позже дойдут руки - сделаю специальную оболочку для тестов...
Пока просто сделал чтобы выводил три позиции.
form, а какой вариант эмулятора UKNCBTL у Вас. У меня itest вылетает в СТОП
form, а какой вариант эмулятора UKNCBTL у Вас. У меня itest вылетает в СТОП
Таймер отключен? Программа не заботится о нем, а монитор затирает в памяти.
---------- Post added at 21:15 ---------- Previous post was at 21:14 ----------
Да, и в последней версии надо строчку определения CCR закоментировать - на УКНЦ кэша нету :)
Таймер отключен? Программа не заботится о нем, а монитор затирает в памяти.
И как его отключить? да и монитор на Вашем диске FB а у меня SJ. Как-то все недооформлено :)
И как его отключить? да и монитор на Вашем диске FB а у меня SJ. Как-то все недооформлено :)
Монитор пофигу - хоть ZM - прога не случайно манипуляции с режимом процессора проводит :)
Отключить - в эмуляторе View / Keyboard / УСТ / таймер / выключен / ИСП
---------- Post added at 21:22 ---------- Previous post was at 21:20 ----------
Может и проще можно - не изучал просто как клавиши мапятся :)
form, только константу комментить или вот этот кусочек тож
KERNL:: RESET
;.IF DF CCR
; BIS #FMISS,@#CCR
.ENDC
form, только константу комментить или вот этот кусочек тож
KERNL:: RESET
;.IF DF CCR
; BIS #FMISS,@#CCR
.ENDC
Определения хватит - здесь он проверяет есть ли оно.
А про то что заглушка нужна на СОМ порт тоже ни слова :)
А про то что заглушка нужна на СОМ порт тоже ни слова :)
Еще бы - ведь она не нужна :)
http://savepic.ru/3921669.png
! )
*********************
Кстати говоря если в UKNCBTL ставлю галочку на принтерный-порт сразу в стоп вылетает ! )
Если строчку
CMP #160000,R0
заменить на
CMP #100000,R0
то система портиться не будет.
...
А если в начале добавить
START:: CLR @#0
CLR @#4
CLR @#10
MOV #2, @#102
MOV #102, @#100
то не надо будет выключать таймер и можно будет запускать на реальной УКНЦ.
.TITLE ITEST -- DL(V)11 INTERRUPT TEST
.IDENT /V01.00/
;CCR == 177746
FMISS == 14
TKS == 177560
TKB == TKS+2
TPS == TKS+4
TPB == TPS+2
CSR == 177564
VEC == 64
;CSR == 176504
;VEC == 304
START:: CLR @#0
CLR @#4
CLR @#10
MOV #2, @#102
MOV #102, @#100
MOV #340,@#16
MOV #KERNL,@#14
BPT
INT0:: MOV #INT1,@#VEC
MOV @SP,R5
MOV #112737,TEST
MOV #0,TEST+2
MOV #CSR+2,TEST+4
MOV #TEST,@SP
RTI
INT1:: MOV #INT2,@#VEC
MOV @SP,R4
MOV #TEST,@SP
RTI
INT2:: MOV @SP,R3
CLR @#CSR
CLR @#CSR+2
SUB #NOPS,R3
SUB #NOPS,R4
SUB #NOPS,R5
ASR R3
ASR R4
ASR R5
MOV R5,R1
CALL PRINT
MOV R4,R1
CALL PRINT
MOV R3,R1
CALL PRINT
CALL OUCHR
TSTB @#TKS
BPL .-4
TSTB @#TKB
BR KERNL
PRINT:: CLR R2
10$: CLR R0
DIV #10.,R0
ADD #'0,R1
MOV R1,-(SP)
INC R2
MOV R0,R1
BNE 10$
20$: MOV (SP)+,R0
CALL OUCHR
SOB R2,20$
MOV #15,R0
CALL OUCHR
MOV #12,R0
OUCHR:: TSTB @#TPS
BPL .-4
MOVB R0,@#TPB
RETURN
KERNL:: RESET
.IF DF CCR
BIS #FMISS,@#CCR
.ENDC
MOV #START,SP
MTPS #0
MOV #52737,TEST
MOV #100,TEST+2
MOV #CSR,TEST+4
MOV #NOPS,R0
10$: MOV #240,(R0)+
CMP #100000,R0
BNE 10$
CLR -(R0)
MOV #INT0,@#VEC
MOV #340,@#VEC+2
TSTB @#CSR
BPL .-4
TEST:: .BLKW 3
NOPS::
.END START
http://savepic.ru/3906311.png
Исходник теста (C) by [form] (http://zx.pk.ru/attachment.php?attachmentid=39498&d=1359036416)
---------- Post added at 19:26 ---------- Previous post was at 19:01 ----------
цифорка по центру скачет сильно то 17 то 54 то 49 то зацикливается на 17 - это нормально для эмулятора? )
Выводить все три позиции тоже полезно - особенно для авторов эмуляторов, у которых чаще всего в первой позиции ноль (а значит - ошибка приёма вектора прерывания не эмулируется
А можно подробнее, особенно вот эта фраза "ошибка приёма вектора прерывания не эмулируется".
А можно подробнее, особенно вот эта фраза "ошибка приёма вектора прерывания не эмулируется".Из-за того, что обработка запроса IRQ начинается процессорами LSI-11 только через одну команду после выставления запроса IRQ устройством - если в этот промежуток запрос IRQ устройством будет снят - начатая процессором обработка запроса IRQ тем не менее продолжится, что неминуемо приведёт к специальной ошибке LSI-11 зависание при приёме вектора прерывания.
Подробнее раньше в этой же теме: Что проверяет PDP-11 Interrupts Test #4 .. (http://zx.pk.ru/showthread.php?postid=468955)
Из-за того, что обработка запроса IRQ начинается процессорами LSI-11 только через одну команду после выставления запроса IRQ устройством - если в этот промежуток запрос IRQ устройством будет снят - начатая процессором обработка запроса IRQ тем не менее продолжится, что неминуемо приведёт к специальной ошибке LSI-11 зависание при приёме вектора прерывания.
На ВМ2 так же?
А если такая ситуация, прерывания были запрещены, внешнее устройство дало запрос на прерывание. Потом процессор разрешил прерывания, и в этот же момент внешнее устройство запрос сняло. Будет такая же ошибка?
На ВМ2 так же?
Да вроде пока только на ВМах и обнаружено. В обычных процах это нормальная ситуация, не являющаяся ошибкой (что документировано). :)
На ВМ2 так же?
Полностью аналогично.
А если такая ситуация, прерывания были запрещены, внешнее устройство дало запрос на прерывание. Потом процессор разрешил прерывания, и в этот же момент внешнее устройство запрос сняло. Будет такая же ошибка?
Смотря в какой момент.
А на самом деле легко получается так. Скажем в регистре терминала 177564 стоит бит готовности, прерывания разрешены. Если установить бит разрешения прерывания, а следующей командой его сбросить, то возникнет ошибка приема адреса вектора прерывания.
На ВМ3 интересно проверить - возможно на многоуровневых это норма, а на одноуровневых нет.
Смотря в какой момент.
В какой-нибудь момент можно? Чтобы началась обработка и испортилась?
В какой-нибудь момент можно? Чтобы началась обработка и испортилась?
Так уже пробовали на УКНЦе вроде: BIS #100,@#177564, BIC #100,@#177564
Так уже пробовали на УКНЦе вроде: BIS #100,@#177564, BIC #100,@#177564
Нет, чтобы не нарочно, а случайно получилось.
Если установить бит разрешения прерывания, а следующей командой его сбросить, то возникнет ошибка приема адреса вектора прерывания.Но это не самый кайф.
Нет, чтобы не нарочно, а случайно получилось.
Самый кайф - запрещать прерывания в регистре статуса терминала, когда RT-11 ещё передаёт байты - тогда при одном запуске из ~ 1000 программа поймает ЗПВП ( так делают многие неопытные программисты, хотя по-правильному надо просто ждать, пока RT-11 сама сбросит бит 0100 в регистре статуса после вывода строки на экран ).
Нет, чтобы не нарочно, а случайно получилось.
Так может и такого давно видели кучу, только отнесли к разряду "прога не работает" :)
В какой-нибудь момент можно? Чтобы началась обработка и испортилась?
Пример момента я привел выше.
А так при запрете прерываний по 7 биту PSW они все равно фиксируются процессором после обработки команды, только если стоит 7-й бит в PSW, то прерывания не происходит.
А если при разрешении прерываний еще и какое-нибудь устройство сбрасывает запрос, то это сложно представить.
Самый кайф - запрещать прерывания в регистре статуса терминала
Просто запрещать хоть дождавшись хоть нет - ошибка - это в принципе может не работать. Строго говоря, ни одной проги (включая здесь на форуме) не видел которая бы правильно делала :)
если при разрешении прерываний еще и какое-нибудь устройство сбрасывает запрос, то это сложно представить.Но легко представить программиста, сбрасывающего бит 0100 в регистре статуса терминала, когда RT-11 ещё не закончила вывод строки на экран.
Но легко представить программиста, сбрасывающего бит 0100 в регистре статуса терминала, когда RT-11 ещё не закончила вывод строки на экран.
Когда вывод закончится - сбрасывать не понадобится. А если его именно сбросили - вывод как раз и не закончился :)
А если его именно сбросили - вывод именно не закончилсяИ эта чисто эстетическая (с виду) проблема один раз на ~ 1000 попыток сопровождается потерей вектора.
---------- Post added at 22:46 ---------- Previous post was at 22:44 ----------
Причём, если "затирается" именно последнее прерывание после вывода последнего байта в строке - "на вид" это никак определить нельзя.
Нет вообще никакого смысла отключать прерывания экрана в RT-11. В принципе. Это сделает система, а программе надо просто дождаться этого и ничего не сбрасывать.
---------- Post added at 02:49 ---------- Previous post was at 02:48 ----------
Но, возвращаясь к исходному вопросу, есть же у нас тут народ с ВМ3 - интересно было бы там попробовать. Подозреваю, что там ситуация с запуском прерывания и недоведением его до конца - нормальное явление.
Но легко представить программиста, сбрасывающего бит 0100 в регистре статуса терминала, когда RT-11 ещё не закончила вывод строки на экран.
Titus, как я понял, имел ввиду другое - если прерывания разрешили (по MTPS #0, или после RTI), а во время исполнения этой команды устройство сняло запрос на прерывание.
Такое на УКНЦ в принципе можно представить - есть каналы обмена К0, К1, К2. Если мы пишем в регистр канала 0 177566 что нибудь, а потом исполняем RESET, то по идее с той стороны прерывание сбрасывается. Теоретически со стороны ПП может возникнуть ошибка приема АВП.
Подозреваю, что достаточно хороший пример всевозможных гадостей с прерываниями - контроллер WD который свои прерывания запускает играясь с сигналами питания CPU :)
---------- Post added at 02:56 ---------- Previous post was at 02:55 ----------
Правда там скорее всего кроме потерь ничего не грозит.
Подозреваю, что достаточно хороший пример всевозможных гадостей с прерываниями - контроллер WD который свои прерывания запускает играясь с сигналами питания CPU :)
Правда там скорее всего кроме потерь ничего не грозит.
Потери АВП при приеме бывают только при векторном прерывании по сигналу VIRQ. Прерывание по аварии источника питания (вектор 24) для процессора внутреннее, вектор он получает из блока констант. К тому же сбросить это прерывание можно только двумя способами - удовлетворить его или сбросить процессор по сигналу DCLO. По команде RESET этот запрос не сбрасывается.
Речь не о том. Просто я так думаю, что эмуляция прерываний сбоем питания может вызвать потери других прерываний. Или нет?
Titus, как я понял, имел ввиду другое - если прерывания разрешили (по MTPS #0, или после RTI), а во время исполнения этой команды устройство сняло запрос на прерывание.Мы это всё (и даже гораздо больше) тестировали начиная с середины 5-й страницы этой темы и дальше. Общий вывод такой - если запрос IRQ был выставлен не во время предыдущей команды - проблем быть не может. Разрешение/запрет прерываний никак на выставление запросов IRQ не влияет.
Совершенно всё равно, какая команда была исполнена перед BIC #100, @#TPS. Если запрос IRQ был выставлен именно тогда и прерывания сейчас разрешены - будет потеря вектора.
BIC #100, @#TPS[
Завтра попробую с ВМ3 кого-нибудь попросить проверить...
Речь не о том. Просто я так думаю, что эмуляция прерываний сбоем питания может вызвать потери других прерываний. Или нет?
Нет не вызывает. Прерывание по сбою питания высокоприоритетное и в режиме USER немаскируемое. Ведь все остальные устройства также будут требовать прерывания по линии VIRQ. По приоритету сначала исполнится сбой питания, а уж затем дойдет дело до VIRQ.
Вот ещё результаты тестов на эту тему:
BIS #100,@#TTPS
MTPS #340
NOP
MTPS #0
>>> Interrupt <<<
NOP
BIS #100,@#TTPS
MTPS #340
BIC #100,@#TTPS
MTPS #0
NOP
BIS #100,@#TTPS
MTPS #340
MTPS #0
>>> Interrupt <<<
BIC #100,@#TTPS
Вот ещё результаты тестов на эту тему:
BIS #100,@#TTPS
MTPS #340
NOP
MTPS #0
>>> Interrupt <<<
NOP
BIS #100,@#TTPS
MTPS #340
BIC #100,@#TTPS
MTPS #0
NOP
BIS #100,@#TTPS
MTPS #340
MTPS #0
>>> Interrupt <<<
BIC #100,@#TTPS
Ну в данных примерах и не должна возникнуть ошибка приема АВП.
Или Titus имел в виду такие "коварные" устройства, которые сами снимают IRQ без "внешней" причины в виде команды процессора ( типа RESET или BIC #100,@#TPS ). Но я про такие устройства ничего не знаю. Бывает такое у реальных устройств ?
Или Titus имел в виду такие "коварные" устройства, которые сами снимают IRQ без "внешней" причины в виде команды процессора ( типа RESET или BIC #100,@#TPS ). Но я про такие устройства ничего не знаю. Бывает такое у реальных устройств ?
UNIBUSные возможно есть - встречал в описаниях что-то про такое.
---------- Post added at 03:18 ---------- Previous post was at 03:15 ----------
Вот кстати что в доке по KDJ11 написано (может я уже приводил):
1.3.5 Interrupt Vector Timeouts
An interrupt vector timeout occurs if the BRPLY L bus signal is not asserted within 10 μseconds after the KDJ11-B acknowledges an interrupt by asserting the BIAK L bus signal. The timeout is ignored by the KDJ11-B and it continues as if the interrupt request did not occur. In a Unibus system, the KDJ11-B does not time out, but relies on the Unibus adapter module to assert the PMI timeout signal.
Или Titus имел в виду такие "коварные" устройства, которые сами снимают IRQ без "внешней" причины в виде команды процессора ( типа RESET или BIC #100,@#TPS ). Но я про такие устройства ничего не знаю. Бывает такое у реальных устройств ?
Вот я тоже понял так, именно про "коварные" устройства. Выше я приводил пример с каналами УКНЦ, где такое теоретически может быть. Но у меня не получилось. Я запускал такой код:
MOV #41,@#177566
NOP
...
NOP
RESET
HALT
Количество NOP-ов было разным. Когда их было мало, то символ "!" просто не выводился, при 8-ми и более NOP-ах выводился, ошибку приема АВП со стороны ПП получить не удалось.
А кстати BIS, BIC #100 не пробовалось на чистом устройстве вроде С2?
А кстати BIS, BIC #100 не пробовалось на чистом устройстве вроде С2?
Попробовал. Как и должно быть - вылетел в пультовый монитор с ошибкой приема АВП.
Надо УКНЦу восстанавливать, а то пробовать такие вещи не на чем...
Эх, время б только найти.
Проверен ВМ3 на предмет
BIS #100,@#177564
BIC #100,@#177564
- вылетает как и другие ВМы...
Утилитка для поиска DL(V)11-подобных контроллеров. В отличие от DECовских, находит все даже если нарушены правила размещения CSR (УКНЦ, ДВК).
На эмуляторе УКНЦ С2 как видно не желает интерруптить :)
В свете последних событий, связанных с интересом к ошибке приема адреса вектора прерывания, реализованной в процессорах семейства 1801ВМх, решил потестировать в УКНЦ такое устройство, как ловушка адреса, и попытаться с помощью него получить ошибку приема АВП. Сразу скажу заранее, что ошибку приема АВП мне получить не удалось, но интересные результаты, связанные с предвыборкой команд в микропроцессоре 1801ВМ2 получил. На ваш суд будут представлены четыре программы, различающиеся только командами установки и сброса разрешения прерывания для регистра ловушки. Отличаться эти команды будут тем, что будут состоять из одного или нескольких слов. Если команда состоит из нескольких слов, то нарушается работа предвыборки, если команда состоит из одного слова, то предвыборка будет работать на следующую команду при исполнении текущей.
Итак, сначала познакомимся с ловушкой адреса в УКНЦ. Ловушка адреса состоит из двух регистров: регистра управления (176644) и регистра адреса для ловушки (176646).
Формат регистра управления:
бит 0 - режим работы, если установлен бит 8, то при установленном разряде 0 вырабатывается прерывание, при сброшенном разряде вырабатывается лог.0 на линии "ПОРТ" и сигнал RPLY.
бит 1 - указатель области памяти, которой принадлежит искомый адрес: 1 - область HALT, 0 - область USER.
биты с 2 по 7 - старшая часть адреса вектора прерывания, младшие два разряда считаются нулем.
бит 8 - разрешение прерывания. При установленном разряде разрешено прерывание или выработка сигнала "ПОРТ".
бит 9 - режим 1. Обеспечивает чтение/запись линии РЕЖ.1, лог.1. - низкий уровень на РЕЖ.1, лог.0 - высокий уровень на РЕЖ.1. Считываемое значение складывается по ИЛИ из значения записанного сигнала и значения приложенного извне к линии РЕЖ.1.
В регистр адреса (176646) записывается искомый адрес, который мы ловим.
Сами регистры ловушки входят в состав БМК 1515ХМ1-039, которая является контроллером адресного пространства ЦП и ОЗУ ЦП. Смысл ловушки состоит в том, что когда на линии адреса/данных по сигналу SYNC защелкивается адрес, который прописан в регистре 176646, то ловушка подает запрос на прерывание при установленных битах 0 и 8 в регистре 176644.
Т.к. чтение команд в микропроцессоре 1801ВМ2 может осуществляться с предвыборкой, то можно получить интересные результаты. Итак, программа работает с разрешенными прерываниями (а иначе не было бы смысла), таймер выключен. В качестве вектора программируем вектор 200, при этом он указывает на ячейку 0, а в ячейке 0 - значение 0 (команда HALT). Таким образом программа может завершиться нормально или остановится с адресом 2 (следующий за командой HALT). Соответственно для разрешения прерывания ловушки надо в регистр управления записать 0601, а для запрещения прерываний записать 0200. Сами программы набивались в пультовом мониторе, мне это удобно, программы небольшие, можно сразу увидеть результат, глянуть регистры, ячейки памяти, что творится в стеке. После прерывания адрес прерванной команды находится в стеке в ячейке с адресом 774.
Программа 1. Используются команды установки и запрещения прерываний ловушки, состоящие из нескольких слов, в результате чего работа предвыборки нарушена.
1000:106427 000000 MTPS #0
1004:012706 001000 MOV #1000,SP
1010:012737 ...... 176646 MOV #......,@#176646
1016:012737 000601 176644 MOV #601,@#176644
1024:012737 000200 176644 MOV #200,@#176644
1032:000240 NOP
1034:000240 NOP
1036:000000 HALT
Вместо "......" последовательно используются значения 1022, 1024, 1026, 1030 и 1032, т.е. используются адреса команды сброса прерывания в регистре ловушки, а также по одному адресу до и после этой команды.
Получившиеся результаты:
1022 - нет прерывания
1024 - прерывание по адресу 1032
1026 - прерывание по адресу 1032
1030 - прерывание по адресу 1032
1032 - нет прерывания
Сразу по результатам. Естественно прерывания по адресу 1022 и быть не может, т.к. после установки разрешения прерывания этот адрес уже был прочитан, работа предвыборки нарушена и следующим будет читаться адрес 1024. По адресам 1024,1026 и 1030 расположена команда MOV #200,@#176644, которая запрещает прерывание от ловушки. Команда состоит из нескольких слов, из-за чего нарушается предвыборка, но при ее исполнении активизируется прерывание и исполняется после исполнения команды, несмотря на то, что команда запрещает прерывание. По адресу 1032 естественно прерывания уже нет, т.к. работа предвыборки нарушена, команда NOP по адресу 1032 будет уже читаться не во время, а после исполнения предыдущей команды, а прерывания от ловушки уже запрещены.
---------- Post added at 21:05 ---------- Previous post was at 20:37 ----------
Программа 2. Используется команды установки прерывания ловушки из нескольких слов, а запрещения прерываний ловушки из одного слова, в результате чего работа предвыборка работает на команду NOP, расположенной после команды запрещения прерываний ловушки.
1000:106427 000000 MTPS #0
1004:012706 001000 MOV #1000,SP
1010:012700 176644 MOV #176644,R0
1014:012702 000601 MOV #601,R2
1020:012703 000200 MOV #200,R3
1024:012737 ...... 176646 MOV #......,@#176646
1032:012737 000601 176644 MOV #601,@#176644
1040:010310 MOV R3,@R0
1042:000240 NOP
1044:000240 NOP
1046:000000 HALT
Вместо "......" последовательно используются значения 1036, 1040, 1042 и 1044, т.е. используются адреса команды сброса прерывания в регистре ловушки, а также по одному адресу до и после этой команды.
Получившиеся результаты:
1036 - нет прерывания
1040 - прерывание по адресу 1042
1042 - прерывание по адресу 1042
1044 - нет прерывания
Рассмотрим результаты. По адресу 1036 прерывания и быть не может, т.к. после установки разрешения прерывания этот адрес уже прочитан. После установки разрешения прерывания командой MOV #601,@#176644 работа предвыборки нарушена и следующая команда будет считываться уже после исполнения предыдущей. Так команды запрета прерываний MOV R3,@R0 считывается при установленном разрешении прерываний, то и прерывание по адресу 1040 будет (хотя она и запрещает прерывания). А далее более интересный случай - команда запрещения прерывания MOV R3,@R0 состоит из одного слова, соответственно работа предвыборки не нарушена, и следующая команда NOP читается во время ее исполнения (т.е. когда фактически прерывания разрешены), поэтому прерывание произойдет. По адресу 1044 уже не будет прерывания, т.к. команда читается во время исполнения предыдущей команды NOP, а прерывания уже запрещены.
---------- Post added at 21:20 ---------- Previous post was at 21:05 ----------
Программа 3. Используется команды установки прерывания ловушки из одного слова, а запрещения прерываний ловушки из нескольких слов, в результате чего предвыборка работает на команду запрещения прерываний ловушки, и не работает на первую команду NOP.
1000:106427 000000 MTPS #0
1004:012706 001000 MOV #1000,SP
1010:012700 176644 MOV #176644,R0
1014:012702 000601 MOV #601,R2
1020:012703 000200 MOV #200,R3
1024:012737 ...... 176646 MOV #......,@#176646
1032:010210 MOV R2,@R0
1034:012737 000200 176644 MOV #200,@#176644
1042:000240 NOP
1044:000240 NOP
1046:000000 HALT
Вместо "......" последовательно используются значения 1032, 1034, 1036, 1040, 1042 и 1044 т.е. используются адреса команды сброса прерывания в регистре ловушки, а также по одному адресу до и после этой команды.
Получившиеся результаты:
1032 - нет прерывания
1034 - нет прерывания
1036 - прерывание по адресу 1042
1040 - прерывание по адресу 1042
1042 - нет прерывания
1044 - нет прерывания
Рассмотрим результаты. Соответственно по адресу 1032 не может быть прерывания, т.к. команда установки уже прочитана из памяти до установки разрешения прерывания. А вот далее работает предвыборка. Т.к. команда установки разрешения прерывания MOV R2,@R0 состоит из одного слова и не нарушает работу предвыборки, первое слово команды запрещения прерывания от ловушки MOV #200,@#176644 будет прочитано еще до установки разрешения прерывания, потому по адресу 1034 прерывания и не произойдет. По адресам 1036 и 1040 прерывание будет, т.к. они читаются при установленном разрешении прерывания от ловушки. Команда NOP по адресу 1042 читается при запрещенном прерывании то ловушки, к тому же предвыборка нарушена, соответственно код команды будет читаться из памяти при запрещенном прерывании от ловушки и прерывания не будет. Также не будет прерывания и по адресу 1044.
Программа 4. Используется команды установки и запрещения прерываний ловушки из одного слова, в результате чего работа предвыборки не нарушается, также предвыборка работает и на команду NOP, расположенную после команды запрещения прерываний ловушки.
1000:106427 000000 MTPS #0
1004:012706 001000 MOV #1000,SP
1010:012700 176644 MOV #176644,R0
1014:012702 000601 MOV #601,R2
1020:012703 000200 MOV #200,R3
1024:012737 ...... 176646 MOV #......,@#176646
1032:010210 MOV R2,@R0
1034:010310 MOV R3,@R0
1036:000240 NOP
1040:000240 NOP
1042:000000 HALT
Вместо "......" последовательно используются значения 1032, 1034, 1036 и 1040, т.е. используются адреса команды сброса прерывания в регистре ловушки, а также по одному адресу до и после этой команды.
Получившиеся результаты:
1032 - нет прерывания
1034 - нет прерывания
1036 - прерывание по адресу 1036
1040 - нет прерывания
Рассмотрим результаты. Соответственно по адресу 1032 не может быть прерывания, т.к. команда установки уже прочитана из памяти до установки разрешения прерывания. А вот далее работает предвыборка. Т.к. команда установки разрешения прерывания MOV R2,@R0 состоит из одного слова и не нарушает работу предвыборки, следующая команда запрещения прерывания от ловушки MOV R3,@R0 будет прочитана еще до установки разрешения прерывания, потому по адресу 1034 прерывания и не произойдет. Команда NOP по адресу 1036 читается во время исполнения команды запрещения прерываний ловушки (т.е. когда фактически прерывания разрешены), поэтому прерывание произойдет. По адресу 1040 уже не будет прерывания, т.к. команда читается во время исполнения предыдущей команды NOP, а прерывания уже запрещены.
Теперь можно взять Программу 2 и подставить команду RESET сначала по адресу 1040, а потом 1042.
ошибку приема АВП мне получить не удалосьСнимает устройство запрос IRQ после сброса разрешения прерывания или нет - зависит только от устройства.
Если снимает - у процессоров LSI-11 и 1801ВМх должна быть потеря вектора (насколько я понимаю).
А вот по сигналу INIT ( команде RESET ) - IRQ должны снимать все устройства (в моём, опять же, понимании работы шины Q-Bus).
Снимает устройство запрос IRQ после сброса разрешения прерывания или нет - зависит только от устройства.
Если снимает - у процессоров LSI-11 и 1801ВМх должна быть потеря вектора (насколько я понимаю).
А вот по сигналу INIT ( команде RESET ) - IRQ должны снимать все устройства (в моём, опять же, понимании работы шины Q-Bus).
Я еще кое в чем не дотестировал ловушку адреса, там есть еще очень интересные моменты. Но по очистке бита прерывания, если уже был зафиксирован запрос на прерывание, то он не очищается, потому и не было ошибки приема АВП.
Если запросы на прерывания снимают командой RESET, то тут уже никак не возникнет ошибка приема АВП, т.к. должны снимать все запросы устройства на шине QBUS, чистится регистр запросов на прерывание внутри процессора (в 1801ВМ2 по RESET запрос по сбою питания не очищается), плюс к тому же сигнал INIT висит несколько сотен тактов, все переходные процессы во всех устройствах успеют завершиться.
Дополнительный отчет по ловушке будет попозже, очень интересные моменты есть, надо их рассмотреть поподробней.
Утилитка для поиска DL(V)11-подобных контроллеров. В отличие от DECовских, находит все даже если нарушены правила размещения CSR (УКНЦ, ДВК).
А можно на исходники глянуть?
А можно на исходники глянуть?
Можно :)
При желании можно дополнить тестом нопов или еще чем.
Можно и упростить - к примеру проверка на TSX особо не нужна так как в TSX всегда "foreground loaded" :)
Можно и упроститьВ данном конкретном случае коллектив авторов эмулятора УКНЦ имеет целью подружить эмулятор с данным тестом.
В данном конкретном случае коллектив авторов эмулятора УКНЦ имеет целью подружить эмулятор с данным тестом.
Для этого надо всего лишь интерруптиться как обычные DLки :)
---------- Post added at 19:02 ---------- Previous post was at 19:01 ----------
Типа, чтобы вектор у портов С2 и СА начал определяться.
Все, что нужно - это чтобы при установке 6 бита в CSR трансмитера возникало прерывание.
Для этого надо всего лишь интерруптиться как обычные DLкиНе берусь учить других писать эмуляторы последовательных портов, но на мой взгляд - особых хитростей в правильной эмуляции прерываний там нет.
Не берусь учить других писать эмуляторы последовательных портов, но на мой взгляд - особых хитростей в правильной эмуляции прерываний там нет.
Я в свое время когда С2 только появился в эмуляторе натолкнулся на то, что прерывания не работали. Видимо до конца вопрос не решен :)
Хотя, для тех кто не верит, что можно написать программу, которая после каждого нажатия пользователем на клавишу будет вызывать 10 прерываний готовности ввода и только потом читать пришедший байт - такой "тест" вполне можно написать.
А то кто его знает - может в половине эмуляторов только выходные порты ставят IRQ как надо (по AND битов готовности и разрешения прерываний), а входные халтурят. Типа, ставят IRQ лишь при приходе нового байта с клавиатуры при установленном разрешении прерываний, а при установке бита разрешения прерываний у готового утройства - нет.
Хотя, для тех кто не верит, что можно написать программу, которая после каждого нажатия пользователем на клавишу будет вызывать 10 прерываний готовности ввода и только потом читать пришедший байт - такой "тест" вполне можно написать.
А то кто его знает - может в половине эмуляторов только выходные порты ставят IRQ как надо (по AND битов готовности и разрешения прерываний), а входные халтурят. Типа, ставят IRQ лишь при приходе нового байта с клавиатуры при установленном разрешении прерываний, а при установке бита разрешения прерываний у готового утройства - нет.
Данный тест проверяет как раз передатчик. Когда я тестировал С2 (давно) в эмуляторе, он интерруптился не по готовности, а по записи символа в передатчик. Как сейчас лень смотреть.
Смейтесь смейтесь... прерывания там есть и они в искуственно созданной ситуации вполне себе работают, причина где-то в другом месте.
form, если не сложно, объясните словами алгоритм проверки прерывания в вашем тесте, в частности если я правильно увидел используется прерывание от таймера.
Данный тест проверяет как раз передатчик.Это я на будущее. Ведь, если исправить эмуляцию прерывания вывода, но не исправить эмуляцию прерывания ввода - "эмуляторная засада" может стать только глубже.
Смейтесь смейтесь... прерывания там есть и они в искуственно созданной ситуации вполне себе работают, причина где-то в другом месте.
form, если не сложно, объясните словами алгоритм проверки прерывания в вашем тесте, в частности если я правильно увидел используется прерывание от таймера.
Алгоритм простой: передатчику терминала устанавливается разрешение прерывания после чего выполняется некоторый цикл ожидания, дочтаточный для возникновения прерывания при наличии готовности передатчика (которая обязана наступить независимо от того подключено что-то к устройству или нет). При этом постепенно понижается приоритет процессора (для УКНЦ собственно вариантов нет - так только 4 и 0 бывают).
При этом постепенно понижается приоритет процессораТипа, если порт выставил IRQ при запрещённых прерываниях - эмулятор его теряет..
Смейтесь смейтесь... прерывания там есть и они в искуственно созданной ситуации вполне себе работают, причина где-то в другом месте.
Vamos, внимательно почитайте, что писал Patron. Он написал абсолютно правильно, что запрос на прерывание возникает, когда предыдущее состояние бита готовности и бита разрешения прерывания по AND было равно нулю, а текущее стало равно единице.
В конце концов посмотрите эмуляцию канала К0 со стороны ЦП (регистры 177560-177566), они по алгоритму установки/снятия запроса на прерывание работают аналогично 1801ВП1-065.
Типа, если порт выставил IRQ при запрещённых прерываниях - эмулятор его теряет..
Не похоже.
Я ради интереса собрал VDT как программу и из него разрешил прерывания. Должен был произойти мгновенный .EXIT так как в векторе 0, а он даже не почесался...
Не похоже.Это был последний релиз эмулятора (http://zx.pk.ru/attachment.php?attachmentid=39543) ?
Вот собственно демонстрация. VDT работает на уровне программы с приоритетом 0. Прерывания не произошло ни при включении прерываний (при наличии готовности) ни при записи в порт...
Это был последний релиз эмулятора (http://zx.pk.ru/attachment.php?attachmentid=39543) ?
По размеру другой, хотя выбирал последнюю версию.
В любом случае с этим точно также все.
В конце концов посмотрите эмуляцию канала К0 со стороны ЦП (регистры 177560-177566), они по алгоритму установки/снятия запроса на прерывание работают аналогично 1801ВП1-065.
Смотрел я туда уже, если Вы думаете что копаться в исходниках которые не сам писал, да еще с моими познаниями в программировании на С++ (я даже книжки не одной не читал)... Кому то понятно что написал Patron, а мне нужно разложить подробно по полочкам, пока я не до конца понимаю как это происходит.
В любом случае с этим точно также все.И даже при записи в порт нет IRQ ?
У этого релиза при записи в порт прерывание должно быть.
И даже при записи в порт нет IRQ ?
У этого релиза при записи в порт прерывание должно быть.
Проверил - нету.
Правда я не конфигурил COM порт.но это не должно влиять.
UPD: сконфигурил - ничего не изменилось. Разьве что готовность исчезла навсегда :)
готовность исчезла навсегдаЭто правильно или нет?
По идее ВП1-065 должен останавливать передачу при отсутствии сигнала RTS.
Это правильно или нет?
По идее ВП1-065 должен останавливать передачу при отсутствии сигнала RTS.
Не силен в этом, но отсутствие провода в разъеме вроде как присутствие. Еще на терминалах натыкался - с тех пор нульмодемный кабель выкинул и пользуюсь обычным для DLек.
В UKNCBTL запись в порт 0176574 обрабатывается так:
void CFirstMemoryController::SetPortWord(WORD address, WORD word)
{
switch (address) {
case 0176574: // Стык С2: Регистр состояния источника
case 0176575: // Bits 0,2,6
m_Port176574 = (m_Port176574 & ~0105) | (word & 0105);
break;
case 0176576: // Стык С2: Регистр данных источника
case 0176577: // нижние 8 бит доступны по записи
m_Port176576 = word & 0xff;
m_Port176574 &= ~128; // Reset bit 7 (Ready)
break;
}
}
А нужно так:
void CFirstMemoryController::SetPortWord(WORD address, WORD word)
{
switch (address) {
case 0176574: // Стык С2: Регистр состояния источника
case 0176575: // Bits 0,2,6
if(((m_Port176574 & 0300) == 0200) && (word & 0100))
{
m_pCPU->InterruptVIRQ(8, 0374);
}
m_Port176574 = (m_Port176574 & ~0105) | (word & 0105);
break;
case 0176576: // Стык С2: Регистр данных источника
case 0176577: // нижние 8 бит доступны по записи
m_Port176576 = word & 0xff;
m_Port176574 &= ~128; // Reset bit 7 (Ready)
break;
}
}
Точно так же нужно изменить обработку всех остальных 3-х регистров статуса ( приёмник С2, приёмник СА, передатчик СА ), учитывая, что адреса векторов и место IRQ в цепочке приоритетов там другие ( для С2 - приемник 7, передатчик 8, для СА - приемник 9, передатчик 10 ).
offtop
Patron, уже предвкушаю (когда до дела дойдёт) какая будет правильная виртуальная УК-НЦ от Patrona ! ) Вот бы чуток в будущее отмотать, скачать и выложить тут - типа вот ребята - вот так короче всё будет )))
ИМХО: пока я не увидел первый исходник на Си - я думал, что Ассемблер(МАКРО-11) страшный и непонятный )))
Точно так же нужно изменить обработку всех остальных 3-х регистров статуса ( приёмник С2, приёмник СА, передатчик СА ), учитывая, что адреса векторов там другие.
Там не только адреса векторов другие, а также другие места в приоритетной цепочке.
при регистрации прерывания нужно правильно указывать место в цепочке приоритетов. Для стыка С2 - приемник 7, передатчик 8, для адаптера ЛС - приемник 9, передатчик 10.Точно!
для С2 - приемник 7, передатчик 8, для СА - приемник 9, передатчик 10 ).
Эти цифры должны быть только такие, или могут быть другие но с соблюдением приоритета?
Эти цифры должны быть только такие, или могут быть другие но с соблюдением приоритета?
Только такие. Vamos, прочтите техописание У11.700.016 ТО, таблица 7. В этой таблице расписаны все источники прерываний в магистрали ЦП по линии VIRQ и указаны их приоритеты.
Понятно, в коде UKNCBTL уже где-то используются VIRQ 7 и 9, это теперь весь код перелопачивать?
Понятно, в коде UKNCBTL уже где-то используются VIRQ 7 и 9, это теперь весь код перелопачивать?
Очереди в коде две, т.к. два процессора. В ПП действительно 7 и 9 очередь занята приемниками каналов 1 и 2, но это ПП, а не ЦП.
Patron, извините за оффтоп
void CFirstMemoryController::SetPortWord(WORD address, WORD word)
{
switch (address) {
case 0176574: // Стык С2: Регистр состояния источника
case 0176575: // Bits 0,2,6
if(((m_Port176574 & 0300) == 0200) && (word & 0100))
{
m_pCPU->InterruptVIRQ(8, 0374);
}
m_Port176574 = (m_Port176574 & ~0105) | (word & 0105);
break;
case 0176576: // Стык С2: Регистр данных источника
case 0176577: // нижние 8 бит доступны по записи
m_Port176576 = word & 0xff;
m_Port176574 &= ~128; // Reset bit 7 (Ready)
break;
}
}
Это должно быть именно в этой функции кода или можно поместить вот сюда
if (m_SerialInCallback != NULL && frameticks % 416 == 0)
{
CFirstMemoryController* pMemCtl = (CFirstMemoryController*) m_pFirstMemCtl;
if ((pMemCtl->m_Port176574 & 004) == 0) // Not loopback?
{
BYTE b;
if (m_SerialInCallback(&b))
{
if (pMemCtl->SerialInput(b) && (pMemCtl->m_Port176570 & 0100))
m_pCPU->InterruptVIRQ(3, 0370);
}
}
}
А то там код и так раскидан по разным местам.
Это должно быть именно в этой функции кодаЭмулятор при записи в регистры устройств вызывает функцию void CFirstMemoryController::SetPortWord(WORD address, WORD word) - туда и надо вносить изменения.
Для реализации прерываний портов СА и С2 нужно модифицировать не только функцию void CFirstMemoryController::SetPortWord(WORD address, WORD word), но и void CFirstMemoryController::SetPortByte(WORD address, BYTE byte), которая в данный момент выглядит довольно бледно.
См. ЗДЕСЬ (http://zx.pk.ru/showthread.php?postid=571643).
Посмотрел тех доку на TU58.
В доке рекомендуется такой порядок инициализации:
включить BREAK
послать два нуля
когда появится готовность выключить BREAK
послать два INITа (4)
Чувствую, что последовательный порт нас ещё удивит..
Вот адаптированный код инициализации TU58 из драйвера DD.SYS:
MOV #177777, @#TPB
BIS #<CS$INT!CS$BRK>, @#TPS
TSTB @#TPS
BPL .-4.
MOV #177777, @#TPB
TSTB @#TPS
BPL .-4.
BIC #CS$BRK,@#TPS
MOV #4, @#TPB
TSTB @#TPS
BPL .-4.
MOV #4, @#TPB
TSTB @#TPS
BPL .-4.
BIC #CS$INT,@#TPS
В большинстве эмуляторов этот код посылает 377, 0, 4, 4. Тогда как на реальном порту он должен посылать 0+FrameError, 4, 4. Порт не может послать в линию отмену FrameError - принимающая сторона снимает признак FrameError после приёма полноценного байта, а признак Break ( в тех портах, где он определяется отдельно ) снимает после приёма первого бита "1" ( перевода линии в состояние IDLE ).
Только вчера я понял, почему код инициализации TU58 из DD.SYS в реальности должен посылать ( есть смысл это проверить ) не 4, а лишь 3 байта ( 0+FrameError, 4, 4 ) - BREAK снимается во время передачи стартового бита второго байта 377, поэтому весь последующий байт распознаётся принимающим портом не как байт, а как перевод линии в состояние IDLE, предшествующее стартовому биту очередной посылки.
Кстати, если во втором байте передать хотя бы один 0-й бит, то он (скорее всего) будет распознан как стартовый с весьма оригинальными последствиями в зависимости от его позиции ( если установленный в 1 бит посылки байта 04 придётся на место стопового - будут переданы два фиктивных байта, иначе возникнет переходящая ошибка FrameErrror и только последний байт 04 будет нормально принят, хотя и с фиктивным значением ).
В большинстве эмуляторов.
И в том нет ничего удивительного - мне в принципе известны только два эмулятора которые умеют работать с живым портом и при этом в принципе отрабатывают BREAK ;)
Если я правильно понимаю суть работы последовательного порта, то при работе без бита паритета возможна передача байтов без FrameError при несовпадающих скоростях передачи и приёма.
Если принимать на скорости 9600, то при передаче байта 0377 ( 11111111 ) будет принято (в зависимости от скорости передачи) следующее:
1. 9600 - 11111111 ( 0377 )
2. 4800 - 11111110 ( 0376 )
3. 2400 - 11111000 ( 0370 )
4. 1200 - 10000000 ( 0200 )
Так как стартовый бит при меньших скоростях передачи будет "длиннее", а передаваемые единицы сыграют роль недостающих битов байта и стопового бита.
Нарисовал небольшую темплату для написания тестов с регистрами терминала, работающих как в однотерминальном так и в многотерминальном мониторе.
Здесь нет переключения в кернел режим, но в данном примере он и не нужен.
.TITLE MTATT
.IDENT /V01.00/
TKS == 176500 ;CSR ТЕСТИРУЕМОГО УСТРОЙСТВА
$JSX == 4 ;РАСШИРЕННОЕ СЛОВО СОСТОЯНИ ЗАДАНИЯ
NOVBG$ == 100 ;БИТ ЗАПРЕТА VBGEXE
$SYPTR == 54 ;УКАЗАТЕЛЬ НА RMON
$CNFG1 == 300 ;СМЕЩЕНИЕ СЛОВА КОНФИГУРАЦИИ
FJOB$ == 200 ;БИТ ЗАГРУЗКИ FOREGROUND
$SYSGE == 372 ;СМЕЩЕНИЕ СЛОВА ГЕНЕРАЦИИ
MTTY$ == 20000 ;БИТ МНОГОТЕРМИНАЛЬНОЙ ПОДДЕРЖКИ
MST.1T == 0 ;СМЕЩЕНИЕ ДО ПЕРВОГО TCB
MST.CT == 2 ;СМЕЩЕНИЕ ДО TCB ПРОГРАММЫ
MST.LU == 4 ;МАКСИМАЛЬНЫЙ НОМЕР ЛИНИИ
MST.ST == 6 ;РАЗМЕР TCB
T.CSR == 16 ;АДРЕС CSR ТЕРМИНАЛА
.ASECT ;ЗАПРЕТ ЗАПУСКА ПОД VBGEXE
.=$JSX ;
.WORD NOVBG$ ;
.PSECT ;
.MCALL .EXIT,.MTSTAT,.PRINT ;МАКРОВЫЗОВЫ
$TKS:: .WORD TKS ;АДРЕС CSR (ЧТОБЫ ЛЕГЧЕ БЫЛО МЕНЯТЬ
;БЕЗ ПЕРЕСБОРКИ)
START:: MOV @#$SYPTR,R3 ;ПОЛУЧАЕМ АДРЕС RMON
; ПРОВЕРЯЕМ НЕТ ЛИ В ПАМЯТИ FOREGROUND/SYSTEM ПРОГРАММЫ.
; ПРИ НАЛИЧИИ ТАКОЙ ПРОГРАММЫ В ПАМЯТИ ЖЕЛЕЗО ЛУЧШЕ НЕ ТРОГАТЬ
; ЧТОБЫ ПОТОМ НЕ БЫЛО МУЧИТЕЛЬНО БОЛЬНО ЗА БЕСЦЕЛЬНО ПОТЕРЯННОЕ
; СОДЕРЖИМОЕ ДИСКА...
TSTB $CNFG1(R3) ;FOREGROUND LOADED?
BPL 10$ ;НЕТ
.PRINT #EFJOB ;ДА, ОШИБКА
.EXIT ;ВЫХОД
10$: MOV $TKS,R5 ;ПОЛУЧАЕМ АДРЕС CSR
BIT #MTTY$,$SYSGE(R3) ;МНОГОТЕРМИНАЛЬНАЯ СИСТЕМА?
BEQ 50$ ;НЕТ
.MTSTAT #AREA,#TSTAT ;ДА, ПОЛУЧАЕМ ИНФОРМАЦИЮ
BCC 20$ ;ОК
.PRINT #EMTST ;ОШИБКА (ПО ИДЕЕ НЕВОЗМОЖНА)
.EXIT ;ВЫХОД
20$: MOV R3,R4 ;ПОЛУЧАЕМ АДРЕС
ADD TSTAT+MST.1T,R4 ;...ПЕРВОГО TCB
MOV TSTAT+MST.LU,R1 ;ПОЛУЧАЕМ КОЛИЧЕСТВО
INC R1 ;...ЛИНИЙ
30$: CMP R5,T.CSR(R4) ;ИЩЕМ СОВПАДЕНИЕ
BNE 40$ ;
MOV #FAKE,T.CSR(R4) ;ПОДСТАВЛЯЕМ ЛЕВЫЙ CSR
BR 50$ ;
40$: ADD TSTAT+MST.ST,R4 ;ПЕРЕХОДИМ К СЛЕДУЮЩЕМУ
SOB R1,30$ ;...TCB
CLR R4 ;СОВПАДЕНИЯ НЕ НАЙДЕНО
50$: CLR @R5 ;ЗАПРЕЩАЕМ ПРЕРЫВАНИЯ
60$: TSTB @R5 ;O
BPL .-2 ; F T
MOVB 2(R5),R0 ; F E
CMPB #'C-100,R0 ; L R
BEQ 70$ ; I M
TSTB 4(R5) ; N I
BPL .-4 ; E N
MOVB R0,6(R5) ; A
BR 60$ ; L
70$: TST R4 ;БЫЛ НАЙДЕН TCB?
BEQ 80$ ;НЕТ
MOV R5,T.CSR(R4) ;ДА. ВОССТАНАВЛИВАЕМ CSR
80$: .EXIT ;ВЫХОДИМ
FAKE:: .BLKW 4 ;ПОДСТАВНЫЕ РЕГИСТРЫ
AREA:: .BLKW 3 ;EMT AREA
TSTAT:: .BLKW 8. ;БЛОК ИНФОРМАЦИИ
EFJOB: .ASCIZ /?MTATT-F-Foreground loaded/
EMTST: .ASCIZ /?MTATT-F-MTSTAT failed/
.END START
---------- Post added at 17:29 ---------- Previous post was at 17:28 ----------
Если принимать на скорости 9600, то при передаче байта 0377 ( 11111111 ) будет принято
Да.
---------- Post added at 17:39 ---------- Previous post was at 17:29 ----------
Потерялся CLR R4 один в проге выше, а редактировать в этом кривофоруме никак не хочет. Ну да по смыслу понятно :)
Для тестирования работы последовательных портов с сигналом BREAK - мною написаны тесты BRKT1 и BRKT2. Оба требуют наличия с другой стороны тестируемой линии специального тестового варианта сервера HX Server (http://emulator.pdp-11.org.ru/misc/HX_Server%202.2_-_UKNC_=_Test_=_07.02.13_18-44.rar), который умеет по запросу клиента посылать в линию сигнал BREAK, а также превращает получаемые в порту сигналы в текстовые сообщения.
Для проведения тестов нужно запустить прилагаемый HX Server на порту PC, подключенному к УКНЦ, ДВК или PDP-11, а на другой стороне - запускать программы BRKT1.SAV и BRKT2.SAV. Если адрес и вектор используемого со стороны PDP-11 порта отличаются от адреса и вектора порта С2 УКНЦ - программы следует перекомпилировать, указав в исходниках нужные значения.
TKS =: 176570
TKINT =: 370
TTKS =: 176570
Результаты тестирования сервер выводит в окно Teletype и сохраняет в файле Teletype.log.
Запускать тесты на УКНЦ можно загрузившись с HX - на этот случай в дистрибутиве тестового сервера уже находится образ BRKT1_&_BRKT2.DSK, подключенный к приводу HX1:
...
Для тестирования работы последовательных портов с сигналом BREAK
Запустил на своем нотебяке с USB<>2COM от St Lab.
Завтра попробую приличный комп проверить.
===================================
BRKT1 - Test COM-port BREAK Part #1
===================================
Test 1: Ask HX Server for 0.3 ms BREAK..
Recived bytes: «376»
Test 2: Ask HX Server for 1 ms BREAK..
Recived bytes: «200»
Test 3: Ask HX Server for 2 ms BREAK..
Recived bytes: «000»
Test 4: Ask HX Server for 20 ms BREAK..
Recived bytes: «000»
Test 5: Ask HX Server for 50 ms BREAK..
Recived bytes: «000»
===================================
BRKT2 - Test COM-port BREAK Part #2
===================================
Test 1: Send SHORT BREAK..
«377»
Test 2: Send 1 byte BREAK..
«000»_Break__Break_EAK..
Test 3: Send 2 byte BREAK..
_Break_«000»
Test 4: Send 3 byte BREAK..
«000»_Break_
Test 5: Send 10 byte BREAK..
_Break__Break_«000»
Test 6: Send 20 byte BREAK..
«000»_Break__Break_
Test 7: Send Bad Frame 1 ..
«000»_Break_«216»«004»
Test 8: Send Bad Frame 2 ..
_Break__Break_«000»
Запустил на своем нотебяке с USB<>2COM от St Lab.В полученных результатах есть следующие "элементы новизны":
1.
Порт PC ни разу не принял BREAK и байт одновременно ( com0com при приёме BREAK - выдаёт байт 0 и BREAK_RECIVED одним событием ).
2.
.Send #377
BiS #1, @#TPS
.Send #^B11110011
BiC #1, @#TPS
.Send #^B00111111
.Send #^B01111111
отправил BREAK - BREAK - 0 - т.е. не было передано ни одного байта, в то время как
.Send #377
BiS #1, @#TPS
.Send #^B11001111
BiC #1, @#TPS
.Send #4
.Send #4
отправил 0 - BREAK - 216 - 4.
Порт PC ни разу не принял BREAK и байт одновременно ( com0com при приёме BREAK - выдаёт байт 0 и BREAK_RECIVED одним событием ).
У этого порта есть косяк - при приеме BREAK, он тутже выплеввывает из буфера то, что он перед этим уже выводил. Получается полная хрень :)
Для тестирования работы последовательных портов с сигналом BREAK
Наконец-то добрался и до этого теста после тестов Titus-а с его программируемым таймером.
Мои результаты:
===================================
BRKT1 - Test COM-port BREAK Part #1
===================================
Test 1: Ask HX Server for 0.3 ms BREAK..
Recived bytes: «374»
Test 2: Ask HX Server for 1 ms BREAK..
Recived bytes: «000»
Test 3: Ask HX Server for 2 ms BREAK..
Recived bytes: «000»
Test 4: Ask HX Server for 20 ms BREAK..
Recived bytes: «000»
Test 5: Ask HX Server for 50 ms BREAK..
Recived bytes: «000»
===================================
BRKT2 - Test COM-port BREAK Part #2
===================================
Test 1: Send SHORT BREAK..
«370»
Test 2: Send 1 byte BREAK..
_Break_«000»
Test 3: Send 2 byte BREAK..
_Break_«000»
Test 4: Send 3 byte BREAK..
_Break_«000»
Test 5: Send 10 byte BREAK..
_Break_«000»
Test 6: Send 20 byte BREAK..
_Break_«000»
Test 7: Send Bad Frame 1 ..
_Break_«000»«036»0«360»_Error+RX_
Test 8: Send Bad Frame 2 ..
_Break_«000»~«366»«377»
Восстановил еще одну машину с нормальным портом. Сделал тест - запустил на ней E11, TT1 подключил к COM порту, связал через порт с 386м компутером где у меня живет эмулятор TU58. Как и предполагалось, с BREAK все отлично и внешний DD: работает как часы.
Мои результатыВыводы таковы:
1. ВП1-065 так же как и все остальные последовательные порты принимает только один байт вне зависимости от продолжительности сигнала BREAK. Если BREAK короче байта - принимается обычный байт, у которого "недостающие биты" заполнены единицами ( т.е. стоповым битом в состоянии IDLE ).
2. Сразу видно, чем хороший COM-порт PC отличается от плохого - при приёме BREAK всегда сначала выдаётся сигнал и только затем нулевой байт.
3. Т.к. у С2 11 битов в посылке, а не 10 - плохие фреймы отработали по-другому.
.Send #377
BiS #1, @#TPS
.Send #^B11001111
BiC #1, @#TPS
.Send #4
.Send #4
отправил BREAK - 0 - 036 - 060 - 360 - FrameError+RX.
Любопытно, что после выдачи сигнала FrameError+RX - COM-порт "обещанный" событием RX байт не выдал - видимо, сигнал относился к предыдущему байту.
.Send #377
BiS #1, @#TPS
.Send #^B11110011
BiC #1, @#TPS
.Send #^B00111111
.Send #^B01111111
отправил BREAK - 0 - 136 - 366 - 377, сработав в полном соответствии с теорией - первые два байта переданы не были, а вторые два превратились в три.
Тест на PC с нормальным портом.
===================================
BRKT1 - Test COM-port BREAK Part #1
===================================
Test 1: Ask HX Server for 0.3 ms BREAK..
Recived bytes: <376>
Test 2: Ask HX Server for 1 ms BREAK..
Recived bytes: <200>
Test 3: Ask HX Server for 2 ms BREAK..
Recived bytes: <000>
Test 4: Ask HX Server for 20 ms BREAK..
Recived bytes: <000>
Test 5: Ask HX Server for 50 ms BREAK..
Recived bytes: <000>
===================================
BRKT2 - Test COM-port BREAK Part #2
===================================
Test 1: Send SHORT BREAK..
<377>
Test 2: Send 1 byte BREAK..
_Break_<000>
Test 3: Send 2 byte BREAK..
_Break_<000>
Test 4: Send 3 byte BREAK..
_Break_<000>
Test 5: Send 10 byte BREAK..
_Break_<000>
Test 6: Send 20 byte BREAK..
_Break_<000>
Test 7: Send Bad Frame 1 ..
_Break_<000><216><210><370>_Error+RX_
Test 8: Send Bad Frame 2 ..
Восстановил еще одну машину с нормальным портом. Сделал тест - запустил на ней E11, TT1 подключил к COM порту, связал через порт с 386м компутером где у меня живет эмулятор TU58. Как и предполагалось, с BREAK все отлично и внешний DD: работает как часы.Главная проблема с посылкой BREAK у эмуляторов в том, что команды эмулируются в нереальном времени, поэтому между установкой и снятием бита BREAK в эмулируемом порту проходит меньше времени, чем нужно для приёма байта в реальном порту. Результат легко предсказуем - недостаточно длинный брейк принимается реальным портом как фиктивный байт.
Главная проблема с посылкой BREAK у эмуляторов в том, что команды эмулируются в нереальном времени, поэтому между установкой и снятием бита BREAK в эмулируемом порту проходит меньше времени, чем нужно для приёма байта в реальном порту. Результат легко предсказуем - недостаточно длинный брейк принимается реальным портом как фиктивный байт.
Ну, как показал тест, в E11 проблема отсутствует как класс (или во всяком случае, не мешает). Эмулятор TU58 работает отлично, причем запускается он у меня в режиме при котором без BREAK он в принципе не начнет работать.
Тест на PC с нормальным портом.Похоже - последняя строка отчёта не скопировалась:
Test 8: Send Bad Frame 2 ..
Похоже - последняя строка отчёта не скопировалась
Возможно.
Сейчас включу снова.
1. ВП1-065 так же как и все остальные последовательные порты принимает только один байт вне зависимости от продолжительности сигнала BREAK. Если BREAK короче байта - принимается обычный байт, у которого "недостающие биты" заполнены единицами ( т.е. стоповым битом в состоянии IDLE ).
Если BREAK длинный, то всегда принимается один нулевой байт. Заметил особенность приема BREAK. При приеме нулевого байта в регистре статуса выставляется бит готовности, а бит ошибки стоп-бита не установлен. Если сразу же прочесть из регистра данных принятый нулевой байт, то готовность сбрасывается, а потом появляется ошибка стоп-бита и ошибка переполнения. Появляются ли они вместе или друг за другом, и зависит ли это от длительности BREAK - я не знаю, надо тестировать.
Если BREAK длинный, то всегда принимается один нулевой байт.
У меня не принимается. Отмечает BREAK и все.
Ну, как показал тест, в E11 проблема отсутствует как класс (или во всяком случае, не мешает). Эмулятор TU58 работает отлично, причем запускается он у меня в режиме при котором без BREAK он в принципе не начнет работать.Значит, или весь E11 работает в режиме непрерывной привязки эмуляции к реальному времени (тогда он должен сильно нагружать процессор), либо эмулятор последовательного порта задерживает сброс BREAK до совпадения эмулироемого времени этого события с реальным.
Значит, или весь E11 работает в режиме непрерывной привязки эмуляции к реальному времени (тогда он должен сильно нагружать процессор), либо эмулятор последовательного порта задерживает сброс BREAK до совпадения эмулироемого времени этого события с реальным.
В виндовсе с SET THROTTLE получается чистый IDLE. В Linux лупит непрерывно, в OS/2 настолько непрерывно, что вешает гуй при одном проце, в OS/2 DOSовский вариант если сделать SET IDLE RELEASE - дает честный IDLE.
---------- Post added at 00:16 ---------- Previous post was at 00:14 ----------
Пробовал в виндовом варианте где скорость (без таймингов - сейчас есть возможность) подгоняется примерно к 11/93. С точки зрения виндовса - IDLE.
При приеме нулевого байта в регистре статуса выставляется бит готовности, а бит ошибки стоп-бита не установлен. Если сразу же прочесть из регистра данных принятый нулевой байт, то готовность сбрасывается, а потом появляется ошибка стоп-бита и ошибка переполнения.Думаю, если новых байтов в порт не поступит - время роли не играет - бит ошибки установится только после чтения регистра данных.
Получается, что ВП1-065 принимает BREAK "нулём вперёд". Т.е. в момент приёма нуля невозможно определить - обычный ли это байт или "предвестник" сигнала BREAK.
Думаю, если новых байтов в порт не поступит - время роли не играет - бит ошибки установится только после чтения регистра данных.
Абсолютно верно.
Все биты TKB читаются только вместе с символом и далее не меняются пока следующий символ не поступит, а пока висит BREAK, он не поступит.
---------- Post added at 00:19 ---------- Previous post was at 00:18 ----------
Похоже - последняя строка отчёта не скопировалась:
Test 8: Send Bad Frame 2 ..
В логе это последняя строчка, но в окне есть еще одна:
<000><276><372><377>
У меня не принимается. Отмечает BREAK и все.В смысле - на стороне PDP-11..
При каждом достаточно длинном брейке на стороне PDP-11 принимался один нулевой байт:
Test 5: Ask HX Server for 50 ms BREAK..
Recived bytes: <000>
В смысле - на стороне PDP-11..
При каждом достаточно длинном брейке на стороне PDP-11 принимался один нулевой байт:
Test 5: Ask HX Server for 50 ms BREAK..
Recived bytes: <000>
При насколько достаточном?
Я уже выкладывал тесты: BREAK длиной 8 символов, дает 120000 и ничего больше. То есть никаких нулевых байтов.
В логе это последняя строчка, но в окне есть еще одна: <000><276><372><377>Если строка не завершена - она выводится в лог только при выходе из программы. Чтобы это поправить - можно добавить в конце теста BRKT2 вывод перевода строки.
Думаю, если новых байтов в порт не поступит - время роли не играет - бит ошибки установится только после чтения регистра данных.
Получается, что ВП1-065 принимает BREAK "нулём вперёд". Т.е. в момент приёма нуля невозможно определить - обычный ли это байт или "предвестник" сигнала BREAK.
Если не читать из регистра данных, то будут установлены и бит готовности, и бит ошибки стоп-бита, ну и может быть бит переполнения.
Тут, судя по всему установка бита готовности происходит еще до приема стоп-битов. А уже потом, если стоп-битов не оказалось, ставится ошибка стоп-бита.
Это проверяется, если возникает готовность приемника, многократно прочесть регистр состояния в буфер, а там можно посмотреть когда ставится ошибка стоп-бита и ошибка переполнения.
Ошибка переполнения может выставится по приходу стартового бита, если предыдущая посылка не прочитана.
Если не читать из регистра данных, то будут установлены и бит готовности, и бит ошибки стоп-бита, ну и может быть бит переполнения.
Будут при условии поступления в порт данных. При BREAK их не поступает.
Я уже попробовал замерять длительность BREAK, но все уперлось в то, что символов в порт не поступает и регистрируется только сам BREAK.
При насколько достаточном?
Я уже выкладывал тесты: BREAK длиной 8 символов, дает 120000 и ничего больше. То есть никаких нулевых байтов.
Исходник теста даёт все ответы
NewVTest:
MovB (R4), (R5)+
RtI
START:
Mov #TKB, R4
Mov #ResBuf, R5
Tst (R4)
Ask_For_Break_And_Wait
Mov #ResBuf, R3
Sub R3, R5
31$:
TstB @#TTPS
BPl .-4.
MovB (R3)+, @#TTPB
SOB R5, 31$
При каждом приёме BREAK порт PDP-11 принимает ровно один нулевой байт.
Будут при условии поступления в порт данных. При BREAK их не поступает.
Я уже попробовал замерять длительность BREAK, но все уперлось в то, что символов в порт не поступает и регистрируется только сам BREAK.
У меня речь идет про 1801ВП1-065, у нее нет отдельного бита детектирования BREAK. И BREAK длинный она принимает как нулевой байт. А вот биты ставятся в описанной мною последовательности.
Я исходник тоже публиковал - попробуй найти в нем почему (правильно) принимается только сам BREAK. Могу дать исходник попроще - в котором делалась попытка замерить длительность BREAK - чем она кончилась сказано выше - никаких символов не поступает.
---------- Post added at 00:28 ---------- Previous post was at 00:28 ----------
У меня речь идет про 1801ВП1-065, у нее нет отдельного бита детектирования BREAK. И BREAK длинный она принимает как нулевой байт. А вот биты ставятся в описанной мною последовательности.
Ну это может быть - про 1801 ничего не скажу.
---------- Post added at 00:32 ---------- Previous post was at 00:28 ----------
Вот собственно исходник - часть которая "меряет" BREAK короткая.
Никакого нулевого символа на DLV11-J не принимается (если не считать приема символа для которого установлен FE).
.TITLE BRKT
.IDENT /V01.00/
PSW == 177776
TKS == 177560
FERR == 20000
LKS == 177546
IE == 100
BCSR == 177520
C800 == 6000
EHOB == 1000
CR == 15
LF == 12
$TTKS:: .WORD TKS
START:: MOV #SYSTM,@#20
MOV #340,@#22
IOT
TIMER:: ADC $TIME+2
ADC $TIME
RTI
$TIME:: .BLKW 2
SYSTM:: MOV #START,SP
RESET
MOV #TIMER,@#100
MOV #341,@#102
MOV $TTKS,R5
MOV #IDENT,R1
CALL PRSTR
BIS #C800,@#BCSR
.IIF EQ TKS-177560 BIC #HOB,@#BCSR
CLR @#PSW
10$: CLR $TIME+2
CLR $TIME
20$: BIT #20000,2(R5)
BEQ 20$
BIS #IE,@#LKS
30$: BIT #20000,2(R5)
BNE 30$
CLR @#LKS
MOV $TIME,R2
MOV $TIME+2,R3
MOV #125.,R0
CALL $DMUL
MOV R1,R2
MOV R0,R1
MOV #100.,R0
CALL $DDIV
MOV R1,R3
MOV R0,-(SP)
CALL PRDEC
MOV #'.,R0
CALL PRCHR
MOV (SP)+,R2
CLR R3
CALL PRDEC
MOV #CR,R0
CALL PRCHR
MOV #LF,R0
CALL PRCHR
BR 10$
PRSTR:: MOVB (R1)+,R0
BEQ 10$
CALL PRCHR
BR PRSTR
10$: RETURN
PRCHR:: TSTB 4(R5)
BPL .-4
MOVB R0,6(R5)
RETURN
PRDEC:: MOV #POWER,R4
CLR R1
10$: MOV #'0,R0
20$: SUB @R4,R2
SBC R3
SUB 2(R4),R3
BLT 30$
INC R0
INC R1
BR 20$
30$: ADD @R4,R2
ADC R3
ADD 2(R4),R3
TST R1
BNE 40$
TST 4(R4)
BNE 50$
40$: CALL PRCHR
50$: CMP (R4)+,(R4)+
TST @R4
BNE 10$
RETURN
POWER:: .WORD 145000,35632 ;1000000000.
.WORD 160400,2765 ;100000000.
.WORD 113200,230 ;10000000.
.WORD 41100,17 ;1000000.
.WORD 103240,1 ;100000.
.WORD 23420,0 ;10000.
.WORD 1750,0 ;1000.
.WORD 144,0 ;100.
.WORD 12,0 ;10.
.WORD 1,0 ;1.
.WORD 0
IDENT:: .ASCIZ /BREAK TIMING TEST V1.0/<CR><LF>
.END START
---------- Post added at 00:34 ---------- Previous post was at 00:32 ----------
Хотя прошлый пример лучше - там готовность проверялась, а здесь бит FE...
Если не читать из регистра данных, то будут установлены и бит готовности, и бит ошибки стоп-бита, ну и может быть бит переполнения.
Тут, судя по всему установка бита готовности происходит еще до приема стоп-битов. А уже потом, если стоп-битов не оказалось, ставится ошибка стоп-бита.
Это проверяется, если возникает готовность приемника, многократно прочесть регистр состояния в буфер, а там можно посмотреть когда ставится ошибка стоп-бита и ошибка переполнения.Точно!
Учитывая, что один бит в порту С2 принимается больше чем за 100 мкс - вполне можно написать "дампер состояния", который будет копировать регистр состояния в буфер каждые 50 мкс, а затем "сливать" весь дамп в битовом виде в лог сервера HX.
---------- Post added at 20:42 ---------- Previous post was at 20:35 ----------
попробуй найти в нем почему (правильно) принимается только сам BREAKЕсли там используется прерывание и оно происходит - значит в статусе принимающего порта устанавливается бит готовности, т.е. принимается байт.
У меня исходник проще - там сначала делается большая задержка, потом читается регистр данных, чтобы сбросить бит готовности, потом у сервера запрашивается BREAK и ожидаются прерывания, при каждом из которых из регистра данных копируется принятый байт.
Если там используется прерывание и оно происходит - значит в статусе принимающего порта устанавливается бит готовности, т.е. принимается байт.
Ну так вот тебе простейший тест который уже делали:
RINT:: MOV @#RDA,(R5)+
DEC R4
BNE 20$
10$: CLR @#LCS
CLR @#TCS
CLR @#RCS
MOV #TDONE,@SP
MOV #340,2(SP)
20$: RTI
Тут видно, что как происходит прерывание, сохраняется весь TKB. Тест показал, что BREAK длиной в 8 символов выдает только одно прерывание при котором принимается FE и ничего больше. Так что если твой HX Server шлет еще что-то, надо говорить о том, что (из виндовса) посылается еще нулевой байт, а не о том, что он принимается.
---------- Post added at 00:47 ---------- Previous post was at 00:44 ----------
PS. Тестил BREAK из SecureCRT (windows) и VT220 - аналогично - регистрируется BREAK и никакого нуля.
---------- Post added at 00:47 ---------- Previous post was at 00:47 ----------
Могу для интереса CM7209 проверить = там можно послать BREAK длиной хоть целый час :)
Так что если твой HX Server шлет еще что-то, надо говорить о том, что (из виндовса) посылается еще нулевой байт, а не о том, что он принимаетсяПосылается чистый BREAK - это хорошо видно, когда время его установки меньше времени приёма байта - тогда вместо BREAK принимается фиктивный байт.
---------- Post added at 20:51 ---------- Previous post was at 20:50 ----------
Если настроить порты на 2400, то при получении BREAK длиной 1 мс или 2 мс - тоже будут приняты фиктивные байты.
Посылается чистый BREAK - это хорошо видно, когда время его установки меньше времени приёма байта - тогда вместо BREAK принимается фиктивный байт.
Так это другой вопрос - если BREAK длится меньше времени, нужного для его определения то конечно получится принятый байт. И с этим мы тоже баловались уже...
Байты принимаются в течении 65000 циклов SOB - если после фиктивного байта не пришёл "дополнительный" ноль - значит посылался чистый BREAK.
Убедившись, что в том пункте, где принимается 2 мс BREAK, всё без обмана - переключаем порты обратно на 9600 и принимаем нулевой байт.
Новый тест - BRKT3[/b] (][b) должен делать дамп последовательных состояний регистра статуса приёмника при приёме сигнала BREAK.
Главная тонкость там - так настроить задержки, чтобы захватить как раз интересующий интервал. Интересно, насколько это удалось.
...
Никакого нулевого символа на DLV11-J не принимается (если не считать приема символа для которого установлен FE).Так это он и есть. Принятый байт ведь передаётся в младшем байте регистра данных, а раз при установке бита готовности там ноль - значит был принят ноль. А с брейком этот байт был принят или без брейка - это уже подробности ( вот, например, ВП1-065 при приёме брейка устанавливает бит брейка только через 100 мкс после установки бита готовности - а до того отличить приём брейка от приёма обычного нулевого байта вообще невозможно ).
...
Так это он и есть.
Речь насколько я понял шла о дополнительном нулевом байте...
Если же нет, то и вопрос отпадает.
Новый тест - BRKT3[/b] (][b) должен делать дамп последовательных состояний регистра статуса приёмника при приёме сигнала BREAK.
Главная тонкость там - так настроить задержки, чтобы захватить как раз интересующий интервал. Интересно, насколько это удалось.
Извиняюсь, чуть подзадержался. Результаты теста:
===================================
BRKT3 - Test COM-port BREAK Part #3
===================================
Ask HX Server for 50 ms BREAK..
«000»00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 10000000 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
Test completed
Речь насколько я понял шла о дополнительном нулевом байте...Сколько портов - столько и признаков приёма BREAK. Единственное, что можно проверить у любого порта при приёме BREAK - это сколько раз установится признак готовности и что каждый раз будет при этом в регистре данных.
С этим определённость полная - готовность устанавливается только один раз ( если продолжительность BREAK >= времени передачи одного бита ), а содержимое регистра данных определяется фазой передачи байта в момент установки BREAK - если никакой байт в этот момент не передавался и BREAK был установлен дольше, чем принимается байт на выбранной скорости приёмника - в момент установки бита готовности в регистре данных приёмника будет ноль.
проверить у любого порта при приёме BREAK - это сколько раз установится признак готовности и что каждый раз будет при этом в регистре данных.
А мы уже проверили.
Выше тест посылки бряка в течение 8 символов.
Готовность была установлена один раз и был получен байт с признаком FE. Больше готовность не устанавливаласть и ничего не принималось.
Результаты тестаЛовко я придумал послать ноль для тайминга, но учесть, что он тоже попадёт в лог - забыл.
Быстро бит BREAK ставится - похоже, даже быстрее, чем передаётся один бит. А вот бит переполнения чего-то ждёт..
Сейчас повышу разрешение, чтобы точнее определить задержку установки бита BREAK.
---------- Post added at 23:18 ---------- Previous post was at 23:16 ----------
BRKT3В этом случае задержки не хватило - слишком быстро SOB крутился.
Быстро бит BREAK ставится - похоже, даже быстрее, чем передаётся один бит.
Во всяком случае я проводил такой опыт. Делалось все по прерыванию, п/п обработки прерывания сохраняла значения регистра состояния и читала регистр данных. Несмотря на то, что для выполнения прерывания нужно положить два слова в стек, прочесть вектор и значение вектора из памяти (два слова) - в сохраненном регистре состояния был установлен только бит готовности. Уже после прерывания и завершения сигнала BREAK в регистре статуса были установлены биты ошибки стоп-бита и переполнения, бит готовности был сброшен.
Версия теста с повышенным разрешением - для УКНЦ:
BRKT3a (http://zx.pk.ru/attachment.php?attachmentid=39692).
...
Версия теста с повышенным разрешением - для УКНЦ:
BRKT3a (http://zx.pk.ru/attachment.php?attachmentid=39692).
...
Результат тот же.
Версия теста с повышенным разрешением - для УКНЦ:
Одни нули.
Результат тот же.Невозможно, как выяснилось? написать простой тест с задержками, который давал бы одинаковую задержку в цикле SOB и на УКНЦ, и на 11/83.
Думал, что получится - но нет..
Надо или разные варианты теста делать ( с разными константами в задержках SOB ), или более крутой "задерживатель" создавать.
---------- Post added at 23:42 ---------- Previous post was at 23:40 ----------
Одни нули.Зато какое разрешение! :)
Сейчас создам промежуточный вариант.
Невозможно, как выяснилось? написать простой тест с задержками, который давал бы одинаковую задержку в цикле SOB и на УКНЦ, и на 11/83.
Думал, что получится - но нет..
Надо или разные варианты теста делать ( с разными константами в задержках SOB ), или более крутой "задерживатель" создавать.
А какая задержка нужна?
У меня таймером можно делать задержку с точностью до 1.25ms.
А какая задержка нужна?С точностью 100 мкс. После отправки серверу запроса - в порт посылается для тайминга нулевой байт. Когда эта отправка "готова" - сервер уже получил запрос и начинает ответ. Теперь нужно пропустить биты данных и начать копирование интересующих регистров, а потом вывести результат:
.Send #0
Tst (R4)
Mov #100., R1
Mov #210., R0 ; Здесь хотим пропустить биты данных
SOB R0, .
3$:
Mov @#TKS, (R5)+
Mov #4., R0
SOB R0, .
SOB R1, 3$
Call ShRes
...
Новая версия теста:
Новая версия теста:
Опять одни нули.
Очередной вариант теста:
===================================
BRKT3 - Test COM-port BREAK Part #3c
===================================
Ask HX Server for 50 ms BREAK..
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
00000000 01000000 00000000 01000000 00000000 01000000 00000000 01000000
Test completed
Очередной вариант теста:
===================================
BRKT3 - Test COM-port BREAK Part #3c
===================================
Ask HX Server for 50 ms BREAK..
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 10000000 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
Test completed
BRKT3cАга! Щас мы его! В смысле - ещё задержку уменьшим..
---------- Post added at 00:20 ---------- Previous post was at 00:20 ----------
BRKT3сА как в порту TKS бит разрешения прерываний выжил.. Он ведь перед измерением обнуляется:
BiC #100, @#TKS
А как в порту TKS бит разрешения прерываний выжил.. Он ведь перед измерением обнуляется
Значит я его в многотерминальной системе запустил...
---------- Post added at 04:24 ---------- Previous post was at 04:21 ----------
Потому и предлагаю делать сразу так, чтобы многотерминальность пофигу была - это совсем не сложно. А то у меня TCP/IP только в многотерминальной система - приходится перегружаться.
Ещё один вариант:
На первый раз при запуске - нули, потом два раза нормально:
===================================
BRKT3 - Test COM-port BREAK Part #3d
===================================
Ask HX Server for 50 ms BREAK..
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Test completed
===================================
BRKT3 - Test COM-port BREAK Part #3d
===================================
Ask HX Server for 50 ms BREAK..
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 10000000 00000000 10000000
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
Test completed
===================================
BRKT3 - Test COM-port BREAK Part #3d
===================================
Ask HX Server for 50 ms BREAK..
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 10000000
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
Test completed
Ещё один вариант:
Нули.
3c тоже - запустил в однотерминальной.
А что собственно выводится-то? :)
А что собственно выводится-то? :)
Для УКНЦ - регистр состояния приемника стыка С2 0176570. Выясняется в какой последовательности ставятся биты готовности, ошибки стоп-бита и переполнения при подаче сигнала BREAK.
Для УКНЦ - регистр состояния приемника стыка С2 0176570. Выясняется в какой последовательности ставятся биты готовности, ошибки стоп-бита и переполнения при подаче сигнала BREAK.
Ха. Так у меня тогда кроме нулей там ничего быть не может.
Все биты ошибок на DL(V)11 пишутся в регистр данных. А готовности после приема BREAKаного символа быть не может пока BREAK активен...
На первый раз при запуске - нули, потом два раза нормальноЗначит, BREAK один раз почему-то не принялся. Но мы уже полчили результат - два отсчёта подряд без установленного признака BREAK. Отсчёты снимались так:
3$:
Mov @#TKS, (R5)+
Mov #7., R0
SOB R0, .
SOB R1, 3$Это сколько будет в тактах процессора ?
---------- Post added at 00:42 ---------- Previous post was at 00:37 ----------
А готовности после приема BREAKаного символа быть не может пока BREAK активен...Это существенно. Т.е. бит готовности устанавливается строго по стоповому биту, и "поймать" признак BREAK в регистре данных - прерывания не помогут.
Это существенно. Т.е. бит готовности устанавливается строго по стоповому биту, и "поймать" признак BREAK в регистре данных - прерывания не помогут.
Что значит не помогут? Отлично ловится из прерываний, что и было показано выше. Только читать надо не байт, а слово :)
Это сколько будет в тактах процессора ?
Это вопрос скорее к Titus-у, он измерениями занимался. Можно конечно взять из эмулятора UKNCBTL, но там довольно усредненные значения.
Что значит не помогут? Отлично ловится из прерываний, что и было показано выше. Только читать надо не байт, а слово :)
Причем этот признак в регистре сохранится после того как BREAK будет снят и очистится только когда придет символ.
Это вопрос скорее к Titus-у, он измерениями занимался. Можно конечно взять из эмулятора UKNCBTL, но там довольно усредненные значения.Раньше мы уже тестировали (программой PORT), что один байт передаётся в порту С2 за 600 NOPов. Значит 1 бит = 600/11 = 55 NOPов.
Если два цикла приведённого кода наберут 55 NOPов - значит бит BREAK устанавливается на следущем битовом интервале после бита готовности.
3$:
Mov @#TKS, (R5)+
Mov #7., R0
SOB R0, .
SOB R1, 3$
Если это ЦП, то порядок чисел такой:
80
30
35
35
Но точно эти команды не мерил.
3$:
Mov @#TKS, (R5)+
Mov #7., R0
SOB R0, .
SOB R1, 3$Это сколько будет в тактах процессора ?
Это вопрос скорее к Titus-у, он измерениями занимался. Можно конечно взять из эмулятора UKNCBTL, но там довольно усредненные значения.
Из эмулятора UKNCBTL:
MOV @#...,(R)+ - 67 тактов;
MOV #...,R - 25 тактов;
SOB в цикле - 45 тактов;
SOB последний - 25 тактов.
Отлично ловится из прерыванийТ.е. прерывание возникает в тот момент, когда должен прийти стоповый бит и если этот бит стартовый - в этот же момент устанавливается и признак BREAK, а в младший байт регистра данных помещается ноль.
---------- Post added at 00:55 ---------- Previous post was at 00:52 ----------
Если это ЦП, то порядок чисел такой:
80+30+35+35Т.е. в NOPах это будет 180/16 = 12, а за два цикла - 24 NOPа.
А один бит передаётся за 50 NOPов.
...
А, понял - продолжительность цикла SOB надо ещё умножить на 7
Т.е. прерывание возникает в тот момент, когда должен прийти стоповый бит и если этот бит стартовый - в этот же момент устанавливается и признак BREAK, а в младший байт регистра данных помещается ноль.
Да.
После этого сколько бы BREAK не висел, готовности больше не будет, а в регистре данных будет висеть то же значение (120000).
Т.е. в NOPах это будет 180/16 = 12, а за два цикла - 24 NOPа.
NOP - 14-15 тактов, на большинстве машин 14.
NOP - 14-15 тактов, на большинстве машин 14.Тогда в одном цикле теста получается 27 NOPов, а в двух - 54 NOPа.
Выходит, что бит BREAK устанавливается в регистре статуса приёмника ВП1-065 ровно через один битовый интервал после установки бита готовности.
---------- Post added at 01:18 ---------- Previous post was at 01:09 ----------
А бит переполнения устанавливается ещё через 11 битовых интервалов:
09 00000000 10000000 00000000 10000000
10 00000000 10000001 00000000 10000001
11 00000000 10000001 00000000 10000001
01 00000000 10000001 00000000 10000001
02 00000000 10000001 00000000 10000001
03 00000000 10000001 00000000 10000001
04 00000000 10000001 00000000 10000001
05 00000000 10000001 00000000 10000001
06 00000000 10000001 00000000 10000001
07 00000000 10000001 00000000 10000001
08 00000000 10000001 00000000 10000001
09 00000000 10000001 00000000 10000001
10 00010000 10000001 00010000 10000001
Для правильной эмуляции последовательных портов важно знать, что получит принимающая строна, если начать непрерывно писать байты в регистр данных передатчика, не проверяя его готовность.
...
Хотя, секрета тут никакого нет. Пока бит готовности не установлен - запись в порт ни на что не влияет. Важнее проверить - сохраняется ли в регистре данных порта значение, если оно было записано туда при сброшенном бите готовности.
Результаты теста выводятся в тестируемый порт. По умолчанию - это порт С2 УКНЦ.
Предложение: для тестов делать в начале программы ячейки, хранящие регистры-векторы. Тогда можно будет без пересборки тесты запускать на других машинах...
TTP - Test TTP port
===================
14«231»
Test completed
Добавил также тест в свой DL<>DL (8 символов):
TEST9:: .WORD T9
MOV #BUFSZ,R1
10$: MOVB R1,@#TDA
SOB R1,10$
BR .
TEST #9
000010 000001
FLAG: 000000
---------- Post added at 17:59 ---------- Previous post was at 17:57 ----------
Важнее проверить - сохраняется ли в регистре данных порта значение, если оно было записано туда при сброшенном бите готовности.
Даже если сохраняется внутренне, проверить не получится: как значение для вывода оно не отработается, а биты эти в регистре данных WO и назад не читаются. Впрочем это ничем не отличается от "не сохраняется" :)
Даже если сохраняется внутренне, проверить не получится: как значение для вывода оно не отработается, а биты эти в регистре данных WO и назад не читаются. Впрочем это ничем не отличается от "не сохраняется"Мой эмулятор только что так же популярно об этом мне напомнил - каждая команда INC @#TPB посылает исключительно и только байт 01.
---------- Post added at 14:15 ---------- Previous post was at 14:10 ----------
Добавил также тест в свой DL<>DL (8 символов)Фактически - это разновидность NOP-метра, проверяющего время установки готовности при передаче байта порт, сдвиговый регистр которого в этот момент свободен.
Для дальнейшего тестирования работы последовательных портов с сигналом BREAK - мною написан тест BRKT4.
Для правильной работы теста необходимо, чтобы при его выполнении квитирование было отключено, поэтому не следует трогать настройку COM-порта
fOutxCtsFlow = FALSE
Также не следует включать сжатие при загрузке с этого сервера.
Этот тест проверяет, какой сигнал получит COM-порт PC если установить BREAK в середине передачи байта 0377, а также проверяет гипотезу о наличии и работе буфера FIFO в контроллере 1801ВП1-065.
Тест требует наличия с другой стороны тестируемой линии специального тестового варианта сервера HX Server (http://emulator.pdp-11.org.ru/misc/HX_Server%202.2_-_UKNC_=_Test_=_09.02.13_18-16.rar), который умеет по запросу клиента посылать в линию эхо, а также превращает получаемые в порту сигналы в текстовые сообщения.
Для проведения тестов нужно запустить прилагаемый HX Server на порту PC, подключенному к УКНЦ, ДВК или PDP-11, а на другой стороне - запустить программу BRKT4.SAV. Если адрес и вектор используемого со стороны PDP-11 порта отличаются от адреса и вектора порта С2 УКНЦ - программу следует перекомпилировать, указав в исходниках нужные значения.
TKS =: 176570
TKINT =: 370
Результаты тестирования сервер выводит в окно Teletype и сохраняет в файле Teletype.log.
Запускать тесты на УКНЦ можно загрузившись с HX - на этот случай в дистрибутиве тестового сервера уже находится образ BRKT-1-2-3-4.DSK, подключенный к приводу HX1:
По сравнению с предыдущей тестовой версией сервера произошло существенное изменение протокола HX в части пакетов спецкоманд BREAK и ECHO - теперь пакеты спецкоманд получили собственный тип пакета 0373, поэтому опубликованные ранее тестовые программы не смогут запрашивать BREAK у данного сервера.
Адаптированные исходники предыдущих тестов также включены в архив.
...
Для дальнейшего тестирования работы последовательных портов с сигналом BREAK - мною написан тест BRKT4.
За компанию...
Кривой порт:
===================================
BRKT4 - Test COM-port BREAK Part #4
===================================
Test 1: Send 0377 - Wait half bits - set 1 byte BREAK
«017»_Break__Error_1 byte BREAK
Test 2: Send 0377 - Wait half bits - set 2 byte BREAK
«017»_Break__Error_te BREAK
Test 3: Send 0377 - Wait half bits - set 8 byte BREAK
«017»_Break__Error_te BREAK
Ask HX Server for ECHO: 'AB' - Wait 100 ms - Read bytes..
B
Ask HX Server for ECHO: 'ABC' - Wait 100 ms - Read bytes..
C
Test completed
Нормальный порт:
===================================
BRKT4 - Test COM-port BREAK Part #4
===================================
Test 1: Send 0377 - Wait half bits - set 1 byte BREAK
_Error_<017><360>
Test 2: Send 0377 - Wait half bits - set 2 byte BREAK
_Error_<017><000><360>_Break+0_
Test 3: Send 0377 - Wait half bits - set 8 byte BREAK
_Error_<017><000><000><000><000><000><000><000>_Break+0__Break_<000><377>
Ask HX Server for ECHO: 'AB' - Wait 100 ms - Read bytes..
B
Ask HX Server for ECHO: 'ABC' - Wait 100 ms - Read bytes..
C
Test completed
Не могу понять, почему ВП1-065 не принимает второй байт, когда первый ещё не считан, ведь при работающем квитировании он должен хранить два байта - один в регистре данных и один в сдвиговом регистре. Почему же тогда при передаче двух байтов без квитирования - второй пропадает.
Какая разница в сигналах порта в этих двух случаях ?
При работающем квитировании порт принимает два байта, устанавливает CTS и передатчик больше не передаёт. Но при передаче только двух байтов и отключенном квитировании - передатчик всё равно останавливает передачу после двух байтов - в чём же разница..
---------- Post added at 18:29 ---------- Previous post was at 18:27 ----------
За компанию...Самый прикол, что тестировавшийся DL-порт обновляет не считанный байт в регистре данных по мере прихода следующих.
Самый прикол, что тестировавшийся DL-порт обновляет не считанный байт в регистре данных.
Да.
Если считать полное слово из регистра данных, там будут установлены биты ERR и OV и в младшем байте последний принятый байт.
в младшем байте последний принятый байт.Это у всех дековских последовательных портов так?
Это у всех дековских последовательных портов так?
Насчет всех не берусь судить, но у тех у кого есть бит OV (не видел тех у кого нет) по идее у всех так.
Описание бита ошибки: The OVR ERR bit is set when a previous character was
received but was not read before it was overwritten by the
current character.
COM порт на РС: Intel(R) ICH7 Family LPC Interface Controller - 27B8
Test 1: Send 0377 - Wait half bits - set 1 byte BREAK
_Error_«017»«340»
Test 2: Send 0377 - Wait half bits - set 2 byte BREAK
_Error_«017»«000»_Break+0_
Test 3: Send 0377 - Wait half bits - set 8 byte BREAK
_Error_«017»«000»_Break+0_
Нормальный порт
Test 1: Send 0377 - Wait half bits - set 1 byte BREAK
_Error_<017><360>
Test 2: Send 0377 - Wait half bits - set 2 byte BREAK
_Error_<017><000><360>_Break+0_
Test 3: Send 0377 - Wait half bits - set 8 byte BREAK
_Error_<017><000><000><000><000><000><000><000>_Break+0__Break_<000><377>
Существенные отличия..
---------- Post added at 18:56 ---------- Previous post was at 18:51 ----------
Keeper, а если BRKT2.SAV запустить - какие будут результаты ?
Если будет интерес, можно сделать у меня тест с чистыми DL без участия PC. Требование: приемная сторона должна быть собрана как /FOR, использовать прерывания и сразу после установки векторов, вызвать .SPND, а после него восстановить векторы и выйти.
Не могу понять, почему ВП1-065 не принимает второй байт, когда первый ещё не считан, ведь при работающем квитировании он должен хранить два байта - один в регистре данных и один в сдвиговом регистре. Почему же тогда при передаче двух байтов без квитирования - второй пропадает.
Какая разница в сигналах порта в этих двух случаях ?
При работающем квитировании порт принимает два байта, устанавливает CTS и передатчик больше не передаёт. Но при передаче только двух байтов и отключенном квитировании - передатчик всё равно останавливает передачу после двух байтов - в чём же разница..
1801ВП1-065 не может принять два байта. При приеме первого байта сразу же устанавливается сигнал CTS. Если же пришел второй, то ставится ошибка переполнения и второй байт теряется.
А вот на выдачу действительно можно запихнуть два байта, и пока не будут сигнала RTS (вход BSYD на 1801ВП1-065), они действительно не уйдут. Первый будет ждать в сдвиговом регистре, второй - в буферном.
можно сделать у меня тест с чистыми DL без участия PC.Чистые DL ставят биты ошибок в регистре данных, а Windows сигналы шлёт. Поэтому, у DL бит ошибки не может "заблудиться", а у Windows (как видим) целый зоопарк сигналов на один брейк может прийти - один сигнал перед "его" байтом, другой - после "его" байта.
---------- Post added at 19:07 ---------- Previous post was at 19:04 ----------
При приеме первого байта сразу же устанавливается сигнал CTS.Тогда понятно. Но это значит, что при работе с квитированием интервалы между передаваемыми байтами будут слегка больше, чем когда байты идут сплошным потоком.
Чистые DL ставят биты ошибок в регистре данных, а Windows сигналы шлёт. Поэтому, у DL бит ошибки не может "заблудиться", а у Windows (как видим) целый зоопарк сигналов на один брейк может прийти - один сигнал перед "его" байтом, другой - после "его" байта.
Можно сделать приемник и отправитель отдельно, один запускать на PDP-11, другое на E11/Win - тоже инстересный тест...
Тогда понятно. Но это значит, что при работе с квитированием интервалы между передаваемыми байтами будут слегка больше, чем когда байты идут сплошным потоком.
Нисколько. Сигнал CTS ставится скорее всего при приеме 8-ми информационных бит, вместе с битом готовности, это выяснилось предыдущими тестами. За оставшиеся два стоп-бита регистр данных уж наверняка будет считан. По моим опытам с BREAK, даже по прерыванию в регистре состояния еще не стояло бита ошибки стоп-бита, а ведь это занос в стек двух слов, чтение вектора, чтение двух слов значения вектора, да еще чтение и исполнения команд п/п прерывания. Так что с этим скорее всего полный порядок.
Можно сделать приемник и отправитель отдельноПередатчик "кривого брейка" довольно прост.
Главное тут правильно вычислить, сколько циклов SOB приходится на одну посылку:
NVTP2: Mov #LL1, (SP)
NVTP1: RtI
......
START:
.Send #015
Mov #NVTP2, @#TPINT
Clr R0
Mov #015, @#TPB
SOB R0, .
LL1:
BiC #100, @#TPS
Mov #NVTP1, @#TPINT
Neg R0
Mov R0, R1
ASR R0
Mov R0, R2
Потом полученные задержки используются, чтобы установить BREAK в середине передачи байта:
Mov R2, R0
Mov R1, R3
Mov #377, @#TPB
TstB @#TPS
BPl .-4.
SOB R0, . ; Wait half byte send time
BiS #1, @#TPS ; Set BREAK
SOB R3, . ; Wait full byte send time
BiC #1, @#TPS ; Clear BREAK
---------- Post added at 19:29 ---------- Previous post was at 19:18 ----------
Нисколько. Сигнал CTS ставится скорее всего при приеме 8-ми информационных бит, вместе с битом готовности, это выяснилось предыдущими тестами.Здесь может помочь режим "лупбэка", т.к. нужно очень точно знать момент начала приёма байта. Тогда, запустив "битовый дампер" регистра статуса - можно будет точно определить в какой момент какой бит там устанавливается.
---------- Post added at 19:39 ---------- Previous post was at 19:29 ----------
BRKT2Если открыть прогон BRKT2 на PC Alex_K (http://zx.pk.ru/showthread.php?postid=573906), то понятно, что при приёме "простого брейка" порты PC ведут себя достаточно похоже.
Я очень некстати испортил USB-TTL адаптер на FT232... может через недельку починю и потестирую. Тестов BRKT2 и BRKT4 будет достаточно?Из программ - да.
А вообще - ещё представляет интерес способность порта со стороны PC работать с ВП1-065 в следующих режимах PC:
1. 2 стоповых бита, fOutxCtsFlow = TRUE, сжатие HX включено.
2. 1 стоповый бит, fOutxCtsFlow = TRUE, сжатие HX включено.
3. 2 стоповых бита, fOutxCtsFlow = FALSE, сжатие HX выключено.
4. 1 стоповый бит, fOutxCtsFlow = FALSE, сжатие HX выключено.
Ради интереса посмотрел что получается при инициализации DD в сторону E11/Win и обратно.
PDP-11 => E11
Хреновый порт:
000000 130000 120000 000004 000004 130000 120000 000360
000360 000004
Это чистый порт. Если бы он принял до этого что-либо - еще бы кучка мусора свалилась (частичный повтор того что он принял ранее).
Тут даже речи не идет о том, чтобы что-то работало. TU58 не начнет работу пока не получит второй INIT (4) после BREAK, а как на мусор отреагирует - черт его знает.
Нормальный порт:
120000 000000 000004 000004
Нормальная инициализация, пригодная для использования.
E11 => PDP-11
Хреновый порт:
120000 000377 000004 000004
Опять фиг знает как TU58 среагирует на мусор, но в целом терпимо.
В это сторону порт ничего не повторяет по BREAK.
Нормальный порт:
120000 000004 000004
Идеально.
С досовским E11 пока негде проверить.
С виндовсным проверялось как на полную скорость, так и с задержкой до уровня чуть быстрее 11/93.
Для дальнейшего тестирования работы последовательных портов с сигналом BREAK - мною написан тест BRKT4.
Результаты тестирования сервер выводит в окно Teletype и сохраняет в файле Teletype.log.
Запускать тесты на УКНЦ можно загрузившись с HX - на этот случай в дистрибутиве тестового сервера уже находится образ BRKT-1-2-3-4.DSK, подключенный к приводу HX1:
Сжатие и квитирование отключил. Смотрим результаты.
BRKT1A:
===================================
BRKT1 - Test COM-port BREAK Part #1a
===================================
Test 1: Ask HX Server for 0.3 ms BREAK..
Recived bytes: «374»
Test 2: Ask HX Server for 1 ms BREAK..
Recived bytes: «000»
Test 3: Ask HX Server for 2 ms BREAK..
Recived bytes: «000»
Test 4: Ask HX Server for 20 ms BREAK..
Recived bytes: «000»
Test 5: Ask HX Server for 50 ms BREAK..
Recived bytes: «000»
===================================
BRKT1 - Test COM-port BREAK Part #1a
===================================
Test 1: Ask HX Server for 0.3 ms BREAK..
Recived bytes: «374»
Test 2: Ask HX Server for 1 ms BREAK..
Recived bytes: «000»
Test 3: Ask HX Server for 2 ms BREAK..
Recived bytes: «000»
Test 4: Ask HX Server for 20 ms BREAK..
Recived bytes: «000»
Test 5: Ask HX Server for 50 ms BREAK..
Recived bytes: «000»
BRKT2:
===================================
BRKT2 - Test COM-port BREAK Part #2
===================================
Test 1: Send SHORT BREAK..
«370»
Test 2: Send 1 byte BREAK..
_Break_«000»
Test 3: Send 2 byte BREAK..
_Break_«000»
Test 4: Send 3 byte BREAK..
_Break_«000»
Test 5: Send 10 byte BREAK..
_Break_«000»
Test 6: Send 20 byte BREAK..
_Break_«000»
Test 7: Send Bad Frame 1 ..
_Break_«000»«036»0«360»_Error+RX_
Test 8: Send Bad Frame 2 ..
_Break_«000»~«366»«377»
===================================
BRKT2 - Test COM-port BREAK Part #2
===================================
Test 1: Send SHORT BREAK..
«370»
Test 2: Send 1 byte BREAK..
_Break_«000»
Test 3: Send 2 byte BREAK..
_Break_«000»
Test 4: Send 3 byte BREAK..
_Break_«000»
Test 5: Send 10 byte BREAK..
_Break_«000»
Test 6: Send 20 byte BREAK..
_Break_«000»
Test 7: Send Bad Frame 1 ..
_Break_«000»«036»0«360»_Error+RX_
Test 8: Send Bad Frame 2 ..
_Break_«000»~«366»«377»
BRKT3E:
===================================
BRKT3 - Test COM-port BREAK Part #3e
===================================
Ask HX Server for 50 ms BREAK..
00000000 10000000 00000000 10000000 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
Test completed
===================================
BRKT3 - Test COM-port BREAK Part #3e
===================================
Ask HX Server for 50 ms BREAK..
00000000 10000000 00000000 10000000 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
Test completed
BRKT4:
===================================
BRKT4 - Test COM-port BREAK Part #4
===================================
Test 1: Send 0377 - Wait half bits - set 1 byte BREAK
_Error_«017»«340»
Test 2: Send 0377 - Wait half bits - set 2 byte BREAK
_Error_«017»«000»«300»_Break+0_
Test 3: Send 0377 - Wait half bits - set 8 byte BREAK
_Error_«017»«000»«000»«000»«000»«000» 000»«000»«000»«200»_Break+0_
Ask HX Server for ECHO: 'AB' - Wait 100 ms - Read bytes..
A
Ask HX Server for ECHO: 'ABC' - Wait 100 ms - Read bytes..
A
Test completed
===================================
BRKT4 - Test COM-port BREAK Part #4
===================================
Test 1: Send 0377 - Wait half bits - set 1 byte BREAK
_Error_«017»«340»
Test 2: Send 0377 - Wait half bits - set 2 byte BREAK
_Error_«017»«000»«300»_Break+0_
Test 3: Send 0377 - Wait half bits - set 8 byte BREAK
_Error_«017»«000»«000»«000»«000»«000» 000»«000»«000»«200»_Break+0_
Ask HX Server for ECHO: 'AB' - Wait 100 ms - Read bytes..
A
Ask HX Server for ECHO: 'ABC' - Wait 100 ms - Read bytes..
A
Test completed
Зависает, почему не знаю.Условия, необходимые для работы сжатия HX описаны ЗДЕСЬ (http://zx.pk.ru/showthread.php?postid=570292).
Кроме того - после выхода последнего дистрибутива сервера HX ( HX_Server_2.2_-_UKNC_21.01.13_16-15 (http://zx.pk.ru/attachment.php?attachmentid=39427) ) было ещё обновление загрузчиков:
Boot_RT-11_from_HX0_v1.2_176570 (http://zx.pk.ru/attachment.php?attachmentid=39465)
Boot_NC-11_from_HX0_v1.2_176570 (http://zx.pk.ru/attachment.php?attachmentid=39469)
Это универсальные загрузчики, не проверяющие бит оверрана ВП1-065.
...
Загрузчик RT-11, проверяющий бит оверрана ВП1-065 - здесь:
Boot_RT-11_from_HX0_(+065_overrun_test_v2_) (http://zx.pk.ru/attachment.php?attachmentid=39490)
В приложении к этому сообщению - специальный загрузчик NC-11 для ВП1-065, проверяющий при загрузке бит оверрана:
Boot_NC-11_from_HX0_(+065_overrun_test_v2_) (http://zx.pk.ru/attachment.php?attachmentid=39753)
...
Test 3: Send 0377 - Wait half bits - set 8 byte BREAK
_Error_«017»«000»«000»«000»«000»«000» 000»«000»«000»«200»_Break+0_Реакцию портов PC на "кривой брейк" настолько трудно понять и предсказать, что и думать не стоит - если реальная PDP-11 пошлёт такой брейк - эмулируемая PDP-11 примет явно не то, что приняла бы реальная и никакой "алгоритмической коррекцией" это не исправить.
А ведь у меня есть PCI-COM на чипе производства Oxford. Посмотрим работу с ним, квитирование отключено, 2 стоп-бита.
BRKT1A:
===================================
BRKT1 - Test COM-port BREAK Part #1a
===================================
Test 1: Ask HX Server for 0.3 ms BREAK..
Recived bytes: «374»
Test 2: Ask HX Server for 1 ms BREAK..
Recived bytes: «000»
Test 3: Ask HX Server for 2 ms BREAK..
Recived bytes: «000»
Test 4: Ask HX Server for 20 ms BREAK..
Recived bytes: «000»
Test 5: Ask HX Server for 50 ms BREAK..
Recived bytes: «000»
===================================
BRKT1 - Test COM-port BREAK Part #1a
===================================
Test 1: Ask HX Server for 0.3 ms BREAK..
Recived bytes: «374»
Test 2: Ask HX Server for 1 ms BREAK..
Recived bytes: «000»
Test 3: Ask HX Server for 2 ms BREAK..
Recived bytes: «000»
Test 4: Ask HX Server for 20 ms BREAK..
Recived bytes: «000»
Test 5: Ask HX Server for 50 ms BREAK..
Recived bytes: «000»
BRKT2:
===================================
BRKT2 - Test COM-port BREAK Part #2
===================================
Test 1: Send SHORT BREAK..
«370»
Test 2: Send 1 byte BREAK..
_Break_«000»
Test 3: Send 2 byte BREAK..
_Break_«000»
Test 4: Send 3 byte BREAK..
_Break_«000»
Test 5: Send 10 byte BREAK..
_Break_«000»
Test 6: Send 20 byte BREAK..
_Break_«000»
Test 7: Send Bad Frame 1 ..
_Break_«000»«036»0«301»
Test 8: Send Bad Frame 2 ..
_Break_«000»~«366»«377»
===================================
BRKT2 - Test COM-port BREAK Part #2
===================================
Test 1: Send SHORT BREAK..
«370»
Test 2: Send 1 byte BREAK..
_Break_«000»
Test 3: Send 2 byte BREAK..
_Break_«000»
Test 4: Send 3 byte BREAK..
_Break_«000»
Test 5: Send 10 byte BREAK..
_Break_«000»
Test 6: Send 20 byte BREAK..
_Break_«000»
Test 7: Send Bad Frame 1 ..
_Break_«000»«036»0«301»
Test 8: Send Bad Frame 2 ..
_Break_«000»~«366»«377»
BRKT3E:
===================================
BRKT3 - Test COM-port BREAK Part #3e
===================================
Ask HX Server for 50 ms BREAK..
00000000 10000000 00000000 10000000 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
Test completed
===================================
BRKT3 - Test COM-port BREAK Part #3e
===================================
Ask HX Server for 50 ms BREAK..
00000000 10000000 00000000 10000000 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
Test completed
BRKT4:
===================================
BRKT4 - Test COM-port BREAK Part #4
===================================
Test 1: Send 0377 - Wait half bits - set 1 byte BREAK
_Error_«017»«340»
Test 2: Send 0377 - Wait half bits - set 2 byte BREAK
_Error__Error_«017»«000»«200»
Test 3: Send 0377 - Wait half bits - set 8 byte BREAK
_Error__Error_«017»«000»«000»«000»«000» 000»«000»«000»_Error+0__Error_«000»«370»
Ask HX Server for ECHO: 'AB' - Wait 100 ms - Read bytes..
A
Ask HX Server for ECHO: 'ABC' - Wait 100 ms - Read bytes..
A
Test completed
===================================
BRKT4 - Test COM-port BREAK Part #4
===================================
Test 1: Send 0377 - Wait half bits - set 1 byte BREAK
_Error_«017»«340»
Test 2: Send 0377 - Wait half bits - set 2 byte BREAK
_Error__Error_«017»«000»«200»
Test 3: Send 0377 - Wait half bits - set 8 byte BREAK
_Error__Error_«017»«000»«000»«000»«000» 000»«000»«000»_Error+0__Error_«000»«370»
Ask HX Server for ECHO: 'AB' - Wait 100 ms - Read bytes..
A
Ask HX Server for ECHO: 'ABC' - Wait 100 ms - Read bytes..
A
Test completed
PCI-COM на чипе производства Oxford, квитирование отключено, 1 стоп-бит.
BRKT1A:
===================================
BRKT1 - Test COM-port BREAK Part #1a
===================================
Test 1: Ask HX Server for 0.3 ms BREAK..
Recived bytes: «374»
Test 2: Ask HX Server for 1 ms BREAK..
Recived bytes: «000»
Test 3: Ask HX Server for 2 ms BREAK..
Recived bytes: «000»
Test 4: Ask HX Server for 20 ms BREAK..
Recived bytes: «000»
Test 5: Ask HX Server for 50 ms BREAK..
Recived bytes: «000»
===================================
BRKT1 - Test COM-port BREAK Part #1a
===================================
Test 1: Ask HX Server for 0.3 ms BREAK..
Recived bytes: «374»
Test 2: Ask HX Server for 1 ms BREAK..
Recived bytes: «000»
Test 3: Ask HX Server for 2 ms BREAK..
Recived bytes: «000»
Test 4: Ask HX Server for 20 ms BREAK..
Recived bytes: «000»
Test 5: Ask HX Server for 50 ms BREAK..
Recived bytes: «000»
BRKT2:
===================================
BRKT2 - Test COM-port BREAK Part #2
===================================
Test 1: Send SHORT BREAK..
«370»
Test 2: Send 1 byte BREAK..
_Break_«000»
Test 3: Send 2 byte BREAK..
_Break_«000»
Test 4: Send 3 byte BREAK..
_Break_«000»
Test 5: Send 10 byte BREAK..
_Break_«000»
Test 6: Send 20 byte BREAK..
_Break_«000»
Test 7: Send Bad Frame 1 ..
_Break_«000»«036»0«301»
Test 8: Send Bad Frame 2 ..
_Break_«000»~«366»«377»
===================================
BRKT2 - Test COM-port BREAK Part #2
===================================
Test 1: Send SHORT BREAK..
«370»
Test 2: Send 1 byte BREAK..
_Break_«000»
Test 3: Send 2 byte BREAK..
_Break_«000»
Test 4: Send 3 byte BREAK..
_Break_«000»
Test 5: Send 10 byte BREAK..
_Break_«000»
Test 6: Send 20 byte BREAK..
_Break_«000»
Test 7: Send Bad Frame 1 ..
_Break_«000»«036»0«301»
Test 8: Send Bad Frame 2 ..
_Break_«000»~«366»«377»
BRKT3E:
===================================
BRKT3 - Test COM-port BREAK Part #3e
===================================
Ask HX Server for 50 ms BREAK..
00000000 10000000 00000000 10000000 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
Test completed
===================================
BRKT3 - Test COM-port BREAK Part #3e
===================================
Ask HX Server for 50 ms BREAK..
00000000 10000000 00000000 10000000 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00000000 10000001
00000000 10000001 00000000 10000001 00000000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
00010000 10000001 00010000 10000001 00010000 10000001 00010000 10000001
Test completed
BRKT4:
===================================
BRKT4 - Test COM-port BREAK Part #4
===================================
Test 1: Send 0377 - Wait half bits - set 1 byte BREAK
_Error_«017»«340»
Test 2: Send 0377 - Wait half bits - set 2 byte BREAK
_Error__Error_«017»«000»«300»
Test 3: Send 0377 - Wait half bits - set 8 byte BREAK
_Error__Error_«017»«000»«000»«000»«000» 000»«000»«000»«000»_Error+0_«370»
Ask HX Server for ECHO: 'AB' - Wait 100 ms - Read bytes..
A
Ask HX Server for ECHO: 'ABC' - Wait 100 ms - Read bytes..
A
Test completed
===================================
BRKT4 - Test COM-port BREAK Part #4
===================================
Test 1: Send 0377 - Wait half bits - set 1 byte BREAK
_Error_«017»«300»
Test 2: Send 0377 - Wait half bits - set 2 byte BREAK
_Error__Error_«017»«000»«200»
Test 3: Send 0377 - Wait half bits - set 8 byte BREAK
_Error__Error_«017»«000»«000»«000»«000» 000»«000»«000»«000»_Error+0_«360»
Ask HX Server for ECHO: 'AB' - Wait 100 ms - Read bytes..
A
Ask HX Server for ECHO: 'ABC' - Wait 100 ms - Read bytes..
A
Test completed
1. В этих тестах квитирование может играть роль только в 4-м тесте и только во второй его части ( при попытке принять на порту PDP-11 два байта подряд без чтения регистра состояния ). При включенном квитировании всё будет точно также, кроме второй части 4-го теста, где должны быть приняты все отправленные с PC байты ( сначала 'AB', потом 'ABC' ).
2. PCI-COM на чипе производства Oxford имеет другой алгоритм определения BREAK - "кривой брейк" он не принимает вообще.
...
бесконечный OverrunЧтобы не было оверрана - у ВП1-065 должно исправно работать квитирование на приём.
Подробности ЗДЕСЬ (http://zx.pk.ru/showthread.php?postid=570292).
...
Если интересно, могу выложить сюда реассемблированную прогу автоконфигурации от RSX. Она ищет все железо какое есть (требуется соблюдение правил выделения CSR) на компьютере и думпит в файл результат. RSXная часть разобрана и откоментирована, а дальше мне лень стало возиться :)
RSXная часть разобрана и откоментирована, а дальше мне лень стало возиться
Выкладывай, не зря же трудился? Сюда или вот в эту тему например http://zx.pk.ru/showthread.php?t=18420
Вобщем вот - кому надо, автоконфигуратор железа. Может чего интересного найдется :)
В последней версии "Эмулятора ДВК" (http://emulator.pdp-11.org.ru/DVK/distr/DVK_Emulator_13.02.13_23-42.rar) адаптер COM-порта якобы стал способен максимально качественно транслировать и байты, и сигналы BREAK в обоих направлениях между двумя COM-портами.
Для проверки этого на реальных портах нужно иметь PDP-11 и две PC, подключив PDP-11 к одному из портов первой PC ( например - COM1 ), запустив эмулятор с конфигом из приложения к этому сообщению ( COM1-COM2.cfg (http://zx.pk.ru/attachment.php?attachmentid=39834) ), соединив COM2 со второй PC и запустив там эмулятор TU58.
Мне такое на реальном оборудовании провернуть слабо.
...
Для проверки этого на реальных портах нужно иметь PDP-11 и две PC, подключив PDP-11 к одному из портов первой PC ( например - COM1 ), запустив эмулятор с конфигом из приложения к этому сообщению ( COM1-COM2.cfg (http://zx.pk.ru/attachment.php?attachmentid=39834) ), соединив COM2 со второй PC и запустив там эмулятор TU58.
Вечером посмотрю.
Только TU58 не может проверить в двух направлениях - там не предусмотрен BREAK в сторону ЭВМ.
TU58 не может проверить в двух направленияхФокус в том, что даже когда один порт из "соединённой пары" только принимает BREAK ( от PDP-11 ), а другой только передаёт ( на PC с эмулятором TU58 ) - тестирование кода реализации адаптера порта происходит в двух направлениях.
---------- Post added at 13:10 ---------- Previous post was at 13:06 ----------
Главная сложность транслирования BREAK под Windows в том, что Windows сообщает о начале BREAK, но ничего не "говорит" о его завершении. Приходится держать BREAK от истечения заранее заданной минимальной продолжительности BREAK до приёма байта в том порту, где до этого был BREAK ( смотря что случится позже ).
Главная сложность транслирования BREAK под Windows в том, что Windows сообщает о начале BREAK, но ничего не "говорит" о его завершении.
То есть 1:1 как в реальной жизни :)
---------- Post added at 17:13 ---------- Previous post was at 17:12 ----------
Фокус в том, что даже когда один порт из "соединённой пары" только принимает BREAK ( от PDP-11 ), а другой только передаёт ( на PC с эмулятором TU58 ) - тестирование кода реализации адаптера порта происходит в двух направлениях.
А-а, всмысле один эмулятор просто транслирует через себя?
А-а, всмысле один эмулятор просто транслирует через себя?Именно так.
Конфиг там - проще некуда:
[modules]
Ядро = Main_module.em
[objects]
ComPort1 = Ядро:Terminal_ComPort_Adapter
ComPort2 = Ядро:Terminal_ComPort_Adapter
[links]
ComPort1 <==> ComPort2
OK, сейчас сооружу что-нибудь с двумя портами.
OK, сейчас сооружу что-нибудь с двумя портами.
Проверил.
PDP-11/83 -> (COM2 <> COM1) -> TU58
TU58 не видит BREAK вообще. Если пропустить ожидание BREAK, загрузка начинается, но виснет еще на этапе отправки загрузчика из TU58.
COM порты полноценные, COM2 проверен терминалом, COM1 проверен попыткой E11 прочитать DD - читает.
---------- Post added at 22:03 ---------- Previous post was at 21:53 ----------
Поменял TU58 на VT220 - работает (BREAK не использовал).
---------- Post added at 22:09 ---------- Previous post was at 22:03 ----------
Завернул дальний конец обратно на PDP-11...
Тесты:
TEST1:: .WORD T1
MOV #BUFSZ,R1
CLR R0
10$: TSTB @#TCS
BPL 10$
MOVB R0,@#TDA
INC R0
SOB R1,10$
BR .
TEST2:: .WORD T2
TSTB @#TCS
BPL .-4
BIS #BRK,@#TCS
BR .
TEST3:: .WORD T3
TSTB @#TCS
BPL .-4
MOVB #123,@#TDA
BIS #BRK,@#TCS
BR .
TEST4:: .WORD T4
MOV #BUFSZ,R1
CLR R0
TSTB @#TCS
BPL .-4
BIS #BRK,@#TCS
10$: TSTB @#TCS
BPL 10$
MOVB R0,@#TDA
INC R0
MOV R1,FLAG
SOB R1,10$
BR .
TEST5: .WORD T5
MOV (PC)+,R1
DELAY: .WORD 50.
MOV R1,FLAG
ADD #50.,DELAY
CMP DELAY,#1050.
BEQ 10$
SUB #2,TESTP
10$: TSTB @#TCS
BPL .-4
MOVB #252,@#TDA
SOB R1,.
BIS #BRK,@#TCS
BR .
TEST6: .WORD T6
MOV #350.,R0
MOV #200.,R1
10$: TSTB @#TCS
BPL .-4
MOVB #-1,@#TDA
SOB R0,.
BIS #BRK,@#TCS
SOB R1,.
CLR @#TCS
BR .
TEST7:: .WORD T7
TSTB @#TCS
BPL .-4
MOVB #252,@#TDA
10$: BIT #4000,@#RCS
BEQ 10$
INC FLAG
BR .
TEST8:: .WORD T8
MOV #6,R1
TSTB @#TCS
BPL .-4
10$: CLR @#TDA
BIS #BRK,@#TCS
TSTB @#TCS
BPL .-4
MOV R1,FLAG
SOB R1,10$
CLR @#TCS
BR .
TEST9:: .WORD T9
MOV #BUFSZ,R1
10$: MOVB R1,@#TDA
SOB R1,10$
BR .
Результат:
TEST #1
000000 000001 000002 000003 000004 000005 000006 000007
FLAG: 000000
TEST #2
120000 000000
FLAG: 000000
TEST #3
120000 000000
FLAG: 000000
TEST #4
120000 000000
FLAG: 000001
TEST #5
120000 000000
FLAG: 000062
TEST #5
120000 000000
FLAG: 000144
TEST #5
120000 000000
FLAG: 000226
TEST #5
120000 000000
FLAG: 000310
TEST #5
120000 120000 120000 120000 120000 120000 120000 120000
FLAG: 000372
TEST #5
120000 120000 120000 120000 120000 120000 120000 120000
FLAG: 000454
TEST #5
120000 120000 120000 120000 120000 120000 120000 120000
FLAG: 000536
TEST #5
120000 120000 120000 120000 120000 120000 120000 120000
FLAG: 000620
TEST #5
120000 120000 120000 120000 120000 120000 120000 120000
FLAG: 000702
TEST #5
120000 120000 120000 120000 120000 120000 120000 120000
FLAG: 000764
TEST #5
120000 120000 120000 120000 120000 120000 120000 120000
FLAG: 001046
TEST #5
120000 120000 120000 120000 120000 120000 120000 120000
FLAG: 001130
TEST #5
120000 120000 120000 120000 120000 120000 120000 120000
FLAG: 001212
TEST #5
120000 120000 120000 120000 120000 120000 120000 120000
FLAG: 001274
TEST #5
120000 120000 120000 120000 120000 120000 120000 120000
FLAG: 001356
TEST #5
120000 120000 120000 120000 120000 120000 120000 120000
FLAG: 001440
TEST #5
120000 120000 120000 120000 120000 120000 120000 120000
FLAG: 001522
TEST #5
120000
FLAG: 001604
TEST #5
120000 120000
FLAG: 001666
TEST #5
120000 120000
FLAG: 001750
TEST #6
120000 000347
FLAG: 000000
TEST #7
000252
FLAG: 000000
TEST #8
120000 000000
FLAG: 000001
TEST #9
000007 000001
FLAG: 000000
То есть BREAK все-таки как-то передается. Может для 386 PC этого мало :)
TU58 не видит BREAK вообще.А если в этой же конфигурации загрузить на PC RT-11 под E-11, то тогда TU58 BREAK увидит.
В приложении конфиг для эмулятора ДВК DVK+COM1.cfg (http://zx.pk.ru/attachment.php?attachmentid=39843) в котором второй порт эмулируемой ДВК повешен на COM1.
Можно сравнить с работой E-11 с TU58 через этот же порт.
На com0com всё идеально работает.
...
А если в этой же конфигурации загрузить на PC RT-11 под E-11, то тогда TU58 BREAK увидит.
Для этого надо третий PC. Моя нотебяка не подойдет из-за кривых портов.
---------- Post added at 22:56 ---------- Previous post was at 22:53 ----------
Сейчас еще вручную попробую послать BREAK и два инита.
Эхх...
.BO
Other users are logged on.
Are you sure you want to stop the system?Y
[System shutdown]
Connect=00:24:00 CPU=00:02:37
Для этого надо третий PC.Имелось в виду - выключить "ретранслятор" и сравнить только отправку BREAK эмуляторами E11 и ДВК.
Имелось в виду - выключить "ретранслятор" и сравнить только отправку BREAK эмуляторами E11 и ДВК.
Чистый эмулятор нормально читает DD.
Регистр/вектор к слову неправильные в конфиге :)
---------- Post added at 23:16 ---------- Previous post was at 23:13 ----------
Хм...
PDP -> PC -> TU58 тоже читает DD нормально...
Сейчас еще проверю загрузку.
---------- Post added at 23:35 ---------- Previous post was at 23:16 ----------
.COP DD:/DEV DDIMG.DSK/FIL/NOQ
.COP DDIMG.DSK/FIL DD:/DEV/NOQ
С исправлением CSR/VEC в драйвере (вот почему подвисал на BOOT) в промежутке прошло успешно...
Но грузиться из DECовского загрузчика по прежнему не хочет (не видит BREAK).
---------- Post added at 23:38 ---------- Previous post was at 23:35 ----------
И также виснет на boot если пропустить проверку BREAK.
Вобщем надо анализировать чем отличется работа драйвера от загрузчика.
Но грузиться из DECовского загрузчика по прежнему не хочет (не видит BREAK)А на PC эмуляторы с того же TU58 грузятся ?
А на PC эмуляторы с того же TU58 грузятся ?
E11 не умеет сам грузиться с DD, а рукописной проги под рукой нету.
Сейчас набиваю загрузчик вручную на PDP-11 - посмотрим.
E11 не умеет сам грузиться с DDИз RT-11 надо сделать BOOT/FORE DD: - это будет точная копия аппаратной загрузки.
Из RT-11 надо сделать BOOT/FORE DD: - это будет точная копия аппаратной загрузки.
Кстати да, он же загрузочный :)
---------- Post added at 23:50 ---------- Previous post was at 23:47 ----------
Фокус не удался. Вспомнил что забыл сделать для загрузки.
Когда чтение/запись на DD работают - без проблем проходит COPY/BOOT прямо через COM-порт.
.COP/BO DD:RT11FB DD:
.BO DD:/FO
RT-11FB (S) V05.07
.SET USR NOSWAP
.
епромовский тоже пашет если в TU58 пропустить ожидание инициализации.
Commands are Help, Boot, List, Setup, Map and Test.
Type a command then press the RETURN key: B DD/A
CSR address = 176510
Trying DD0
Starting system from DD0
RT-11FB (S) V05.07
.SET USR NOSWAP
.
Вобщем надо смотреть в чем особенность епромовского и опубликованного загрузчиков. А пока попробую свой написать...
епромовский тоже пашет если в TU58 пропустить ожидание инициализацииА если напрямую к PDP-11 подключить порт TU58 - то эта проблема не возникает.
А если напрямую к PDP-11 подключить порт TU58 - то эта проблема не возникает.
Да, напрямую все работает без пинков - я так поднимал с нуля все.
Значит это проблема реализации прямого копирования порта в порт под Windows, с которой мне ещё надо поработать.
Сделать лог прихода байтов и брейков в порт TU58 вряд ли реально, а без этого понять в чём затык не получится.
Значит это проблема реализации прямого копирования порта в порт под Windows, с которой мне ещё надо поработать.
Сделать лог прихода байтов и брейков в порт TU58 вряд ли реально, а без этого понять в чём затык не получится.
Ну вобщем и так можно жить.
Сейчас допишу загрузчик, потом подумаю - может вспомню молодость и напрограмлю под дос думпилку того что прилетает.
---------- Post added at 00:44 ---------- Previous post was at 00:03 ----------
А как определяется время в течение которого нужно выдерживать BREAK на выходе?
А как определяется время в течение которого нужно выдерживать BREAK на выходе?Сначала должно пройти время, заданное параметром MinimalBreakTime_MKS, и если за это время накопились байты для передачи - BREAK снимается и байты передаются.
Иначе - BREAK снимается как только придёт первый байт для передачи.
Сначала должно пройти время, заданное параметром MinimalBreakTime_MKS и если за это время накопились байты для передачи - BREAK снимается и байты передаются.
Иначе - BREAK снимается как только придёт первый байт для передачи.
А настроить этот параметр где можно? В конфигах его нет ни в одном.
А настроить этот параметр где можно? В конфигах его нет ни в одном.Мне удалось найти:
[ComPort1.ini]
PortName = COM1
InitialStateOf[ShowPortUse]=0
SaveChangesFor[ShowPortUse]=0
InitialStateOf[StopReading]=0
SaveChangesFor[StopReading]=0
MinimalBreakTime_MKS = 3000
Мне удалось найти:
[ComPort1.ini]
PortName = COM1
InitialStateOf[ShowPortUse]=0
SaveChangesFor[ShowPortUse]=0
InitialStateOf[StopReading]=0
SaveChangesFor[StopReading]=0
MinimalBreakTime_MKS = 3000
А-а, у меня его просто нету. Надо было искать на уже запускавшемся в таком варианте видимо.
Сейчас включу тот комп.
Может сборка эмулятора старая - тогда BREAK транслироваться точно не будет.
Может сборка эмулятора старая - тогда BREAK транслироваться точно не будет.
Я старый стираю сразу после распаковки так как у тебя неудобная нумерация файлов и они в каталоге как попало лежат :)
---------- Post added at 01:12 ---------- Previous post was at 01:11 ----------
Однако и в том который работал нет такого файла...
Ты точно тот эмулятор выложил по ссылке? :)
---------- Post added at 01:12 ---------- Previous post was at 01:12 ----------
Хотя BREAK-то был как минимум в принципе.
---------- Post added at 01:13 ---------- Previous post was at 01:12 ----------
Не, вру, нашел.
Не там смотрел.
---------- Post added at 01:16 ---------- Previous post was at 01:13 ----------
А эти самые 3000 - это в каких единицах? :)
Максимум как я понимаю 20000 - обрезает до него если больше.
А эти самые 3000 - это в каких единицах?В микросекундах.
Минимум 1000.
Проблема может быть в том, что за время удержания брейка теряются байты, поэтому можно самую маленькую задержку попробовать.
В микросекундах.
Минимум 1000.
Проблема может быть в том, что за время удержания брейка теряются байты, поэтому можно самую маленькую задержку попробовать.
Попробую вытащить загрузчик из рома, скомпоновать с думпером и тогда можно будет играться. А то перетыкать клаву каждый раз чтобы перезапустить TU58 или тянуться через весь стол к нотебяку лениво.
---------- Post added at 02:21 ---------- Previous post was at 01:38 ----------
Загнал тот загрузчик которым пользовался пока не понял, что в роме есть родной, в качестве теста и посмотрел разицу:
Прямая петля:
120000 000004 000010 000000
Петля через эмулятор:
120000 000000 000004 000010 000000
От значения задержки не зависит.
---------- Post added at 02:25 ---------- Previous post was at 02:23 ----------
Ладно, наигрался пока. Пошел TSX ковырять. Могу кого-нибудь через телнет запустить параллельно в TSX на живом 11/83 :)
120000 000000 000004Брейк порождает в порту Windows фиктивный ноль, отличить который от настоящего можно только по времени прихода ( тесты показали уже, что этот ноль принимается не одновременно с сигналом BREAK, а немного позже ). Если бы принимающий и передающий порт работали синхронно - этот ноль умер бы сам во время брейка. А так он накапливается в буфере и отправляется передающим портом после снятия брейка.
Это очевидная ошибка для победы над которой потребуется ещё экран кода.
---------- Post added at 23:27 ---------- Previous post was at 23:14 ----------
Хотя, если в момент прихода сигнала BREAK сделать в Windows очистку входных буферов ( что вполне логично - какие ещё входные буфера, когда BREAK пришёл ), то вполне возможно, что фиктивный ноль умрёт не родившись.
Вообще лишний ноль по идее не должен был мешать. Вполне возможно, что это особенность именно этого эмулятора, который жестко привязан к 4 сразу после BREAK.
---------- Post added at 04:08 ---------- Previous post was at 03:55 ----------
Правда возможен еще вариант: и там и там съедается один 4, просто в одном случае совсем, в другом он вырождается в 0. По протоколу вроде два инита положено слать и в доке явно сказано что только по второму TU58 начнет работу.
Сейчас на код посмотрю что он должен слать вообще.
---------- Post added at 04:11 ---------- Previous post was at 04:08 ----------
Хотя проще посмотреть что шлет DD при чтении - там он тоже начинает с инита.
Утилитка для поиска DL(V)11-подобных контроллеров. В отличие от DECовских, находит все даже если нарушены правила размещения CSR (УКНЦ, ДВК).
На эмуляторе УКНЦ С2 как видно не желает интерруптить :)
Что выводит утилита DLTST на реале?
В эмуляторе UKNCBTL сейчас так:
CSR Vec Pri
------ --- ---
177560 60 4
176560 360 4
176570 370 4
176640 N/A -
176660 460 4
176670 N/A -
Что выводит утилита DLTST на реале?Типа, в качестве "реала" интересуют именно реальные УКНЦ, на которых их владельцам предлагается запустить DLTST.SAV (http://zx.pk.ru/attachment.php?attachmentid=39533) и сообщить результаты.
Хотя проще посмотреть что шлет DD при чтенииПотому чтение и проходит без проблем, что при чтении шлётся совсем другое.
Насколько я понял, у TU58 есть специальная команда "переслать загрузчик", чтобы можно было делать совсем компактные начальные загрузчики, и как раз эта команда критически искажается при ретрансляции.
...
Сделал новый вариант эмулятора: DVK_Emulator_18.02.13_19-37 (http://emulator.pdp-11.org.ru/DVK/distr/DVK_Emulator_18.02.13_19-37.rar), который якобы не должен транслировать фиктивный ноль при копировании траффика из одного COM-порта в другой.
Потому чтение и проходит без проблем, что при чтении шлётся совсем другое.
Шлется именно <BREAK><4><4>. Проверено. Шлется другим способом - это да.
Насколько я понял, у TU58 есть специальная команда "переслать загрузчик"
Да.
Сделал новый вариант эмулятора: DVK_Emulator_18.02.13_19-37 (http://emulator.pdp-11.org.ru/DVK/distr/DVK_Emulator_18.02.13_19-37.rar), который якобы не должен транслировать фиктивный ноль при копировании траффика из одного COM-порта в другой.
Сейчас посмотрим.
---------- Post added at 23:41 ---------- Previous post was at 23:36 ----------
Точно также - если просто запустить TU81.EXE не грузится, а если пропустить ожидание инициализации - грузится.
---------- Post added at 23:52 ---------- Previous post was at 23:41 ----------
Зато загрузчик которым я грузил поначалу грузит без проблем.
START: MOV #176510,R1
MOV #176514,R2
MOV R1,R0
INC @R2
10$: TSTB @R2
BPL .-2
ASL R0
BNE 20$
CLR @R2
MOV #4,R0
TST 2(R1)
20$: BIC #20,R0
MOV R0,2(R2)
BNE 10$
CLR R3
30$: TSTB @R1
BPL .-2
MOVB 2(R1),(R3)+
CMP #1000,R3
BHI 30$
CLR PC
Шлется именно <BREAK><4><4>.При запросе загрузчика шлётся ( насколько я понял ) <BREAK><4><10><Номер привода>.
10 - это команда RAW-передачи загрузчика, в ответ на которую должны прилететь 512 байтов из нулевого блока привода, указанного в команде.
При запросе загрузчика шлётся ( насколько я понял ) <BREAK><4><10><Номер юнита>.
10 - это команда RAW-передачи загрузчика, в ответ на которую должны прилететь 512 байтов из нулевого блока привода, указанного в команде.
Ну понятно, что команды отличаются, но суть остается - сначала инициализация, потом команды. Так вот при загрузке эмулятор TU58 так и не выходит из ожидания инициализации, а при чтении - выходит. Теперь вот загрузчик код которого я выше написал тоже нормально грузится.
Примечательно, что этот опубликованный загрузчик похоже специально написан для этого эмулятора. В доке по TU58 черным по белому написано, что аппарат не начнет работать пока не получит второй команды инициализации, а этот загрузчик шлет одну. Хотя надо еще раз почитать - может команда загрузки тоже годится :)
---------- Post added at 00:17 ---------- Previous post was at 00:12 ----------
Да, точно, можно BOOT слать:
Bootstrap - A flagbyte saying Bootstrap (octal 10), followed by a byte containing a drive number, causes the TU58 to read block 0 of the selected drive. It returns the 512 bytes without radial serial packaging. This simplifies bootstrap operations. Bootstrap may be sent by the host instead of a second INIT as part of the initialization process described below.
Сделал новый вариант эмулятора:
Этот вариант только ради сетевых тестов или обязательный к обновлению?
Кроме указанного изменения, другие ( в ini файлах например) изменения есть?
Этот вариант только ради сетевых тестов или обязательный к обновлению?Описание ЗДЕСЬ (http://zx.pk.ru/showthread.php?p=577479#post577479).
С DL(V)11 за последнее время наигрались. Пора заняться DZ(Q,V)11 :)
Поразбирался как оно работает немного. Один контроллер занимает 4 слова на IOPAGE в которых размещаются 6 регистров устройства:
Регистр состояния и управления (CSR), +0, RW
Буфер приемника (RBUF), +2, RO
Регистр параметров линии (LPR), +2, WO
Регистр управления передатчиком (TCR), +4 RW
Регистр состояния модема (MSR), +6 RO
Регистр данных передатчика (TDR), +6 WO
Биты CSR
<02:00> не используются
<03> MAINT, замыкание выходов на входы
<04> CLR, сброс устройства (бит сбрасывается по окончании сброса)
<05> MSE, разрешение сканирования линий
<06> RIE, разрешение прерываний от приемника
<07> RDONE, принят символ
<10:08> TLINE, номер линии передатчика треюующей обслуживания
<11> не используется
<12> SAE, разрешения прерываний по SA и запрет по RDONE
<13> SA, SILO заполнен (16 или более символов)
<14> TIE, разрешение перываний передатчика
<15> TRDY, передатчик линии TLINE готов к приему
В отличие от DL, здесь прерывания передатчика запрещать не нужно вообще. Когда прерывания от передатчика не нужны, просто очищается соответствующий бит в TCR.
Сканирование линий идит сверху вниз. Как только найдена линия, готовая к передаче, сканирование останавливается, номер линии заносится в биты TLINE CSR и выставляется сигнал TRDY. Если при этом выставлен бит TIE, происходит прерывание. Пока линия не будет обслужена (передан символ или снят бит данной линии в TCR), сканирование не возобновится. После обслуживания, сканирование продолжится с того места где остановилось и потом начнется сначала.
При приеме символа, выставляется бит RDONE, если установлен бит RIE, происходит прерывание (если установлен бит SAE, то прерывание происходит только когда заполнится SILO и установится бит SA - в этот момент устройство приняло не менее 16 символов).
Устройства бывают с поддержкой 4 и 8 линий. В оригинале на QBUS поддерживаются только 4 линии, однако попалось описание не-DECовского DZV11 с 8 линиями. В случае 4 линий, старший бит не используется и при записи его должен быть нулем.
Биты RBUF
<07:00> принятый символ
<10:08> номер линии с которой символ принят
<11> не используется
<12> ошибка четности
<13> frame error
<14> overrun
<15> считаные данные актуальны
Здесь вобщем-то все понятно. Бит 15 показывает, что все прочитанное из регистра актуально (считан символ и состояние). Полезно при включенном SAE для вычитывание всех символов которые устройство приняло.
Биты LPR (только запись)
<02:00> - номер линии для которой выставляются параметры
<04:03> длина символа
00 - 5 бит
01 - 6 бит
10 - 7 бит
11 - 8 бит
<05> стоп биты
0 - 1 стоп бит
1 - 2 (1.5) стоп бита
<06> parity enable
<07> odd parity
<11:08> скорость
0000 - 50
0001 - 75
0010 - 110
0011 - 134.5
0100 - 150
0101 - 300
0110 - 600
0111 - 1200
1000 - 1800
1001 - 2000
1010 - 2400
1011 - 3600
1100 - 4800
1101 - 7200
1110 - 9600
1111 - 19800 (скорость не поддерживается DECовским софтом, для DECовского DZQ11 написано что может быть и не 19800 в зависимости от перемычек; для не-DECовского DZV11 написано просто 19200)
<12> разрешение приемника
<15:13> не используется
Биты TCR
<07:00> разрешения передатчика линий 0-7
<15:08> DTR для линий 0-7
Биты MSR
<07:00> RI линий 0-7
<15:08> DCD линий 0-7
Биты TDR
<07:00> - символ для передачи в линию заданную битами <10:07> CSR
<15:08> - посылка BREAK в линии 0-7
Все регистры кроме RBUF и MSR допускают байтовое обращение к младшему и старшему байту.
---------- Post added at 20:15 ---------- Previous post was at 20:13 ----------
Первая прога как обычно - offline терминальчик по опросу. Только в отличие от DL, здесь сразу охватываются все линии мультиплексора :)
.TITLE DZT
.IDENT /V01.00/
DZ$CSR = 160100 ;АДРЕС CSR
DZ.CSR = 0 ;CSR
DZ.BUF = 2 ;БУФЕР ПРИЕМНИКА
DZ.LPR = 2 ;РЕГИСТР ПАРАМЕТРОВ ЛИНИИ
DZ.TCR = 4 ;РЕГИСТР УПРАВЛЕНИЯ ПЕРЕДАЧЕЙ
DZ.TDR = 6 ;РЕГИСТР ДАННЫХ ПЕРЕДАЧИ
TRDY = 100000 ;ГОТОВНОСТЬ ПЕРЕДАТЧИКА
RDONE = 200 ;СИМВОЛ ПРИНЯТ
MSE = 40 ;РАЗРЕШЕНИЯ СКАНИРОВАНИЯ
MCLR = 20 ;СБРОС УСТРОЙСТВА
S9600 = 7000 ;СКОРОСТЬ 9600
CL8 = 30 ;ДЛИНА СИМВОЛА 8 БИТ
ST1 = 0 ;1 СТОП БИТ
RXEN = 10000 ;РАЗРЕШЕНИЕ ПРИЕМНИКА
.MCALL .DEVICE
START: .DEVICE #AREA,#LIST ;СБРОС УСТРОЙСТВА ПО ВЫХОДУ
MOV #DZ$CSR,R5 ;УСТАНАВЛИВАЕМ CSR
BIS #MCLR,@R5 ;СБРОС УСТРОЙСТВА
BIT #MCLR,@R5 ;ЗАВЕРШЕН?
BNE .-4 ;НЕТ ЕЩЕ
MOV #8.,R0 ;ИНИЦИАЛИЗИРУЕМ ЛИНИИ
MOV #S9600!CL8!ST1!RXEN,R1 ;
10$: MOV R1,DZ.LPR(R5) ;
INC R1 ;
SOB R0,10$ ;
MOV #MSE,@R5 ;РАЗРЕШАЕМ СКАНИРОВАНИЕ
20$: TSTB @R5 ;ЖДЕМ НАЖАТИЯ КЛАВИШИ
BPL .-2 ;
MOV DZ.BUF(R5),R0 ;ПОЛУЧАЕМ ДАННЫЕ
MOV R0,R1 ;ПОЛУЧАЕМ НОМЕР ЛИНИИ
SWAB R1 ;
BIC #^C7,R1 ;
MOVB LINE(R1),DZ.TCR(R5) ;РАЗРЕШАЕМ ПЕРЕДАТЧИК ДЛЯ ЛИНИИ
TST @R5 ;ЖДЕМ ГОТОВНОСТИ ПЕРЕДАТЧИКА
BPL .-2 ;
MOVB R0,DZ.TDR(R5) ;ПЕРЕДАЕМ СИМВОЛ
CLR DZ.TCR(R5) ;ЗАПРЕЩАЕМ ПЕРЕДАТЧИК
BR 20$ ;КУ
AREA: .BLKW 2
LIST: .WORD DZ$CSR,MCLR
.WORD 0
LINE: .BYTE 1,2,4,10,20,40,100,200
.END START
---------- Post added at 20:19 ---------- Previous post was at 20:16 ----------
Про вектора ничего не сказал... Но тут вобщем-то все также: XX0 - прерывание приемника, XX4 - прерывание передатчика.
Замерил количество NOPов между прерываниями на DZQ11. Исходное состояние - выполнен master clear, дождались завершения, тест. Первый тест - просто разрешили прерывания от передатчика линии 0 и пошли нопы, остальные 23 теста - вывод символа и нопы. С разными скоростями. 19800 условно - сколько реально оно дает - фиг знает. На скоростях ниже 600 доходит до HALT в конце буфера.
600 1200 2000 2400 3600 4800 7200 9600 19800
----- ----- ----- ----- ----- ----- ----- ----- -----
440 440 440 440 440 440 440 440 440
705 550 505 515 489 469 459 457 447
16306 8355 5169 4394 3069 2404 1743 1414 901
16205 8404 6410 5823 4023 3120 2218 1768 1072
16205 8389 5953 5391 4375 3385 2395 1899 1135
16207 8395 6122 5553 4502 3482 2460 1949 1158
16206 8394 6060 5493 4540 3519 2484 1966 1167
16206 8392 6084 5514 4550 3531 2492 1973 1170
16207 8397 6076 5509 4547 3536 2497 1977 1173
16208 8395 6079 5511 4549 3539 2499 1977 1172
16208 8396 6080 5512 4550 3541 2497 1980 1175
16209 8397 6079 5511 4550 3539 2500 1978 1173
16210 8396 6080 5512 4551 3543 2501 1980 1175
16209 8397 6080 5512 4550 3542 2500 1979 1176
16211 8396 6081 5513 4552 3544 2502 1981 1176
16210 8400 6081 5513 4552 3544 2502 1982 1177
16213 8397 6083 5514 4553 3544 2504 1982 1177
16211 8400 6082 5515 4553 3545 2502 1982 1178
16213 8400 6084 5515 4554 3544 2504 1984 1178
16212 8400 6083 5515 4554 3546 2504 1981 1179
16215 8402 6084 5516 4554 3546 2505 1985 1179
16213 8401 6084 5516 4555 3545 2503 1984 1180
16215 8402 6086 5517 4555 3548 2507 1985 1180
16213 8400 6082 5514 4553 3545 2503 1983 1178
И для интереса разрешил все линии сразу. Тест на скорости 9600, остальные лень делать. Да вобщем-то и так примерно понятно :)
449
450
451
451
452
452
453
453
1321
463
514
455
1646
465
515
458
1767
467
518
459
1813
469
519
461
Отключил пока петли с DZQ11, подключил VT220.
Тест показал, что условные 19800 соответствуют нормальным 19200.
Как-то выкладывал здесь недоразобранную программу автоконфигурации.
Вот более старый вариант (из RSX-11M-PLUS V3.0) в исходниках. Думаю кое-что полезного из них можно почерпнуть...
ZIPовал в VMSе, возможно при распаковке надо делать "unzip -a", но может и не надо.
открыл в winrar-е, там инфо показывает базовую ось vax/vms :) прикольно :)
AlexCherny
14.03.2013, 00:07
Как-то выкладывал здесь недоразобранную программу автоконфигурации.
Вот более старый вариант (из RSX-11M-PLUS V3.0) в исходниках. Думаю кое-что полезного из них можно почерпнуть...
ZIPовал в VMSе, возможно при распаковке надо делать "unzip -a", но может и не надо.
На скорую руку посмотрел модуль ACFROT.MAC в архиве - в нём среди прочего определяется тип процессора и набор дополнительных (к базовому набору) инструкций процессора.
Не помню точно, но кажется, что при генерации ОС РВ ACF.TSK не запускался. Или нужно было бы подправить значение "TICKS: .WORD 60." на 50 с точкой - на наши 50 Гц.)))
Не помню точно, но кажется, что при генерации ОС РВ ACF.TSK не запускался. Или нужно было бы подправить значение "TICKS: .WORD 60." на 50 с точкой - на наши 50 Гц.)))
Тики ему пофигу, а вот запускаться он должен обязательно из базовой системы которая живет в [2,54], а у нас по советски обычно считалось - а нафига она если в [1,54] тоже система есть :)
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot