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

[Alex_K]

Alex_K, вп1-065 переключил на укнц на скорость выше 9600?можно фото где эти перемычки искать?

Если схемотехника Квантовская - то под клавиатурой. А если СЭМЗ-овская, то переключать только программным способом.

---------- Post added 10.01.2013 at 00:18 ---------- Previous post was 09.01.2013 at 23:59 ----------

На случай, если потоковые буфера Windows имеют размер под сотню килобайт - написана специальная программа SPAM.SAV, посылющая в порт С2 УКНЦ столько байтов - что мало не покажется.

Увы, часть времени у программы уходит на формирование выводимой строки, да и строка выводится через EMT 351, значит используется операционная система, потом идут прерывания от терминала для вывода, так что здесь даже порт до максимальной скорости не дотягивает.

[palsw]

Alex_K, под клавиатурой есть такое дело.

[Patron]

Увы, часть времени у программы уходит на формирование выводимой строки, да и строка выводится через 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 байтов.

[Alex_K]

Здесь идея в том, чтобы проверить - пропадут или не пропадут байты в COM-порту Windows, когда сервер надолго перестанет их принимать, а потом продолжит.

Если сначала установить fRtsControl = RTS_CONTROL_ENABLE, а потом fRtsControl = RTS_CONTROL_HANDSHAKE - то разница должна быть очевидной.

При fRtsControl = RTS_CONTROL_ENABLE естественно посылка в порт все время продолжается, байты теряются. При fRtsControl = RTS_CONTROL_HANDSHAKE посылка через некоторое время приостанавливается, потерь вроде нет. Нажал примерно на 103, остановилось на 147.

[Patron]

При 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. А проблемы со скоростью чтения у "продвинутого варианта" адаптера порта не могли быть вызваны, например, выключенным сжатием ?

[Patron]

Ну вот, вроде отладил и протокол HX v2.1, и драйвер HX.SYS v2.1.

Сервер HX для УКНЦ, поддерживающий новый протокол с новым драйвером: HX_Server 2.1_-_UKNC_10.01.13_21-06.

...

[Advertiser]

[bigral]

4.В архиве уже содержится образ системы с драйвером HX. HXsys54.DSK

Вот бы теперь узреть смертельный номер - RSX-11M запущенная на УК-НЦ! Есть ли принципиальные преграды на этом пути? (ну естественно non mapped system на 56кб но все же!)

[form]

Вот бы теперь узреть смертельный номер - RSX-11M запущенная на УК-НЦ! Есть ли принципиальные преграды на этом пути? (ну естественно non mapped system на 56кб но все же!)

Принципиальных приград нет - написать драйверы устройства и загрузчика. Смысла только в этом нет - так, побаловаться. RSX-11 без MMU превращается в весьма неуклюжую систему из которой придется убрать больше половины полезного функционала.

---------- Post added at 07:59 ---------- Previous post was at 07:58 ----------

Можно запустить 11S (собственно это тот же 11M только упрощенный) - ему даже драйвера не нужны.

[Patron]

Написал специальный первичный загрузчик для УКНЦ: Boot_RT-11_from_HX0.BIN ( исходники в файле BotHX0.MAC ) и добавил в настройки объекта UKNCcomSender опцию, включающую впечатывание даты и времени сервера в передаваемый файл ( в ячейки 06..012 ). По умолчанию эта опция включена, поэтому теперь загрузка должна идти с привода HX0 с установкой на УКНЦ даты и времени сервера: HX_Server 2.1_-_UKNC_11.01.13_16-10.

В драйвере HX.SYS устранена ошибка из-за которой все предыдущие драйверы выводили сообщение об ошибке чтения вторичного загрузчика не на экран, а в порт HX.

...

[Alex_K]

Написал специальный первичный загрузчик для УКНЦ: 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.