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

[palsw]

Patron, сжатие наверное не работает - я его раньше тоже не использовал на 9600.Пытается загружаться и все замирает.Да и так быстро грузит

[Patron]

С одним стоповым битом работает ?

[palsw]

Надо поставить fOutxCtsFlow = TRUE.

С этой опцией не грузит сжатием и без зжатия

---------- Post added at 23:14 ---------- Previous post was at 23:11 ----------

Версию использую HX_Server 2.1_-_UKNC_11.01.13_16-10 - проверенную временем

[Patron]

Версию использую 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.

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

[Vamos]

Хех..





Скришоты обновил.

[Alex_K]

Со сжатием у этой УКНЦ проблемы из-за того, что она почему-то портит самый первый пакет протокола HX.

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

Со сжатием проблемы в другом. Если квитирование работает плохо, то во время распаковки сжатого блока, если это занимает длительное время, успевает прийти еще байт на место несчитанного, возникает ошибка переполнения. Если со стороны PC передаются скажем 157 байт, то из-за переполнения УКНЦ думает, что приняла так скажем 155-156 байт и тупо ожидает остаток, а HX-сервер думает, что все нормально передал и ждет очередной команды.
Если уж загрузится со сжатием не удалось, то и включать его бесполезно. Та же самая проблема и будет.

Однако если квитирование работает нормально, то и проблем нету. И загрузка идет нормально, и далее все работает, т.к. при нормальном квитировании ошибок переполнения просто нет, передача со стороны PC просто успевает затормозиться в нужный момент.

[Patron]

Со сжатием проблемы в другом.

Конкретная УКНЦ ( или 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.

[Alex_K]

Вот исходник обработки меню загрузки из ПЗУ УКНЦ:

; Обработка вызова меню загрузки (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.

[Patron]

Что там может быть можно глянуть в программе управления меню УСТАНОВКА и ЗАГРУЗКА

Но большого смысла в этом нет, т.к. всё равно невозможно управлять этим значением для выбора номера загружаемого привода.

[Patron]

В приложении - улучшенный вариант загрузчика Boot_RT-11_from_HX0.bin, который теперь реализует тайм-ауты при приёме байтов, а также имеет защиту от "выбега из буфера" при ошибках сжатия.

При использовании этого загрузчика - потеря байтов из-за переполнения при приёме не может привести к "зависанию" протокола.

...