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

[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-сервер.

[Advertiser]

[Patron]

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

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

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

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

[Alex_K]

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

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

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

Покурив более подробно доки, я тоже пришел к этому выводу. При RTS_CONTROL_ENABLE сигнал RTS устанавливается и остается на все время обмена, но состояние линии RTS можно менять с помощью EscapeCommFunction.
Тут я не думаю, что это связано с буферами FIFO, скорее со своими внутренними в Windows.

---------- Post added at 19:14 ---------- Previous post was at 19:12 ----------

В принципе - при установке

fRtsControl  = RTS_CONTROL_HANDSHAKE

Windows как раз должна выставлять сигнал RTS, когда свободна хотя бы половина приёмного буфера FIFO, и снимать его, когда приёмный буфер FIFO заполнен больше, чем на 3/4.

Очевидно, что при отключенных буферах FIFO эта опция нормально работать не может.

А вот сейчас я выставил fRtsControl = RTS_CONTROL_HANDSHAKE и провожу тест. Уже идет копирование с HX0: на HX7:, пока все нормально. Буфера FIFO в настройках UART включены.

[Patron]

А вот сейчас я выставил fRtsControl = RTS_CONTROL_HANDSHAKE и провожу тест.

Тут главная фишка в том, что когда в Windows никто не читает порт - после заполнения входного буфера должен автоматически сниматься сигнал RTS.

Чтобы это проверить - я написал драйвер C2.SYS, который позволяет копировать текстовые файлы из RT-11 в порт C2.

Новый вариант - HX_Server 2.0 - UKNC_09.01.13_19-35, где добавлено окно Teletype, на которое выводится терминальный обмен в порту C2.

Если загрузить RT-11 с драйвером C2.SYS не через HX, завершить HX-сервер и дать в УКНЦ команду копирования на C2: какого-нибудь довольно большого ASCII-файла ( больше, чем входной буфер COM-порта в Windows ), то после запуска HX-сервера в окно Teletype должен выйти весь отправленный текст без потери байтов.

...

[Alex_K]

Тут главная фишка в том, что когда в Windows никто не читает порт - после заполнения входного буфера должен автоматически сниматься сигнал RTS.
...
Если загрузить RT-11 с драйвером C2.SYS не через HX, завершить HX-сервер и дать в УКНЦ команду копирования на C2: какого-нибудь довольно большого ASCII-файла ( больше, чем входной буфер COM-порта в Windows ), то после запуска HX-сервера в окно Teletype должен выйти весь отправленный текст без потери байтов.

Ну грузиться с дискеты мне пока влом. Но провел такой опыт. Порт по умолчанию в менеджере устройств настроен на 9600,8N2, аппаратный контроль, буфера FIFO включены. Захожу в пультовый отладчик, смотрю регистр 176574, стоит 0200, т.е. готовность есть. Записываю байт 041 в регистр 176576, далее смотрю регистр 176574, в регистре 0, бит готовности не установлен. Т.е. либо посылка не ушла, либо линия RTS неактивна, а значит неактивный уровень на входе BSYD 1801ВП1-065, тогда посылке не уйти.
После запуска HX-сервера готовность в регистре 176574 устанавливается и все, что заносится в 176576, отображается в окне Teletype. Но посланный ранее байт 041 не отображается.

[Patron]

После запуска HX-сервера готовность в регистре 176574 устанавливается и все, что заносится в 176576, отображается в окне Teletype. Но посланный ранее байт 041 не отображается.

Похоже, пока Com-порт не открыт в программе для чтения/записи - Windows не копирует данные из буфера FIFO в потоковый буфер подсистемы ввода-вывода.

Посмотрел код написанных мною полгода назад функций чтения и записи порта (в исходнике адаптера COM-порта модульного API) и понял, что без потоковых буферов Windows эти функции читали бы и писали не больше 60 байтов в секунду. Переписал этот код - теперь и чтение, и запись должны работать немного быстрее.

Новый вариант - HX_Server 2.0 - UKNC_09.01.13_21-02 с изменёнными алгоритмами чтения и записи COM-порта.

...

[Alex_K]

Похоже, пока Com-порт не открыт в программе для чтения/записи - Windows не копирует данные из буфера FIFO в потоковый буфер подсистемы ввода-вывода.

Вообще-то похоже, что пока COM-порт не открыт, то не установлены сигналы DTR и RTS, а без установленного RTS у меня с моим кабелем не уходят посылки, т.к. на входе BSYD неактивный уровень. И даже если есть возможность записать один байт, то он все равно не получается HX-сервером при запуске. Видно при открытии идет инициализация COM-порта и очистка всех буферов Windows.

---------- Post added at 21:19 ---------- Previous post was at 21:14 ----------

Посмотрел код написанных мною полгода назад функций чтения и записи порта (в исходнике адаптера COM-порта модульного API) и понял, что без потоковых буферов Windows эти функции читали бы и писали не больше 60 байтов в секунду.

Откуда такая уверенность, что не более 60-ти? Все версии HX-сервера, которые выкладывались, использовали COM-порт под полную катушку на скорости порта 9600,8N2. Проблем не возникло ни при чтении, ни при записи (проводил же тест командой COPY/DEV HX0: HX7:).

[Alex_K]

Посмотрел код написанных мною полгода назад функций чтения и записи порта (в исходнике адаптера COM-порта модульного API) и понял, что без потоковых буферов Windows эти функции читали бы и писали не больше 60 байтов в секунду. Переписал этот код - теперь и чтение, и запись должны работать немного быстрее.

Увы. Практический опыт показывает обратное. Копирую диск в диск командой COP/DEV HX0: HX7:. Копируется по 38400 байт.
В новейшей версии HX_Server 2.0 - UKNC_09.01.13_21-02 чтение идет 73 сек в среднем, а запись около 45 секунд. А в предыдущей версии HX_Server 2.0 - UKNC_09.01.13_19-35 и чтение и запись выполнялись за 44 секунды. Так что в предыдущей версии порт использовался на пределе своих возможностей.