А в других случаях? Уж кабель должен быть сделан так, чтобы поддерживалось квитирование в обе стороны, да и возможно чтобы было работать в полном дуплексе.Цитата:
Сообщение от Patron
Вид для печати
А в других случаях? Уж кабель должен быть сделан так, чтобы поддерживалось квитирование в обе стороны, да и возможно чтобы было работать в полном дуплексе.Цитата:
Сообщение от Patron
А если в файле UKNC_HX_COM.cfg включить запись на диск лога HX:Цитата:
Сообщение от palsw
то что в процессе загрузки запишется в файл HX_Log.log ?Код:[HX_Log.ini]
TabTitle =""
InitialStateOf[StatusBar] = 0
SaveChangesFor[StatusBar] = 0
InitialStateOf[ControlBar] = 0
SaveChangesFor[ControlBar] = 0
InitialStateOf[Log] = 1
SaveChangesFor[Log]=0
DumpMode=1
---------- Post added at 23:59 ---------- Previous post was at 23:54 ----------
У palsw с новым загрузчиком первый блок грузиться с HX2 и только остальные с HX0 - это у всех так ?
Ну в первоначальном варианте УКНЦ по техописанию были все сигналы, т.е. и RTS, и CTS, и DTR, и DSR. Но реально 1801ВП1-065 поддерживает только два сигнала. Да и сигналы DTR и DSR не имеют к обмену никакого отношения. Эти сигналы о том, что аппаратура включена, или на компьютере программа будет использовать COM-порт. Т.е. включили модем и если DSR оказался активен, то можем судить, что на модем подали питание. А вот сигналы RTS и CTS служат как раз для управления обменом и каждая из сторон предупреждает другую, может ли она в данный момент принять данные. Так что сначала хотели сделать на УКНЦ и что в итоге получили - большая разница. Да и сигнал 109, который закрывает вход, имеет обозначение DCD, его ставит модем, когда установил связь с другим модемом, а если связь не установлена, то УКНЦ вообще ничего не сможет получить.Цитата:
Сообщение от Vamos
---------- Post added at 01:02 ---------- Previous post was at 01:01 ----------
У меня нормально, все с нулевого драйва.Цитата:
Сообщение от Patron
Похоже, я понял, что может вызывать проблему.
В приложении - новый вариант сервера ( HX_Server 2.1_-_UKNC_12.01.13_04-11 ) с драйвером HX.SYS и загрузчиком Boot_RT-11_from_HX0.bin, которые более корректно осуществляют повторные попытки загрузки при неудаче первой ( ошибка чтения вторичного загрузчика пока может быть обнаружена только при отключенном сжатии ).
Также изменены ячейки для впечатывания даты в передаваемый загрузчик.
...
Ну этот вариант для тех, кто дружен с электроникой и паяльником. А если кто-то не хочет лезть в плату?Цитата:
Сообщение от Keeper
Нелогично называть универсальным решение, которое работает только тогда, когда программа ставит fDtrControl = DTR_CONTROL_ENABLE.
Ведь в любом случае нужно что-то паять. Уж если паять - то так, чтобы работа не зависела от наличия нужного уровня на выводе DTR.
То же относится и к закорачиванию DTR и DSR на стороне PC. Это решение никак нельзя назвать универсальным - всегда есть такой набор настроек порта, при установке которых работа через подобный "универсальный" кабель станет невозможна.
Patron, еще в последних версиях HX-сервера заметил такую особенность - если при старте, когда еще не было загрузки с HX, можно было нажимать и отжимать кнопку "Boot HX0", а после загрузки, если ее нажать, то она сразу отжимается и в последовательный порт начинает поступать первичный загрузчик.
Еще есть предложение - может передаваемую дату и номер загружаемого устройства располагать в последних словах, там в конце как раз четыре свободных слова. А потом с этих слов копировать в ячейки вторичного загрузчика.
Значит, там фаза не сбрасывается в начальное состояние и после первого срабатывания - UKNCcomSender продолжает "думать", что только что получил с УКНЦ байт промпта. Сейчас исправлю.Цитата:
Сообщение от Alex_K
Я затеял экстремальную компактизацию загрузчика, чтобы освободить достаточно места для подсчёта контрольной суммы передаваемых пакетов ( сейчас контрольная сумма загрузчиком не проверяется ), поэтому в последней версии загрузчика дата впечатывается прямо в код:Цитата:
может передаваемую дату и номер загружаемого устройства располагать в последних словах, там в конце как раз четыре свободных слова. А потом с этих слов копировать в ячейки вторичного загрузчика.
Код:BOOT:
Mov #5000, R2 ; R2 -> Time & Date block in BSTRAP
Mov (PC)+, (R2)+ ; Set TicksHi
TicksHi:
.Word 0
Mov (PC)+, (R2)+ ; Set TicksLo
TicksLo:
.Word 0
Mov (PC)+, (R2)+ ; Set Date
Date:
.Word 0 ;
ReBOOT:
Mov #10000, SP ; Boottime SP value
Clr @(PC)+ ; Warm Boot ( set Date & Time )
BDEVU: .Word 0 ; Boot from Unit 0 ( ONLY !!! )
В этом случае адреса ячеек могут быть разными после очередной оптимизации, а так они будут всегда одинаковыми, ну и в этом случае оптимизироваться можно до бесконечности.Цитата:
Сообщение от Patron
Неплохо бы в очередной версии HX-сервере сделать выбор загружаемого устройства.
Если вторичному загрузчику не принципиально, чтобы в 4-х последних словах были -1, тогда можно. Когда я модифицировал первичный загрузчик MX, создалось впечатление, что вторичный загрузчик при работе что-то в последние 4 слова первичного пишет, но насколько важно их начальное значение - непонятно.
Если выбирать номер загружаемого устройства в cfg-файле (путём текстового редактирования), то чтобы подставить нужный образ в HX0 - требуется столько же кликов, как и чтобы задать номер загружаемого привода в каком-то другом месте.Цитата:
Неплохо бы в очередной версии HX-сервере сделать выбор загружаемого устройства.
Любой другой способ - еще накладнее, поэтому логично оставить как есть и выбирать загружаемый образ путём редактирования раздела [HX.ini].
---------- Post added at 13:40 ---------- Previous post was at 13:37 ----------
Чтобы загрузиться с другого привода уже после загрузки с HX0 - достаточно в RT-11 подать команду BOOT HXn: