Особенности процессоров и устройств архитектуры PDP-11. Тесты. Диагностика.

[Alex_K]

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 тактов.

[Advertiser]

[Patron]

Отлично ловится из прерываний

Т.е. прерывание возникает в тот момент, когда должен прийти стоповый бит и если этот бит стартовый - в этот же момент устанавливается и признак 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

[form]

Т.е. прерывание возникает в тот момент, когда должен прийти стоповый бит и если этот бит стартовый - в этот же момент устанавливается и признак BREAK, а в младший байт регистра данных помещается ноль.

Да.
После этого сколько бы BREAK не висел, готовности больше не будет, а в регистре данных будет висеть то же значение (120000).

[Titus]

Т.е. в NOPах это будет 180/16 = 12, а за два цикла - 24 NOPа.

NOP - 14-15 тактов, на большинстве машин 14.

[Patron]

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

[Patron]

Для правильной эмуляции последовательных портов важно знать, что получит принимающая строна, если начать непрерывно писать байты в регистр данных передатчика, не проверяя его готовность.

...

Хотя, секрета тут никакого нет. Пока бит готовности не установлен - запись в порт ни на что не влияет. Важнее проверить - сохраняется ли в регистре данных порта значение, если оно было записано туда при сброшенном бите готовности.

[form]

Результаты теста выводятся в тестируемый порт. По умолчанию - это порт С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 и назад не читаются. Впрочем это ничем не отличается от "не сохраняется"

[Patron]

Даже если сохраняется внутренне, проверить не получится: как значение для вывода оно не отработается, а биты эти в регистре данных WO и назад не читаются. Впрочем это ничем не отличается от "не сохраняется"

Мой эмулятор только что так же популярно об этом мне напомнил - каждая команда INC @#TPB посылает исключительно и только байт 01.

---------- Post added at 14:15 ---------- Previous post was at 14:10 ----------

Добавил также тест в свой DL<>DL (8 символов)

Фактически - это разновидность NOP-метра, проверяющего время установки готовности при передаче байта порт, сдвиговый регистр которого в этот момент свободен.

[Patron]

Для дальнейшего тестирования работы последовательных портов с сигналом BREAK - мною написан тест BRKT4.

Для правильной работы теста необходимо, чтобы при его выполнении квитирование было отключено, поэтому не следует трогать настройку COM-порта

fOutxCtsFlow = FALSE

Также не следует включать сжатие при загрузке с этого сервера.

Этот тест проверяет, какой сигнал получит COM-порт PC если установить BREAK в середине передачи байта 0377, а также проверяет гипотезу о наличии и работе буфера FIFO в контроллере 1801ВП1-065.

Тест требует наличия с другой стороны тестируемой линии специального тестового варианта сервера HX Server, который умеет по запросу клиента посылать в линию эхо, а также превращает получаемые в порту сигналы в текстовые сообщения.

Для проведения тестов нужно запустить прилагаемый 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 у данного сервера.

Адаптированные исходники предыдущих тестов также включены в архив.

...

[form]

Для дальнейшего тестирования работы последовательных портов с сигналом 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