УКНЦ загрузка через стык С2

[palsw]

Vamos, если я правильно понял вопрос - отвечу -в самой программе есть выбор образа и не одного .Но номер загружаемого образа зависит от самой УКНЦ -у меня например HX2:.
HХ2:есть загружаемый образ и в нем должен быть вставлен диск HXsys54.DSK
В остальные образы можно вставить любой софт на свой вкус - и на самой УКНЦ уже запускать программы с нужного диска.

[Vamos]

Извиняюсь, действительно есть.

[Alex_K]

Ох! Вроде удалось победить проблему ошибки переполнения, теперь грузится при включенном сжатии и если выхожу в пульт при нажатии "СТОП", то в регистре 176570 бит переполнения не устанавливается. При продолжении по нажатию "ИСП" все нормально идет дальше.
Файл Terminal_ComPort_Adapter.ini:

[Main]
BaudRate=CBR_9600
fDtrControl=DTR_CONTROL_ENABLE
fRtsControl=RTS_CONTROL_ENABLE
Parity=NOPARITY
StopBits=TWOSTOPBITS
ByteSize=8
fParity=FALSE
fOutxCtsFlow=TRUE
fOutxDsrFlow=TRUE
fDsrSensitivity=FALSE
fTXContinueOnXoff=FALSE
fOutX=FALSE
fInX=FALSE
fErrorChar=FALSE
fNull=FALSE
fAbortOnError=FALSE
XonLim=512
XoffLim=512
XonChar=021
XoffChar=023
ErrorChar=0

Жирным выделены параметры, которые я изменял. Кабель у меня по управлению сигналами RTS/CTS, поэтому следующие параметры можно оставить такими: fDtrControl=DTR_CONTROL_DISABLE и fOutxDsrFlow=FALSE. Самое главное, чтобы было 2 стоп-бита. В 1801ВП1-065 сигнал RR сбрасывается судя по всему с приходом стоп-бита, а за 2 стоп-бита он успевает обработаться и Windows. Два стоп-бита я ставил при настройках с HANDSHAKE, но оказалось это какой-то модемный протокол с восстановлением связи, естественно с УКНЦ хоть и грузилось, но с ранее описанными глюками.

[Patron]

А как в УКНЦ задаётся число стоп-битов у 1801ВП1-065 ?

[Alex_K]

А как в УКНЦ задаётся число стоп-битов у 1801ВП1-065 ?

Никак. И у 1801ВП1-035, и у 1801ВП1-065 их железно два.

---------- Post added at 22:15 ---------- Previous post was at 22:05 ----------

Небольшое дополнение. 1801ВП1-035 при выдаче посылки размером 5 бит выдает 1,5 стоп-бита, в других случаях (7 и 8 бит) - два стоп-бита. 1801ВП1-065 умеет выдавать посылки размером только 7 или 8 бит, поэтому стоп-бита всегда два.

[Patron]

Никак. И у 1801ВП1-035, и у 1801ВП1-065 их железно два.

А сколько тогда битов на байт передаётся портом терминала ДВК.. Я всегда думал, что 10, а не 11.

И ещё - очень странно, откуда взялось мнение, будто ВП1-065 не может управлять потоком при работе с PC, если достаточно установить в DCB

fRtsControl  = RTS_CONTROL_ENABLE
fOutxCtsFlow = TRUE

и сразу всё заработает..

[Alex_K]

А сколько тогда битов на байт передаётся портом терминала ДВК.. Я всегда думал, что 10, а не 11.

Последовательный порт плат МС1201.01 и МС1201.02 построен на основе 1801ВП1-035, поэтому всегда передается 11 бит.

И ещё - очень странно, откуда взялось мнение, будто ВП1-065 не может управлять потоком при работе с PC, если достаточно установить в DCB

fRtsControl  = RTS_CONTROL_ENABLE
fOutxCtsFlow = TRUE

и сразу всё заработает..

Мнение взялось из-за программного управления линиями квитирования со стороны PC. Все в этом случае зависит от алгоритма обработки этих сигналов. Если алгоритм не очень, то видно проблемы и были. Я тоже играл со всеми параметрами два дня, судя по всему чего-то упустил и не получалось.
Но получиться только с полным кабелем. Если кабель будет минимальный, то увы - будут проблемы. С минимальным кабелем надо обрабатывать поступающую информацию в реальном режиме времени, либо использовать протокол XON/XOFF.

[Patron]

Последовательный порт плат МС1201.01 и МС1201.02 построен на основе 1801ВП1-035, поэтому всегда передается 11 бит.

За столько лет ещё никто ни разу не запустил программу CPS.SAV ни на одной ДВК ( или хотя бы стандартной материнской плате ДВК ).

получится только с полным кабелем

Насколько я понял - достаточно двух дополнительных линий, передающих сигналы RTS и CTS.

Но если эти линии в кабеле есть и паметры DCB выбраны правильно - всё сразу начинает работать. И даже если включить на максимум буфера FIFO в PC - всё работает ( и не просто работает, а работает ещё лучше ).

[Alex_K]

Насколько я понял - достаточно двух дополнительных линий, передающих сигналы RTS и CTS.

Но если эти линии в кабеле есть и паметры DCB выбраны правильно - всё сразу начинает работать. И даже если включить на максимум буфера FIFO в PC - всё работает ( и не просто работает, а работает ещё лучше ).

Ну получается, что так.
Провел небольшой опыт. Сжатие было все время включено. Сперва буфера FIFO отключил, потом включил. Ну теперь собственно тесты.
1. DIR/BAD/FIL
2. COPY/DEV HX0: HX7:
3. DIFF/BIN/DEV HX0: HX7:

Собственно все проверки прошли успешно, и даже с включенным буфером FIFO, что удивительно.

P.S. Хотя может при включении/выключении FIFO надо Windows перезагружать? Не знаю, не перезагружал. Только перезапускал HX-сервер.

[Patron]

Хотя может при включении/выключении FIFO надо Windows перезагружать?

Насколько я понял - в режиме RTS_CONTROL_ENABLE квитирование на приём в Windows отключено и независимо от заполненности приёмного буфера FIFO - сигнал разрешения передачи ( RTS ) не снимается.

Если это так и, не запуская сервер - дать какую-нибудь команду чтения HX ( например DIR HX0: ) - то драйвер выдаст запрос и когда приёмный буфер FIFO активен - запрос закешируется и прочтётся сервером после запуска, а когда приёмный буфер FIFO выключен - запрос должен пропасть.

Кстати - если запрос пропал и драйвер HX.SYS висит в ожидании ответа - он отвалится по ошибке, если ему вручную послать Ctrl/C.