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

[Vamos]

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

Вопросы у меня возникли не в связи с последними сообщениями (это частный случай), решил доделать эмуляцию -065 в UKNCBTL.
Мы можем долго теоретизировать и приводить контраргументы по поводу буферизации в Windows, но UKNCBTL то стыкуется через com0com.
Добавить одно условие "не отправлять байт при снятии CTS" и можно мне в личку такую версию HX_Server, чтобы не распространять неправильно работающую программу , а я ее уже погоняю и с железом тоже. О результатах доложу.

- - - Добавлено - - -

Жаль, что не так много народу пробовало подключить нстоящий терминал к настоящему железу - помогает

А чего пробовать, свежи воспоминания, нажал на клавишу и ждешь пока символ появится

[form]

А чего пробовать, свежи воспоминания, нажал на клавишу и ждешь пока символ появится

ждешь до бесконечности всмысле?
Мне с СМ7209 проще было - он сразу информировал - первый раз пискнет на клавишу, а потом просто игнорирует клавиатуру... Это началось на старых E11 еще с прямым пробросом порта - тогда кусал лишнее. Позже в E11 добавили фичу ручной установки сигналов. Потом на железе (не PDPшном). С PDP-шным стало проще - на DL(V)11 куда его обычно нужно было подключить других сигналов просто нет по определению

[Vamos]

Мне с СМ7209 проще было - он сразу информировал - первый раз пискнет на клавишу, а потом просто игнорирует клавиатуру...

Ну дык и я Patronу говорю что не должен байт без разрешения уходить, и не только я, еще Alex_K в начале темы на это указывал.

[form]

Ну дык и я Patronу говорю что не должен байт без разрешения уходить, и не только я, еще Alex_K в начале темы на это указывал.

Я скажу проще. В DL(V)11 никогда не было никаикх разрешений. Всегда были три (четыре) провода. И никакого контроля. Я согласен, советские инженеры лет через 10-20 попытались сориентироваться на аппаратный контроль, но вся беда, что IBM и последователи на это никак не ориентировались, а уж в последующие годы и вовсе все шло к тому, что нужно написать вручную контроллер (считай у УКНЦ идею сперли [хотя и раньше была])... Так что наш ответ чемберлену - использовать только то, что штатно положено. Обкусанные "управляющие" сигналы к счастью приравниваются к правильно выставленным

[Patron]

Добавить одно условие "не отправлять байт при снятии CTS"

Это лишено смысла из-за того, что: 1) синхронная работа COM-порта возможна только при заполненном аппаратном буфере передачи ( за заполнение буфера передачи COM-порта отвечает драйвер Windows ) ; 2) нормальная работа драйвера Windows возможна только при заполненном буфере передачи драйвера.

Поэтому обычная работа выглядит так - ещё до завершения передачи первого байта драйвер Windows сообщает программе, что передана куча байтов, с таким расчётом, чтобы заполнить два буфера - свой и COM-порта. Поэтому, когда происходит снятие CTS - дёргаться уже поздно - аппаратный буфер передачи COM-порта заполнен и поэтому именно COM-порт должен остановить передачу.

И всё это без проблем работает на нормальных COM-портах. Обсуждаемые же нами проблемы вообще не имеют отношения к алгоритму работы портов и вызваны конкретными особенностями схемотехники некоторых УКНЦ.

[form]

И всё это без проблем работает на нормальных COM-портах. Обсуждаемые же нами проблемы вообще не имеют отношения к алгоритму работы портов и вызваны конкретными особенностями схемотехники некоторых УКНЦ.

Наличие таковых сигналов в принципе - особенность УКНЦ или ДВК (я имею в виду именно порт типа DL[V]11). Эти сигналы в принципе есть, комп их никак не контролирует, результат - загадка...

[Advertiser]

[Patron]

результат - загадка...

На УКНЦ с нормальной схемотехникой ( где все линии связи с COM-портом настроены на +/-12в ) - 065 без проблем работает с квитированием, но на УКНЦ с TTL-уровнями на линиях квитирования - приход от COM-порта постоянного уровня [-12в] по линии CTS вызывает сбои при приёме 065.

Почему никто из владельцев проблемных УКНЦ до сих пор не попробовал убрать из кабеля эту линию, которая даром не нужна и только вредит - вот это настоящая загадка.

[Alex_K]

но на УКНЦ с TTL-уровнями на линиях квитирования

А где есть такие УКНЦ? Единственно в УКНЦ с СЭМЗ-овской схемотехникой на TTL-уровне сидит один сигнал DCD, который открывает вход для посылок извне, всё остальное честно сделано на +/- 12В.

[Patron]

Единственно в УКНЦ с СЭМЗ-овской схемотехникой на TTL-уровне сидит один сигнал DCD, который открывает вход для посылок извне, всё остальное честно сделано на +/- 12В.

Но при получении от COM-порта постоянного уровня "TRUE" по линии RTS эти УКНЦ всё равно сбоят при приёме.

[Vamos]

На УКНЦ с нормальной схемотехникой ( где все линии связи с COM-портом настроены на +/-12в ) - 065 без проблем работает с квитированием, но на УКНЦ с TTL-уровнями на линиях квитирования - приход от COM-порта постоянного уровня [-12в] по линии CTS вызывает сбои при приёме 065.

"Не правильно Вы бутерброд держите, дядя Федор" Без проблем работала только УКНЦ Alex_K с одним TTL-уровнем и то он не подключался к кабелю.
НО читаем пост http://zx-pk.ru/showthread.php?t=160...l=1#post565490

Это лишено смысла из-за того, что: 1) синхронная работа COM-порта возможна только при заполненном аппаратном буфере передачи ( за заполнение буфера передачи COM-порта отвечает драйвер Windows ) ; 2) нормальная работа драйвера Windows возможна только при заполненном буфере передачи драйвера.

Поэтому обычная работа выглядит так - ещё до завершения передачи первого байта драйвер Windows сообщает программе, что передана куча байтов, с таким расчётом, чтобы заполнить два буфера - свой и COM-порта. Поэтому, когда происходит снятие CTS - дёргаться уже поздно - аппаратный буфер передачи COM-порта заполнен и поэтому именно COM-порт должен остановить передачу.

Вот сейчас сделал специальную версию UKNCBTL где переполнение возникает сразу если передающая программа не отреагировала на снятие CTS, HX_Server успел насыпать в буфер Windows или com0com 25 байт и встал, что там и насколько заполняет это еще вопрос.