Зачем для этого провод тянуть.. Разве в самой УКНЦ нужный уровень найти трудно ?Цитата:
Сообщение от Alex_K
Вид для печати
Зачем для этого провод тянуть.. Разве в самой УКНЦ нужный уровень найти трудно ?Цитата:
Сообщение от Alex_K
Был по этому поводу спор с Vamos. Я использовал для этого +5В с самого разъема стык С2. Но у меня УКНЦ со всеми винчами и дисководами питается от AT-источника питания. У Vamos УКНЦ питается от своего источника, который довольно хилый. А ведь сигналы уровня RS-232 это не TTL-уровень, там размах от -12В до +12В, естественно после подключения кабеля у него была просадка до 4.4В. Сразу скажу, что в УКНЦ СЭМЗ-овской схемотехники этот вход 7 (сигнал 109) сделан как ТТЛ-уровень, поэтому там можно подать (да и нужно) +5В. А вот для УКНЦ с квантовской схемотехникой нужен сигнал уровня RS-232, и остается подать его только с PC.Цитата:
Сообщение от Patron
Тогда DSR распаивать не надо, а DTR использовать "в роли RTS", задав:Цитата:
Сообщение от Alex_K
Некоторые сомневаются, работает ли нога DTR у ВП1-065 так же оперативно, как нога RTS.Код:fDtrControl = DTR_CONTROL_HANDSHAKE
fRtsControl = RTS_CONTROL_HANDSHAKE
Самое время это проверить при помощи кнопки запрета приёма.
---------- Post added at 23:39 ---------- Previous post was at 23:37 ----------
Можно вообще на стороне ВП1-065 объединить этот сигнал для 7(109) и 9(107)
Была у меня еще мысль выпаять резистор который с -12 на 109 и может даже на +5 этот резистор подключить, но как на это отреагирует 170УП ?
DSR действительно можно не распаивать, а вот fDtrControl = ENABLE, иначе при переполнении входного буфера в Windows закроется вход у УКНЦ. Да и ноги DTR у 1801ВП1-065 нету, из управляющих есть только BSYD (подключается к RTS PC) и RR (подключается к CTS PC).Цитата:
Сообщение от Patron
>palsw
Что тест Titusa пишет? ) - мои результаты )
Лучше не надо. Но если fRtsControl = RTS_CONTROL_ENABLE будет всегда, то тогда можно.Цитата:
Сообщение от Patron
Но смысла в экономии проводов нет, т.к. со стороны УКНЦ идет разъем IDC-10 и туда просто зажимается плоский 10-жильный кабель. А распаивается уже DB-9 со стороны PC.
В случае HX это не страшно - протокол симплексный.Цитата:
Сообщение от Alex_K
И остается вопрос почему RTS/CTS на схеме УКНЦ обозначены как 107/108, если по описанию в ГОСТе должны быть 105/106.
Тогда из предложенной схемы нужно просто выкинуть распайку DSR.Цитата:
Сообщение от Alex_K
А в других случаях? Уж кабель должен быть сделан так, чтобы поддерживалось квитирование в обе стороны, да и возможно чтобы было работать в полном дуплексе.Цитата:
Сообщение от 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:
Так вопрос идет не о загрузочном файле, а именно о номере загружаемого привода. Да и сначала грузится с HX0:, а потом с другого - накладно по времени. Также не забывайте, что у УКНЦ есть и второй процессор, там при загрузке могут остаться резиденты, отсюда следует, что образ в HX0: должен быть минималистичным.Цитата:
Сообщение от Patron
---------- Post added at 15:21 ---------- Previous post was at 14:46 ----------
Ничего у меня при загрузке не портится в ячейках 770-777. несколько раз нажимал "СТОП" и смотрел значения. Начали они портится только тогда, когда SP стал равен 01000, ну думаю тут понятно почему.Цитата:
Сообщение от Patron
Зачем какой-то образ может потребоваться грузить обязательно с какого-то конкретного (не нулевого) привода ?Цитата:
Сообщение от Alex_K
Разные конфигурации. Не стоит забывать, что у УКНЦ есть периферийный процессор, а собственно универсального протокола о взаимодействии загружаемых модулей нет. Соответственно существуют программы, использующие ПП, взаимно не совместимые друг с другом.Цитата:
Сообщение от Patron
Кстати об оптимизации - можно оптимизировать, а точнее убрать макрос SOB, все равно загрузчик чисто для УКНЦ, а команда SOB в 1801ВМ2 есть.
Возможны только две ситуации:
1. Мы ещё не загружены и хотим загрузить какой-то образ - тогда в любом случае нужно редактировать cfg-файл ( или как сейчас - подставлять нужный образ в HX0, или как предлагается - изменять в настройках номер загружаемого привода ). По совершаемым действиям это равноценно. Никакой выгоды возможность задания номера загружаемого привода в такой ситуации не даёт.
2. Мы уже загружены и хотим загрузиться с другого привода - тогда лучше команды BOOT HXn: ничего быть не может.
В какой ситуации возможность задания номера загружаемого привода в cfg-файле может дать решающее преимущество ?
---------- Post added at 14:38 ---------- Previous post was at 14:37 ----------
Это универсальный загрузчик. На ДВК он будет загружаться небольшим предварительным ODT-скриптом, имитирующим поведение УКНЦ при загрузке из порта С2. Только при компиляции нужно будет другой адрес порта указать.Цитата:
Сообщение от Alex_K
---------- Post added at 14:43 ---------- Previous post was at 14:38 ----------
Кстати, образ в приводе HX0 можно сменить и без редактирования cfg-файла, тогда как изменить номер загружаемого привода можно было бы только редактированием.
Если у меня несколько конфигураций, скажем штук 5, в приводах с HX2: по HX6:, и грузить мне их можно только на холодную, т.е. перезапустить УКНЦ кнопочкой <Reset>. Тут уже лучше сразу их расставить заранее во все приводы, а потом выбирать загрузочный номер.Цитата:
Сообщение от Patron
---------- Post added at 15:53 ---------- Previous post was at 15:49 ----------
Можно сделать условную компиляцию и этого макроса. Соответственно, указали - нужен он нам или нет. А также все ДВК имеют команду SOB, этой команды нет только на самых первых PDP-11, точнее по моделям на 04, 05/10, 15/20.Цитата:
Сообщение от Patron
Фокус в том, что выбирать номер можно только редактированием cfg-файла, предварительно закрыв сервер, а выбирать образ - при работающем сервере - кнопкой на полосе статуса.
Поэтому, если расположить все образы в приводах HX1..HX7, а образ в приводе HX0 выбирать непосредственно перед нажатием <Reset> на УКНЦ - всё будет легко и приятно и не надо будет: 1) Выкючать сервер; 2) Изменять номер в cfg-файле; 3) Запускать сервер.
---------- Post added at 14:57 ---------- Previous post was at 14:55 ----------
На суть это не влияет - ведь если считать контрольную сумму - это надо делать для всех вариантов компиляции.Цитата:
Сообщение от Alex_K
Так ведь собственно можно сделать так, что если кнопка "Boot HX0" находится в отжатом положении, а мы ее нажимаем, то выводится меню с HX0 по HX7. Выбираем HX2, кнопочка становится нажатой, но уже с надписью "Boot HX2".Цитата:
Сообщение от Patron
Кнопка [Boot HX0] - это объект модульного API типа SB_StatePushButton, подключаемый к любому состоянию любого объекта модульного API и позволяющий: 1) определять фазу состояния объекта по виду кнопки; 2) изменять фазу состояния объекта при помощи нажатий кнопки.Цитата:
Сообщение от Alex_K
Если не учинять апгрейд API, а использовать те возможности, которые уже есть - загрузка с HX0 с предварительным выбором загружаемого образа при помощи кнопки выбора образов - оптимальное решение.
Новый вариант сервера ( HX_Server 2.1_-_UKNC_12.01.13_16-01 ) с загрузчиком Boot_RT-11_from_HX0.bin, который (якобы) проверяет при загрузке контрольные суммы получаемых пакетов протокола HX.
Теперь повторная передача загрузчика при нажатии кнопки [Boot HX0] должна начинаться только после повторного получения промпта от УКНЦ.
Изменены ячейки для впечатывания даты в передаваемый загрузчик - теперь это ячейки 0770, 0772, 0774
...
А полноценный драйвер для УКНЦа появился уже?
Всмысле чтобы функционал системы не ломал - там этого вроде не требуется :)
Попутно заглянул в драйвер, заполнение остатка блока нулями делается драйвером, что криво и накладно. Это задача контроллера (сервера).
Специально перенёс заполнение нулями из сервера в драйвер, чтобы протокол стал более однозначным - при запросе у сервера чтения одного байта - читается один байт, при запросе записи одного байта - пишется один байт.
А оно так и получается в любом случае: передается столько сколько указано. Зануление конца блока - не передача данных, а документированное требование к блочным устройствам, актуальное по сей день.Цитата:
Сообщение от Patron
Обращаю внимание: к устройствам, не к драйверу.
В смысле, чтобы номер загружаемого привода принимался в R0 ?Цитата:
Сообщение от form
Всмысле чтобы .READ и .READC работали.Цитата:
Сообщение от Patron
В случае когда делается смешивание консоли с диском такое потребует вмешательства в систему или написание драйвера хукающегося по принципу PI. Для отдельного порта таких трудностей нет.
А как .READ и .READC реализованы у VM.SYS и как они работают у MX.SYS ( MX.SYS при работе вообще запрещает прерывания ) ?Цитата:
Сообщение от form
VM.SYS - драйвер мгновенного действия (и то он как раз из-за этого имеет проблемы в SJ), а что касается MX - у нас полно драйверов криво писали. Но это же не повод перенимать глупости :)Цитата:
Сообщение от Patron
Ладно бы были трудности, так ведь их нет.
А так, согласись, драйвер который ломает функционал системы - драйвером называться не имеет права :)
---------- Post added at 14:39 ---------- Previous post was at 14:25 ----------
Наглядный пример потери функционала из-за нерабочести .READ/.READC. Это тупой тест, а я видел достаточно много программ которые выполняли реальную работу во время I/O.
Прога тупо читает 20. блоков с SY: и пока они читаются занимается своими делами (инкрементит счетчик).
На достаточно быстром SCSI на 11/83 имеем (время меньше секунды):Код:.TITLE TIO -- I/O TEST
.IDENT /V01.00/
.MCALL .LOOKUP,.READC,.EXIT,.PRINT
START:: .LOOKUP #AREA,#0,#DBLK
BCC 20$
.PRINT #ERR1
10$: CLR R0
.EXIT
20$: .READC #AREA,#0,#BUFF,#WCNT,#CRTN,#0
BCC 30$
.PRINT #ERR2
BR 10$
30$: CMP FLAG,#1
BCC 40$
ADC COUNT+2
ADC COUNT
BR 30$
40$: MOV #VALUE,R0
MOV COUNT,R1
MOV PC,R2
CALL $CBOMG
MOVB #<',>,(R0)+
MOV COUNT+2,R1
MOV PC,R2
CALL $CBOMG
.PRINT #VALUE
BR 10$
CRTN:: INC FLAG
RETURN
COUNT:: .WORD 0,0
FLAG:: .WORD 0
BUFF:: .BLKW 256.*20.
WCNT == <.-BUFF>/2
DBLK:: .RAD50 /SY/
.WORD 0,0,0
AREA:: .BLKW 7
VALUE: .ASCIZ /XXXXXX,XXXXXX/
ERR1: .ASCIZ /LOOKUP FAILED/
ERR2: .ASCIZ /READ FAILED/
.END START
На УКНЦ (MZ по прерываниям [что не несет никаких проблем программам, работающим с ПП несмотря на мифы об этом]) получается 167000 с чем-то, время около секунды. А на HX примерно за пол минуты имеем ноль сделанного :)Код:.RU TIO
000000,002275
.
Небольшой оффтоп - хотелось бы поподробнее узнать про мифы насчет этого.Цитата:
Сообщение от form
Мифы читал у Арсения на сайте - там выложена подборка каких-то статей, среди прочего была статья с исходниками драйвера MZ без прерываний и обоснование - мол поскольку работают через одну дырку, драйвер может мешать - глотает прерывания (и соответственно портит содержимое CSR или что-то в этом роде). Теоретически такое возможно например в случае запуска чтения с MZ вышеупомянутыми .READ/.READC и параллельной загрузки кода в ПП. Ну или в случае кривого драйвера (что по-видимому имело место с автором статьй) который не выключает прерывания по завершению I/O.Цитата:
Сообщение от Alex_K
А-а-а-а!!!!! Теперь понял. Смысл состоит в том, что если программа через канал 2 передает блок (а это четыре байта), и в это время произойдет прерывание от драйвера MZ, и он тоже начнет что-то передавать по каналу К2, то собьется синхронизация счетчика драйвера канала 2 в системном ПЗУ ПП. Но вообще-то это невозможно, т.к. последний четвертый байт не читается из К2 со стороны ПП, пока не будет завершена операция. Т.е. если по .READ/.READC что-то запросить и сразу же попробовать работать с К2, то у него не будет установлен бит готовности. Как-то вот так ...Цитата:
Сообщение от form