Просмотр полной версии : УКНЦ загрузка через стык С2
Alex_K, вп1-065 переключил на укнц на скорость выше 9600?можно фото где эти перемычки искать?
Если схемотехника Квантовская - то под клавиатурой (http://kisly-alexey.pisem.net/UKNC/IMAG0372.jpg). А если СЭМЗ-овская, то переключать только программным способом.
---------- Post added 10.01.2013 at 00:18 ---------- Previous post was 09.01.2013 at 23:59 ----------
На случай, если потоковые буфера Windows имеют размер под сотню килобайт - написана специальная программа SPAM.SAV, посылющая в порт С2 УКНЦ столько байтов - что мало не покажется.
Увы, часть времени у программы уходит на формирование выводимой строки, да и строка выводится через EMT 351, значит используется операционная система, потом идут прерывания от терминала для вывода, так что здесь даже порт до максимальной скорости не дотягивает.
Alex_K, под клавиатурой есть такое дело.
Увы, часть времени у программы уходит на формирование выводимой строки, да и строка выводится через EMT 351, значит используется операционная система, потом идут прерывания от терминала для вывода, так что здесь даже порт до максимальной скорости не дотягивает.Здесь идея в том, чтобы проверить - пропадут или не пропадут байты в COM-порту Windows, когда сервер надолго перестанет их принимать, а потом продолжит.
Если сначала установить fRtsControl = RTS_CONTROL_ENABLE, а потом fRtsControl = RTS_CONTROL_HANDSHAKE - то разница должна быть очевидной.
---------- Post added at 23:36 ---------- Previous post was at 23:27 ----------
Если RTS_CONTROL_HANDSHAKE работает как надо - можно будет даже оценить размер потокового буфера Windows, как разницу между номером последней ( перед отключением приёма ) строки спама в окне Teletype и номером строки, на которой заблокируется работа SPAM.SAV (этот номер выводится на экран УКНЦ).
Каждая строка спама = 80 байтов.
Здесь идея в том, чтобы проверить - пропадут или не пропадут байты в COM-порту Windows, когда сервер надолго перестанет их принимать, а потом продолжит.
Если сначала установить fRtsControl = RTS_CONTROL_ENABLE, а потом fRtsControl = RTS_CONTROL_HANDSHAKE - то разница должна быть очевидной.
При fRtsControl = RTS_CONTROL_ENABLE естественно посылка в порт все время продолжается, байты теряются. При fRtsControl = RTS_CONTROL_HANDSHAKE посылка через некоторое время приостанавливается, потерь вроде нет. Нажал примерно на 103, остановилось на 147.
При fRtsControl = RTS_CONTROL_HANDSHAKE посылка через некоторое время приостанавливается, потерь вроде нет. Нажал примерно на 103, остановилось на 147.Всё, что выводится в окно Teletype - одновременно пишется в файл Teletype.log - его можно открыть и внимательно всё проверить.
Любое окно начинает писать своё содержимое в файл, если в его настройках указать:
[Teletype.ini]
TabTitle=""
InitialStateOf[ControlBar]=0
SaveChangesFor[ControlBar]=0
InitialStateOf[StatusBar]=1
SaveChangesFor[StatusBar]=0
DumpMode=1
InitialStateOf[Log]=1
SaveChangesFor[Log]=0
Получается, что для каждого открытого COM-порта Windows заводит потоковый буфер объёмом примерно 3 Килобайта.
В принципе - Win32 API позволяет напрямую заказывать объём потокового буфера для порта, но это будет актуально только для мегабитных скоростей, которые у большинства последовательных портов не встречаются.
...
P.S. А проблемы со скоростью чтения у "продвинутого варианта" адаптера порта не могли быть вызваны, например, выключенным сжатием ?
Ну вот, вроде отладил и протокол HX v2.1, и драйвер HX.SYS v2.1.
Сервер HX для УКНЦ, поддерживающий новый протокол с новым драйвером: HX_Server 2.1_-_UKNC_10.01.13_21-06 (http://emulator.pdp-11.org.ru/misc/HX_Server%202.1_-_UKNC_10.01.13_21-06.rar).
...
4.В архиве уже содержится образ системы с драйвером HX. HXsys54.DSK
Вот бы теперь узреть смертельный номер - RSX-11M запущенная на УК-НЦ! :) Есть ли принципиальные преграды на этом пути? (ну естественно non mapped system на 56кб но все же!)
Вот бы теперь узреть смертельный номер - RSX-11M запущенная на УК-НЦ! :) Есть ли принципиальные преграды на этом пути? (ну естественно non mapped system на 56кб но все же!)
Принципиальных приград нет - написать драйверы устройства и загрузчика. Смысла только в этом нет - так, побаловаться. RSX-11 без MMU превращается в весьма неуклюжую систему из которой придется убрать больше половины полезного функционала.
---------- Post added at 07:59 ---------- Previous post was at 07:58 ----------
Можно запустить 11S (собственно это тот же 11M только упрощенный) - ему даже драйвера не нужны.
Написал специальный первичный загрузчик для УКНЦ: Boot_RT-11_from_HX0.BIN ( исходники в файле BotHX0.MAC ) и добавил в настройки объекта UKNCcomSender опцию, включающую впечатывание даты и времени сервера в передаваемый файл ( в ячейки 06..012 ). По умолчанию эта опция включена, поэтому теперь загрузка должна идти с привода HX0 с установкой на УКНЦ даты и времени сервера: HX_Server 2.1_-_UKNC_11.01.13_16-10 (http://emulator.pdp-11.org.ru/misc/HX_Server%202.1_-_UKNC_11.01.13_16-10.rar).
В драйвере HX.SYS устранена ошибка из-за которой все предыдущие драйверы выводили сообщение об ошибке чтения вторичного загрузчика не на экран, а в порт HX.
...
Написал специальный первичный загрузчик для УКНЦ: Boot_RT-11_from_HX0.BIN ( исходники в файле BotHX0.MAC ) и добавил в настройки объекта UKNCcomSender опцию, включающую впечатывание даты и времени сервера в передаваемый файл ( в ячейки 06..012 )...
Не очень хорошие ячейки выбраны. Все дело в том, что в ячейке 6 у меня оказалось значение 062. Вторичный загрузчик для определения объема памяти меняет только значение вектора 4, а значит при прерывании TRAP4 заодно в PSW устанавливается бит T, вектор 14 не инициализирован, отсюда всякие последствия. Лично у меня вылетает в пульт с адресом 160000.
---------- Post added at 19:08 ---------- Previous post was at 18:45 ----------
Заметил еще, что в файле teletype.log оказываются не все строки, хотя в окне на закладке Teletype HX-сервера они присутствуют. Какой-то закономерности не заметил. Использовал для этого программу SPAM.SAV.
Перевыложил архив - теперь ячейки 06..012 очищаются сразу после входа в загрузчик и копирования даты и времени.
---------- Post added at 18:25 ---------- Previous post was at 18:22 ----------
в файле teletype.log оказываются не все строки, хотя в окне на закладке Teletype HX-сервера они присутствуют. Какой-то закономерности не заметил. Использовал для этого программу SPAM.SAV.SPAM.SAV нумирует строки. Если какие-то пропускаются, то в логе это хорошо должно быть видно.
1. Строки целиком пропадают ?
2. Какой максимальный разрыв между номерами последовательных строк в teletype.log ?
1. Строки целиком пропадают ?
2. Какой максимальный разрыв между номерами последовательных строк в teletype.log ?
Пропадает какая-нибудь одна строка из четырех "SPAM". Закономерности никакой нет. Но это строка присутствует в логе Teletype HX-сервера.
Интересно посмотреть какой-нибудь такой файл teletype.log..
Изучаю контент этой темы вот с чем столкнулся
http://savepic.ru/3839055.png
C2 LINK ругается )
последнее сообщение как-бы подвисает, но машинка(система) отлипает по CTRL+C
Дискету не выкладываю, поскольку жду уже всем всем одобренной версии драйвера HX.SYS )
C2 LINK ругаетсяМоя ошибочка - перевыложил архив с исправленным вариантом C2.MAC:
HX_Server 2.1_-_UKNC_11.01.13_16-10 (http://emulator.pdp-11.org.ru/misc/HX_Server%202.1_-_UKNC_11.01.13_16-10.rar)
...
Интересно посмотреть какой-нибудь такой файл teletype.log..
Интересно? Получите. Нету строк с номерами 50, 92 и 274. В окне лога HX-сервера они все присутствуют.
Кстати, сделал опыт, скопировав командой COPY/DEV HX0: HX7:, один диск в другой. Во время процесса копирования нажимал кнопочку "Stop reading", процесс копирования действительно приостанавливался, потом возобновлял. После копирования оба диска были идентичны, никакого расхождения, а значит и потерь нет.
После копирования оба диска были идентичны, никакого расхождения, а значит и потерь нет.Только начиная с версии протокола HX v2.1 начало стандартно для RT-11 отрабатываться частичное чтение по запросам, выходящим за границу образа. До этого и источник, и приёмник на границе образа не читались и не писались вообще, поэтому хотя BINCOM и не мог увидеть там различий - они в принципе могли быть.
Только начиная с версии протокола HX v2.1 начало стандартно для RT-11 отрабатываться частичное чтение по запросам, выходящим за границу образа. До этого и источник, и приёмник на границе образа не читались и не писались вообще, поэтому хотя BINCOM и не мог увидеть там различий - они в принципе могли быть.
Ну это еще можно проверить файлы в командной строке с помощью команды "fc /b". Но раньше я не проверял, а на HX 2.1 проверил - нормально. Тут еще BINCOM.SAV так написан, что он запрашивает размеры дисков после того, как попытался прочесть за границей диска.
Нету строк с номерами 50, 92 и 274. В окне лога HX-сервера они все присутствуют.Все окна в HX-сервере - это экземпляры объекта "консоль".
Строк в логе нет целиком, значит консоль просто не пишет их в файл ( строка должна писаться в лог в момент перехода на новую строку ). Консоль написана много лет назад и имеет несколько глюков, если строки выводятся очень быстро. Вот теперь выяснилось, что и в лог некоторые строки при быстром выводе не попадают.
---------- Post added at 19:22 ---------- Previous post was at 19:18 ----------
BINCOM.SAV так написан, что он запрашивает размеры дисков после того, как попытался прочесть за границей диска.BINCOM.SAV из RT-11 v05.07 запрашивает размер сначала, но читает всё равно огромными кусками до тех пор, пока драйвер не вернёт ошибку чтения. Это сделано намерено, поскольку разные драйверы в RT-11 по-разному реагируют на попытку чтения за пределами устройства, а в BINCOM.SAV реализован универсальный алгоритм, позволяющий сравнивать блочные устройства с, например, перфолентами ( там запрос размера устройства ничем не поможет ).
В с такой дискеты УК-НЦ можно будет запустить? )
http://savepic.ru/3806316.png
Image : RT1154Y_HX_UKNC.dsk
Format : DSK
Size : 800 Kb
Volume ID: RT11A
Owner :
File Blocks Date Bytes
---------- ------ ----------- ----------
SWAP .SYS 27P 19-Dec-1988 13'824
RT11SJ.SYS 78P 16-Dec-2012 39'936
TT .SYS 2P 23-Jan-1980 1'024
STARTS.COM 1 11-Jan-2013 512
RESORC.SAV 25 01-Mar-2012 12'800
IND .SAV 58 18-Jan-1988 29'696
DUP .SAV 45 27-Dec-1983 23'040
LD .SYS 8P 18-Jan-1988 4'096
DAY .SAV 4 19-Dec-2012 2'048
SPAM .MAC 4 09-Jan-2013 2'048
WD .SYS 3P 05-Aug-1979 1'536
WE .SYS 2P 16-May-1979 1'024
COLS .SAV 17 09-Aug-1990 8'704
WDR .SAV 3 01-Oct-1980 1'536
RUS .SAV 2 16-Oct-1994 1'024
SYS .SAV 3 30-May-1979 1'536
LAT .SAV 2 16-Oct-1994 1'024
TTY .SAV 3 25-Jan-1991 1'536
NYS .SAV 22 22-Oct-1993 11'264
PMEM .SAV 2 25-Aug-1993 1'024
TUK .SAV 35 27-Mar-1980 17'920
TS .SAV 40 31-Jul-1992 20'480
SKY .SAV 4 08-Apr-1993 2'048
MZFORM.SAV 6 13-Jun-1990 3'072
CAT .SAV 52 01-Sep-1992 26'624
HUST .SAV 6 31-Dec-1999 3'072
FONTUK.SAV 5 31-Dec-1999 2'560
AC .SYS 5P 12-Sep-1994 2'560
MZ .SYS 4P 12-Jan-1990 2'048
PIP .SAV 30 31-Oct-1998 15'360
DESS19.SAV 19 04-Mar-1994 9'728
MACRO .SAV 63 21-Dec-2012 32'256
LINK .SAV 59 31-Oct-1998 30'208
SYSMAC.SML 92 31-Oct-1998 47'104
DIR .SAV 20 31-Oct-1998 10'240
DISASM.SAV 8 07-Dec-2011 4'096
SL .SYS 10 19-Jan-1988 5'120
UCL .SAV 2 31-Dec-1999 1'024
KLAV .SAV 18 10-Feb-1989 9'216
RMKOI8.SAV 6 31-Dec-1999 3'072
RDWR .SAV 3 20-Dec-1991 1'536
TSSPD .SAV 23 25-Apr-1980 11'776
SYSLIB.OBJ 47 19-Dec-1988 24'064
SPAM .SAV 2 31-Dec-1999 1'024
TSSPD .MAC 93 11-Jan-2013 47'616
BINCOM.SAV 25 31-Oct-1998 12'800
BOT .COM 1 11-Jan-2013 512
BOTHX0.MAC 10 11-Jan-2013 5'120
C2 .COM 1 09-Jan-2013 512
C2 .MAC 5 11-Jan-2013 2'560
HX .COM 1 17-Nov-2012 512
HX .MAC 28 11-Jan-2013 14'336
C2 .LST 13 31-Dec-1999 6'656
HX .LST 73 31-Dec-1999 37'376
HX .SYG 4 31-Dec-1999 2'048
BOTHX0.LST 27 31-Dec-1999 13'824
BOTHX0.BIN 1 31-Dec-1999 512
C2 .SYS 2 31-Dec-1999 1'024
HX .SYS 4 31-Dec-1999 2'048
< UNUSED > 428 219'136
---------- ------ ----------- ----------
59 Files, 1158 Blocks
428 Free blocks
Воспринимая критику кабеля со стороны Vamos, хочу предложить следующий вариант:
Разъем Разъем
Стык С2 DB9S
1,10 (102) ■─────────────────────■ 5 (GND)
5 (103) ■──────────┐ ┌────■ 3 (TD)
┌────■│■────┘
6 (104) ■────┘ └──────────■ 2 (RD)
3 (+5В) ■─ ┌────■ 4 (DTR)
│
7 (109) ■────────────────┤ ─■ 1 (CD)
│
└────■ 6 (DSR)
2 (108) ■──────────┐ ┌────■ 7 (RTS)
┌────■│■────┘
9 (107) ■────┘ └──────────■ 8 (CTS)
Отличается тем, что на вход 7 УКНЦ (сигнал 109) подается не +5В с УКНЦ, а сигнал DTR с PC. Сразу предупрежу, что этот кабель для УКНЦ с квантовской схемотехникой. На УКНЦ с СЭМЗ-овской схемотехникой на вход 7 надо подавать ТТЛ-уровень, так что там остается вариант только с +5В.
Для нормального функционирования данного кабеля в настройках HX-сервера обязательно должны стоять следующие параметры:
fDtrControl = DTR_CONTROL_ENABLE
fRtsControl = RTS_CONTROL_HANDSHAKE
StopBits = TWOSTOPBITS
fOutxCtsFlow = TRUE
fOutxDsrFlow = TRUE
hobot, RT1154Y_HX22_UKNC.rar запустил...
http://i.piccy_.info/i7/0b5ceecb7ba157ba7a0d197090d0b0cc/4-55-601/20896698/20130111_213418_218_240.jpg (http://piccy_.info/view3/3968149/05fecdf2b2877b805f864ec38efdfd71/)http://i.piccy_.info/a3/2013-01-11-19-23/i7-3968149/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-11-19-23/i7-3968149/240x180-r)
RT1154Y_HX22_UKNC.rar запустил...
там есть тест DR_Titusa ! )
Patron, Словил баг что ли - у меня образ всегда грузится с HX2:
На новой версии первый блок грузиться с HX2: а остальные только с HX0:.Тоесть образ должен быть загружен в HX0: и HX2: одинаковый и одновременно
Patron,
какой именно образ?
hobot, HX_Server 2.1_-_UKNC_11.01.13_16-10.rar из новой версии .Раньше я на HX0 и HX1 свои образы загружал,а в HX2 загрузочный образ был
Воспринимая критику кабеля со стороны Vamos, хочу предложить следующий вариант кабеляНо если с этим вариантом кабеля сигнал DTR постоянно установлен через fDtrControl = DTR_CONTROL_ENABLE - то какой тогда смысл в fOutxDsrFlow = TRUE ?
Ведь, если на входе DSR всегда будет TRUE от DTR - никакого управления потоком через DSR не будет..
Но если с этим вариантом кабеля сигнал DTR постоянно установлен через fDtrControl = DTR_CONTROL_ENABLE - то какой тогда смысл в fOutxDsrFlow = TRUE ?
Ведь, если на входе DSR всегда будет TRUE от DTR - никакого управления потоком через DSR не будет..
А нет никакого смысла. Управление через DTR/DSR не ведется. А на самом деле смысл есть только в установке fDtrControl = DTR_CONTROL_ENABLE, чтобы открывало вход для посылок извне на УКНЦ, а fOutxDsrFlow = TRUE так для проверки, что DTR установился.
И какие вообще преимущества должен ( по идее ) дать пятый провод в кабеле, когда и четырёх проводов больше чем достаточно..
Ведь, провод RTS реально используется только тогда, когда сервер не забирает байты у Windows более 3 секунд ( а он обычно это делает 60 раз в секунду ). Если просто подать TRUE на вывод 9(107) и не распаивать провод RTS в кабеле - ни какой разницы при реальной работе не будет.
---------- Post added at 23:19 ---------- Previous post was at 23:15 ----------
А нет никакого смысла.Не нужно вообще с DTR заморачиваться - это совершенно бессмысленная затея. Со стороны PC ни DTR, ни DSR распаивать не надо.
И какие вообще преимущества должен ( по идее ) дать пятый провод в кабеле, когда и четырёх проводов больше чем достаточно..
А каких четырех? Давайте считать. 1 - земля, 2 - принимаемые данные, 3 - передаваемые данные, 4 - контроль по CTS. Ну и если нет контроля по RTS, то с RTS или DTR подать сигнал на вход УКНЦ 7 (сигнал 109), иначе посылки приниматься не будут, это пятый.
с RTS или DTR подать сигнал на вход УКНЦ 7 (сигнал 109)Зачем для этого провод тянуть.. Разве в самой УКНЦ нужный уровень найти трудно ?
Зачем для этого провод тянуть.. Разве в самой УКНЦ нужный уровень найти трудно ?
Был по этому поводу спор с Vamos. Я использовал для этого +5В с самого разъема стык С2. Но у меня УКНЦ со всеми винчами и дисководами питается от AT-источника питания. У Vamos УКНЦ питается от своего источника, который довольно хилый. А ведь сигналы уровня RS-232 это не TTL-уровень, там размах от -12В до +12В, естественно после подключения кабеля у него была просадка до 4.4В. Сразу скажу, что в УКНЦ СЭМЗ-овской схемотехники этот вход 7 (сигнал 109) сделан как ТТЛ-уровень, поэтому там можно подать (да и нужно) +5В. А вот для УКНЦ с квантовской схемотехникой нужен сигнал уровня RS-232, и остается подать его только с PC.
для УКНЦ с квантовской схемотехникой нужен сигнал уровня RS-232, и остается подать его только с PC.Тогда DSR распаивать не надо, а DTR использовать "в роли RTS", задав:
fDtrControl = DTR_CONTROL_HANDSHAKE
fRtsControl = RTS_CONTROL_HANDSHAKEНекоторые сомневаются, работает ли нога DTR у ВП1-065 так же оперативно, как нога RTS.
Самое время это проверить при помощи кнопки запрета приёма.
---------- Post added at 23:39 ---------- Previous post was at 23:37 ----------
Можно вообще на стороне ВП1-065 объединить этот сигнал для 7(109) и 9(107)
Была у меня еще мысль выпаять резистор который с -12 на 109 и может даже на +5 этот резистор подключить, но как на это отреагирует 170УП ?
Тогда DSR распаивать не надо, а DTR использовать "в роли RTS", задав:
fDtrControl = RTS_CONTROL_HANDSHAKE
fRtsControl = RTS_CONTROL_HANDSHAKEНекоторые сомневаются, работает ли нога DTR у ВП1-065 так же оперативно, как нога RTS.
Самое время это проверить при помощи кнопки запрета приёма.
DSR действительно можно не распаивать, а вот fDtrControl = ENABLE, иначе при переполнении входного буфера в Windows закроется вход у УКНЦ. Да и ноги DTR у 1801ВП1-065 нету, из управляющих есть только BSYD (подключается к RTS PC) и RR (подключается к CTS PC).
>palsw
Что тест Titusa пишет? ) - мои результаты (http://zx.pk.ru/showpost.php?p=471887&postcount=215) )
Можно вообще на стороне ВП1-065 объединить этот сигнал для 7(109) и 9(107)
Лучше не надо. Но если fRtsControl = RTS_CONTROL_ENABLE будет всегда, то тогда можно.
Но смысла в экономии проводов нет, т.к. со стороны УКНЦ идет разъем IDC-10 и туда просто зажимается плоский 10-жильный кабель. А распаивается уже DB-9 со стороны PC.
при переполнении входного буфера в Windows закроется вход у УКНЦВ случае HX это не страшно - протокол симплексный.
И остается вопрос почему RTS/CTS на схеме УКНЦ обозначены как 107/108, если по описанию в ГОСТе должны быть 105/106.
смысла в экономии проводов нетТогда из предложенной схемы нужно просто выкинуть распайку DSR.
В случае HX это не страшно - протокол симплексный.
А в других случаях? Уж кабель должен быть сделан так, чтобы поддерживалось квитирование в обе стороны, да и возможно чтобы было работать в полном дуплексе.
На новой версии первый блок грузиться с HX2: а остальные только с HX0А если в файле UKNC_HX_COM.cfg включить запись на диск лога HX:
[HX_Log.ini]
TabTitle =""
InitialStateOf[StatusBar] = 0
SaveChangesFor[StatusBar] = 0
InitialStateOf[ControlBar] = 0
SaveChangesFor[ControlBar] = 0
InitialStateOf[Log] = 1
SaveChangesFor[Log]=0
DumpMode=1
то что в процессе загрузки запишется в файл HX_Log.log ?
---------- Post added at 23:59 ---------- Previous post was at 23:54 ----------
У palsw с новым загрузчиком первый блок грузиться с HX2 и только остальные с HX0 - это у всех так ?
И остается вопрос почему RTS/CTS на схеме УКНЦ обозначены как 107/108, если по описанию в ГОСТе должны быть 105/106.
Ну в первоначальном варианте УКНЦ по техописанию были все сигналы, т.е. и RTS, и CTS, и DTR, и DSR. Но реально 1801ВП1-065 поддерживает только два сигнала. Да и сигналы DTR и DSR не имеют к обмену никакого отношения. Эти сигналы о том, что аппаратура включена, или на компьютере программа будет использовать COM-порт. Т.е. включили модем и если DSR оказался активен, то можем судить, что на модем подали питание. А вот сигналы RTS и CTS служат как раз для управления обменом и каждая из сторон предупреждает другую, может ли она в данный момент принять данные. Так что сначала хотели сделать на УКНЦ и что в итоге получили - большая разница. Да и сигнал 109, который закрывает вход, имеет обозначение DCD, его ставит модем, когда установил связь с другим модемом, а если связь не установлена, то УКНЦ вообще ничего не сможет получить.
---------- Post added at 01:02 ---------- Previous post was at 01:01 ----------
У palsw с новым загрузчиком первый блок грузиться с HX2 и только остальные с HX0 - это у всех так ?
У меня нормально, все с нулевого драйва.
Похоже, я понял, что может вызывать проблему.
В приложении - новый вариант сервера ( HX_Server 2.1_-_UKNC_12.01.13_04-11 ) с драйвером HX.SYS и загрузчиком Boot_RT-11_from_HX0.bin, которые более корректно осуществляют повторные попытки загрузки при неудаче первой ( ошибка чтения вторичного загрузчика пока может быть обнаружена только при отключенном сжатии ).
Также изменены ячейки для впечатывания даты в передаваемый загрузчик.
...
Могу предложить ещё один вариант решения проблемы с сигналом 109 :)
Идея следующая, сделать так что бы 109 не влиял на прием данных не зависимо от того к чему он подключен. Для этого нужно найти выв. 12 микросхемы ЛН3 который звонится на выв. 28 ВП1-065 и отсоединить его от платы :)
Ну этот вариант для тех, кто дружен с электроникой и паяльником. А если кто-то не хочет лезть в плату?
Нелогично называть универсальным решение, которое работает только тогда, когда программа ставит fDtrControl = DTR_CONTROL_ENABLE.
Ведь в любом случае нужно что-то паять. Уж если паять - то так, чтобы работа не зависела от наличия нужного уровня на выводе DTR.
То же относится и к закорачиванию DTR и DSR на стороне PC. Это решение никак нельзя назвать универсальным - всегда есть такой набор настроек порта, при установке которых работа через подобный "универсальный" кабель станет невозможна.
Patron, еще в последних версиях HX-сервера заметил такую особенность - если при старте, когда еще не было загрузки с HX, можно было нажимать и отжимать кнопку "Boot HX0", а после загрузки, если ее нажать, то она сразу отжимается и в последовательный порт начинает поступать первичный загрузчик.
Еще есть предложение - может передаваемую дату и номер загружаемого устройства располагать в последних словах, там в конце как раз четыре свободных слова. А потом с этих слов копировать в ячейки вторичного загрузчика.
после загрузки, если ее нажать, то она сразу отжимается и в последовательный порт начинает поступать первичный загрузчик.Значит, там фаза не сбрасывается в начальное состояние и после первого срабатывания - UKNCcomSender продолжает "думать", что только что получил с УКНЦ байт промпта. Сейчас исправлю.
может передаваемую дату и номер загружаемого устройства располагать в последних словах, там в конце как раз четыре свободных слова. А потом с этих слов копировать в ячейки вторичного загрузчика.Я затеял экстремальную компактизацию загрузчика, чтобы освободить достаточно места для подсчёта контрольной суммы передаваемых пакетов ( сейчас контрольная сумма загрузчиком не проверяется ), поэтому в последней версии загрузчика дата впечатывается прямо в код:
BOOT:
Mov #5000, R2 ; R2 -> Time & Date block in BSTRAP
Mov (PC)+, (R2)+ ; Set TicksHi
TicksHi:
.Word 0
Mov (PC)+, (R2)+ ; Set TicksLo
TicksLo:
.Word 0
Mov (PC)+, (R2)+ ; Set Date
Date:
.Word 0 ;
ReBOOT:
Mov #10000, SP ; Boottime SP value
Clr @(PC)+ ; Warm Boot ( set Date & Time )
BDEVU: .Word 0 ; Boot from Unit 0 ( ONLY !!! )
Я затеял экстремальную компактизацию загрузчика, чтобы освободить достаточно места для подсчёта контрольной суммы передаваемых пакетов ( сейчас контрольная сумма загрузчиком не проверяется ), поэтому в последней версии загрузчика дата впечатывается прямо в код:
BOOT:
Mov #5000, R2 ; R2 -> Time & Date block in BSTRAP
Mov (PC)+, (R2)+ ; Set TicksHi
TicksHi:
.Word 0
Mov (PC)+, (R2)+ ; Set TicksLo
TicksLo:
.Word 0
Mov (PC)+, (R2)+ ; Set Date
Date:
.Word 0 ;
ReBOOT:
Mov #10000, SP ; Boottime SP value
Clr @(PC)+ ; Warm Boot ( set Date & Time )
BDEVU: .Word 0 ; Boot from Unit 0 ( ONLY !!! )
В этом случае адреса ячеек могут быть разными после очередной оптимизации, а так они будут всегда одинаковыми, ну и в этом случае оптимизироваться можно до бесконечности.
Неплохо бы в очередной версии HX-сервере сделать выбор загружаемого устройства.
Если вторичному загрузчику не принципиально, чтобы в 4-х последних словах были -1, тогда можно. Когда я модифицировал первичный загрузчик MX, создалось впечатление, что вторичный загрузчик при работе что-то в последние 4 слова первичного пишет, но насколько важно их начальное значение - непонятно.
Неплохо бы в очередной версии HX-сервере сделать выбор загружаемого устройства.Если выбирать номер загружаемого устройства в cfg-файле (путём текстового редактирования), то чтобы подставить нужный образ в HX0 - требуется столько же кликов, как и чтобы задать номер загружаемого привода в каком-то другом месте.
Любой другой способ - еще накладнее, поэтому логично оставить как есть и выбирать загружаемый образ путём редактирования раздела [HX.ini].
---------- Post added at 13:40 ---------- Previous post was at 13:37 ----------
Чтобы загрузиться с другого привода уже после загрузки с HX0 - достаточно в RT-11 подать команду BOOT HXn:
Если выбирать номер загружаемого устройства в cfg-файле (путём текстового редактирования), то чтобы подставить нужный образ в HX0 - требуется столько же кликов, как и чтобы задать номер загружаемого привода в каком-то другом месте.
Любой другой способ - еще накладнее, поэтому логично оставить как есть и выбирать загружаемый образ путём редактирования раздела [HX.ini].
---------- Post added at 13:40 ---------- Previous post was at 13:37 ----------
Чтобы загрузиться с другого привода уже после загрузки с HX0 - достаточно в RT-11 подать команду BOOT HXn:
Так вопрос идет не о загрузочном файле, а именно о номере загружаемого привода. Да и сначала грузится с HX0:, а потом с другого - накладно по времени. Также не забывайте, что у УКНЦ есть и второй процессор, там при загрузке могут остаться резиденты, отсюда следует, что образ в HX0: должен быть минималистичным.
---------- Post added at 15:21 ---------- Previous post was at 14:46 ----------
Если вторичному загрузчику не принципиально, чтобы в 4-х последних словах были -1, тогда можно. Когда я модифицировал первичный загрузчик MX, создалось впечатление, что вторичный загрузчик при работе что-то в последние 4 слова первичного пишет, но насколько важно их начальное значение - непонятно.
Ничего у меня при загрузке не портится в ячейках 770-777. несколько раз нажимал "СТОП" и смотрел значения. Начали они портится только тогда, когда SP стал равен 01000, ну думаю тут понятно почему.
Так вопрос идет не о загрузочном файле, а именно о номере загружаемого привода.Зачем какой-то образ может потребоваться грузить обязательно с какого-то конкретного (не нулевого) привода ?
Зачем какой-то образ может потребоваться грузить обязательно с какого-то конкретного (не нулевого) привода ?
Разные конфигурации. Не стоит забывать, что у УКНЦ есть периферийный процессор, а собственно универсального протокола о взаимодействии загружаемых модулей нет. Соответственно существуют программы, использующие ПП, взаимно не совместимые друг с другом.
Кстати об оптимизации - можно оптимизировать, а точнее убрать макрос SOB, все равно загрузчик чисто для УКНЦ, а команда SOB в 1801ВМ2 есть.
Возможны только две ситуации:
1. Мы ещё не загружены и хотим загрузить какой-то образ - тогда в любом случае нужно редактировать cfg-файл ( или как сейчас - подставлять нужный образ в HX0, или как предлагается - изменять в настройках номер загружаемого привода ). По совершаемым действиям это равноценно. Никакой выгоды возможность задания номера загружаемого привода в такой ситуации не даёт.
2. Мы уже загружены и хотим загрузиться с другого привода - тогда лучше команды BOOT HXn: ничего быть не может.
В какой ситуации возможность задания номера загружаемого привода в cfg-файле может дать решающее преимущество ?
---------- Post added at 14:38 ---------- Previous post was at 14:37 ----------
все равно загрузчик чисто для УКНЦ, а команда SOB в 1801ВМ2 есть.Это универсальный загрузчик. На ДВК он будет загружаться небольшим предварительным ODT-скриптом, имитирующим поведение УКНЦ при загрузке из порта С2. Только при компиляции нужно будет другой адрес порта указать.
---------- Post added at 14:43 ---------- Previous post was at 14:38 ----------
Кстати, образ в приводе HX0 можно сменить и без редактирования cfg-файла, тогда как изменить номер загружаемого привода можно было бы только редактированием.
В какой ситуации возможность задания номера загружаемого привода в cfg-файле может дать решающее преимущество ?
Если у меня несколько конфигураций, скажем штук 5, в приводах с HX2: по HX6:, и грузить мне их можно только на холодную, т.е. перезапустить УКНЦ кнопочкой <Reset>. Тут уже лучше сразу их расставить заранее во все приводы, а потом выбирать загрузочный номер.
---------- Post added at 15:53 ---------- Previous post was at 15:49 ----------
Это универсальный загрузчик. На ДВК он будет загружаться небольшим предварительным ODT-скриптом, имитирующим поведение УКНЦ при загрузке из порта С2. Только при компиляции нужно будет другой адрес порта указать.
Можно сделать условную компиляцию и этого макроса. Соответственно, указали - нужен он нам или нет. А также все ДВК имеют команду SOB, этой команды нет только на самых первых PDP-11, точнее по моделям на 04, 05/10, 15/20.
Фокус в том, что выбирать номер можно только редактированием cfg-файла, предварительно закрыв сервер, а выбирать образ - при работающем сервере - кнопкой на полосе статуса.
Поэтому, если расположить все образы в приводах HX1..HX7, а образ в приводе HX0 выбирать непосредственно перед нажатием <Reset> на УКНЦ - всё будет легко и приятно и не надо будет: 1) Выкючать сервер; 2) Изменять номер в cfg-файле; 3) Запускать сервер.
---------- Post added at 14:57 ---------- Previous post was at 14:55 ----------
Можно сделать условную компиляцию и этого макроса.На суть это не влияет - ведь если считать контрольную сумму - это надо делать для всех вариантов компиляции.
Фокус в том, что выбирать номер можно только редактированием cfg-файла, предварительно закрыв сервер, а выбирать образ - при работающем сервере - кнопкой на полосе статуса.
Поэтому, если расположить все образы в приводах HX1..HX7, а образ в приводе HX0 выбирать непосредственно перед нажатием <Reset> на УКНЦ - всё будет легко и приятно и не надо будет: 1) Выкючать сервер; 2) Изменять номер в cfg-файле; 3) Запускать сервер.
Так ведь собственно можно сделать так, что если кнопка "Boot HX0" находится в отжатом положении, а мы ее нажимаем, то выводится меню с HX0 по HX7. Выбираем HX2, кнопочка становится нажатой, но уже с надписью "Boot HX2".
Так ведь собственно можно сделать так, что если кнопка "Boot HX0" находится в отжатом положении, а мы ее нажимаем, то выводится меню с HX0 по HX7. Выбираем HX2, кнопочка становится нажатой, но уже с надписью "Boot HX2".Кнопка [Boot HX0] - это объект модульного API типа SB_StatePushButton, подключаемый к любому состоянию любого объекта модульного API и позволяющий: 1) определять фазу состояния объекта по виду кнопки; 2) изменять фазу состояния объекта при помощи нажатий кнопки.
Если не учинять апгрейд API, а использовать те возможности, которые уже есть - загрузка с HX0 с предварительным выбором загружаемого образа при помощи кнопки выбора образов - оптимальное решение.
Новый вариант сервера ( HX_Server 2.1_-_UKNC_12.01.13_16-01 (http://emulator.pdp-11.org.ru/misc/HX_Server%202.1_-_UKNC_12.01.13_16-01.rar) ) с загрузчиком Boot_RT-11_from_HX0.bin, который (якобы) проверяет при загрузке контрольные суммы получаемых пакетов протокола HX.
Теперь повторная передача загрузчика при нажатии кнопки [Boot HX0] должна начинаться только после повторного получения промпта от УКНЦ.
Изменены ячейки для впечатывания даты в передаваемый загрузчик - теперь это ячейки 0770, 0772, 0774
...
А полноценный драйвер для УКНЦа появился уже?
Всмысле чтобы функционал системы не ломал - там этого вроде не требуется :)
Попутно заглянул в драйвер, заполнение остатка блока нулями делается драйвером, что криво и накладно. Это задача контроллера (сервера).
Специально перенёс заполнение нулями из сервера в драйвер, чтобы протокол стал более однозначным - при запросе у сервера чтения одного байта - читается один байт, при запросе записи одного байта - пишется один байт.
Специально перенёс заполнение нулями из сервера в драйвер, чтобы протокол стал более однозначным - при запросе у сервера чтения одного байта - читается один байт, при запросе записи одного байта - пишется один байт.
А оно так и получается в любом случае: передается столько сколько указано. Зануление конца блока - не передача данных, а документированное требование к блочным устройствам, актуальное по сей день.
Обращаю внимание: к устройствам, не к драйверу.
А полноценный драйвер для УКНЦа появился уже? Всмысле чтобы функционал системы не ломал - там этого вроде не требуетсяВ смысле, чтобы номер загружаемого привода принимался в R0 ?
В смысле, чтобы номер загружаемого привода принимался в R0 ?
Всмысле чтобы .READ и .READC работали.
В случае когда делается смешивание консоли с диском такое потребует вмешательства в систему или написание драйвера хукающегося по принципу PI. Для отдельного порта таких трудностей нет.
Всмысле чтобы .READ и .READC работали.А как .READ и .READC реализованы у VM.SYS и как они работают у MX.SYS ( MX.SYS при работе вообще запрещает прерывания ) ?
А как .READ и .READC реализованы у VM.SYS и как они работают у MX.SYS ( MX.SYS при работе вообще запрещает прерывания ) ?
VM.SYS - драйвер мгновенного действия (и то он как раз из-за этого имеет проблемы в SJ), а что касается MX - у нас полно драйверов криво писали. Но это же не повод перенимать глупости :)
Ладно бы были трудности, так ведь их нет.
А так, согласись, драйвер который ломает функционал системы - драйвером называться не имеет права :)
---------- Post added at 14:39 ---------- Previous post was at 14:25 ----------
Наглядный пример потери функционала из-за нерабочести .READ/.READC. Это тупой тест, а я видел достаточно много программ которые выполняли реальную работу во время I/O.
Прога тупо читает 20. блоков с SY: и пока они читаются занимается своими делами (инкрементит счетчик).
.TITLE TIO -- I/O TEST
.IDENT /V01.00/
.MCALL .LOOKUP,.READC,.EXIT,.PRINT
START:: .LOOKUP #AREA,#0,#DBLK
BCC 20$
.PRINT #ERR1
10$: CLR R0
.EXIT
20$: .READC #AREA,#0,#BUFF,#WCNT,#CRTN,#0
BCC 30$
.PRINT #ERR2
BR 10$
30$: CMP FLAG,#1
BCC 40$
ADC COUNT+2
ADC COUNT
BR 30$
40$: MOV #VALUE,R0
MOV COUNT,R1
MOV PC,R2
CALL $CBOMG
MOVB #<',>,(R0)+
MOV COUNT+2,R1
MOV PC,R2
CALL $CBOMG
.PRINT #VALUE
BR 10$
CRTN:: INC FLAG
RETURN
COUNT:: .WORD 0,0
FLAG:: .WORD 0
BUFF:: .BLKW 256.*20.
WCNT == <.-BUFF>/2
DBLK:: .RAD50 /SY/
.WORD 0,0,0
AREA:: .BLKW 7
VALUE: .ASCIZ /XXXXXX,XXXXXX/
ERR1: .ASCIZ /LOOKUP FAILED/
ERR2: .ASCIZ /READ FAILED/
.END START
На достаточно быстром SCSI на 11/83 имеем (время меньше секунды):
.RU TIO
000000,002275
.
На УКНЦ (MZ по прерываниям [что не несет никаких проблем программам, работающим с ПП несмотря на мифы об этом]) получается 167000 с чем-то, время около секунды. А на HX примерно за пол минуты имеем ноль сделанного :)
На УКНЦ (MZ по прерываниям [что не несет никаких проблем программам, работающим с ПП несмотря на мифы об этом])
Небольшой оффтоп - хотелось бы поподробнее узнать про мифы насчет этого.
Небольшой оффтоп - хотелось бы поподробнее узнать про мифы насчет этого.
Мифы читал у Арсения на сайте - там выложена подборка каких-то статей, среди прочего была статья с исходниками драйвера MZ без прерываний и обоснование - мол поскольку работают через одну дырку, драйвер может мешать - глотает прерывания (и соответственно портит содержимое CSR или что-то в этом роде). Теоретически такое возможно например в случае запуска чтения с MZ вышеупомянутыми .READ/.READC и параллельной загрузки кода в ПП. Ну или в случае кривого драйвера (что по-видимому имело место с автором статьй) который не выключает прерывания по завершению I/O.
Мифы читал у Арсения на сайте - там выложена подборка каких-то статей, среди прочего была статья с исходниками драйвера MZ без прерываний и обоснование - мол поскольку работают через одну дырку, драйвер может мешать - глотает прерывания (и соответственно портит содержимое CSR или что-то в этом роде). Теоретически такое возможно например в случае запуска чтения с MZ вышеупомянутыми .READ/.READC и параллельной загрузки кода в ПП. Ну или в случае кривого драйвера (что по-видимому имело место с автором статьй) который не выключает прерывания по завершению I/O.
А-а-а-а!!!!! Теперь понял. Смысл состоит в том, что если программа через канал 2 передает блок (а это четыре байта), и в это время произойдет прерывание от драйвера MZ, и он тоже начнет что-то передавать по каналу К2, то собьется синхронизация счетчика драйвера канала 2 в системном ПЗУ ПП. Но вообще-то это невозможно, т.к. последний четвертый байт не читается из К2 со стороны ПП, пока не будет завершена операция. Т.е. если по .READ/.READC что-то запросить и сразу же попробовать работать с К2, то у него не будет установлен бит готовности. Как-то вот так ...
то у него не будет установлен бит готовности. Как-то вот так ...
Да, это я проверял когда свой драйвер писал.
Так, что остается просто кривой драйвер который всегда держит прерывания разрешенными. Ну или в FB можно в теории нарваться :)
В самом начале тестирования HX-сервера с УКНЦ - квитирование, помнится, не хотело работать.
А что если HX-сервер не всё сетапит в COM-порту, что надо - и поэтому нормально работает только тогда, когда между включением PC и его запуском не запускались другие программы, работающие с тем же COM-портом..
Возможно, есть смысл это проверить, запустив на этом же COM-порту сначала эмулятор TU58 или HyperTerminal и только затем - HX-сервер.
Эмулятор TU58 работает только на полноценных портах. На моем ST-Labовском USBшном двойнике к примеру работать не будет из-за кривой реализации break (подозреваю, что драйвера такие [у всех pci, usb железок]). А HX вполне пашет несмотря на то, что порт плюется громадными пакетами символов за раз :)
В самом начале тестирования HX-сервера с УКНЦ - квитирование, помнится, не хотело работать.
А что если HX-сервер не всё сетапит в COM-порту, что надо - и поэтому нормально работает только тогда, когда между включением PC и его запуском не запускались другие программы, работающие с тем же COM-портом..
Возможно, есть смысл это проверить, запустив на этом же COM-порту сначала эмулятор TU58 или HyperTerminal и только затем - HX-сервер.
Квитирование не хотело работать по другой причине. Первое - передача с УКНЦ уходила всегда, потому что всегда на входе BSYD 1801ВП1-065 был активный уровень, связанный с настройками fRtsControl = RTS_CONTROL_ENABLE. После изменения на fRtsControl = RTS_CONTROL_HANDSHAKE все стало в этом плане нормально работать. В случае с приемом ситуация оказалась потяжелее. После получения очередного байта 1801ВП1-065 выставлял неактивный уровень на выходе RR. По идее Windows со своей стороны должна была это видеть и прекратить передачу со своей стороны. Решилось это следующими установками: fOutxCtsFlow = TRUE и StopBits = TWOSTOPBITS. Первая установка заставляет следить Windows за уровнем сигнала CTS, и не передавать, когда он неактивный. А вот два стоп-бита пришлось поставить потому, потому что с одним стоп-битом Windows не успевала обрабатывать CTS и умудрялась послать очередной байт, в связи с чем на УКНЦ возникала ошибка переполнения, если предыдущий байт не был считан.
Но попробую запущу и TU58, и гипертерминал, но попозже.
Возможно, есть смысл это проверить, запустив на этом же COM-порту сначала эмулятор TU58 или HyperTerminal и только затем - HX-сервер.
Ну, как и предполагалось все нормально работает и после запуска TU58, и после запуска гипертерминала. Ну а собственно и не могло быть иначе, ведь HX-сервер программирует COM-порт через структуру DCB.
с одним стоп-битом Windows не успевала обрабатывать CTS и умудрялась послать очередной байт, в связи с чем на УКНЦ возникала ошибка переполнения, если предыдущий байт не был считан.Мне почему-то кажется, что если передающий порт использует один стоповый бит, а принимающий - два, то правильно может быть передан только первый байт в непрерывном потоке байтов.
Мне почему-то кажется, что если передающий порт использует один стоповый бит, а принимающий - два, то правильно может быть передан только первый байт в непрерывном потоке байтов.
Кажется неправильно. С одним стоп-битом работает, если не используется сжатие. Со сжатием сразу проблемы, если передаваемый блок большой и хорошо запакован.
Новый вариант сервера ( HX_Server 2.1_-_UKNC_13.01.13_18-28 (http://emulator.pdp-11.org.ru/misc/HX_Server%202.1_-_UKNC_13.01.13_18-28.rar) ) с загрузчиком Boot_RT-11_from_HX0.bin, который (якобы):
1. При обнаружении любой ошибки протокола - входит в режим пропуска байтов, из которого выходит только тогда, когда за 12 выводов байта 015 в порт терминала - в порт HX не поступит ни одного байта от сервера.
2. При входе в первичный драйвер запоминает параметры вызова процедуры чтения и, в случае ошибки передачи - после процедур, описанных выше - повторяет ошибочно завершившийся запрос.
...
С одним стоп-битом работаетТеперь понятно, почему предыдущие попытки наладить управление потоком между PC и 1801ВП1-065 кончались печалью.
Байты от PC проходили и с одним стоповым битом, поэтому в ходе экспериментов никто не сподобился переключить COM-порт на два стоповых бита.
Попробовал провести опыт с USB-COM-портом. Чип Prolific PL2303-HXA, сейчас он уже не поддерживается производителем, драйвера старые. Использовал HX-сервер версии "HX_Server 2.1_-_UKNC_12.01.13_16-01".
Первоначально все шло замечательно, загрузка прошла с включенным сжатием, никаких зависаний и ошибок. Тест командой DIR/BAD/FIL прошел без всяких проблем, во время чтения данных выходил в пультовый отладчик и смотрел регистр 176570, никакого переполнения.
Проблемки начались при исполнении команды COP/DEV HX0: HX7:. При нажатии кнопки "Stop reading" посылка данных останавливалась, при отжатии - возобновлялась, проблем нет. Оставил исполняться команду до конца. Во время HX-WRITE появилась ошибка контрольной суммы. На этом завершилось. Перезапустил HX-сервер и УКНЦ, прогрузка с включенным сжатием не пошла - ошибки переполнения.
Ну чтож, передернул в USB COM-порт, далее все пошло как надо, но на команде COP/DEV HX0: HX7: на HX_WRITE опять встало, никаких ошибок и никакого обмена.
---------- Post added at 20:21 ---------- Previous post was at 20:20 ----------
Завтра возьму на работе PCI-COM-порты, интересно как с ними будет?
Alex_K, Этот пролифик - коварная и гнусная вещь. Очень любит ловить ошибки: помехи по COM порту часто воспринимаются им как USB команда перейти в sleep режим, а дальше - только передергивание USB. По версии чип-вендора виноваты китайские производители с плохой разводкой платы. Я склонен думать что просто чип - г..., хотя он и самый распространенный.
Надо USB-COM либо на CP2102 (около $12 с доставкой оттуда), либо на FTDI FT232, он подороже, где-то $14 (СP2102 последний, вышел позже FT и Prolific)
Я программатор два раза в гарантию носил, пока не сказал жёсткое нет пролифику ;-)
Alex_K, Этот пролифик - коварная и гнусная вещь.
О да!!! Сейчас я понял это. На новой версии HX-сервера снова все подвисло на ошибке контрольной суммы на HX_WRITE. И это при отключенном сжатии (хотя это играет роль только при чтении). Да и сам чип у меня, который больше не поддерживается, об этом на сайте производителя прямо и написано, мол есть более свежие версии, для них и драйвера свежие есть. Вот так-то.
Alex_K, А более свежий пролифик - просто более свежее г...
снова все подвисло на ошибке контрольной суммы на HX_WRITEТ.е. просто пишет про ошибку и перестаёт что-либо передавать и принимать..
А если в файле UKNC_HX_COM.cfg включить запись на диск лога HX:
[HX_Log.ini]
TabTitle =""
InitialStateOf[StatusBar] = 0
SaveChangesFor[StatusBar] = 0
InitialStateOf[ControlBar] = 0
SaveChangesFor[ControlBar] = 0
InitialStateOf[Log] = 1
SaveChangesFor[Log]=0
DumpMode=1
то что запишется в файл HX_Log.log ?
---------- Post added at 21:26 ---------- Previous post was at 21:01 ----------
А если выяснить, на каком блоке всё время присходит сбой и потом заказать COP/DEV HX0:/ST:nn HX7:/ST:nn прямо с этого блока - тогда тут же и зависнет ?
А если выяснить, на каком блоке всё время присходит сбой и потом заказать COP/DEV HX0:/ST:nn HX7:/ST:nn прямо с этого блока - тогда тут же и зависнет ?
Блоки могут быть разные, так что смысла выяснять нету. Это собственно из-за USB-COM-порта Prolific.
Блоки могут быть разныеПросто интересно, почему перестаёт работать, а не ошибку записи возвращает. Ведь по-хорошему сервер должен сообщить драйверу об ошибке, а тот - выдать признак ошибки в программу.
---------- Post added at 22:50 ---------- Previous post was at 22:48 ----------
В принципе - с таким любопытным портом можно сделать и отладить "повторные попытки записи" в драйвере.
С родным аппаратно-железным COM1 все прошло без сучка и задоринки.
А любопытным портом отлаживать не стоит, ибо неизвестно что он выкинет в следующий раз. Выход из ошибки возможен, когда известен алгоритм работы COM-порта, известно что надо в этом случае сделать. А когда COM-порт работает по принципу "хочу-не хочу", то тут отлаживаться можно до бесконечности.
когда COM-порт работает по принципу "хочу-не хочу", то тут отлаживаться можно до бесконечности.Если запись иногда проходит - повторные попытки записи в драйвере вполне могут помочь. Ведь для того и передаётся контрольная сумма, чтобы выявлять ошибки. Но после сообщения об ошибке контрольной суммы обмен зависать не должен - сервер должен послать драйверу пакет с сообщением об ошибке, а драйвер, получив его - должен установить признак аппаратной ошибки в CSW и завершить вызов.
Если так не происходит - это довольно странно, ведь читает драйвер (насколько я понял) с "плохим" портом без проблем, а значит, сообщение сервера об ошибке получить должен.
Если так не происходит - это довольно странно, ведь читает драйвер (насколько я понял) с "плохим" портом без проблем, а значит, сообщение сервера об ошибке получить должен.
Вот после этого проблемы и начинаются и с чтением. Происходят ошибки переполнения, и это при установленных двух стоп-битах. Естественно из-за этого и со сжатием не грузится. Помогает только передергивание по USB, да и то ненадолго.
Вот после этого проблемы и начинаются и с чтением.Получается, что драйвер "осмысленное" сообщение сервера об ошибке не получает и крутится в цикле его ожидания.
---------- Post added at 23:49 ---------- Previous post was at 23:46 ----------
В такой момент должна помогать отправка Ctrl/C через окно Teletype.
Получается, что драйвер "осмысленное" сообщение сервера об ошибке не получает и крутится в цикле его ожидания.
весьма возможно, но мне проверять это уже не хочется, USB-COM-порт отсоединил, завтра (хотя уже сегодня) притащу с работы другие, попробую.
USB-COM-порт
У тебя этот порт тоже рывками работает из под RT-11?
Мой например по команде DIR мгновенно нафигачивает по пол экрана информации. В RSX все плавно, но это видимо следствие полнофункционального драйвера который дозирует выдачу.
А именно тесты из этого сообщения
"http://zx.pk.ru/showpost.php?p=567532&postcount=249
описание тестов PORT - для ДВК и PORT2 для УК-НЦ )"
Image : 54y_HX22_TESTUK.dsk
Format : DSK
Size : 800 Kb
Volume ID: RT11A
Owner :
File Blocks Date Bytes
---------- ------ ----------- ----------
SWAP .SYS 27P 19-Dec-1988 13'824
RT11SJ.SYS 78P 16-Dec-2012 39'936
TT .SYS 2P 23-Jan-1980 1'024
STARTS.COM 1 11-Jan-2013 512
RESORC.SAV 25 01-Mar-2012 12'800
IND .SAV 58 18-Jan-1988 29'696
DUP .SAV 45 27-Dec-1983 23'040
LD .SYS 8P 18-Jan-1988 4'096
DAY .SAV 4 19-Dec-2012 2'048
SPAM .MAC 4 09-Jan-2013 2'048
WD .SYS 3P 05-Aug-1979 1'536
WE .SYS 2P 16-May-1979 1'024
COLS .SAV 17 09-Aug-1990 8'704
WDR .SAV 3 01-Oct-1980 1'536
RUS .SAV 2 16-Oct-1994 1'024
SYS .SAV 3 30-May-1979 1'536
LAT .SAV 2 16-Oct-1994 1'024
TTY .SAV 3 25-Jan-1991 1'536
NYS .SAV 22 22-Oct-1993 11'264
PMEM .SAV 2 25-Aug-1993 1'024
TUK .SAV 35 27-Mar-1980 17'920
TS .SAV 40 31-Jul-1992 20'480
SKY .SAV 4 08-Apr-1993 2'048
MZFORM.SAV 6 13-Jun-1990 3'072
CAT .SAV 52 01-Sep-1992 26'624
HUST .SAV 6 31-Dec-1999 3'072
FONTUK.SAV 5 31-Dec-1999 2'560
AC .SYS 5P 12-Sep-1994 2'560
MZ .SYS 4P 12-Jan-1990 2'048
PIP .SAV 30 31-Oct-1998 15'360
DESS19.SAV 19 04-Mar-1994 9'728
MACRO .SAV 63 21-Dec-2012 32'256
LINK .SAV 59 31-Oct-1998 30'208
SYSMAC.SML 92 31-Oct-1998 47'104
DIR .SAV 20 31-Oct-1998 10'240
DISASM.SAV 8 07-Dec-2011 4'096
SL .SYS 10 19-Jan-1988 5'120
UCL .SAV 2 31-Dec-1999 1'024
KLAV .SAV 18 10-Feb-1989 9'216
RMKOI8.SAV 6 31-Dec-1999 3'072
RDWR .SAV 3 20-Dec-1991 1'536
TSSPD .SAV 23 25-Apr-1980 11'776
SYSLIB.OBJ 47 19-Dec-1988 24'064
SPAM .SAV 2 31-Dec-1999 1'024
TSSPD .MAC 93 11-Jan-2013 47'616
BINCOM.SAV 25 31-Oct-1998 12'800
BOT .COM 1 11-Jan-2013 512
BOTHX0.MAC 10 11-Jan-2013 5'120
C2 .COM 1 09-Jan-2013 512
C2 .MAC 5 11-Jan-2013 2'560
HX .COM 1 17-Nov-2012 512
HX .MAC 28 11-Jan-2013 14'336
C2 .LST 13 31-Dec-1999 6'656
HX .LST 73 31-Dec-1999 37'376
HX .SYG 4 31-Dec-1999 2'048
BOTHX0.LST 27 31-Dec-1999 13'824
BOTHX0.BIN 1 31-Dec-1999 512
C2 .SYS 2 31-Dec-1999 1'024
HX .SYS 4 31-Dec-1999 2'048
PALSW .SAV 23 11'776
PORT .MAC 12 14-Jan-2013 6'144
PORT .SAV 16 14-Jan-2013 8'192
PORT2 .SAV 16 14-Jan-2013 8'192
< UNUSED > 361 184'832
---------- ------ ----------- ----------
63 Files, 1225 Blocks
361 Free blocks
"http://zx.pk.ru/showpost.php?p=567532&postcount=249
описание тестов PORT - для ДВК и PORT2 для УК-НЦ )"
Испытал PCI-Serial плату OX16PCI952 производства Oxford Semiconductors Ltd. Могу сказать, что результаты положительные. Загрузка происходила с включенным сжатием. Команды DIR/BAD/FIL и COP/DEV HX1: HX7: выполнены успешно. Во время чтения выходил в пультовый режим и смотрел регистр 176570, все отлично - бита переполнения не установлено.
А если PORT.SAV и PORT2.SAV запустить - какие результаты выводит ?
А если PORT.SAV и PORT2.SAV запустить - какие результаты выводит ?
Так собственно уже давно ответил (http://zx.pk.ru/showpost.php?p=567603&postcount=250).
---------- Post added at 21:38 ---------- Previous post was at 20:10 ----------
Испытал VSCom uPCI-200L. Вообще не пошло. На некоторых настройках PC вместо одного байта "@" получает почему-то два - "@" как надо и байт с кодом ноль. Когда получение "@" проходит нормально, то передается несколько байт первичного загрузчика и на этом все замирает.
"@" как надо и байт с кодом ноль
Именно так было и в начале тестирования (http://zx.pk.ru/showthread.php?postid=564666):
http://emulator.pdp-11.org.ru/misc/tst1.png
Именно так было и в начале тестирования (http://zx.pk.ru/showthread.php?postid=564666):
Нет, у меня сначала "@", а потом <000>. Но не всегда, только с некоторыми настройками порта.
А потом прочитывалось несколько байт первичного загрузчика и замирало.
В приложении - тестовая версия Boot_RT-11_from_HX0.bin (http://zx.pk.ru/attachment.php?attachmentid=39330), выводящая эхо на экран при приёме каждого байта из порта С2. Если вывод на экран УКНЦ не упирается в конце строки - можно оценить число принятых байтов.
...
В приложении - тестовая версия Boot_RT-11_from_HX0.bin (http://zx.pk.ru/attachment.php?attachmentid=39330), выводящая эхо на экран при приёме каждого байта из порта С2. Если вывод на экран УКНЦ не упирается в конце строки - можно оценить число принятых байтов.
...
У меня первичный загрузчик прочитаться не мог, так что тут даже до Boot_RT-11_from_HX0.bin не доходит. А последний раз прочлось 27 байт, т.к. значение R1 = 033. Т.е. УКНЦ шлет "@", затем HX-засылает 512 байт первичного загрузчика, но даже и он не проходит.
В приложении - тестовая версия Boot_RT-11_from_HX0 v1.2 (test) (http://zx.pk.ru/attachment.php?attachmentid=39331), выводящая каждый принятый из порта С2 байт обратно в порт С2 ( для просмотра в окне Port Dump ).
...
У меня первичный загрузчик прочитаться не мог, так что тут даже до Boot_RT-11_from_HX0.bin не доходит. А последний раз прочлось 27 байт, т.к. значение R1 = 033. Т.е. УКНЦ шлет "@", затем HX-засылает 512 байт первичного загрузчика, но даже и он не проходит.Это и при одном, и при двух стоповых битах так ?
Это и при одном, и при двух стоповых битах так ?
При двух.
---------- Post added at 23:11 ---------- Previous post was at 22:53 ----------
Ну вот, закончил тестирование SUNIX SER4037A. Все тесты прошла нормально, но только при отключенном сжатии. Соответственно плохо реагирует на изменение CTS, есть ошибки переполнения при включенном сжатии.
Последовательный порт плат МС1201.01 и МС1201.02 построен на основе 1801ВП1-035, поэтому всегда передается 11 бит.В описании плат МС1201.01 и МС1201.02 говорится про блок переключателей SA2 с 8-ю переключателями:
SA2.1 - 177560/60 или 176560/360
SA2.2 - 7 или 8 бит
SA2.3 - с паритетом или без паритета
SA2.4 - чёт или нечет
SA2.5 - выбор скорости
SA2.6 - выбор скорости
SA2.7 - выбор скорости
SA2.8 - выбор скорости
Т.е. (если я правильно понимаю) количество битов на байт у 1801ВП1-035 может составлять от 10 до 12.
В описании плат МС1201.01 и МС1201.02 говорится про блок переключателей SA2 с 8-ю переключателями:
SA2.1 - 177560/60 или 176560/360
SA2.2 - 7 или 8 бит
SA2.3 - с паритетом или без паритета
SA2.4 - чёт или нечет
SA2.5 - выбор скорости
SA2.6 - выбор скорости
SA2.7 - выбор скорости
SA2.8 - выбор скорости
Т.е. (если я правильно понимаю) количество битов на байт у 1801ВП1-035 может составлять от 10 до 12.
В случае с МС1201.01 и МС1201.02 кол-во бит может составлять от 10 до 12 (зависит от длины посылки - 7 или 8 бит и наличия бита паритета). Но стандартно по умолчанию настроено на 8 бит без бита паритета, получается 11.
Только сейчас я понял, что контроллеры, использующие разное количество стоповых битов, могут успешно обмениваться синхронными данными из-за того, что стоповый бит это всегда "0", а стартовый - всегда "1". Поэтому, при приёме данных контроллеры не считают стоповые биты, а просто ожидают фронта стартового.
В такой ситуации, когда единственное, чем грозит передача неправильного количества стоповых битов - это отправка лишнего байта при работе с квитированием ( что часто сходит с рук при наличии в принимающем порту буфера FIFO ) - только самые вдумчивые и ответственные китайцы станут делать работу порта при отправке двух стоповых битов чем-то отличающейся от работы с одним.
Можно предположить, что именно способность честно отправлять 2 стоповых бита критически важна для успешного взаимодействия контроллера COM-порта PC с 1801ВМ1-065.
Относительно протестированного SUNIX SER4037A можно предположить, что он просто игнорирует настройку на 2 стоповых бита, продолжая отправлять один.
Что же до VSCom uPCI-200L, то думается, что при настройке на один стоповый бит - он смог бы передать первичный загрузчик целиком - видимо, режим с 2 стоповыми битами его разработчиками не тестировался, но уж режим-то с одним стоповым битом должен работать как часы - иначе как вообще этот контроллер можно было бы применять..
Только сейчас я понял, что контроллеры, использующие разное количество стоповых битов, могут успешно обмениваться синхронными данными из-за того, что стоповый бит это всегда "0", а стартовый - всегда "1". Поэтому, при приёме данных контроллеры не считают стоповые биты, а просто ожидают фронта стартового.
Ну насчет "0" и "1" - это смотря с какой стороны посмотреть, вообще стартовый бит по диаграммам всегда низкого уровня, а стоповый - высокого. А стоповые биты (как и стартовый) нужны при асинхронном обмене - во время стопового бита контроллер готовится к приему следующего (сбрасывает счетчики, копирует сдвиговый регистр в буферный), передающая сторона при необходимости опрашивает линии управления.
В такой ситуации, когда единственное, чем грозит передача неправильного количества стоповых битов - это отправка лишнего байта при работе с квитированием ( что часто сходит с рук при наличии в принимающем порту буфера FIFO ) - только самые вдумчивые и ответственные китайцы станут делать работу порта при отправке двух стоповых битов чем-то отличающейся от работы с одним.
Ну при включенном буфере FIFO на аппаратном COM-порте тоже все нормально проходит, значит Windows умеет тормозить отправку буфера. А у всяких PCI- и USB-COM-портов качество работы зависит от внутреннего firmware контроллера и от драйвера в Windows, т.к. там обычно работа делается на программном уровне.
Можно предположить, что именно способность честно отправлять 2 стоповых бита критически важна для успешного взаимодействия контроллера COM-порта PC с 1801ВМ1-065.
А вот протестированный мной PCI Serial с чипом производства Oxford Semiconductors Ltd. успешно работает и с одним стоп-битом. Складывается впечатление, что он работает с квитированием на аппаратном уровне.
Относительно протестированного SUNIX SER4037A можно предположить, что он просто игнорирует настройку на 2 стоповых бита, продолжая отправлять один.
Что же до VSCom uPCI-200L, то думается, что при настройке на один стоповый бит - он смог бы передать первичный загрузчик целиком - видимо, режим с 2 стоповыми битами его разработчиками не тестировался, но уж режим-то с одним стоповым битом должен работать как часы - иначе как вообще этот контроллер можно было бы применять..
Вот уж и не хочется тестировать, да и отнес я их обратно. Я уже писал выше, что если криво сделано firmware контроллера и драйвера, то так и работать будут.
Кстати вчера испытал новый Prolific со свежими драйверами. Загрузится не удалось, на УКНЦ писалось, что идут плохие пакеты. А ведь старый хоть чуть-чуть, но работал. Так что dk_spb в этом плане оказался прав - новый Prolific - новое г.....
Patron, А можно Вас попросить добавить в HX_Server выбор СОМ порта.
добавить в HX_Server выбор СОМ порта.Используемый COM-порт нужно указать в файле UKNC_HX_COM.cfg в разделе ComPort.ini в параметре PortName.
По умолчанию используется порт COM1:
[ComPort.ini]
PortName = "COM1"
InitialStateOf[ShowPortUse]=1
SaveChangesFor[ShowPortUse]=1
Новый вариант сервера HX_Server 2.1_-_UKNC_19.01.13_20-05 (http://emulator.pdp-11.org.ru/misc/HX_Server%202.1_-_UKNC_19.01.13_20-05.rar).
Изменения:
1. Добавлен загрузочный образ NCsys54.DSK с монитором NC11SJ.SYS, сгенерённым для работы с портом С2 в качестве системного терминала. Драйвер HX.SYS, находящийся в этом образе - при загрузке выводит сообщения в порт С2.
2. Добавлен загрузчик Boot_NC-11_from_HX0.bin, который при загрузке выводит сообщения в порт С2.
3. Добавлен файл конфигурации NC11_HX_COM.cfg - для загрузки образа NCsys54.DSK на УКНЦ. Для загрузки файла конфигурации нужно использовать пункт меню: Файл -> Открыть.
4. Добавлен файл Terminal.ini, содержащий настройки терминала типа VT52, используемого в качестве системного терминала при работе с монитором NC11SJ.SYS через порт С2.
...
В приложении - новый вариант сервера
...
Изменения:
1. Добавлен загрузочный образ NCsys54.DSK с монитором NC11SJ.SYS, сгенерённым для работы с портом С2 в качестве системного терминала. Драйвер HX.SYS, находящийся в этом образе - при загрузке выводит сообщения в порт С2.
Спасибо!!! Загрузился, все работает. Ну хотя все нормально будет работать, если программы используют только системные вызовы RT-11. Сделано все грамотно, используется прерывание 370 для С2, поставлены биты защиты на ячейки 370-377 в битовой маске $LOWMA.
Я такое тоже когда-то сотворял для вывода через С2 на гипертерминал. Но там я уже грузил обычную систему, потом выходил в пульт, ставил значения векторов 370-377 равным 60-67, устанавливал бит разрешения прерывания на приемник С2, в RMON правил ячейки системного терминала на адреса С2, ну и устанавливал защиту на ячейки 370-377 в $LOWMA.
Сделано все грамотноДостаточно при генерации монитора использовать такой файл SYSGEN.CND:
SYSG$N = 1 ;Indicate sysgened monitor
RDF$L = 1 ;System I/O error messages
TTYOUT = 40. ;Size of the output buffers
TTYIN = 82. ;Size of the input buffers
U$CL = 1 ;User command linkage
U$TIL = 1 ;Utility commands
L$ANG = 1 ;Language commands
M$INI = 1 ;Minimal commands
CLOCK = 50. ;Power line frequency
STAR$T = 1 ;Startup command file
TKS = 176570 ;
TKB = 176572 ;
TPS = 176574 ;
TPB = 176576 ;
V.TKB = 370 ;
V.TPS = 374 ;
Достаточно при генерации монитора использовать такой файл SYSGEN.CND:
Ячейки защиты посмотрел в самом ОЗУ, они там стоят. А вот в мониторе NC11SJ.SYS не стоят, видно ставит вторичный загрузчик при загрузке системы по факту используемого вектора прерывания.
Ну чтож! Можно и мультитерминальную систему забабахать с двумя терминалами - встроенным и через С2.
Можно и мультитерминальную систему забабахать с двумя терминаламиДля начала можно попробовать определить, при какой степени дисфункции УКНЦ можно загрузиться вслепую и работать через С2:
1. Если к УКНЦ не подключен монитор.
2. Если неисправен видеовыход УКНЦ.
3. Если неисправен периферийный процессор.
А вот в мониторе NC11SJ.SYS не стоят,
А можно попросить при упоминанию любого ПО для УК-НЦ его тоже выкладывать или ссылку, что бы сразу забрать можно было ) Спасибо! )
Для начала можно попробовать определить, при какой степени дисфункции УКНЦ можно загрузиться вслепую и работать через С2:
1. Если к УКНЦ не подключен монитор.
2. Если неисправен видеовыход УКНЦ
3. Если неисправен периферийный процессор.
palsw ?! http://s2.rimg.info/30317106e968fc609c0537ab6c3924a4.gif (http://smayliki.ru/smilie-251761287.html)
Для начала можно попробовать определить, при какой степени дисфункции УКНЦ можно загрузиться вслепую и работать через С2:
1. Если к УКНЦ не подключен монитор.
2. Если неисправен видеовыход УКНЦ.
Будем считать, что все остальное исправно. Если воткнут контроллер дисковода или отсутствует сетевой адаптер, то УКНЦ переходит в главное загрузочное меню. Достаточно нажать <4><ВВОД> и загрузка пойдет. При отсутствии контроллера дисковода и присутствии сетевого адаптера происходит вызов загрузки из сети - тут достаточно нажать <СТОП> для выхода в меню.
Есть правда одно большое НО - при выходе в пульт, информация из пультового отладчика будет выводится через регистры 177560-177567. Сам пультовый отладчик в ЦП можно загрузить свой или подправить текущий, но он правда работает в КОИ-8 и использует Esc-последовательности чисто для УКНЦ (там даже клавиши-стрелки перепрограммируются). Также одна Esc-последовательность устанавливает в ОЗУ пультового отладчика ЦП ключ продолжения.
Так что пульт грузить лучше свой.
3. Если неисправен периферийный процессор.
Тут все просто - УКНЦ не запустится.
А можно попросить при упоминанию любого ПО для УК-НЦ его тоже выкладывать или ссылкуИмеет место определённая вложенность - упомянутое ПО находится в образе NCsys54.DSK, который находится в архиве HX_Server 2.1_-_UKNC_19.01.13_20-05.rar, который находится в приложении 39404, которое находится в сообщении 569128 :)
Имеет место определённая вложенность - упомянутое ПО находится в образе NCsys54.DSK, который находится в архиве HX_Server 2.1_-_UKNC_19.01.13_20-05.rar, который находится в приложении 39404, которое находится в сообщении 569128 :)
Да, я первый пункт "Добавлено" перечитал, разобрался, 2>Alex_K(!)извиняюсь, спасибо за ссылку ) В связи с тем, что в очередной раз проделана огромная работа и достигнуты высокие результаты - почистил ссылки на мордочке архива.
"http://archive.pdp-11.org.ru/" - осн.сайт
"http://hobot.pdp-11.ru/" - зеркало
Если загрузить монитор NC11SJ.SYS с дискеты или винчестера, то прицепив к порту С2 терминал вроде 15ИЭ-00-013 - можно работать с УКНЦ почти как с ДВК-2.
Новый вариант сервера HX_Server_2.2_-_UKNC_21.01.13_16-15 (http://emulator.pdp-11.org.ru/misc/HX_Server_2.2_-_UKNC_21.01.13_16-15.rar).
Изменения:
1. Сервер теперь поддерживает расширенный протокол HX v2.2, полностью совместимый с HX v2.1
2. Теперь при нажатии Ctrl/H в терминале - генерится код 010, а не 0177
3. В файл Terminal.ini добавлены новые параметры, задающие коды, посылаемые клавишами [Backspace] и [Enter]:
ANSI_STR_FOR_KEY[Backspace] = "\177"
ANSI_STR_FOR_KEY[Enter] = "\015"
Если загрузить монитор NC11SJ.SYS с дискеты или винчестера, то прицепив к порту С2 терминал вроде 15ИЭ-00-013 - можно работать с УКНЦ почти как с ДВК-2.
Еще бы распиновку разъема С2 на 15ИЭ-00-013 знать, а то в книжке только токовая петля обозначена.
Еще бы распиновку разъема С2 на 15ИЭ-00-013 знать, а то в книжке только токовая петля обозначена.Ну, землю наверное найти нетрудно. После этого остаётся найти только линию передатчика и линию приёмника. Передатчик выдаст себя при автоповторе клавиши "забой" ( она почти сплошняком единицы передаёт - тут даже вольтметр сгодится ). Останется найти линию приёмника.
А сколько всего линий идёт от разъёма С2 на плату 15ИЭ-00-013 ?
В приложении - новый вариант сервера
Есть предложение, со следующей версии (если будет!) в отдельную тему перенести
все обсуждения и релизы касаемые HX 2.x UKNC сервера, поскольку в плане сайтостроения проще - сделать один раз ссылку на авторскую тему "программы" на форуме, где в шапке "всегда" актуальная версия весит. Но это так, на морде архива
поправил строку с названием и ссылку. )
Так как УКНЦ у меня уже работает стабильно -решил поиграться с скорость ВП1-065.
Сначала попробовал 19200 -всё прошло отлично ,но прибавки на глаз не было заметно.Сейчас выставил скорость 57600 и это просто сказка! Загружается очень шустро :)
Видео скоро загрузиться:
http://youtu.be/wexswhkpUf8
выставил скорость 57600 и это просто сказка! Загружается очень шустроКакие настройки COM-порта ( файл Terminal_ComPort_Adapter.ini ) ?
Со сжатием на 57600 нормально работает ?
Patron,
[Main]
BaudRate = CBR_57600
fDtrControl = DTR_CONTROL_ENABLE
fRtsControl = RTS_CONTROL_HANDSHAKE
Parity = NOPARITY
StopBits = TWOSTOPBITS
ByteSize = 8
fParity = FALSE
fOutxCtsFlow = FALSE
fOutxDsrFlow = FALSE
fDsrSensitivity = FALSE
fTXContinueOnXoff = FALSE
fOutX = FALSE
fInX = FALSE
fErrorChar = FALSE
fNull = FALSE
fAbortOnError = FALSE
XonLim = 512
XoffLim = 512
XonChar = 021
XoffChar = 023
ErrorChar = 0
все настройки родные кроме скорости.сжатие походу я еще не разу не включал :)
Кабель - шлейф ?
Какая длина кабеля ?
Patron, косичка с полной распайкой,длина чуть примерно 15 см .Кабель заводской удлинитель ком порта примерно 1м
Надо поставить fOutxCtsFlow = TRUE.
сжатие походу я еще не разу не включалБез сжатия и с одним стоповым битом должно работать ( это ещё на 10% быстрее ).
Весь фокус в том, успеет ли Windows на 57600 обработать прерывание RTS за время передачи второго стопового бита - только тогда со сжатием не будет проблем.
Patron, сжатие наверное не работает - я его раньше тоже не использовал на 9600.Пытается загружаться и все замирает.Да и так быстро грузит
С одним стоповым битом работает ?
Надо поставить fOutxCtsFlow = TRUE.
С этой опцией не грузит сжатием и без зжатия
---------- Post added at 23:14 ---------- Previous post was at 23:11 ----------
Версию использую HX_Server 2.1_-_UKNC_11.01.13_16-10 - проверенную временем :)
Версию использую HX_Server 2.1_-_UKNC_11.01.13_16-10 - проверенную временемТам загрузчик Boot_RT-11_from_HX0.bin морально устаревший - он даже контрольные суммы не считает.
Лучше взять загрузчик последней версии.
---------- Post added at 00:21 ---------- Previous post was at 00:19 ----------
Но загрузчик последней версии дату передаёт в других ячейках - тогда уж и сервер последней версии нужен.
---------- Post added at 02:07 ---------- Previous post was at 00:21 ----------
Со сжатием у этой УКНЦ проблемы из-за того, что она почему-то портит самый первый пакет протокола HX.
Если загрузиться без сжатия, а потом его включить - всё должно работать ( если сигналы квитирования нормально передаются и обрабатываются ).
Хех..
http://zx-pk.ru/attachment.php?attachmentid=39466&stc=1&d=1358949066
http://zx-pk.ru/attachment.php?attachmentid=39467&stc=1&d=1358949066
http://zx-pk.ru/attachment.php?attachmentid=39468&stc=1&d=1358949066
Скришоты обновил.
Со сжатием у этой УКНЦ проблемы из-за того, что она почему-то портит самый первый пакет протокола HX.
Если загрузиться без сжатия, а потом его включить - всё должно работать ( если сигналы квитирования нормально передаются и обрабатываются ).
Со сжатием проблемы в другом. Если квитирование работает плохо, то во время распаковки сжатого блока, если это занимает длительное время, успевает прийти еще байт на место несчитанного, возникает ошибка переполнения. Если со стороны PC передаются скажем 157 байт, то из-за переполнения УКНЦ думает, что приняла так скажем 155-156 байт и тупо ожидает остаток, а HX-сервер думает, что все нормально передал и ждет очередной команды.
Если уж загрузится со сжатием не удалось, то и включать его бесполезно. Та же самая проблема и будет.
Однако если квитирование работает нормально, то и проблем нету. И загрузка идет нормально, и далее все работает, т.к. при нормальном квитировании ошибок переполнения просто нет, передача со стороны PC просто успевает затормозиться в нужный момент.
Со сжатием проблемы в другом.Конкретная УКНЦ ( или PC ) palsw портит первый пакет.
Ниже поясню, как это понял, но сначала один вопрос.
Вот исходник обработки меню загрузки из ПЗУ УКНЦ:
; Обработка вызова меню загрузки (M)
161160$:JSR R4,163006$ ; Вызов меню загрузки
.WORD 163505$
CALL 172614$ ; Прочесть данные из канала 0 (номер пункта)
MOV R0,R1 ; R1 = номер выбранного пункта * 2
CALL 172614$ ; Прочесть данные из канала 0 (номер уст-ва)
CALL @162350$(R1) ; Вызов соответствующей п/п
BR 161160$
Там сначала читается номер пункта меню, потом читается номер загружаемого привода и помещается в R0. Получается, что при загрузке не через загрузчик, а через 0-й блок системного образа - можно при помощи меню загрузки передавать в R0 номер загружаемого привода. В загрузчике я это убрал, но если начальное значение R0 при загрузке через С2 у УКНЦ не случайно - можно вернуть в загрузчик выбор загружаемого привода при помощи меню загрузки.
В УКНЦ palsw R0 всегда был равен 2 вот из-за чего:
BOOT:
Mov #10000, SP ; Boottime SP value
Mov R0, @#B$DEVU ; Get cold boot unit num
Mov #2, R0 ; Block number of BSTRAP
Mov #2000, R1 ; Word count of BSTRAP
Mov #1000, R2 ; Loading addr for BSTRAP
Call READ
......
......
READ:
Call B.ChIn ; Packet type
CmpB R5, #'R ; Packet type == REPLY ?
BNE BOOTКогда на первый запрос приходил плохой пакет - драйвер уходил на перезагрузку, снова копируя R0 в номер привода, но в R0 уже было значение 2.
Вот исходник обработки меню загрузки из ПЗУ УКНЦ:
; Обработка вызова меню загрузки (M)
161160$:JSR R4,163006$ ; Вызов меню загрузки
.WORD 163505$
CALL 172614$ ; Прочесть данные из канала 0 (номер пункта)
MOV R0,R1 ; R1 = номер выбранного пункта * 2
CALL 172614$ ; Прочесть данные из канала 0 (номер уст-ва)
CALL @162350$(R1) ; Вызов соответствующей п/п
BR 161160$
Там сначала читается номер пункта меню, потом читается номер загружаемого привода и помещается в R0. Получается, что при загрузке не через загрузчик, а через 0-й блок системного образа - можно при помощи меню загрузки передавать в R0 номер загружаемого привода. В загрузчике я это убрал, но если начальное значение R0 у УКНЦ не случайно - можно вернуть в загрузчик выбор загружаемого привода при помощи меню загрузки.
Меню загрузки вызывается из программы в ЦП с помощью Esc-последовательности. Далее ПП уже обрабатывает эту Esc-последовательность и выводит на экран меню загрузки и управляет им. По нажатию <Enter>, <ИСП> или <0> в ЦП по каналам клавиатуры передаются два байта - один из них номер пункта меню*2, а второй - номер устройства. Но номер устройства в меню можно выбрать только для пунктов 1.дисковод и 2.кассета ПЗУ, для остальных пунктов выбор номера устройства невозможен, в этом случае передаваемое значение не определено. Что там может быть можно глянуть в программе управления меню УСТАНОВКА и ЗАГРУЗКА, располагается в ПЗУ с адреса 100000.
Что там может быть можно глянуть в программе управления меню УСТАНОВКА и ЗАГРУЗКАНо большого смысла в этом нет, т.к. всё равно невозможно управлять этим значением для выбора номера загружаемого привода.
В приложении - улучшенный вариант загрузчика Boot_RT-11_from_HX0.bin (http://zx.pk.ru/attachment.php?attachmentid=39465), который теперь реализует тайм-ауты при приёме байтов, а также имеет защиту от "выбега из буфера" при ошибках сжатия.
При использовании этого загрузчика - потеря байтов из-за переполнения при приёме не может привести к "зависанию" протокола.
...
Со сжатием проблемы в другом. Если квитирование работает плохо, то во время распаковки сжатого блока, если это занимает длительное время, успевает прийти еще байт на место несчитанного, возникает ошибка переполнения. Если со стороны PC передаются скажем 157 байт, то из-за переполнения УКНЦ думает, что приняла так скажем 155-156 байт и тупо ожидает остаток, а HX-сервер думает, что все нормально передал и ждет очередной команды.
Склоняюсь к мнению Patron потому что в эмуляторе со сжатием почти регулярно вылетает в СТОП по адресу 000002, связь между эмулятором и НХ сервером через программу сом0сом т.е. все через буферы и контроль виндовс.
Обновил скриншоты на предыдущей странице.
В приложении - улучшенный вариант загрузчика Boot_NC-11_from_HX0.bin (http://zx.pk.ru/attachment.php?attachmentid=39469) ( для загрузки образа NCsys54.DSK ), который теперь реализует тайм-ауты при приёме байтов, а также имеет защиту от "выбега из буфера" при ошибках сжатия.
При использовании этого загрузчика - потеря байтов из-за переполнения при приёме не может привести к "зависанию" протокола.
...
в эмуляторе со сжатием почти регулярно вылетает в СТОП по адресу 000002, связь между эмулятором и НХ сервером через программу сом0сом т.е. все через буферы и контроль виндовс.Нужно убедиться, что в сом0сом выключен Overrun и включена эмуляция скорости порта:
If sending port is CNCA0 and receiving port is CNCB0, then:
1. Launch the Setup Command Prompt shortcut.
2. Enter the change commands, for example:
command> change CNCB0 EmuOverrun=no
command> change CNCA0 EmuBR=yes
HX_Server 2.2 , загрузчик из последнего поста
сом0сом - выключен Overrun и включена эмуляция скорости порта, с сжатием
http://zx-pk.ru/attachment.php?attachmentid=39471&stc=1&d=1358953649
сом0сом - включен Overrun и включена эмуляция скорости порта, с сжатием
http://zx-pk.ru/attachment.php?attachmentid=39472&stc=1&d=1358953649
сом0сом - включен Overrun и включена эмуляция скорости порта, без сжатия
http://zx-pk.ru/attachment.php?attachmentid=39473&stc=1&d=1358953649
сом0сом - выключен Overrun и включена эмуляция скорости порта, с сжатиемА какие настройки COM-порта в сервере ( файл Terminal_ComPort_Adapter.ini ) ?
Решил переменить свое мнение http://zx-pk.ru/showpost.php?p=570159&postcount=394 , только поменять направление хода рассуждений Alex_K . Копаясь в исходниках UKNCBTL обратил внимание на то как происходит работа с буфером СОМ порта (или файлами через которые читает/пишет программа в СОМ порт), так вот в эмуляторе это делается одной функцией которая как я понимаю в один момент времени может или прочитать байт из буфера или передать байт в буфер, а как это реализовано в НХ сервере и в драйвере виндов. Ведь если в момент передачи(записи в буфер) надо еще и принять(прочитать из буфера), может что-то здесь.
---------- Post added at 19:48 ---------- Previous post was at 19:46 ----------
А какие настройки COM-порта в сервере ( файл Terminal_ComPort_Adapter.ini ) ?
BaudRate = CBR_9600
fDtrControl = DTR_CONTROL_ENABLE
fRtsControl = RTS_CONTROL_HANDSHAKE
Parity = NOPARITY
StopBits = TWOSTOPBITS
ByteSize = 8
fParity = FALSE
fOutxCtsFlow = TRUE
fOutxDsrFlow = TRUE
fDsrSensitivity = FALSE
остальные не менял.
в эмуляторе это делается одной функцией которая как я понимаю в один момент времени может или прочитать байт из буфера или передать байт в буфер, а как это реализовано в НХ сервере и в драйвере виндов. Ведь если в момент передачи(записи в буфер) надо еще и принять(прочитать из буфера), может что-то здесьВряд ли. Windows буферизует по 3К на приём и передачу, да и com0com, насколько понимаю - тоже буферизует.
Но дело тут явно в том, что при эмуляции 1801ВП1-065 успешно эмулируется оверран, но не получается эмуляция квитирования. В результате работа идёт так, как на реальной УКНЦ без квитирования.
Возможно, эмулятор УКНЦ не устанавливает в DCB
fRtsControl = RTS_CONTROL_HANDSHAKE
fOutxCtsFlow = TRUE
Возможно, эмулятор УКНЦ не устанавливает в DCB
В моей версии устанавливает, все как в ini для НХ сервера, если не установить вообще не загружается.
Но дело тут явно в том, что при эмуляции 1801ВП1-065 успешно эмулируется оверран
вот оверран как раз не эмулируется это возложено на стандартную обработку виндами. Точнее эмулируется но до него событие переполнения раньше обработает драйвер виндовс.
но не получается эмуляция квитирования
а вот это можно попробовать сделать, но опять же упремся в буфер и драйвер виндовс.
Если я правильно использую терминологию, то 1801ВП1-065 работает в асинхронном режиме а вот как работает COM порт или драйвер. Судя по тому что я наблюдаю в нижней части окна НХ сервера при работе со сжатием в момент приема эмулятором он также может отправить какое-то кол-во байт, а при работе без сжатия прием и предача чередуются.
В приложении - новый вариант сервера HX_Server_2.2_-_UKNC_21.01.13_16-15 (http://zx.pk.ru/attachment.php?attachmentid=39427).
Изменения:
1. Сервер теперь поддерживает расширенный протокол HX v2.2, полностью совместимый с HX v2.1
2. Теперь при нажатии Ctrl/H в терминале - генерится код 010, а не 0177
3. В файл Terminal.ini добавлены новые параметры, задающие коды, посылаемые клавишами [Backspace] и [Enter]:
ANSI_STR_FOR_KEY[Backspace] = "\177"
ANSI_STR_FOR_KEY[Enter] = "\015"
Проверил свежую версию сервера HX на скорости 57600 - полёт нормальный.(Сжатие не работает).
http://i.piccy_.info/i7/cd4f7e6728c7fc76b89981d86fa1e17f/4-55-1051/12419795/20130123_214921_046_240.jpg (http://piccy_.info/view3/4024935/34d701e88650135adbfd09c23a3a2b79/)http://i.piccy_.info/a3/2013-01-23-19-50/i7-4024935/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-23-19-50/i7-4024935/240x180-r)
Patron, для проверки версии Alex_K добавьте в загрузчик проверку на переполнение 12 бит регистра 176570 / 010000 и посмотрим
проверку на переполнение 12 бит регистра 176570 / 010000В приложении - тестовая версия загрузчика Boot_RT-11_from_HX0.bin (http://zx.pk.ru/attachment.php?attachmentid=39488), которая читает байты из порта так:
B.ChIn:
Clr R5 ; R5 = Timeout count
In.Try:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
BiT #10000, @#TKS ; Overrun bit test
BEq 1$ ; 1801VP1-035 -065 ==> ONLY <==
Mov #Overrun, (SP) ;
RtI ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
1$:
TstB @#TKS
BMi In.OK
SOB R5, In.Try
Mov #BadPak, (SP)
RtI
In.OK:
Clr R5
BiSB @#TKB, R5
Add R5, R0
RtI
Мне удалось загрузится в эмуляторе со сжатием, я там одну переменную которая как-то задает время на обработку прерывания не в ту сторону менял :(
я там одну переменную которая как-то задает время на обработку прерывания не в ту сторону менял
листинг конфигурационного файла, скрин загрузки, эмулятор все кнопочки под рукой,
пожалуйста - тема очень очень важная ведь! )
hobot, позже, сейчас тестирование идет.
Ну да, вернул значения параметра к тем которые считал правильными и вот результат
http://zx-pk.ru/attachment.php?attachmentid=39489&stc=1&d=1358977373
осталось только на реале проверить.
(Сжатие не работает).Сжатие может работать только если:
1) В файле Terminal_ComPort_Adapter.ini установлен параметр fOutxCtsFlow = TRUE.
2) В кабеле правильно разведён (и не отвалился) провод CTS.
3) У 1801ВП1-065 исправно работает (и не отвалилась) нога 2 (108).
Последние два пункта можно проверить тестером, если не выходя в меню загрузки на УКНЦ - отправить с PC из окна терминала и телетайпа какие-нибудь байты в порт. До отправки байта с PC на линии CTS должен быть уровень TRUE, а после отправки - FALSE.
...
вот результатТам каждый второй раз вылезает "Bad Packet" из-за того, что после оверрана не очищается входной буфер и остаток предыдущего пакета попадает в начало приёма следующего.
В приложении - тестовая версия загрузчика Boot_RT-11_from_HX0.bin (http://zx.pk.ru/attachment.php?attachmentid=39490), которая должна быть лишена этого недостатка.
...
С исходным значением параметра в эмуляторе
http://zx-pk.ru/attachment.php?attachmentid=39491&stc=1&d=1358979832
С новым значением параметра (подобран эмпирически)
http://zx-pk.ru/attachment.php?attachmentid=39492&stc=1&d=1358979832
Не пробегало исходники TU58.SAV хочется посмотреть :)
загрузчик грузится на скорости 9600, а потом устанавливает скорость из конфигаНужен ассемблерный код установки скорости.
А реализовать это (наверное) лучше через предзагрузчик. Кому не надо - просто будут сразу запускать загрузчик. А то в загрузчике уже места для дополнительного кода не осталось.
Vamos, взял HX Server отсюда http://zx-pk.ru/showpost.php?p=564797&postcount=160 связал с эмулятором (текущие исходники ревизия 484) по com0com -- загрузился через Стык С2. Или с этим и не было проблем?
Как грузиться с TU58 -- где посмотреть?
Как грузиться с TU58 -- где посмотреть?Для TU58.exe все настройки в файле TU58.ini
port 0
baud 9600,N,8,1Это для COM1.
Для COM2 нужно указать port 1, для COM3 - port 2 и т.д.
Запускать TU58.exe лучше через окно командной строки:
C:\TU58> TU58.exe DDSYS.dsk
C TU58 работает драйвер DD.SYS (его исходники полезно посмотреть), поэтому, после обычной загрузки делаем DIR DD: и если каталог прочитался успешно - BOOT DD:
---------- Post added at 01:27 ---------- Previous post was at 01:22 ----------
взял HX Server отсюдаТекущая версия HX Server - ЗДЕСЬ (http://zx.pk.ru/showthread.php?p=569515#post569515).
Нужен ассемблерный код установки скорости.
http://zx-pk.ru/showpost.php?p=392643&postcount=58
Или с этим и не было проблем?
Не грузилось до rev. 484
Как грузиться с TU58 -- где посмотреть?
http://zx-pk.ru/showpost.php?p=469503&postcount=101
После загрузки TU58 нажать ESC потом в эмуляторе "пробел"
Там для установки скорости целая программа под RT-11
переключение нестабильное и может на первый раз не сработать. Может стабильности удастся добиться, вставив паузу между заносом в регистр 177704 нового значения и установкой бита 8 в 177700, а также между установкой и сбросом бита 8 в 177700.
А надёжный вариант предзагрузчика для запуска на голом железе кто-нибудь напишет ?
Для меня ПП УКНЦ - тёмный лес.
http://zx-pk.ru/showpost.php?p=392643&postcount=58
Не грузилось до rev. 484
http://zx-pk.ru/showpost.php?p=469503&postcount=101
После загрузки TU58 нажать ESC потом в эмуляторе "пробел"
HX Server 2.2 -- тоже загрузился на текущей версии исходников.
TU58 -- через UkncComSender передаётся и запускается TU58.SAV, загрузка висит после нажатия пробела в эмуляторе, неясно что происходит.
---------- Post added at 14:20 ---------- Previous post was at 14:11 ----------
А, так оказалось что у меня TU58.EXE вообще не запускается -- оно 16-разрядное, а винда 64-разрядная.
---------- Post added at 14:22 ---------- Previous post was at 14:20 ----------
Пару ссылок нашёл про TU58:
http://www.fpns.net/willy/pdp11/tu58-emu.htm
http://www.fpns.net/willy/pdp11/rt11arc.txt
---------- Post added at 14:27 ---------- Previous post was at 14:22 ----------
Вот ещё один эмулятор TU58, намного более конфигурируемый, да ещё и с исходным кодом:
http://www.ak6dn.dyndns.org/PDP-11/TU58/tu58em/
---------- Post added at 14:36 ---------- Previous post was at 14:27 ----------
С эмулятором tu58em пытается грузиться, доходит до надписи
RT-11SJ V05.04 (Rus\Lat)
и на этом висит.
Вот ещё один эмулятор TU58, намного более конфигурируемый, да ещё и с исходным кодомЭтот эмулятор TU58 работает заметно менее стабильно. Сразу после запуска он в ~ 80% случаев не успевает ответить на запросы DD.SYS и тот отваливает по таймауту, но после первого удачного ответа становится заметно лучше, хотя иногда сервер не отвечает на запросы драйвера и загрузка зависает.
.BO DD:
SL V08.00 [SW] Сторожевых С.В. 1988
RT-11SJ (Y) V05.04 G
.SET USR NOSWAP
.SET EXIT NOSWAP
.SET TT SCOPE
.SET EM ON
.SET SL ON
.SH MEM
Address Module Words
------- ------ -----
160000 IOPAGE 4096.
155542 DD 591.
144714 RMON 2251.
142214 EM 672.
135674 SL 1128.
125630 USR 2066.
001000 ..BG.. 21708.
Этот эмулятор TU58 работает заметно менее стабильно. Сразу после запуска он в ~ 80% случаев не успевает ответить на запросы DD.SYS и тот отваливает по таймауту, но после первого удачного ответа становится заметно лучше, хотя иногда сервер не отвечает на запросы драйвера и загрузка зависает.
TU58 работает не только стабильно, но и на порядок стабильнее. Это и не удивительно - там нет такого понятия как рассинхронизация протокола так как в любой момент его можно мгновенно синхронизировать. Но есть один нюанс: требуется полноценный порт, а не всякое PCI-USB дерьмо. Для работы TU58 (в том числе штатной) обязательным условием является использованием BREAK в сторону TU58. Я пока не нашел ни одного PCI или USB порта который бы умел это. С родными же COM портами еще ни разу не было ни малейшего сбоя даже если эмулятор TU58 запускался в VMWare на перегруженной в усмерть системе...
---------- Post added at 22:14 ---------- Previous post was at 22:12 ----------
Только вот родной TU58 маловат для чего-либо кроме диагностики и начальной установки :)
Для работы TU58 (в том числе штатной) обязательным условием является использованием BREAK в сторону TU58.
В сторону TU58.SAV или TU58.EXE ?
Для работы TU58 (в том числе штатной) обязательным условием является использованием BREAK в сторону TU58.Как выяснилось, правильная эмуляция сигнала BREAK - довольно сложная и увлекательная задача. Есть несколько важных вопросов, для ответа на которые потребуется несколько тестов ( напишу тесты на следующей неделе ):
1. При установке BREAK порт устанавливает в линии постоянный 0, т.е. начинает непрерывно передавать стартовые биты. Эмулятор порта com0com при каждом получении BREAK передаёт нулевой байт - отсюда вопросы:
1.1. Принимает ли реальный DL-порт фиктивный нулевой байт при получении BREAK.
1.2. Устанавливается ли в принимающем порту бит готовности если у принимаемого байта не пришёл стоповый бит.
1.3. Те же вопросы про COM-порт.
2. Влияет ли бит BREAK на передачу текущего байта ( у которого уже ушёл стартовый бит, но ещё не ушёл стоповый бит ).
2.1. Как с этим дела у DL-порта.
2.2. Как с этим дела у COM-порта.
3. Устанавливается ли бит готовности в передающем DL-порту после "завершения передачи" байта, если в ходе передачи был установлен бит BREAK.
3.1. Если бит BREAK был установлен после начала передачи и сброшен до завершения передачи.
3.2. Если бит BREAK был установлен после начала передачи и сброшен после завершения передачи.
4. Устанавливается ли бит готовности в передающем DL-порту после "завершения передачи" байта, если до начала передачи был установлен бит BREAK.
В сторону TU58.SAV или TU58.EXE ?
Я так полагаю, что это одно и то же функционально?
К слову, я говорил только о .EXE - .SAV я не видел.
В сторону TU58.SAV или TU58.EXE ?От RT-11 ( работающей, например, на эмуляторе УКНЦ ) к TU-серверу ( в виде программы TU58.exe, программы TU58em.exe или реального привода TU58, подключенного к реальному порту ).
---------- Post added at 19:41 ---------- Previous post was at 19:41 ----------
.SAV я не видел.Это загрузчик TU58 в виде программы для RT-11.
Как выяснилось, правильная эмуляция сигнала BREAK - довольно сложная и увлекательная задача
А его и не надо эмулировать - аппаратура отлично справляется с этим. Если конечно речь идет не об урезанных COM портах.
При установке BREAK порт устанавливает в линии постоянный 0
Да, шлются непрерывные нули.
BREAK передаёт нулевой байт.
Не просто нулевой байт, а все передаваемые биты - нули - никаких стоповых.
1.1. Принимает ли реальный DL-порт фиктивный нулевой байт при получении BREAK.
Принимает скорее всего нулевой байт. Ни разу не проверял за ненужностью так как нулевой байт сам по себе не является признаком BREAK.
Устанавливается ли в принимающем порту бит готовности если у принимаемого байта не пришёл стоповый бит.
Да.
Кроме того нужно анализировать состояние принятого байта. В некоторых реализациях (DLV-11J, KDJ11-B SLU) есть бит явного определения BREAK (11й чтоли - не помню). Этот способ определения неудобен так как зависит от устройства. Более простой способ - бит 13 (TKB) - frame error. BREAK гарантированно его установит.
1.3. Те же вопросы про COM-порт.
Про COM порт уже не помню - со времен доса не ковырялся, вроде там стандартизован бит обнаружения BREAK.
2. Влияет ли бит BREAK на передачу текущего байта ( у которого уже ушёл стартовый бит, но ещё не ушёл стоповый бит ).
Скорее всего нет, но нет и особой разницы начать BREAK с нового байта или с того который уже ушел - frame error будет и в том и в другом случае.
Устанавливается ли бит готовности в DL-порту после "завершения передачи" байта, если в ходе передачи был установлен бит BREAK.
Да.
На примере того же TU58, правила требуют инициализации контроллера установкой BREAK и отправкой 6 или 7 (точно не помню) нулей (естественно с проверкой готовности или по прерыванию), после чего BREAK снимается. На этом месте как раз косячат кривые порты. Мой к примеру сигнализирует BREAK один раз, после чего выплеввывает некий внутренний буфер (в котором находится то, что уже было выдано из порта только что).
3.1. Если бит BREAK был установлен после начала передачи и сброшен до завершения передачи.
3.2. Если бит BREAK был установлен после начала передачи и сброшен после завершения передачи.
Уверенности нет и проверить сейчас не на чем - надо комп какой-нибудь из под стола вытаскивать.
4. Устанавливается ли бит готовности в DL-порту после "завершения передачи" байта, если до начала передачи был установлен бит BREAK.
Как уже было написано выше - да.
---------- Post added at 23:56 ---------- Previous post was at 23:55 ----------
Это загрузчик TU58 в виде программы для RT-11.
Тогда речь не о нем.
Речь об эмуляторе TU58.
1. При установке BREAK порт устанавливает в линии постоянный 0, т.е. начинает непрерывно передавать стартовые биты. Эмулятор порта com0com при каждом получении BREAK передаёт нулевой байт - отсюда вопросы:
1.1. Принимает ли реальный DL-порт фиктивный нулевой байт при получении BREAK.
По поводу 1801ВП1-065 могу сказать точно, что если подается сигнал BREAK и по длительности он превышает длину байта, т.е. вместо стоп-битов передается сигнал низкого уровня, то 1801ВП1-065 устанавливает бит готовности в регистре статуса приемника, в этом же регистре устанавливает бит 0 - ошибка приема стопового бита, в регистре данных приемника будет соответственно ноль.
1801ВП1-035 отличается тем, что у нее нет в регистре состояния приемника ошибки приема стопового бита, вместо этого на выводе HLT устанавливается активный низкий уровень, и если этот вывод присоединен в соответствующей ноге процессора, то процессор переводится в режим останова (выход в пульт). Сбросить этот активный уровень можно по сигналу INIT (команда RESET).
Руки все не доходят сделать эмулятор dt2 под RT-11 или вообще sa...
Да, точно - поведение передающего порта не зависит от состояния бита BREAK:
BIS #CS$BRK,@R0 ;SET BREAK FOR SIGNAL
MOV (PC)+,R3 ;SEND ONES FOR TIMING
.WORD 177777
CALL BCHROS ;OUTPUT THEM
CONRD1: TSTB @R0 ;READY YET ?
BPL CONRD1 ;NOT YET
BIC #CS$BRK,@R0 ;CLEAR THE BREAK
А что происходит на принимающей стороне:
1. Ничего не принимается
2. Принимается один нулевой байт
3. Принимаются непрерывные нулевые байты
бит 0 - ошибка приема стопового бита
Это так в документации называется?
А при установке бита 00 в регистре состояния передатчика как долго выдается старт бит?
1. Ничего не принимается
2. Принимается один нулевой байт
3. Принимаются непрерывные нулевые байты
Принимается столько нулевых байтов сколько их отправлено. По крайней мере на нормальном порту. Завтра подключу комп с досом или полуосью, запущу там E11 на прием и более детально можно будет тесты покрутить. Можно конечно еще под OpenVMS написать прогу, но тут придется или изучать функции или полагаться на POSIX termios, что не надежно не в UNIXе :)
Завтра подключу комп с досом или полуосьюА 11/83 от брейка всегда в пульт вылетает ?
Это так в документации называется?
Не все в документации на УКНЦ описано. Читайте документацию на КТЛК, она как раз на 1801ВП1-065 построена, там кое-что поподробнее описано.
А при установке бита 00 в регистре состояния передатчика как долго выдается старт бит?
А вот про это в документации на УКНЦ вроде точно описано: "при установленном разряде с случае готовности линии на выходе устанавливается высокий уровень (старт). при отсутствии готовности на выходе устанавливается низкий уровень (стоп)".
Под готовностью линии тут понимается активный низкий уровень на входе BSYD 1801ВП1-065. А так если линия все время готова, то установили бит 0, 1801ВП1-065 стал слать непрерывно нулевые биты, сбросили - начинает слать единичные.
А 11/83 от брейка всегда в пульт вылетает
Зависит от настройки. У меня включено.
---------- Post added at 00:18 ---------- Previous post was at 00:17 ----------
Нашел досовскую машинку недалеко с нормальным портом. Сейчас проверим все :)
Принимается столько нулевых байтов сколько их отправлено.Фокус в том, что передающий порт передаёт "непрерывный ноль" вне зависимости от наличия байта для передачи в сдвиговом регистре. Поэтому принимающий порт будет получать нули даже тогда, когда сдвиговый регистр передающего порта пуст. Даже если принимающий порт имеет отличающиеся настройки - он будет принимать нули в режиме BREAK.
Или когда сдвиговый регистр пуст - порт в режиме BREAK будет передавать единицы (стоповые биты) ?
Фокус в том, что передающий порт передаёт "непрерывный ноль" вне зависимости от наличия байта для передачи в сдвиговом регистре. Поэтому принимающий порт будет получать нули даже тогда, когда сдвиговый регистр передающего порта пуст. Даже если принимающий порт имеет отличающиеся настройки - он будет принимать нули в режиме BREAK.
Именно так. Передаваемые при установленном BREAK байты нжны исключительно чтобы вычислить длительности BREAK. А что касается принимающего порта, как я и говорил, BREAK гарантированно идентифицируется и принятое значение само по себе не имеет значения.
Достаточно принимать из TKB не байт, а слово, чтобы следующей командой поставить BMI, а там куда BMI передается проверить frame error.
BREAK гарантированно идентифицируется и принятое значение само по себе не имеет значенияЭто становится важно, когда пишешь эмулятор порта - нужно, чтобы всё там было "как взаправду".
Это становится важно, когда пишешь эмулятор порта - нужно, чтобы всё там было "как взаправду".
Сейчас напишу программку для тестов и проверим разные варианты.
Кстати о портах - обозвал бы в эмуляторе попривычнее, а то название DL11-W дважды вводит в заблуждение :)
com0com только один нулевой байт принимает вне зависимости от продолжительности BREAK, а что реальный COM-порт - сколько нулевых байтов принимает при непрерывном нуле на входе ?
com0com только один нулевой байт принимает вне зависимости от продолжительности BREAK, а что реальный COM-порт - сколько нулевых байтов принимает при непрерывном нуле на входе ?
Столько сколько полных посылок передается.
По поводу 1801ВП1-065 могу сказать точно, что если подается сигнал BREAK и по длительности он превышает длину байта, т.е. вместо стоп-битов передается сигнал низкого уровня, то 1801ВП1-065 устанавливает бит готовности в регистре статуса приемника, в этом же регистре устанавливает бит 0 - ошибка приема стопового бита, в регистре данных приемника будет соответственно ноль.Т.е. обнулятся даже те биты, которые были приняты до установки BREAK ?
Но если установить BREAK на время передачи только одного бита - только он, наверное, и окажется обнулённым.
Т.е. обнулятся даже те биты, которые были приняты до установки BREAK ?
В каком смысле? Как я понял сначала послать байт на выдачу, а затем установить бит подачи BREAK во время его посылки?
Но если установить BREAK на время передачи только одного бита - только он, наверное, и окажется обнулённым.
Возможно, если не стартовым.
В каком смысле? Как я понял сначала послать байт на выдачу, а затем установить бит подачи BREAK во время его посылки?Ну, да - это же общий случай. Допустим, 7 битов передаваемого байта из 8 уже попали в сдвиговый регистр принимающего порта, как вдруг программа на передающей стороне установила в передающем порту бит BREAK. Что окажется в регистре данных принимающего порта после установки бита готовности его приёмника ?
Ну, да - это же общий случай. Допустим, 7 битов передаваемого байта из 8 уже попали в сдвиговый регистр принимающего порта, как вдруг программа на передающей стороне установила в передающем порту бит BREAK. Что окажется в регистре данных принимающего порта после установки бита готовности его приёмника ?
Тогда, по идее, если это возможно, то принятые биты останутся принятыми, остальные нулями и возникнет ошибка приема стопового бита.
При нормальном BREAK, который устанавливает линию в это состояние, когда она пустая, естественно принимаются все нулевые биты.
Сегодня эксперимент отменяется - DOSовская машина 386 - не тянет E11.
Завтра откопаю OS/2шную.
---------- Post added at 01:34 ---------- Previous post was at 01:30 ----------
Сегодня эксперимент отменяется - DOSовская машина 386 - не тянет E11.
Завтра откопаю OS/2шную.
Хмм... Похоже от недосыпа мозги слиплись :)
Нахрена мне вообще второй комп если у меня DLV11-J есть :)
Нахрена мне вообще второй комп если у меня DLV11-J естьИ если не в каждом порту брейк выносит 11/83 в пульт ( или в каждом? ).
И если не в каждом порту брейк выносит 11/83 в пульт ( или в каждом? ).
У меня родной KDJ11 SLU настроен на HOB. В DLV11-J четвертый порт можно настроить на HOB (с завода он так и настроен и совпадает с регистрами консольного порта, я переконфигурил чтобы не мешался родному и убрал HOB).
Вобщем тест на DLV11-J показал, что с BREAK (как минимум на приличных портах) все не так как предполагалось :)
К сожалению ни одной живой PCшки с нормальным портом не нашлось - все надо чистить и проверять.
Провел несколько тестов в пределах одного DLV11-J воткнув выход TT2 на вход TT3 и наоборот.
Исходные данные:
BUFSZ - размер буфера в словах (8)
BUFF - буфер
TCS, TDA - регистры передатчика
FLAG - просто слово для сохранения чего-нибудь
Тест заканчивается как только приемник принял 8 слов или примерно через 1 секунду после начала.
Тесты:
;Просто вывод символов 000-007
TEST1:: .WORD T1
MOV #BUFSZ,R1
CLR R0
10$: TSTB @#TCS
BPL 10$
MOVB R0,@#TDA
INC R0
SOB R1,10$
BR .
; Установка BREAK и ничего не выводим
TEST2:: .WORD T2
TSTB @#TCS
BPL .-4
BIS #BRK,@#TCS
BR .
; Выводим символ и сразу устанавливаем BREAK
TEST3:: .WORD T3
TSTB @#TCS
BPL .-4
MOVB #123,@#TDA
BIS #BRK,@#TCS
BR .
; Устанавливаем BREAK и выводим символы 000-007
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 .
Результаты:
.RU DLT
TEST #1
000000 000001 000002 000003 000004 000005 000006 000007
FLAG: 000000
TEST #2
120000
FLAG: 000000
TEST #3
120000
FLAG: 000000
TEST #4
120000
FLAG: 000001
Итого:
простой вывод как и положено просто вывел
включение BREAK выводит один полный набор нулей и все
установка BREAK вслед за отправкой символа дает BREAK (можно поиграться с паузами или потестить бит ACTIVE на приемнике и после установки его сделать BREAK)
пока бит BREAK установлен, ничего не выводится, и вывод символов в программах в этом случае нужен только для достаточности паузы
установка BREAK вслед за отправкой символа дает BREAKОно и понятно - если на скорости 9600 посылка из 10 битов передаётся за 960 NOPов, то только передача стартового бита займёт ~ 100 NOPов (после засылки байта в порт для передачи).
Оно и понятно - если на скорости 9600 посылка из 10 битов передаётся за 960 NOPов, то только передача стартового бита займёт ~ 100 NOPов (после засылки байта в порт для передачи).
Предлагай варианты тестов - их легко добавлять :)
---------- Post added at 23:07 ---------- Previous post was at 23:04 ----------
У KDJ11-B на консольном SLU есть битик в приемнике: The RCV ACT bit is set by the start bit of the serial input data and is cleared by the stop bit at the end of the serial input data. The RX DONE bit is set by the next bit time
after RCV ACT is cleared..
Но есть ли такой на DLV11-J фиг знает - вот бита обнаружения BREAK как вижу нету (у KDJ11-B есть) - только frame error.
Предлагай варианты тестов - их легко добавлять
Можно попробовать выставлять BREAK с задержкой кратной передаче бита:
; Выводим символ и устанавливаем BREAK с задержкой в R5
TEST3:: .WORD T3
TSTB @#TCS
BPL .-4
MOVB #377,@#TDA
SOB R5, .-.
BIS #BRK,@#TCS
BR .
При R5 = 50 ; 100 ; 150 ; 200 ; 250 ; 300 ; 350 ; 400 ; 450 ; 500
Можно попробовать выставлять BREAK с задержкой кратной передаче бита:
; Выводим символ и сразу устанавливаем BREAK
TEST3:: .WORD T3
TSTB @#TCS
BPL .-4
MOVB #123,@#TDA
SOB R5, .-.
BIS #BRK,@#TCS
BR .
При R5 = 50 ; 100 ; 150 ; 200 ; 250 ; 300 ; 350 ; 400 ; 450 ; 500
Сейчас чего-нибудь придумаем. R5 и R4 усить нельзя - они используются.
Можно конечно второй набор регистров задействовать, но лениво :)
Да, передавать лучше все единицы ( 0377 ).
---------- Post added at 19:13 ---------- Previous post was at 19:11 ----------
R5 и R4 усить нельзя - они используются.Номер регистра для задержки не принципиален :)
Тест с задержками:
TEST5: .WORD T5
MOV (PC)+,R1
DELAY: .WORD 50.
MOV R1,FLAG
ADD #50.,DELAY
CMP DELAY,#550.
BEQ 10$
SUB #2,TESTP
10$: TSTB @#TCS
BPL .-4
MOVB #-1,@#TDA
SOB R1,.
BIS #BRK,@#TCS
BR .
TEST #5
120000
FLAG: 000062
TEST #5
120000
FLAG: 000144
TEST #5
120001
FLAG: 000226
TEST #5
120001
FLAG: 000310
TEST #5
120003
FLAG: 000372
TEST #5
120003
FLAG: 000454
TEST #5
120007
FLAG: 000536
TEST #5
120007
FLAG: 000620
TEST #5
120017
FLAG: 000702
TEST #5
120017
FLAG: 000764
То есть данные начинает передавать, а потом идут нули и получается frame error.
---------- Post added at 23:27 ---------- Previous post was at 23:19 ----------
Расширил тест, передается #252:
TEST #5
120052
FLAG: 001356
TEST #5
120252
FLAG: 001440
TEST #5
120252
FLAG: 001522
TEST #5
000252 120000
FLAG: 001604
Похоже, что если установить BREAK после задержки 350 ( 0536 ), а потом снять после дополнительной задержки 200 ( 0310 ) - то байт передастся вполне нормально, но два бита в середине у него обнулятся.
---------- Post added at 19:36 ---------- Previous post was at 19:31 ----------
Расширил тест, передается #252Т.е. в битовом виде: 10101010 - странновато выглядит, особенно на фоне 00001111 при задержке 500.
Т.е. в битовом виде: 10101010 - странновато выглядит, особенно на фоне 1111 при задержке 500.
Это разные тесты. В первом 377 передавалось, во втором 252.
---------- Post added at 23:39 ---------- Previous post was at 23:37 ----------
Похоже, что если установить BREAK после задержки 350 ( 0536 ), а потом снять после дополнительной задержки 200 ( 0310 ) - то байт передастся вполне нормально, но два бита в середине у него обнулятся.
Именно так:
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 .
TEST #6
000347
FLAG: 000000
The RCV ACT bit is set by the start bit of the serial input data and is cleared by the stop bit at the end of the serial input data. The RX DONE bit is set by the next bit time after RCV ACT is clearedПолучается, что при наличии BREAK - бит RCV ACT не очищается, а бит RX DONE не устанавливается. В реальности так и есть ?
Получается, что при наличии BREAK - бит RCV ACT не очищается, а бит RX DONE не устанавливается. В реальности так и есть ?
Сейчас попробую выяснить есть ли этот бит на DLV11-J - с консольным портом огород городить лениво :)
---------- Post added at 23:49 ---------- Previous post was at 23:44 ----------
Похоже нету у DLV11-J такого.
TEST7:: .WORD T7
TSTB @#TCS
BPL .-4
MOVB #252,@#TDA
10$: BIT #4000,@#RCS
BEQ 10$
INC FLAG
BR .
TESTP:: .WORD TESTS
TESTS:: .WORD TEST7
.WORD 0
.EX DLT
TEST #7
000252
FLAG: 000000
Похоже нету у DLV11-J такогоВопрос в том, у всех ли принимающих портов устанавливается бит готовности в конце посылки без стоповых битов.
Бит RX DONE на консольном SLU связан как-то с битом готовности ?
RX DONE не устанавливается.
Устанавливается так как иначе прерывания бы не было, а оно есть.
---------- Post added at 23:55 ---------- Previous post was at 23:55 ----------
Бит RX DONE на консольном SLU связан как-то с битом готовности ?
Ну это собственно он и есть.
Ну это собственно он и есть.Т.е. описание работы бита RCV ACT врёт - этот бит очищается не стоповым битом, а истечением интервала bit_time x bit_size.
Т.е. описание работы бита RCV ACT врёт - этот бит очищается не стоповым битом, а истечением интервала bit_time x bit_size.
А описание и не говорит ничего про стоп бит в отношении RX DONE.
И так поступают вообще все порты - иначе они бы не устанавливали готовность приёма без стоповых битов.
И так поступают вообще все порты - иначе они бы не устанавливали готовность приёма без стоповых битов.
Насчет стоповых битов, скорее всего имеется в виду то место где он должен быть, а не установленный бит в этом месте.
А описание и не говорит ничего про стоп бит в отношении RX DONE.Там сказано, что бит RX DONE устанавливается через bit_time после очищения RCV ACT, в отношении которого совершенно однозначно утверждается, что бит RCV ACT очищается именно стоповым битом (ошибка!).
Там сказано, что бит RX DONE устанавливается через bit_time после очищения RCV ACT, в отношении которого совершенно однозначно утверждается, что бит RCV ACT очищается именно стоповым битом (ошибка!).
Ошибки нет. Стоп бит принимается. А установлен он или нет - это уже другой вопрос.
Ошибки нет. Стоп бит принимается.Точно! В случае с BREAK - именно так и есть.
Значит ли это, что если скорость передающего порта меньше скорости принимающего и вместо стопового бита пришёл бит данных - готовность приёма наступит, а если скорость передающего порта больше скорости принимающего и вместо стопового бита пришло неопределённое состояние - готовность приёма не наступит.
Вобщем вот описание битов KDJ11-B SLU. Вполне можно прочитать неоднозначно по крайней мере при моем знании языка :)
В любом случае, понятно что имеется в виду и для реализации вполне достаточно.
TKS
===
Bit(s) Name Status Function
------- --------------- --------------- ------------------------------------------------------------
<15:12> Not used RO Read as zeros.
11 RCV ACT RO The RCV ACT bit is set by the start bit of the serial input
data and is cleared by the stop bit at the end of the serial
input data. The RX DONE bit is set by the next bit time
after RCV ACT is cleared.
<10:8> Not used RO Read as zeros.
7 RX DONE RO The RX DONE bit is set when a character is received and
is ready to be read from the RBUF register. The bit is
cleared by reading the RBUF register and by power-up.
6 RX IE RW The RX IE bit is set when RXIRQ is enabled and a
program interrupt is requested while RX DONE is set
with this bit. The bit is cleared by BUS INIT and by
power-up.
<5:0> Not used RO Read as zeros.
TKB
===
Bit(s) Name Status Function
------- --------------- --------------- ------------------------------------------------------------
15 ERR RO The ERR bit is set when the OVR ERR bit or the FRM
ERR. bit is set. This bit does not generate a program
interrupt and is clear when both of these bits are clear.
14 OVR ERR RO The OVR ERR bit is set when a previous character was
received but was not read before it was overwritten by the
current character.
13 FRM ERR RO The FRM ERR bit is set when the current character has
no stop bit. This bit is used to detect breaks.
12 Not used RO Read as zero.
11 RCV BRK RO The RCV BRK bit is set when the end of the serial data
input remains in the space condition for all 11 bits. The
bit remains set until the serial data input returns to the
mark condition.
<10:8> Not used RO Read as zeros.
<7:0> Input data RO These eight bits are an ASCII character read as input
when RCSR bit 7 is set.
TPS
===
Bit(s) Name Status Function
------- --------------- --------------- ------------------------------------------------------------
<15:8> Not used RO Read as zeros.
7 TX RDY RO The TX RDY bit is set when the XBUF is cleared and
can receive another character. The bit is cleared when the
XBUF is full. It is also set by power-up and by BUS INIT.
6 TX IE RW The TX IE bit is set when TXIRQ is enabled and a
program interrupt is requested while TX RDY is set with
this bit. The bit is cleared by BUS INIT and by power-up.
<5:3> Not used RO Read as zeros.
2 MAINT RW The maintenance bit is set during a self-test that disconnects
the external serial input and connects it to the internal
serial output. This bit is cleared by BUS INIT and by
power-up.
1 Not used RO Read as zero.
0 XMIT BRK RW The XMIT BRK bit is set when the output serial data is
forced into the space condition. The bit is cleared by BUS
INIT and by power-up.
TPB
===
Bit(s) Name Status Function
------- --------------- --------------- ------------------------------------------------------------
<15:8> Not used NA Read as zeros.
<7:0> Output data WO These eight bits are an ASCII character transmitted as
output when XCSR bit 7 is set.
---------- Post added at 00:15 ---------- Previous post was at 00:12 ----------
Значит ли это, что если скорость передающего порта меньше скорости принимающего и вместо стопового бита пришёл бит данных - готовность приёма наступит, а если скорость передающего порта больше скорости принимающего и вместо стопового бита пришло неопределённое состояние - готовность приёма не наступит.
А черт его знает. Но одно из применений функции BREAK - подстройка параметров линии под терминал. В описании UNIX можно найти эту процедуру. Правда работает это только на мультиплексорах - у DL(V)11 нет нужного функционала.
А черт его знает.Я ошибался - после завершения передачи порт держит на линии уровень стопового бита, а не неопределённое состояние, поэтому при любой разнице скоростей стоповый бит будет принят.
Сейчас распознаю qbus interfaces для удобства - это единственное описание (кроме внутренностей) по DLV11-J которое я нашел и там вроде расписаны биты которые он использует...
описание битов KDJ11-B SLU
Отличается от битов DL11-W:
http://emulator.pdp-11.org.ru/misc/DL11W_bits.png
Отличается от битов DL11-W
Ну да, там нету явного бита определения break (да и вообще по-моему кроме KDJ11 нигде нету), есть бит ошибки parity. Все остальные хитрости трех вариантов его использования переключателями ставятся :)
там нету явного бита определения break (да и вообще по-моему кроме KDJ11 нигде нетуА сможет ли KDJ11 с первого байта отличить BREAK от Framing_Error, если до установки BREAK успели приняться несколько ненулевых битов..
А сможет ли KDJ11 с первого байта отличить BREAK от Framing_Error, если до установки BREAK успели приняться несколько ненулевых битов..
Я думаю индикатор break срабатывает только на все нули. Иначе как его собственно отличить от frame error каковым break сам по себе тоже является :)
---------- Post added at 00:35 ---------- Previous post was at 00:34 ----------
А байт, как мы видим, первый и он же последний обычно...
Правда у меня CM7209 есть который шлет BREAK пока не скажешь чтобы перестал...
---------- Post added at 00:37 ---------- Previous post was at 00:35 ----------
Кстати надо будет еще терминалы подключить и посмотреть что они передают.
VT220 к примеру передает длинный break, но сам его отключает.
Я думаю индикатор break срабатывает только на все нули.Т.к. ошибка распознания BREAK грозит вылетом в пульт - может случиться, что BREAK распознаётся только если вместо стопового бита принимаются N стартовых.
И вообще - если порт на той стороне передаёт на скорости 300 bps, а SLU принимает на максимальной ( какая она? ) то при достаточной разнице скоростей обычный стартовый бит обычной посылки вынесет принимающую сторону в пульт.
Т.к. мы умеем уже тестировать порт "с битовым разрешением" - момент установки бита BREAK_RECIVED в SLU вполне возможно протестировать.
Т.к. ошибка распознания BREAK грозит вылетом в пульт - может случиться, что BREAK распознаётся только если вместо стопового бита принимаются N стартовых.
Подумаю как потестить консольный порт...
Жаль его нельзя перенастроить на другой регистр-вектор - можно только убрать совсем.
---------- Post added at 00:49 ---------- Previous post was at 00:47 ----------
А что до ошибочного срабатывания BREAK, я с этим еще в E11 на CM7209 намучился - он при включении шлет BREAK. Кончилось тем, что я вообще запретил реакцию на него в E11.
---------- Post added at 00:50 ---------- Previous post was at 00:49 ----------
Если так дело дальше пойдет, придется расчищать место и собирать 11/84 в качестве второго настольника :)
Заодно пресловутый DL11-W можно будет потестить...
Если сгенерить RT-11 с нестандартным консольным портом - можно выяснить задержку определения BREAK по тому моменту, когда тест, устанавливающий и (после задержки) снимающий BREAK - начнёт выносить 11/83 в пульт.
Если сгенерить RT-11 с нестандартным консольным портом - можно выяснить задержку определения BREAK по тому моменту, когда тест, устанавливающий и (после задержки) снимающий BREAK - начнёт выносить 11/83 в пульт.
В этом случае придется или на ходу перетыкать провода или переконфигурять настройки чтобы загрузка была автоматической - сейчас он у меня в диалог входит.
На досуге надо панель переключателей сделать будет, а заодно всякие индикаторы и enable/halt туда вынести - последнего мне очень не хватает :)
---------- Post added at 01:02 ---------- Previous post was at 00:59 ----------
Хотя наверное проще попробовать с помощью PCшного порта реализовать нужное.
Завтра посмотрю что у меня там с памятью в 386м гробу - у меня вроде запасной дофига было к нему.
---------- Post added at 01:12 ---------- Previous post was at 01:02 ----------
Выдержка из описания DLV11-J:
Break Logic
During normal operation, the UART checks each received character
for the proper number of stop bits. It does this by testing for a marking
condition at the appropriate bit time. If it finds a spacing condition
instead, it sets the framing error (FE) flag. The BREAK signal is a
continuous spacing condition, and is interpreted by the UART as a
data character that is missing its stop bit(s). The UART, therefore,
responds to the BREAK signal by asserting FE H. If the channel 3
break response jumper is installed from X to B, FE H will negate
control line BDCOK H; BDCOK H indicates to the processor that dc
power is “OK.” When FE H negates this signal, it causes the computer
to restart at the bootstrap (provided proper processor power-up mode
is selected).
If the break jumper is installed from X to H, the computer will not
“boot” on a framing error, but FE H will negate control line BHALT L.
This causes the computer to halt when a framing error is received.
---------- Post added at 01:22 ---------- Previous post was at 01:12 ----------
Вобщем нету в DLV11 всех этих хитрых битиков какие есть в KDJ11. В TKS есть только готовность, прерывания и вот такой хитрый бит:
Bit: 0
Description: Reader Enable. Setting this bit advances the paper
tape reader on an LT33 terminal one character at a time. Setting of this
bit clears Receiver Done (bit 7). Write-only bit.
The DLV11-KA 20 mA current loop option is required for operation of
this bit.
TKB полностью идентичен DL11-W.
TPS - готовность, прерывания, break.
TPB - как обычно просто байт.
Для эмулятора ДВК самое оно :)
И до кучи, DLV11-E...
KDJшные биты есть кроме явного BREAK.
Добавляются модемные линии и даже программная установка скорости...
Чтобы отличить явный BREAK от Framing_Error при скорости передатчика 50 bps - нужно ждать 200 мс. Не зря VT-100 шлёт короткий брейк продолжительностью 230 мс.
Чтобы отличить явный BREAK от Framing_Error при скорости передатчика 50 bps - нужно ждать 200 мс. Не зря VT-100 шлёт короткий брейк продолжительностью 230 мс.
Только сдается мне, никто и не пытается отличать. По крайней мере DLV11-J точно, судя по описанию...
---------- Post added at 02:09 ---------- Previous post was at 01:55 ----------
Выдержка из доки на DL11-W:
3.4.3 Break Generation Logic
When the BREAK bit (bit 0 in the XCSR) is set, it causes transmission of a continuous space. Because the XMIT RDY flag continues to function normally, the duration of a break can be timed by the pseudo-transmission of a number of characters. However, because the transmitter section of the UART is double-buffered, a null character (all Os) should precede transmission of the break to ensure that the previous character clears the line. In a similar manner, the final pseudo-transmitted character in the break should be null.
Авторы драйвера DD.SYS создали любопытную засаду для тех, кто эмулирует последовательные порты:
MOV #177777,@TOBFRA ;;;SEND ONES FOR TIMING
BIS #<CS$INT!CS$BRK>,@TOCSRA ;;;SET BREAK AND INTERRUPT ENABLE
CALL OUTRTN ;;;OUTPUT WAIT
MOV #177777,R5 ;SEND RUBOUT FOR TIMING
CALL OUTCHR ; AND WAIT ON IT
BIC #CS$BRK,@TOCSRA ;SHUT OFF BREAK
Перед установкой сигнала BREAK драйвер DD.SYS отправляет биты 11111111 в передающий порт и только затем устанавливает BREAK.
Но если бы после отправки единиц в порт - драйвер DD.SYS ещё и дождался прерывания готовности и только потом установил BREAK - засада из-за этого могла бы стать ещё глубже, потому что в реальном порту при этом успевает передаться ТОЛЬКО СТАРТОВЫЙ БИТ.
потому что в реальном порту
Это основная проблема эмуляции. Нужно эмулировать всякие задержки. В SimH есть много подобных задержек. В E11 реализованы только заждержки прерываний на заданное количество инструкций. К слову, в RT-11 DD под E11 работает очень хреново и чуть что, повисает.
DD под E11 работает очень хреново и чуть что, повисает.Если в приведённом фрагменте поменять местами верхние две строчки - DD.SYS должен без проблем работать под любым эмулятором, передающим BREAK.
Но мы об этом никому не скажем, правда :)
Ведь иначе эмуляция последовательных портов в эмуляторах PDP-11 так навсегда и останется весьма приблизительной.
Если в приведённом фрагменте поменять местами верхние две строчки - DD.SYS должен без проблем работать под любым эмулятором, передающим BREAK.
Я думаю, что дело там не в BREAK так как сам DD тоже полностью эмулируется :)
Ведь иначе эмуляция последовательных портов в эмуляторах PDP-11 так навсегда и останется весьма приблизительной.
Ну за сегодня вон сколько информации выудили интересной :)
PS. Только не надо делать эмуляцию Halt-On-Break в устройстве, обзываемом в конфиге DL11-W, а то будет тройная дезинформация ;)
Я думаю, что дело там не в BREAK так как сам DD тоже полностью эмулируетсяСудя по поведению TU58em.exe, который весьма точно эмулирует реальный TU58 - он совершенно обалдевает, получая единицы вместо нулей и не после установки BREAK, а перед ней ( большинство эмуляторов последовательных портов ведь сначала отправляют передаваемый байт и только потом делают задержку выставления своей готовности - а надо наоборот ).
Судя по поведению TU58em.exe, который весьма точно эмулирует реальный TU58 - он совершенно обалдевает, получая единицы вместо нулей и не после установки BREAK, а перед ней ( большинство эмуляторов ведь сначала отправляют передаваемый байт и только потом делают задержку выставления своей готовности - а надо наоборот ).
Про это я уже говорил - он совершенно не работает на PCI и USB COM портах (по крайней мере на тех что попадались), но прекрасно себя чувствует на стандартных PCшных портах как вживую так и под VMWare. Правда мне никогда в голову не приходила мысль подключить его к эмулятору :)
---------- Post added at 03:02 ---------- Previous post was at 02:57 ----------
Кстати насчет точности, по описанию автора, этот эмулятор вроде не работает с RSX. Видимо точность ограничена.
Все не доходят руки попробовать свой эмулятор сделать, чтобы не досовский был. Полное описание протокола есть...
Про это я уже говорилИмено про TU58em.exe, а не про TU58.exe ?
Это разные программы - TU58.exe единицами вместо нулей не испугать.
Имено про TU58em.exe, а не про TU58.exe ?
Это разные программы - TU58.exe единицами вместо нулей не испугать.
Я про досовский. Вроде TU58.EXE...
А TU58EM у меня вообще ни разу не завелся (если я правильно понял что это) :)
Правда я его мог пробовать завести на кривых портах как раз.
---------- Post added at 03:23 ---------- Previous post was at 03:07 ----------
Попробовал TU58EM с тем портом что есть - разумеется не работает нифига. Сам TU58EM повис намертво и убить нельзя :)
Кстати, в коде драйвера DD.SYS есть одна небольшая неточность:
MOV #177777,@TOBFRA ;;;SEND ONES FOR TIMING
BIS #<CS$INT!CS$BRK>,@TOCSRA ;;;SET BREAK AND INTERRUPT ENABLE
CALL OUTRTN ;;;OUTPUT WAIT
MOV #177777,R5 ;SEND RUBOUT FOR TIMING
CALL OUTCHR ; AND WAIT ON IT
BIC #CS$BRK,@TOCSRA ;SHUT OFF BREAK
Выставляя BREAK до готовности порта - единственное, чего можно добиться - это испортить текущий передаваемый байт.
Чтобы установить BREAK на линии в тот момент, когда передаётся стартовый бит только что отправленного в порт байта - нужно дождаться готовности порта, потому что в реальных последовательных портах признак готовности передатчика устанавливается не позже середины стартового бита текущей посылки.
Поэтому, более корректный код должен выглядеть так:
MOV #177777,@TOBFRA ;;;SEND ONES FOR TIMING
BIS #CS$INT,@TOCSRA ;;;SET INTERRUPT ENABLE
CALL OUTRTN ;;;WAIT FOR START BIT
BIS #CS$BRK,@TOCSRA ;;;SET BREAK
MOV #177777,R5 ;SEND RUBOUT FOR TIMING
CALL OUTCHR ; AND WAIT ON IT
BIC #CS$BRK,@TOCSRA ;SHUT OFF BREAK
Кроме того, если авторы драйвера думали, что отправив второй раз единицы в порт и сняв BREAK после прерывания готовности они опять "превратили единицы в нули" - это было их ошибкой.
Кроме того, если авторы драйвера думали, что отправив второй раз единицы в порт и сняв BREAK после прерывания готовности они опять "превратили единицы в нули" - это было их ошибкой.
Независимо от того, что они думали, они получили абсолютно правильный результат. А уж из каких соображений это сделано... :)
Во всяком случае драйвер брошен давно, в последних версиях он даже не поддерживается и просто лежит довеском, а работает как часы как на живом TU58 так и на TU58.EXE.
А вообще в доке по TU58 было написано, что нужно включить BREAK и "послать" 6-7 нулей, после чего снять BREAK и послать ноль (или несколько) - что-то в этом роде, на память не помню.
Восстановил 386 и опробовал в качестве TU58.
Можно будет потестить что-нибудь с точки зрения PC...
Commands are Help, Boot, List, Setup, Map and Test.
Type a command then press the RETURN key: B DD/A
CSR address = 176520
Trying DD0
Starting system from DD0
RT-11FB (S) V05.07
.SET USR NOSWAP
.SH DEV
Device Status CSR Vector(s)
------ ------ --- ---------
DD Resident 176520 320 324
DU Installed 172150 154
XL Installed 176500 300 304
VM Installed 177572 250
.
---------- Post added at 07:56 ---------- Previous post was at 07:32 ----------
Посмотрел тех доку на TU58. Похоже я не его рекомендации вспомнил :)
В доке рекомендуется такой порядок инициализации:
включить BREAK
послать два нуля
когда появится готовность выключить BREAK
послать два INITа (4)
Спаял шнур COM-Стык С2. Подключил, запускаю HX Server и ничего не происходит. В программе написано: Ожидание приглашения. Конфиг запущен.
Со стороны УКНЦ вообще ничего. Загрузка со Стыка включена.
Спаял шнур COM-Стык С2. Подключил, запускаю HX Server и ничего не происходит. В программе написано: Ожидание приглашения. Конфиг запущен. Со стороны УКНЦ вообще ничего. Загрузка со Стыка включена.Сначала надо проверить, принимают ли приёмники обеих сторон то, что передаёт другая сторона.
Можно запустить на PC любую терминалку, настроенную на работу с используемым COM-портом, а на УКНЦ - смотреть в пульте содержимое регистров С2: 176570 - 176576
Если нажать клавишу в окне терминалки на PC - в регистре состояния приёмника С2 ( 176570 ) должен установиться признак готовности, а в регистре данных ( 176572 ) - появиться код нажатой клавиши.
Если же записать ASCII-код в регистр данных передатчика С2 ( 176576 ) - этот же символ должен появиться в окне терминалки на PC.
Вот так:
http://zx.pk.ru/showpost.php?p=201649&postcount=520
Хм... а как у стыка2 идут цифры ножек?
Вот ничего не понятноЧто надо нажать, чтобы на экране УКНЦ появился значок "@" и можно было, вводя адрес и нажимая "/" - смотреть содержимое ячеек памяти ?
@176572/000000
Отладка?
Получилось один раз загрузить, и больше не получается :D
Получилось один раз загрузить, и больше не получаетсяВ смысле - получилось загрузить RT-11 через С2 или получилось выйти в режим отладки ?
RT-11 загрузилась...но всего один раз, больше не получается :(
RT-11 загрузилась...но всего один разЗагрузилась и всё нормально работало до перезагрузки или загрузилась и всё повисло ?
После перезагрузки больше не грузит....
После перезагрузки больше не грузит....А начальное сообщение загрузчика на экране появляется ?
HX 2.0 - Warm boot v1.2 176570Если да - можно скачать этот архив (http://zx.pk.ru/attachment.php?attachmentid=39490) и скопировать оттуда файл: Boot_RT-11_from_HX0.bin в каталог: HX_Server 2.2 - UKNC.
Этот загрузчик проверяет ошибку переполнения при приёме данных.
Не, даже загрузчик не появляется....
А как грузить через СА? Провод тот же?
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot