Просмотр полной версии : УКНЦ загрузка через стык С2
Сегодня в эмуляторе УКНЦ сделал поддержку COM-порта.
В аттаче лежит новый UKNCBTL.exe для Win32, код тоже закоммичен.
Настройка на порт пока только через реестр, строковый ключ "SerialPort", значение например "COM1". Включение через пункт меню Emulator > Serial.
Для проверки работы порта использовал вариант загрузки главного меню "4 - Стык С2".
Для этого поставил com0com -- это штука которая создаёт два связанных между собой виртуальных COM-порта. http://sourceforge.net/projects/com0com/
Соответственно с одной стороны подключен UKNCBTL, для другой стороны написал короткую программу которая ждёт байт 0100 и после его получения высылает 512 байт из файла. Эти 512 байт я взял с не-загрузочного диска, первый блок тома.
В общем, запускаем UkncComSender.exe, выбираем загрузку через Стык С2, через пару секунд видим надпись No boot on device, т.е. блок передался и запустился.
Эта проверочная программа с исходником -- тоже в аттаче.
Было бы неплохо если бы кто-нибудь её прогнал на реальном УКНЦ, подключенном к COM-порту PC.
Дальше было бы интересно сделать загрузчик, чтобы можно было через COM-порт какую-нибудь игрушку передать.
А когда в эмуле будет точная растактовка хотя бы процессоров?
А когда в эмуле будет точная растактовка хотя бы процессоров?Определить точную растактовку 1801ВМ2 можно (насколько я понимаю) только с помощью осциллографа ( или ещё лучше - логического анализатора ).
Если у Вас ( либо кого-то ещё ) есть возможность наблюдать форму напряжений на выходах 1801ВМ2 при выполнении команд - я с удовльствием расскажу, что конкретно нужно сделать для определения точных растактовок процессора.
Дальше было бы интересно сделать загрузчик, чтобы можно было через COM-порт какую-нибудь игрушку передать.
Просто игрушку передать через С2 можно стандартными VTCOM+TANSF из RT-11.
Собственно сейчас попробую с 11/83 чего-нибудь перетащить :)
---------- Post added at 21:18 ---------- Previous post was at 21:05 ----------
Фокус не удался - Failed to open COM port...
---------- Post added at 21:22 ---------- Previous post was at 21:18 ----------
Создал ключик SerialPort в registry, теперь failed to confiure COM port :)
Создал ключик SerialPort в registry, теперь failed to confiure COM port :)
Это значит что вызов SetCommState() завершился неудачно.
Возможно, проблема что я проверял только на виртуальных портах. Попытаюсь найти машину с реальным.
Это значит что вызов SetCommState() завершился неудачно.
Возможно, проблема что я проверял только на виртуальных портах. Попытаюсь найти машину с реальным.
Могу потестить или дать виртуальную тестовую машинку с портом.
Просто игрушку передать через С2 можно стандартными VTCOM+TANSF из RT-11.
А у вас есть VTCOM / TANSF которые могли бы работать на УКНЦ?
Есть. Сейчас выложу образ диска.
Только там есть нюанс - если VTCOM запускать с эмулятора - у него должна быть нормальная скорость - на огромной скорости он таймера не увидит :)
---------- Post added at 00:23 ---------- Previous post was at 00:16 ----------
Дискета с RT-11 V5.7.
XL перестроен под адреса C2, есть и TRANSF и VTCOM. VTCOM нужно использовать .RELовский - .SAVовский требует mapped монитора. Принцип такой:
.FR/PA VTCOM
.LO XL=F
.RESU VTCOM
CTRL/F
...
Создал ключик SerialPort в registry, теперь failed to confiure COM port :)
Попробуйте этот вариант. Сделал несколько мелких поправок и показ кодов ошибок от GetLastError. Если не поможет -- скажите какое сообщение и какой код ошибки. можно также поэкспериментировать с открытием того же порта через UkncComSender -- там код работы с портом тот же.
UPD: http://ukncbtl.googlecode.com/files/UKNCBTL-beta20.zip
Попробуйте этот вариант.
Работает в одну сторону: на эмулятор передает, обратно - нет.
Скорость эмуляции огромная - приходится потрудиться, чтобы текст набрать :)
Работает в одну сторону: на эмулятор передает, обратно - нет.
Скорость эмуляции огромная - приходится потрудиться, чтобы текст набрать :)
Включите кнопку Sound -- помимо звука это выравнивает и скорость.
Может тогда и в обратную сторону заработает.
Скорость выровнялась, но работает все-равно в одну сторону. Я правда не знаю как С2 в реале работает - может там какой битик разрешить надо, а не просто как с терминалом сразу начинать работать. Проверить не на чем - у меня как раз С2 дохлый :(
Скорость эмуляции огромная - приходится потрудиться, чтобы текст набрать :)
Кстати, забавно. В 2007 примерно году когда мы начинали делать эмулятор, было у людей и такое мнение что мол ничего не выйдет потому что в УКНЦ дофига устройств и все работают одновременно, PC не потянет 8-)
Кстати, забавно. В 2007 примерно году когда мы начинали делать эмулятор, было у людей и такое мнение что мол ничего не выйдет потому что в УКНЦ дофига устройств и все работают одновременно, PC не потянет 8-)
Особенно если учесть, что в это время уже много лет существовал E11 которой в досовском варианте прекрасно все тянет да еще и - страшно сказать - не тормозит во время работы с флопом :)
В техническом описании указано что бит 2 регистра состояния источника (176574) включает режим проверки стыка С2 -- т.е. источник замыкается на приёмник.
Есть ли какой-то софт для проверки этого режима?
В техническом описании указано что бит 2 регистра состояния источника (176574) включает режим проверки стыка С2 -- т.е. источник замыкается на приёмник.
Есть ли какой-то софт для проверки этого режима?
Вот набросал что-то. Проверял замыканием двух терминальных портов на 11/83.
Тестит в цикле всеми 256 байтами, выходит по любой клавише. Текст в комплекте на случай доделок.
Чтобы проверить живой петлей (заглушкой) надо запускать так:
.GET C2TEST
.D 1000=0
.ST
UkncComSender.exe при запуске пишет "приложение не было запущено, поскольку оно некорректно настроено. Повторная установка приложения может решить данную проблему."
UkncComSender.exe при запуске пишет "приложение не было запущено, поскольку оно некорректно настроено. Повторная установка приложения может решить данную проблему."
Опять версия runtime вероятно.
Предлагаю самому собрать из исходника -- см. аттач.
Был ещё где-то вопрос "в какой ветке реестра задать параметр SerialPort?" --
HKEY_CURRENT_USER\Software\UKNCBTL
Был ещё где-то вопрос
да, сам разобрался, вопрос стер
Предлагаю самому собрать из исходника
это надо сначала Cи установить. я у себя нашел исходники для С2, записать на дискету смогу только на работе. Версия runtime какая должна быть?
это надо сначала Cи установить. я у себя нашел исходники для С2, записать на дискету смогу только на работе. Версия runtime какая должна быть?
В аттаче статически собранный exe, настроен на COM9.
заработало
настроен на COM9
а на СОМ1 как настроить, я бы на УКНЦ попробовал, на ноуте только СОМ1.
а на СОМ1 как настроить, я бы на УКНЦ попробовал, на ноуте только СОМ1.
Исправил на COM1.
Vamos, расскажите хоть что получилось.
расскажите хоть что получилось.
Пока ничего :( по этому и не отписывался. последний раз ...нцать лет назад С2 у меня работал, на прием точно. Сейчас перепроверяю распайку кабелей, записал на диск прогу которую когда-то писал для С2, вечером еще помучаю УКНЦ :).
А тест который я тут выкладывал работает на живом УКНЦ?
А то я его проверял на 11/83 замыканием двух портов друг на друга без всяких битиков петли :)
На УКНЦу вроде нашли мне микросхему - ждем :)
А тест который я тут выкладывал работает на живом УКНЦ?
Сегодня попробую.
Пока ситуация следующая, в гипертерминале виндовом код 100 "@" от УКНЦ получаю, отправить в обратную сторону никак. UkncComSender код 100 в упор не видит, при этом с эмулятора подхватывает даже при запуске после нажатия загрузки С2, из буфера что ли берет...
Схема распайки С2 - СОМ http://zx.pk.ru/showpost.php?p=201649&postcount=520
вызывает сомнения, в другом источнике http://support.mdl.ru/Pc_compl/doc/cable/gl4/rs232c.htm RTS/CTS в УКНЦ отсутствуют. Попробую сегодня вариант нуль-модемный, не уверен что замыкание TD/RD достаточно для УКНЦ.
Пока ситуация следующая, в гипертерминале виндовом код 100 "@" от УКНЦ получаю, отправить в обратную сторону никак. UkncComSender код 100 в упор не видит, при этом с эмулятора подхватывает даже при запуске после нажатия загрузки С2, из буфера что ли берет...
Схема распайки С2 - СОМ http://zx.pk.ru/showpost.php?p=201649&postcount=520
вызывает сомнения, в другом источнике http://support.mdl.ru/Pc_compl/doc/cable/gl4/rs232c.htm RTS/CTS в УКНЦ отсутствуют. Попробую сегодня вариант нуль-модемный, не уверен что замыкание TD/RD достаточно для УКНЦ.
Ну для того, чтобы получать в УКНЦ информацию, надо на вход 7 (109) обязательно подать +5 - +12 В. Достаточно замкнуть 3 и 7 выводы. Иначе вход для посылок извне закрыт. Если надо использовать чисто асинхронную линию (без контроля передачи), то надо обязательно замкнуть 3 и 7 выводы для получению посылок извне и 2 и 9 выводы (контроль передачи). Контроль передачи в ВП-065 аппаратный и его никак не отключить. В принципе вывод 2 можно оставить висеть в воздухе, тогда на вход 9 надо подать +5 вольт.
А схема зря вызывает сомнения. С помощью этого кабеля я подсоединял УКНЦ к гипертерминалу, грузил RT-11, потом заменял в ячейках RMON значения ячеек терминала со 177560-177566 на значения регистров С2, настраивал вектора С2 на вектора 60 и 64, ставил биты в битовой маске защиты на вектора С2. После этого RT-11 выводила всю информацию на стык С2, и все нормально работало.
А схема зря вызывает сомнения.
Сначала я по этой схеме все сделал, сомнения возникли из-за проседания +5 до +4,4 и стала сбоить загрузка с дисков.
Vamos, пробуй сокращенный вариант из прилагаемого файла. У Tnt23 с ним работало (см. на Полигоне призраков).
потом заменял в ячейках RMON значения ячеек терминала со 177560-177566 на значения регистров С2, настраивал вектора С2 на вектора 60 и 64, ставил биты в битовой маске защиты на вектора С2. После этого RT-11 выводила всю информацию на стык С2, и все нормально работало.
Для этого можно просто сгенерить многотерминальную систему и штатной командой перенастроить консоль. Правда в этом случае многие программы (где тупо отключаются прерывания клавиатуры очисткой бита) работать перестанут :)
Или можно собрать XL драйвер с адресами C2 и пользоваться самим УКНЦ как терминалом и передавать файлы через VTCOM/TRANSF :)
Сначала я по этой схеме все сделал, сомнения возникли из-за проседания +5 до +4,4 и стала сбоить загрузка с дисков.
Интересный момент. Сам я пользуюсь для питания УКНЦ с дисководами 200-ваттным AT-шным блоком питания. Напряжения не замерял, но работает нормально. Если УКНЦ с СЭМЗ-овской схемотехникой (все кварцы собраны рядом), то на вход 7 (109) обязательно нужно подавать только +5 В, т.к. он использует TTL-уровень. В случае Квантовской схемотехники можно подать DTR с PC, но в случае обмена DTR должен быть обязательно установлен, иначе на вход ничего не будет поступать.
И так, все заработало, был обрыв в кабеле.
Программа UkncComSender получила байт 100 и отправила 512 байт в УКНЦ, на экране ТВ появилась надпись ?BOOT-U-No boot on volume.
Программа C2TEST, запущенная на УКНЦ, передает набор символов на гипертерминал РС. Причем пишет ОК даже при отключенном кабеле, при замыкании RD и TD тоже ОК, но набор символов не отображается.
Вопрос вызывает постоянное присутствие байта 370 в регистре 176576, в эмуляторе регистр пустой.
У меня УКНЦ завода "Квант", по схеме и на плате вход 7 (109) через резистор подключен к -12 В и на вход 170УП, поэтому вариант +5 В не подходит и не работает. Перепробовал все предложенные варианты, в итоге работает только этот:
Стык С2 DB9S
1,10 (102) ■─────────────────────■ 5 (GND)
4,5 (103) ■──────────┐ ┌────■ 3 (TD)
┌────■│■────┘
6 (104) ■────┘ └──────────■ 2 (RD)
2 (108) ■────┐ ┌────■ 4 (DTR)
│ │
7 (109) ■────┤ ├────■ 1 (CD)
│ │
9 (107) ■────┘ └────■ 6 (DSR)
┌────■ 7 (RTS)
│
└────■ 8 (CTS)
На УКНЦ завода СЭМЗ скорость обмена выставляется перемычками или как на другом варианте схемы дешифратором?
Программа C2TEST, запущенная на УКНЦ, передает набор символов на гипертерминал РС. Причем пишет ОК даже при отключенном кабеле, при замыкании RD и TD тоже ОК, но набор символов не отображается.
Ага, значит при включении бита петли данные и назад заворачиваются и на выход летят - вот уже данные эмулятора :)
Вот такой вариант:
.GET C2TEST
.D 1000=0
.STA
не включает бит петли и должен ругаться если контакты TX/RX не замкнуты.
form, извините, я чего-то не догоняю...
C2TEST по умолчанию устанавливает бит который должен выход подавать обратно на вход. Если в адрес 1000 перед стартом записать 0 - не будет устанавливать этот бит.
Ага с битом ясно, только у меня на команду GET система ругается ?MON-F-Directory I/O error 130702.
и еще вопрос, набор символов при замкнутой петле должен отображатся на экране?
Программа UkncComSender получила байт 100 и отправила 512 байт в УКНЦ, на экране ТВ появилась надпись ?BOOT-U-No boot on volume.
Это показывает, что UkncComSender работает и с реалом тоже -- хорошо.
Можно попробовать ещё пообщаться между реальным УКНЦ и эмулятором тем же VTCOM.
На УКНЦ завода СЭМЗ скорость обмена выставляется перемычками или как на другом варианте схемы дешифратором?
А что, разве была возможность установить другую скорость кроме 9600 бод? Только аппаратно или программно тоже?
Ага с битом ясно, только у меня на команду GET система ругается ?MON-F-Directory I/O error 130702.
и еще вопрос, набор символов при замкнутой петле должен отображатся на экране?
Если GET так ругается, значит диск с которого делается попытка загрузить программу не читается (или его совсем нет). Я написал команды из расчета, что C2TEST.SAV лежит на DK. Если он на SY, то соответственно команда будет GET SY:C2TEST.
Насчет замкнутой петли - если имеется в виду физическое закорачивание RX-TX, тут ничего не могу сказать - не силен в этом.
А что, разве была возможность установить другую скорость кроме 9600 бод? Только аппаратно или программно тоже?
Из тех схем что пробегали по форуму и на других сайтах есть два варианта, один вариант соответствует УКНЦ "Квант" я ее сравнивал с платой (на плате есть две ошибки в разводке, остальное совпадает) скорость выставляется перемычками, второй вариант видимо соответствует сборке СЭМЗ платы у меня нет (а то бы сравнил) по схеме скорость выставляется микросхемой - отсюда и вопрос.
Насчет замкнутой петли - если имеется в виду физическое закорачивание RX-TX
программа C2TEST должна печатать на экране то что передает или только принимает и сообщает о результате?
программа C2TEST должна печатать на экране то что передает или только принимает и сообщает о результате?
А-а речь об экране программы.
Нет, не печатает - если печатать символы получится каша так как он передает полный набор от 000 до 377, а если печатать числовые значения - будет много времени тратиться. В качестве компромиса можно добавить печать разницы в случае ошибки. В сущности исходники прилагались - если не лень - можно доделать :)
Попробовал, не понятно.
В эмуляторе при D 1000 и 1000=0 пишет TIMEOUT
На УКНЦ при D 1000=0 ОК при замкнутых 2-7-9, но 4,5-6 (TX/RX) не замкнуты
А здесь понятно
На УКНЦ при D 1000=0 TIMEOUT и D 1000 ОК при пустом разъеме С2 - работает бит 2 в 176574
Попробовал, не понятно.
В эмуляторе при D 1000 и 1000=0 пишет TIMEOUT
На УКНЦ при D 1000=0 ОК при замкнутых 2-7-9, но 4,5-6 (TX/RX) не замкнуты
А здесь понятно
На УКНЦ при D 1000=0 TIMEOUT и D 1000 ОК при пустом разъеме С2 - работает бит 2 в 176574
Ну в эмуляторе C2 только появился и поведение еще не до конца эмулируется - собственно C2TEST для того и делал, чтобы проверить поведение - теперь думаю будет реализовано на основе полученных данных.
А тем временем и мне микросхема на замену приедет - можно будет вживую попробовать :)
В ночи попутал, да надеюсь nzeemin поправит в эмуляторе обработку бита 2.
У Шахнова в справочнике вроде все биты описаны.
Для меня пока остаются два вопроса:
1. На УКНЦ при D 1000=0 ОК при замкнутых 2-7-9, но 4,5-6 (TX/RX) не замкнуты
2. Что делает байт 370 в 176576 и как при его наличии происходит правильная передача данных.
стаются два вопроса:
1. На УКНЦ при D 1000=0 ОК при замкнутых 2-7-9, но 4,5-6 (TX/RX) не замкнуты
2. Что делает байт 370 в 176576 и как при его наличии происходит правильная передача данных.
1. Запускалось через GET/D/START или через D/RUN? :)
2. На чтение этот регистр не определен, а 370 - пережитки чего-то, что просаживает шину вниз (1 с точки зрения шины) во время цикла чтения на старших битах байта
form, забыл спросить (еще не проснулся), у Вас какого завода УКНЦ?
2. Что делает байт 370 в 176576 и как при его наличии происходит правильная передача данных.
При чтении из регистра данных передатчика читается вектор прерывания приемника. Вектор передатчика соответственно на 4 больше.
Запускалось через GET/D/START
пережитки чего-то, что просаживает шину вниз (1 с точки зрения шины)
тогда наверное было бы 377
---------- Post added at 12:00 ---------- Previous post was at 11:54 ----------
Alex_K, спасибо, успокоили, тоже думал что чего-то где то подсаживает.
Ваше мнение по поводу схемы подключения и влияния на режим приема передачи С2
form, забыл спросить (еще не проснулся), у Вас какого завода УКНЦ?
Квантовский.
form, это хорошо, будет возможность сделать выводы о схеме подключения С2
form, это хорошо, будет возможность сделать выводы о схеме подключения С2
Главное его сначала запустить :)
Пока это все безобразие выглядит так (http://pdp-11.nsk.ru/~form/files/pics/uknc/cimg2048.jpg).
form, пока Вы ждете микросхему, можно Вас озадачить вопросом:
вот здесь http://zx.pk.ru/showpost.php?p=302625&postcount=188
во вложении пара дискет для исследования. Задача такая дизасемблировать драйвер GD.SYS и выяснить как он работает, что бы nzeemin в эмуляторе подправил.
form, пока Вы ждете микросхему, можно Вас озадачить вопросом:
вот здесь http://zx.pk.ru/showpost.php?p=302625&postcount=188
во вложении пара дискет для исследования. Задача такая дизасемблировать драйвер GD.SYS и выяснить как он работает, что бы nzeemin в эмуляторе подправил.
Ну дизассемблировать недолго, а там посмотрим.
Ну дизассемблировать недолго, а там посмотрим.
У меня на памяти кто-то давно говорил что регистры 176644 176646 являются не тем что в описании (управление и ловушка) а это регистры доступа видео ОЗУ план 0.
У меня на памяти кто-то давно говорил что регистры 176644 176646 являются не тем что в описании (управление и ловушка) а это регистры доступа видео ОЗУ план 0.
Регистры доступа к видеопамяти 176640 и 176642. Совсем недавно баловался в драйвере часов :)
Причем доступны два плана, а не один.
Регистры доступа к видеопамяти 176640 и 176642
это планы 1 и 2 , а к 0 считается что нет регистрового доступа, все видео ОЗУ три плана по 32 Кб.
на диске GD есть два графических пакета для КГД, с драйвером на УКНЦ они работают, а в эмуляторе не работают.
а к 0 считается что нет регистрового доступа
Из ЦП вроде как и нет. Может в каких-то моделях вместо ловушки делали, но на тех (двух, обе вроде квантовские), что мне попадались ловушка была на месте.
На УКНЦ завода СЭМЗ скорость обмена выставляется перемычками или как на другом варианте схемы дешифратором?
На УКНЦ с СЭМЗ-овской схемотехникой скорость обмена выставляется программно через регистр 177704 на шине ПП, закрепляется скорость переключением бита 8 регистра 177700. Во вложении программка для переключения скорости из архива Олега Ховайко. Сам Олег мне говорил, что переключение нестабильное и может на первый раз не сработать. Может стабильности удастся добиться, вставив паузу между заносом в регистр 177704 нового значения и установкой бита 8 в 177700, а также между установкой и сбросом бита 8 в 177700.
В эмуляторе появилась настройка номера СОМ порта, появился адрес вектора прерывания в регистре 176576, а вот бит 2 не отрабатывается.
В эмуляторе появилась настройка номера СОМ порта, появился адрес вектора прерывания в регистре 176576, а вот бит 2 не отрабатывается.
Да, точно так.
Попытался сегодня разобраться с этим битиком, но пока безуспешно. Сделать поддержку параллельного порта оказалось проще 8-)
Сделать поддержку параллельного порта оказалось проще 8-)
А программную поддержку скорости обмена получится?
А программную поддержку скорости обмена получится?
Пока ничего не могу обещать. Посмотрим как пойдёт.
Давненько про С2 что-то не писали... ;)
Скачал эмулятор beta20 от 21-Jun-2011, попробовал С2.
Уже лучше: передача идет в обе стороны, но на прием прерывание генерируется правильно, а на отдачу во-первых генерится при записи в 176576 (должно генериться при готовности "железа" для записи в него), во-вторых по фиг знает какому вектору.
Кроме того при RESET не сбрасываются биты разрешения прерываний ни с источника ни с приемника.
Еще немного и VTCOM/TRANSF заработает :)
Попробовал beta21. При передаче символа в C2 снаружи (при получении внутри эмулятора) возникает прерывание независимо от того включен бит или нет :)
Попробовал beta21. При передаче символа в C2 снаружи (при получении внутри эмулятора) возникает прерывание независимо от того включен бит или нет :)
А там с С2 еще ничего и не делалось. Пока на очереди надо доделать работу с 1801ВП1-128 (контроллер флоппи), программируемый таймер, регистр 177054. А там уже и с С2 можно повозиться.
А там с С2 еще ничего и не делалось. Пока на очереди надо доделать работу с 1801ВП1-128 (контроллер флоппи), программируемый таймер, регистр 177054. А там уже и с С2 можно повозиться.
Там С2 уже передает данные. А прерывания входящей стороны в прошлой бете даже работали правильно. Сейчас - криво :)
---------- Post added at 22:44 ---------- Previous post was at 22:40 ----------
Хотя может и в прошлой неправильно было - на вход я его под VTCOM проверял, а вот на выход уже (после нерабочести VTCOM) тестил через ODT, а сейчас и на вход в ODT попробовал и обнаружил, что прерывание происходит сразу независимо от бита 6 в CSR.
Хотя может и в прошлой неправильно было - на вход я его под VTCOM проверял, а вот на выход уже (после нерабочести VTCOM) тестил через ODT, а сейчас и на вход в ODT попробовал и обнаружил, что прерывание происходит сразу независимо от бита 6 в CSR.
Вот. В 21-й бете на магистрали ЦП только ловушка адреса появилась, все остальное не затрагивалось.
По приоритету сперва контроллер флоппи стоит, надо привести в порядок в соответствии с последними сведениями.
Так что, form, извините, попозже будет. Там Ваша помощь будет очень нужна, в том смысле как в RT-11 работать с COM-портом. Тестировать, как я понимаю, можно и в E11, привязать к виртуальному железу реальный COM-порт.
По приоритету сперва контроллер флоппи стоит, надо привести в порядок в соответствии с последними сведениями.
А какие программы/диски не идут на текущем контроллере флоппи?
Вот. В 21-й бете на магистрали ЦП только ловушка адреса появилась, все остальное не затрагивалось.
По приоритету сперва контроллер флоппи стоит, надо привести в порядок в соответствии с последними сведениями.
Так что, form, извините, попозже будет. Там Ваша помощь будет очень нужна, в том смысле как в RT-11 работать с COM-портом. Тестировать, как я понимаю, можно и в E11, привязать к виртуальному железу реальный COM-порт.
Ну С2 появился-то достаточно давно, только не доведен до ума еще :)
А я все хочу эмулятор связать с 11/83 :)
E11 да, его легко привязать к живому железу.
С живым отлично все работает. Вот через телнет если делать (мы с Andrey_Ak устанавливали связь между RT-11 по телнету и гоняли файлы взад-вперед) - тут придется в бубен постучать и поплясать вокруг костра :)
А работать - собственно вариантов немного:
- использовать как отдельный терминал куда можно повесить отдельную прогу или переключить консоль (для УКНЦ впрочем вариант не сильно актуальный хоть и возможный)
- использовать для терминального подключения к другому кому/передачи данных (VTCOM, TRANSF).
(это из того что сразу в RT-11 есть без дополнительного софта)
А какие программы/диски не идут на текущем контроллере флоппи?
Да диски все идут. Иногда не ставится бит готовности (дисковод подвисает), бит готовности может поставится тогда, когда не надо. Бывают моменты, что не сбрасываются изменения на диск.
Ну и самое главное - отвязать собственно контроллер от дисководов. Для дисководов надо только запоминать текущую дорожку и все. Сигнал стороны идет с контроллера, переключили дисковод, там и стала та сторона. К тому же дисководы являются только источником текущей информации, контроллер не должен менять состояния при изменении текущего дисковода. Если он вошел в режим декодирования MFM, то здесь по барабану какой дисковод, с того и пойдут данные, остановлен мотор или не выбран дисковод - идут нули.
Сорри, если несколько сумбурно. Но с 1801ВП1-128 провозился достаточно долго, чтобы понять его работу внутри. Надо бы привести код в эмуляторе в порядок в соответствии с последними знаниями. Но все равно работать он будет точно на уровне считываемых слов, в реальности он работает с потоком MFM-битов, а это в реальности совершенно другое, но в эмуляторе это и не надо.
Т.е. глюк как бы плавающий, и нет конкретных дисков или программ, где он проявляется стабильно?
Во вложении -- UkncComSender.exe плюс исходник от него.
Скрестил то что было в SAV2WAV со своими тестами Стык С2, заглядывая в описание Алексея (UKNC_TAPE.doc).
Работает так:
1. Используя драйвер com0com (http://sourceforge.net/projects/com0com/) создаём и соединяем два виртуальных порта -- на один настраиваем эмулятор, во второй будем высылать SAV-файл.
2. Запускаем UkncComSender, указав два параметра -- имя COM-порта и название SAV-файла.
3. Стартуем эмулятор, выбираем загрузку из Стык С2.
UkncComSender.exe COM9 vert.sav
Serial port COM9 opened.
Serial port configured.
Opening the input file vert.sav...
Reading the first block...
Waiting for byte 0100...
0x40
Sending loader...
Sending data ...............
COM port closed.
Действие программы такое же как у SAV2WAV: в первый 512-байтовый блок вставляется короткий загрузчик, который догружает хвост файла и запускает его.
Код загрузчика пока корявый, но работает -- VERT.SAV из примера у меня запустился.
000000 000240 NOP ; Опознавательный знак
000002 000447 BR 000122 ; Запуск загрузчика
000122 012701 001000 MOV #001000,R1 ; Адрес куда считывать остаток файла
000126 013702 000324 MOV @#000324,R2 ; Длина остатка в словах
000132 006302 ASL R2 ; Длина остатка в байтах
000134 105737 176570 TSTB @#176570 ; Приемник готов ?
000140 100375 BPL 000132 ; Нет
000142 113721 176572 MOVB @#176572,(R1)+ ; Переслать принятый байт в память
000146 077206 SOB R2,000132 ; Продолжаем пока не прочитали всё
000150 013706 000042 MOV @#000042,SP
000154 013707 000040 MOV @#000040,PC ; Запускаем загруженную программу
Во вложении -- UkncComSender.exe плюс исходник от него.
А сам C2 в эмуляторе нельзя починить?
Я тут писал уже что не работает - совсем мелочи остались :)
Хотя может и в прошлой неправильно было - на вход я его под VTCOM проверял, а вот на выход уже (после нерабочести VTCOM) тестил через ODT, а сейчас и на вход в ODT попробовал и обнаружил, что прерывание происходит сразу независимо от бита 6 в CSR.
Во вложении -- вариант где бит учитывается, попробуйте пожалуйста.
Во вложении -- вариант где бит учитывается, попробуйте пожалуйста.
На вход вроде работает правильно теперь (прерывание не проверял).
На выход по прежнему неправильно: прерывание возникает в момент записи в регистр данных, а не когда регистр даннных готов принять байт.
Само прерывание происходит по непонятному вектору.
RESET по прежнему не сбрасывает бит разрешения прерываний (как минимум для 176574).
На вход вроде работает правильно теперь (прерывание не проверял).
На выход по прежнему неправильно: прерывание возникает в момент записи в регистр данных, а не когда регистр даннных готов принять байт.
Само прерывание происходит по непонятному вектору.
RESET по прежнему не сбрасывает бит разрешения прерываний (как минимум для 176574).
Вектор поправил, сброс поправил, про момент возникновения прерывания -- пока думаю.
Вектор поправил, сброс поправил, про момент возникновения прерывания -- пока думаю.
Вектора работают правильно.
У 176574 бит 6 (100) сбрасывается по RESETу как и положено.
У 176570 не сбрасывается.
Осталась мелочь и можно будет связывать.
Момент возникновения проще вычислять в аппаратных принципах: прервание возникает сразу же как устанавливается 7 бит (200).
7 бит устанавливается как только в буфере COM порта (или того что в него отсылает) есть место для символа.
Это касается 176574/176576 всмысле, у 176570/176572 все нормально.
Момент возникновения проще вычислять в аппаратных принципах: прервание возникает сразу же как устанавливается 7 бит (200).Прерывание возникает и у устройства с разрешёнными прерываниями (установлен бит 6) при достижении готовности (установка бита 7), и у готового устройства (установлен бит 7) при разрешении прерываний (установка бита 6).
Прерывание возникает и у устройства с разрешёнными прерываниями (установлен бит 6) при достижении готовности (установка бита 7), и у готового устройства (установлен бит 7) при разрешении прерываний (установка бита 6).
Это то же самое только другими словами :)
Просто не упоминал разрешение так как его уже обсуждали.
Ну и про приритет (точнее "приоритет") CPU не упоминал как про очевидное :)
Ну и про приритет (точнее "приоритет") CPU не упоминал как про очевидноеПри абстрактной эмуляции выставления запроса IRQ на шину Q-Bus (без отдельной эмуляции запроса вектора) я учитываю (и всем рекомендую учитывать) следующие аппаратные параметры:
bool SetIRQ(
word uVector,
word uBR_Line,
word uBR_LinePosition,
bool bClearedByInit = true
)
Если за то время, пока прерывания в процессоре были запрещены, успело поступить несколько запросов прерываний от разных устройств, то после разрешения обработки прерываний - первым обсуживается тот запрос, который пришёл по линии BR с большим номером и от того устройства, которое расположено на этой линии BR ближе к процессору.
При абстрактной эмуляции выставления запроса IRQ на шину Q-Bus (без отдельной эмуляции запроса вектора) я учитываю (и всем рекомендую учитывать) следующие аппаратные параметры:
bool SetIRQ(
word uVector,
word uBR_Line,
word uBR_LinePosition,
bool bClearedByInit = true
)
Если за то время, пока прерывания в процессоре были запрещены, успело поступить несколько запросов прерываний от разных устройств, то после разрешения обработки прерываний - первым обсуживается тот запрос, который пришёл по линии BR с большим номером и от того устройства, которое расположено на этой линии BR ближе к процессору.
Это уже вопросы к самой организации эмулятора, они выходят за рамки вопроса поправки C2 :)
Это уже вопросы к самой организации эмулятора, они выходят за рамки вопроса поправки C2Хорошо если так.
Для устройств, имеющих разные векторы прерываний передачи и приёма, в реальном оборудовании (как правило) задан жёсткий порядок обсуживания этих прерываний при одновременном поступлении.
Является ли "правильной" эмуляция, при которой данный порядок не соблюдается и требует ли такая ситуация учёта и "поправки" - вопрос абстрактный.
Хорошо если так.
Для устройств, имеющих разные векторы прерываний передачи и приёма, в реальном оборудовании (как правило) задан жёсткий порядок обсуживания этих прерываний при одновременном поступлении.
Является ли "правильной" эмуляция, при которой данный порядок не соблюдается и требует ли такая ситуация учёта и "поправки" - вопрос абстрактный.
Ну это все отдельная тема по организации самого эмулятора.
Для этой темы думаю нашлось бы много полезного материала.
Мне же пока нужно просто чтобы С2 в эмуляторе заработал - тогда я успокоюсь даже без починки С2 в своем УКНЦ и буду его плавно готовить к тому, чтобы сплавить нахрен :)
В исходники эмулятора не полезу принципиально :)
Ну это все отдельная тема по организации самого эмулятора.
Для этой темы думаю нашлось бы много полезного материала.В тему правильной эмуляции прерываний PDP-11 глубже всего проник Боб Супник: PDP-11 Interrupts: Variations On A Theme (http://simh.trailing-edge.com/docs/pdp11interrupts.pdf).
В тему правильной эмуляции прерываний PDP-11 глубже всего проник Боб Супник: PDP-11 Interrupts: Variations On A Theme (http://simh.trailing-edge.com/docs/pdp11interrupts.pdf).
В описании E11 есть глава, посвященная эмуляции прерываний в условиях эмулируемого же железа. В двух словах кроме уже упомянутых rank, level, нужен еще параметр сколько команд cpu пропустить прежде чем приерывание сработает. Это особенно критично для DECовского софта в котором часто обработчики прерывания надеются не на приоритет процессора, а на то, что хватит времени обработать прерывание раньше чем возникнет следующее :)
Тамже кстати примеры есть из реальной жизни.
---------- Post added at 18:16 ---------- Previous post was at 17:53 ----------
Кстати о Супнике... Ни у кого случайно нет с ним связи? :)
У них там в эмуляторе RK06/07 криво запись делает. Пробовал написать на адрес на который "пишите" - это оказался список рассылки на который еще надо подписаться. Попробовал подписаться - молчание. На том и кончилась добрая инициатива по отправке им патча :)
сколько команд cpu пропустить прежде чем приерывание сработает.Так приходится поступать (например, буферизовать принимаемые через порт символы и передавать их процессору только тогда, когда после передачи предыдущего символа процессор успел выполнить не менее 100 команд ), но это уже относится не к корректной, а к комфортной эмуляции.
Это особенно критично для DECовского софта в котором часто обработчики прерывания надеются не на приоритет процессора, а на то, что хватит времени обработать прерывание раньше чем возникнет следующееВ ядре монитора RT11SJ есть забавный баг, который приводит к тому, что если очередной символ поступает на вход порта терминала раньше, чем процессор успел выполнить 100 команд - символы заносятся в кольцевой буфер ввода в обратном порядке. Причём, это происходит (если не ошибаюсь) даже в том случае, когда при генерации монитора заказан High Speed Ring Buffer :)
Во всех остальных мониторах, кроме SJ - такого бага нет.
В ядре монитора RT11SJ есть забавный баг, который приводит к тому, что если очередной символ поступает на вход порта терминала раньше, чем процессор успел выполнить 100 команд - символы заносятся в кольцевой буфер ввода в обратном порядке. Причём, это происходит (если не ошибаюсь) даже в том случае, когда при генерации монитора заказан High Speed Ring Buffer :)
Во всех остальных мониторах, кроме SJ - такого бага нет.
В доке на E11 упоминается это. А также MSCP, RK05 в RSTS итд :)
Сказать, что это баг не совсем верно будет - ведь на живом железе оно не проявляется. Так, что это скорее кривая реализация :)
Кстати насчет клавиатуры в SJ. На SB не распространяется - проверил :)
(клавиша выдает "1234567890")
Сказать, что это баг не совсем верно будет - ведь на живом железе оно не проявляется. Так, что это скорее кривая реализация :)Баг проявляется, когда терминал может запоминать последовательности символов и передавать их (в нужный момент) компьютеру со скоростью порта терминала.
При скорости порта 9600 bps процессор должен выполнять менее 100'000 команд в секунду (т.е. иметь быстродействие меньше 0.1 MIPS), чтобы этот баг проявился.
При скорости порта 57600 bps - баг проявится при быстродействии процессора менее 0.6 MIPS.
Учитывая, что минимальная тактовая частота процессора 1801ВМ1 примерно 100 КГц, а при тактовой частоте 5 МГц быстродействие 1801ВМ1 составляет примерно 0.2 MIPS - вполне можно собрать реальную конфигурацию, в которой данный баг проявится.
Учитывая, что минимальная тактовая частота процессора 1801ВМ1 примерно 100 КГц, а быстродействие 1801ВМ1 при тактовой частоте 5 МГц составляет примерно 0.2 MIPS - вполне можно собрать реальную конфигурацию, в которой данный баг проявится.
Между можно собрать и тем, что выпускалось разница огромная :)
; DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS
; SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.
знакомы строчки? :)
DEC частенько даже в коментариях писал замечания вроде "не менять команды местами", "не убирать вот эти команды" итд. RT-11 правда в этом отношении бедновата на коментарии вообще - более-менее детально коментировать его начал уже Mentec.
Между можно собрать и тем, что выпускалось разница огромная
; DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS
; SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.
знакомы строчки?Это не относится к устройствам, подключаемым к стандартным портам DEC - подключать к портам допустимо любые устройства, соответствующие стандарту порта.
Учитывая, что быстродействие стандартной LSI-11 при выполнении кода ядра RT11SJ составляет (если не ошибаюсь) около 0.1 MIPS - обсуждаемый баг вполне может проявиться. Нужно лишь подключить достаточно продвинутый терминал.
Учитывая, что быстродействие стандартной LSI-11 при выполнении кода ядра RT11SJ составляет (если не ошибаюсь) около 0.1 MIPS - обсуждаемый баг вполне может проявиться. Нужно лишь подключить достаточно продвинутый терминал.
Есть еще такой список - железо которое поддерживается системой, в котором в том числе терминалы упоминаются...
Кстати, сейчас попробую организовать глюк в SJ на живом 11/83 :)
---------- Post added at 19:33 ---------- Previous post was at 19:28 ----------
Testing in progress - Please wait
Memory Size is 2048 K Bytes
9 Step memory test
Step 1 2 3 4 5 6 7 8 9
Message 04 Entering Dialog mode
Commands are Help, Boot, List, Setup, Map and Test.
Type a command then press the RETURN key: B MU
Trying MU0
Starting system from MU0
MSBOOT V05.04
*MDUP.AI
MDUP V05.30
?MDUP-I-No bad blocks detected VM0:
RT-11 V05.04... Ждемс...
Есть еще такой список - железо которое поддерживается системой, в котором в том числе терминалы упоминаются...Глюк будет с любым терминалом, у которого есть клавиши, генерящие при одном нажатии более одного кода.
Так я на этот глюк и наткнулся. При установке в эмуляторе малых скоростей процессора и больших скоростей порта - клавиши доп.клавиатуры переставали нормально отрабатываться.
Глюк будет с любым терминалом, у которого есть клавиши, генерящие при одном нажатии более одного кода.
Так я на этот глюк и наткнулся. При установке в эмуляторе малых скоростей процессора и больших скоростей порта - клавиши доп.клавиатуры переставали нормально отрабатываться.
Сильно подозреваю, что не будет ни с каким.
Просто будут потери символов, а прерывания не станут чаще чем задумано.
Впрочем осталось недолго - каких-нибудь минут 20 еще и система поставится :)
Ну а в эмуляторе или стороннем железе (не терминале) вероятность конечно большая.
---------- Post added at 20:41 ---------- Previous post was at 20:25 ----------
Добиться не удалось ни потерь ни переворота в буфере на 38400.
Надо проц послабее.
Надо проц послабее.А какую скорость работы процессора показывает SPEED.SAV ?
А какую скорость работы процессора показывает SPEED.SAV ?
.RU DU4:SPEED
tEST BYSTRODEJSTWIQ.
bYSTRODEJSTWIE (TYS.OP./SEK)
kOMANDA SLOVENIQ REGISTR-REGISTR: 1632
kOMANDA SLOVENIQ REGISTR-PAMQTX: 948
kOMANDA UMNOVENIQ REGISTR-REGISTR: 188
kOMANDA DELENIQ REGISTR-REGISTR: 668
wYKL@^ITE TAJMER...
На этом дело остановилось - поскольку таймер управляемый да еще и от внутреннего генератора процессорной платы. Сейчас попробую повесить в память драйвер который по нажатии на клавишу запретит через CSR.
На этом дело остановилось - поскольку таймер управляемый да еще и от внутреннего генератора процессорной платы. Сейчас попробую повесить в память драйвер который по нажатии на клавишу запретит через CSR.Это версия SPEED.SAV из комплекта TMOS. Она требует включить таймер перед началом работы (иначе не сможет определить быстродействие процессора) и выключить таймер перед завершением работы (иначе не смогут работать тесты TMOS).
Быстродействие ~1.0 MIPS обычных команд - слишком большое для "глюка SJ" - нужно замедлить процессор минимум в 10 раз :)
Это версия SPEED.SAV из комплекта TMOS. Она требует включить таймер перед началом работы (иначе не сможет определить быстродействие процессора) и выключить таймер перед завершением работы (иначе не смогут работать тесты TMOS).
Быстродействие ~1.0 MIPS обычных команд - слишком большое для "глюка SJ" - нужно замедлить процессор минимум в 10 раз :)
У меня таймер управляемый, поэтому даже мысли не было о том, чтобы реализовать внешнее отключение тем более что BEVNT не используется для него :)
Сейчас допилю драйвер чтобы отключать со второго терминала :)
А что до глюка - сильно подозреваю, что ни одна DECовская DL11 железка просто не даст прерываний больше чем DEC ожидал :)
---------- Post added at 22:03 ---------- Previous post was at 21:55 ----------
Не вышло ничего - видимо он приоритет проца задирает в этом месте - второй терминал перестает отзываться :)
Попробовал вывалить в пульт, запретить таймер и запустить дальше - прога просто вышла :)
---------- Post added at 22:03 ---------- Previous post was at 22:03 ----------
Надо в XXDP порыться - там поди есть.
У меня таймер управляемый, поэтому даже мысли не было о том, чтобы реализовать внешнее отключениеВ данном случае этого также не требуется - никакой дополнительной информации SPEED.SAV после выключения таймера не сообщает - просто выполняет EMT 0350.
В данном случае этого также не требуется - никакой дополнительной информации SPEED.SAV после выключения таймера не сообщает - просто выполняет EMT 0350.
Гы. Ну и фиг с ним :)
---------- Post added at 23:14 ---------- Previous post was at 22:05 ----------
Немно зверства :)
.RU ODT
ODT V05.08
*177520/003007 7007
*^C
.RU DU4:SPEED
+EST BYSTRODEJSTWIQ.
bYSTRODEJSTWIE (TYS.OP./SEK)
+OMANDA SLOVENIQ REGISTR-REGISTR: 100
+OMANDA SLOVENIQ REGISTR-PAMQTX: 60
+OMANDA UMNOVENIQ REGISTR-REGISTR: 12
+OMANDA DELENIQ REGISTR-REGISTR: 40
+YKL@^ITE TAJMER...
А вообще пора наверное тему заводить специально по вопросам диагностики :)
Благодаря собранной информации, смог загрузить через стык С2 операционную систему.
Огромная благодарность form и Andrey_Ak за предоставленные программу TU58 и процесс загрузки на ДВК, ну и текст загрузчика (http://www.tis.kz/forum/topic.php?forum=1&topic=16&postid=1329595762#1329595762).
Также огромная благодарность nzeemin за программу UkncComSender.
Программу UkncComSender пришлось немного модифицировать, т.к. для связи я использую кабель с контролем передачи (задействованы линии CTS и RTS), модификация состоит в присвоении в блоке DCB переменным fDtrControl и fRtsControl значений DTR_CONTROL_ENABLE и RTS_CONTROL_ENABLE соответственно. Также в архиве пример образа для загрузки (в образе нет драйверов MZ и WD), на основе этого образа можно собрать свой.
Сам процесс загрузки начинается с посылки загрузчика TU58 на УКНЦ (TU58.SAV) с помощью программы UkncComSender. Далее загруженная программа ожидает нажатия пробела, и потом начинается загрузка с образа.
Alex_K, ссылка "текст загрузчика" прокисла -- может сюда этот текст выложить?
hantarex
29.12.2012, 16:23
Господа! Ткните носом - где можно посмотреть формат команд/пакетов для сетевого диска? Грубо говоря - что творится на Стык2 после загрузки в УКНЦ RT-11 и монтирования Стык2, как сетевого диска?
Господа! Ткните носом - где можно посмотреть формат команд/пакетов для сетевого диска?Зависит от диска ( т.е. от того драйвера, который перенаправляет файловые запросы в порт ).
Сеть УКНЦ использует свой формат, эмулятор TU-58 - свой, мультиплексор HX - свой.
hantarex
29.12.2012, 16:51
тогда какой формат наиболее прост? есть мысль реализовать файл-сервер на какой-нить простенькой Меге с SD-картой и RS232 портом.
даже так - где взять инфу по трем вышеперечисленным дискам/драйверам?
тогда какой формат наиболее прост? есть мысль реализовать файл-сервер на какой-нить простенькой Меге с SD-картой и RS232 портом.Я это уже сделал. Мультиплексор HX как раз и работает с файл-сервером на PC через RS-232, позволяя одновременно использовать тот же самый порт ещё и в качестве системного терминала ( для УКНЦ это не очень актуально, а для запуска "на столе" голых процессорных плат ДВК / PDP-11 - самое то ).
В РАФОСе был драйверок и несколько программок. Там сервер был под TSX (РАФОС/TS), а клиентами была кучка RT-11. И через линию тоже можно было терминалом подключаться или диски монтировать. Руки не дошли поковырять, софт этот у меня валяется среди рафосов.
hantarex
29.12.2012, 17:01
на мой взгляд РС здесь лишний:) где почитать про протокол НХ? только прошу не предлагайте покурить листинги:)
где почитать про протокол НХ? только прошу не предлагайте покурить листингиОписание протокола HX существует только на языках MACRO-11 ( описание протокола с точки зрения клиента ) и C++ ( описание протокола с точки зрения сервера ).
Ведь адекватно описать фазовую машину протокола без использования алгоритмических конструкций невозможно - поэтому листинг реализации фазовой машины и является её единственно адекватным описанием.
hantarex
29.12.2012, 17:20
я думал - все гораздо проще:) команда-отклик:) считать блок-записать блок.
режим терминала реализовываться не будет. только файл-сервер и только для УКНЦ.
команда-откликТам ведь по одному каналу идут и пакеты дискового обмена, и обычный байтовый обмен с терминалом.
Фильтр протокола HX на стороне сервера, получая эту кашу - опознаёт в ней пакеты и извлекает их, а всё остальное пропускает на сокет подключения терминала.
Если на любой стадии разборки пакета тот отклоняется от стандарта HX - все принятые в процессе разборки байты возвращаются в терминальный обмен и отправляются терминалу.
hantarex
29.12.2012, 17:29
и пакеты дискового обмена
вот об этом можно поподробней?
режим терминала реализовываться не будет. только файл-сервер и только для УКНЦ.Лучше, чем уже сделано - сделать вряд ли получится.
А какой смысл делать хуже, если можно просто запустить "Эмулятор VT52 (http://zx.pk.ru/showthread.php?t=20092)" в режиме HX-сервера и пользоваться.
hantarex
29.12.2012, 17:32
да блин. в том-то и дело, что хочу реализовать файл-сервер без ББ, автономно. и я не собираюсь делать лучше, собираюсь по другому.
в мегах немного рублю, в RT-11 - не очень, потому и прошу помощи.
вот об этом можно поподробней?
Вот, например, как драйвер HX.SYS для RT-11 реализует вызов чтения массива слов с диска ( с поддержкой режима сжатия на стороне сервера ):
HX.Read:
.IF NE MMG$T
Mov HXCQE, R4
.EndC
BiC #100, @#TPS
Mov #1, R0 ; Send SOH
Call ChOu
;; MovB #375, R0 ; Short packet
;; Call ChOu
;; Mov #7, R0 ; Packet size.
;; Call ChOu
Mov #176407, R0 ; Short packet ; Packet size = 7
Call WOu
;; Mov #'C, R0 ; Packet type = COMMAND
;; Call ChOs
;; Mov #'R, R0 ; Command = Cmd_READ_RAW
;; Call ChOs
;; Mov #"RC, R0 ; Packet type = COMMAND ; Command = Cmd_READ_RAW
Mov #"rC, R0 ; Packet type = COMMAND ; Command = Cmd_READ_PACKED_STREAM
Call WOs
Mov R3, R0 ; Unit
Call ChOs
Mov R2, R0 ; Block
Call WOs
Mov R1, R0 ; WordCount
Call WOs
Call TTKPrep
Mov ChSum, R0
Call WOu ; CheckSumm
................
Clr ChSum
1$:
Call ChIn
CmpB R0, #374 ; PACKED_STREAM ?
BEq GetPackedStream
CmpB R0, #376 ; Long packet == Data
BEq GetData
CmpB R0, #3 ; Ctrl_C ?
BEq ERR
CmpB R0, #375
BNE 1$
; Short packet == Error
Call ChIn
Mov R0, R3 ; R3 == Packet Size;
BEq ERR ; Packet Size == 0 ?
Skip:
CmpB (R3)+, (R3)+ ; R3 += 2;
Call ChIn
SOB R3, .-4. ; Get packet bytes.
Br ERR
GetData:
Call WInR3 ; R3 == Packet Size;
BEq ERR ; Packet Size == 0 ?
Call ChIn
CmpB R0, #'R ; Pcket type == REPLY ?
BNE Skip
Dec R3
BLE ERR
Add R0, ChSum
Call ChIn
CmpB R0, #'D ; Reply type == RAW DATA ?
BNE Skip
Dec R3
BLE ERR
Add R0, ChSum
ASL R1 ; R1 == Byte Count
2$:
Call ChIn
Add R0, ChSum
.IF EQ MMG$T
MovB R0, (R5)+
.IFF
Mov R0, -(SP)
Call @$PTBYT
.EndC
Dec R3
BEq 3$
SOB R1, 2$
3$:
Tst R3
BGt Skip
Call WInR3 ; R3 == CheckSumm
Dec R1
BNE ERR
CmpR3:
Cmp R3, ChSum
BNE ERR
OK: Tst (PC)+
ERR: SeC
Return
................
GetPackedStream:
NextPackedBlock:
Call ChIn ; R0 == PackedBlock Header
Add R0, ChSum
Dec R0 ;
BMi EndOfStream ; = 0 - End Of Stream
BEq GetRptBlock ; = 1 - RPT_Block
Inc R0 ; > 1 - RAW_Block
; Get RAW_Block
Mov R0, R2 ; R2 == RAW Bytes Count
1$:
Call ChIn
Add R0, ChSum
.IF EQ MMG$T
MovB R0, (R5)+
.IFF
Mov R0, -(SP)
Call @$PTBYT
.EndC
SOB R2, 1$
Br NextPackedBlock
EndOfStream:
Call WInR3 ; R3 == CheckSumm
Br CmpR3
GetRptBlock:
Call ChIn ;
Add R0, ChSum
Mov R0, R2 ; R2 == RPT Count
Call ChIn ; R0 == Byte to repeat.
Add R0, ChSum
1$:
.IF EQ MMG$T
MovB R0, (R5)+
.IFF
Mov R0, -(SP)
Call @$PTBYT
.EndC
DecB R2
BNE 1$
Br NextPackedBlock
---------- Post added at 16:36 ---------- Previous post was at 16:35 ----------
файл-сервер без ББ, автономно.Это как?
hantarex
29.12.2012, 17:55
я же писал - Мега с SD-картой и портом RS232. Мега обрабатывает пакеты, читает-пишет SD-карту. если тяму хватит - будет поддержка FAT16 на SD-карте. если нет - просто массив блоков. Мега - всмысле ATmega8,16,32 и т.д. конструктив очень простой - мега, МАХ232, стабилизаторы 5В и 3.3В,цепь сброса, согласователь на резисторах для карты. разъем карты, разъем подключения. все вроде.
по идее протокол не может быть очень сложным?
диск с последовательным доступом вобщем.
сорри, не доступом, а интерфейсом:)
---------- Post added at 17:55 ---------- Previous post was at 17:46 ----------
у мну есть и КНГД и КНЖД, но они вместе с дисками довольно громоздки и не всегда удобны. а тут коробка с пол-пачки сигарет, грубо говоря. а если реализую поддержку FAT, так инфу с-на-карту будет ваще просто переносить:) (это я пока мечтаю) :)
по идее протокол не может быть очень сложным?Там ( см. приложение (http://zx.pk.ru/attachment.php?attachmentid=39010) ) всё элементарно. Из обработчика можно смело выкинуть запоминание входного потока для отправки терминалу в случае ошибочного опознавания, а всё остальное должно уложиться в несколько килобайт.
...
Описание и исходники протокола HX v2.2 (http://zx.pk.ru/showthread.php?t=20683)
...
Мои попытки подключить С2 к rs232:
1.Косичку спаял по схеме "минимальный"
2.На писюке проверил ком порт обычной ком-мышкой -все работает.
3.запустил гипертерминал на winXP SP3 ,настроил COM1.На УКНЦ запустил загрузку стык2 .На в окне терминала появился символ @
4.Запустить программу UkncComSender.exe - ошибка
http://i.piccy_.info/i7/2d95a675f3af54e118d36580c40e2bed/4-55-376/51216316/Bezymiannyi_240.jpg (http://piccy_.info/view3/3939379/4a86f531600f0d2d182e35bce0b6cc9d/)http://i.piccy_.info/a3/2013-01-05-13-07/i7-3939379/240x55-r/i.gif (http://i.piccy_.info/a3c/2013-01-05-13-07/i7-3939379/240x55-r)
Ага,запускается из этого поста http://zx.pk.ru/showpost.php?p=391152&postcount=23 Значит в 1 посте не актуальные версии программ?
http://piccy_.info/code2/3939397/9ace014d5d46d81b8e4cd10f9cfd95e0/
можно по пунктам что включить где скачать и что нажать?А пока пойду тему еще раз перечитывать - с первого раза что то не дочитал :)
4.Запустить программу UkncComSender.exe - ошибка
http://i.piccy_.info/i7/2d95a675f3af54e118d36580c40e2bed/4-55-376/51216316/Bezymiannyi_240.jpg (http://piccy_.info/view3/3939379/4a86f531600f0d2d182e35bce0b6cc9d/)http://i.piccy_.info/a3/2013-01-05-13-07/i7-3939379/240x55-r/i.gif (http://i.piccy_.info/a3c/2013-01-05-13-07/i7-3939379/240x55-r)
Ага,запускается из этого поста http://zx.pk.ru/showpost.php?p=391152&postcount=23 Значит в 1 посте не актуальные версии программ?
На контупере не нашлось подходящего runtime для той версии MSVC под которой собиралось.
Соберите из исходников: http://code.google.com/p/ukncbtl/source/browse/#svn%2Ftrunk%2Fsrc%2FUkncComSender
---------- Post added at 17:20 ---------- Previous post was at 17:16 ----------
http://piccy_.info/code2/3939397/9ace014d5d46d81b8e4cd10f9cfd95e0/
можно по пунктам что включить где скачать и что нажать?А пока пойду тему еще раз перечитывать - с первого раза что то не дочитал :)
UkncComSender.exe ожидает два параметра. Первый -- имя ком-порта, второй -- имя .SAV-файла. Судя по скриншоту, у вас что-то со вторым параметром -- например указан несуществующий файл.
UkncComSender писался как утилита для проверки Стык С2, контроль ошибок не на высоте.
получилось,дело в том что нужно распаковать папку с программкой из первого поста и заменить в этой папке EXE скаченный из поста №23 .
Было бы не плохо в 1 посте обновить файлы до актуальных версий и если нужно дополнить описание .А то сразу не въехал.
http://i.piccy_.info/i7/63b860fa4566ad61716bf3093b30d404/4-55-377/1009328/20130105_152841_375_240.jpg (http://piccy_.info/view3/3939411/0542714351f0b94dadc3d2a57cb952e8/)http://i.piccy_.info/a3/2013-01-05-13-21/i7-3939411/240x180-
r/i.gif (http://i.piccy_.info/a3c/2013-01-05-13-21/i7-3939411/240x180-r)
По варианту из этого поста http://zx.pk.ru/showpost.php?p=469503&postcount=101 дохожу до нажатия пробела на УКНЦ - нажимаю и дальше нечего не происходит.Ждал мин 15 -может дольше нужно ждать?
http://i.piccy_.info/i7/3b1f7793a52dab49ac298a50b8068fc9/4-55-377/50467672/55555_240.jpg (http://piccy_.info/view3/3939490/c346c8cc6ea14d933d451671d924bd7c/)http://i.piccy_.info/a3/2013-01-05-13-43/i7-3939490/240x150-r/i.gif (http://i.piccy_.info/a3c/2013-01-05-13-43/i7-3939490/240x150-r)
В архиве - HX_Server_05.01.13_17-04 (http://emulator.pdp-11.org.ru/misc/HX_Server_05.01.13_17-04.rar).
Номер используемого COM-порта PC нужно указать в файле UKNC_HX_COM.cfg, в разделе
[ComPort.ini]
PortName="COM1"
Настройки параметров COM-порта PC - в файле Terminal_ComPort_Adapter.ini.
...
Только вряд ли драйвер HX, который там используется, сможет нормально читать-писать через C2 УКНЦ, т.к. он настроен на адрес порта 177560.
Какой адрес порта С2 у УКНЦ ?
http://i.piccy_.info/i7/1334360fce9cef3d37d7aa8d2346eb4e/4-55-378/10504426/6666_240.jpg (http://piccy_.info/view3/3939545/c000c83c79ada1cb849200fdbe57fd2d/)http://i.piccy_.info/a3/2013-01-05-14-00/i7-3939545/240x181-r/i.gif (http://i.piccy_.info/a3c/2013-01-05-14-00/i7-3939545/240x181-r)http://i.piccy_.info/i7/a408b6d9d50403372127fc1760bbeb2c/4-55-378/14812165/20130105_160827_578_240.jpg (http://piccy_.info/view3/3939553/c4a4a01eb8c42f9c930b240c92b65b03/)http://i.piccy_.info/a3/2013-01-05-14-02/i7-3939553/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-05-14-02/i7-3939553/240x180-r)
У HX запрос протокола вылез на экран из-за того, что драйвер настроен на порт 177560.
Нужно сгенерить вариант драйвера HX.SYS для УКНЦ, подставив туда правильный адрес порта.
Кто знает адрес С2 у УКНЦ ?
У HX запрос протокола вылез на экран из-за того, что драйвер настроен на порт 177560.
Нужно сгенерить вариант драйвера HX.SYS для УКНЦ, подставив туда правильный адрес порта.
Кто знает адерес С2 у УКНЦ ?
176570 - 176577
Новый вариант - HX_Server_-_UKNC_05.01.13_17-04 (http://emulator.pdp-11.org.ru/misc/HX_Server_-_UKNC_05.01.13_17-04.rar)
Добавлены исходники драйвера HX.SYS.
Драйвер HX.SYS изменён для работы с портом 176570 .
Номер используемого COM-порта PC нужно указать в файле UKNC_HX_COM.cfg, в разделе
[ComPort.ini]
PortName="COM1"
Настройки параметров COM-порта PC - в файле Terminal_ComPort_Adapter.ini.
...
Где ХЭППИ ФИНАЛ ? Скриншот - с системой и игрушками )))
http://i.piccy_.info/i7/9803a20b6610e162481cfd93f1e6f389/4-55-379/49587048/1_240.jpg (http://piccy_.info/view3/3939759/596fb0902f013c316f41c23b5678a34d/)http://i.piccy_.info/a3/2013-01-05-15-08/i7-3939759/240x179-r/i.gif (http://i.piccy_.info/a3c/2013-01-05-15-08/i7-3939759/240x179-r)
http://i.piccy_.info/i7/8ec1259bc72c2c58d52e813759bd5781/4-55-379/53462746/2_240.jpg (http://piccy_.info/view3/3939765/f2a56ceb6818a2a767484409c5855447/)http://i.piccy_.info/a3/2013-01-05-15-09/i7-3939765/240x179-r/i.gif (http://i.piccy_.info/a3c/2013-01-05-15-09/i7-3939765/240x179-r)
http://i.piccy_.info/i7/2a8f326195f79f34c4bbe324c044d18e/4-55-379/56233519/3_240.jpg (http://piccy_.info/view3/3939772/f3946e55c7f51b09600b9028de286b74/)http://i.piccy_.info/a3/2013-01-05-15-10/i7-3939772/240x178-r/i.gif (http://i.piccy_.info/a3c/2013-01-05-15-10/i7-3939772/240x178-r)
Понятно, где собака порылась..
Загрузчик считывает значение R0 и использует его в качестве номера загружаемого юнита.
Решений два:
1. Как-то обнулить R0 перед запуском загрузчика.
2. Подключить загружаемый образ к тому приводу HX, куда по факту "смотрит" R0 ( на приведённом скриншоте это - HX2: ).
http://i.piccy_.info/i7/8ed3e7ec79f64217757bc5d2e03495e8/4-55-381/9958614/444444_240.jpg (http://piccy_.info/view3/3939920/119f19599ce96de1fa6894d4a5e283d3/)http://i.piccy_.info/a3/2013-01-05-15-44/i7-3939920/240x179-r/i.gif (http://i.piccy_.info/a3c/2013-01-05-15-44/i7-3939920/240x179-r)
На экране УКНЦ просто моргает курсор и надпись ЛАТ.
Сейчас отладочную версию загрузчика сделаю.
На экране УКНЦ просто моргает курсор и надпись ЛАТ.
что то не так, но прогресс на лицо! )
176570 - 176577
Мне кажется или проблема по прежнему в неправильном HX.SYS ?
Моя попытка "пересобрать" драйвер что-то не увенчалась
http://savepic.ru/3801061.png
---------- Post added at 20:07 ---------- Previous post was at 20:05 ----------
Я механизм не совсем вникаю, но вот файл HXBOOT это куда вообще лепиться?
И если лепиться, там же адреса внизу в последовательности строк с окончанием на м,
все ли правильные в случае с УК-НЦ ? )
Загрузчик считывает значение R0 и использует его в качестве номера загружаемого юнита.
Да, в этом случае у УКНЦ нет выбора, откуда грузиться. Либо при загрузке спрашивать, как драйвер жесткого диска WD, либо делать выбор в HX-сервере.
Кстати, все надписи, которые должны по идее выводиться на экран, благополучно выводятся в стык С2. Также я смог загрузиться только при выключенном сжатии.
Т.к. использую полный кабель с задействованными линиями CTS и RTS, то в ini-файле установил параметры fDtrControl=DTR_CONTROL_ENABLE и fRtsControl=RTS_CONTROL_ENABLE.
---------- Post added at 20:47 ---------- Previous post was at 20:16 ----------
Мои попытки подключить С2 к rs232:
1.Косичку спаял по схеме "минимальный"...
palsw, а как же она у Вас на УКНЦ заработала? Там же вход закрыт для посылок извне, надо на вход 7 (сигнал 109) подавать единицу и вход 8 (сигнал 107) на землю вешать, иначе посылки уходить не будут.
Хотелось бы увидеть схему кабеля.
Alex_K, схема кабеля из поста http://zx-pk.ru/showpost.php?p=392288&postcount=33
Ps:Спаять еще одну "косичку" дело 5 мин -например из этого поста http://zx.pk.ru/showpost.php?p=201649&postcount=520 но незнаю будет работать на моей плате (плата у меня с кварцами разбросанными по углам и 3 микросхемы ГФ24
файл HXBOOT это куда вообще лепиться?Это заготовка с простейшим загрузчиком HX - если кто-то захочет написать HXBOOT.SAV размером один блок, который можно будет загружать вместо нулевого блока образа и настраивать номер загружаемого привода в R0.
все надписи, которые должны по идее выводиться на экран, благополучно выводятся в стык С2. Также я смог загрузиться только при выключенном сжатии.Сделал отладочную версию HX_Server - UKNC_Test_1.0, где HX.SYS должен выводить сообщения на системный терминал ( в том числе кое-какие отладочные ) и сжатие в первичном драйвере выключено.
...
http://i.piccy_.info/i7/53bfe4e855d4746b427b20bcda28ad6c/4-55-383/30500974/11_240.jpg (http://piccy_.info/view3/3940193/bb6d7db28144d2729d43e5d3dccc2531/)http://i.piccy_.info/a3/2013-01-05-17-08/i7-3940193/240x179-r/i.gif (http://i.piccy_.info/a3c/2013-01-05-17-08/i7-3940193/240x179-r)
http://i.piccy_.info/i7/310595e1811fee06280bbc7c76ec26b5/4-55-383/30797454/22_240.jpg (http://piccy_.info/view3/3940195/5c2868ed7bb811489e959aa03a7ef06b/)http://i.piccy_.info/a3/2013-01-05-17-08/i7-3940195/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-05-17-08/i7-3940195/240x180-r)
http://i.piccy_.info/i7/dd0ce3c8eba801709f6690d65213ab7c/4-55-383/31954410/33_240.jpg (http://piccy_.info/view3/3940197/e040fa2c273d2f2cfdb66649217ab4f3/)http://i.piccy_.info/a3/2013-01-05-17-08/i7-3940197/240x179-r/i.gif (http://i.piccy_.info/a3c/2013-01-05-17-08/i7-3940197/240x179-r)
Сделал отладочную версию HX_Server - UKNC_Test_1.0 (http://zx.pk.ru/attachment.php?attachmentid=39135), где HX должен выводить сообщения на системный терминал ( в том числе кое-какие отладочные ) и сжатие в первичном драйвере выключено.
...
Ну, одна из главных проблем - на УКНЦ по умолчанию включен сетевой таймер, поэтому обычно в загрузчике ячейки 100 и 102 содержат 102 и 2 (RTI). По умолчанию сжатие включено. При выключенном таймере (там еще с помощью RESET надо сбросить запрос на прерывание) в конце-концов останавливается по адресу 177562.
В логе бесконечно пишет: "HX: READ: Unit:2 Block:2 WordCount:1024".
Сделал отладочную версию HX_Server - UKNC_Test_1.1 - в предыдущей версии в первичном драйвере использовался R4, что фатально влияло на BSTRAP..
...
Сделал отладочную версию HX_Server - UKNC_Test_1.1 (http://zx.pk.ru/attachment.php?attachmentid=39136). - в предыдущей версии в первичном драйвере использовался R4, что фатально влияло на BSTRAP..
...
Увы. При включенном таймере останавливается на ячейке 12. При выключенном и сброшенном таймере все также - лог забит сообщениями "HX: READ: Unit:2 Block:2 WordCount:1024".
---------- Post added at 21:51 ---------- Previous post was at 21:50 ----------
После долгих попыток остановился по адресу 160.
---------- Post added at 21:56 ---------- Previous post was at 21:51 ----------
palsw, по поводу TU58, попробуй спаяй кабель, как у меня (http://zx.pk.ru/showpost.php?p=201649&postcount=520). Соответственно UKNCComSender надо взять из того же сообщения. Т.к. кабель с контролем передачи, то контроль по DTR и RTS должен быть разрешен.
Сделал отладочную версию HX_Server - UKNC_Test_1.2 (http://emulator.pdp-11.org.ru/misc/HX_Server%20-%20UKNC_Test_1.2.rar) - теперь в первичном загрузчике HX.SYS установлен вектор 0100, а отладочные сообщения отключены.
...
Alex_K, я только что спаял еще одну "косичку" из поста http://zx.pk.ru/showpost.php?p=201649&postcount=520 TU58 отреагировала на нажатие клавиши пробел и загрузка пошла !
http://i.piccy_.info/i7/45131bad875e859a54b23327f76b7eee/4-55-385/52365723/20130105_202149_843_240.jpg (http://piccy_.info/view3/3940489/55a8a2f215df1f357bcfc27cdb3fb0ac/)http://i.piccy_.info/a3/2013-01-05-18-11/i7-3940489/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-05-18-11/i7-3940489/240x180-r)
Ура три раза! Всем ! Да здравствуют Ассемблер и Паяльник ! Patron, Alex_K - неоценимый вклад !
Теперь веб-архив по настоящему полезен становиться ! )))
palsw, теперь просто или на системную дискету или (а есть возможность работать с ещё одной дискетой при таком варианте загрузки?) любые тестовые программы для УК-НЦ !
"Поехали"
http://i.piccy_.info/i7/d57bbf58cbea364c836a2431deca7b5f/4-55-386/5260049/20130105_202820_484_240.jpg (http://piccy_.info/view3/3940530/6bdc4e82c1cbe54009b1765b659506da/)http://i.piccy_.info/a3/2013-01-05-18-17/i7-3940530/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-05-18-17/i7-3940530/240x180-r)
---------- Post added at 21:19 ---------- Previous post was at 21:18 ----------
Patron, работает только на минимальном варианте "Косички" - на полном варианте даже не реагирует на загрузку С2
А не шлёт ли мой вариант UKNCcomSender один лишний байт..
Сделал отладочную версию HX_Server - UKNC_Test_1.3 (http://emulator.pdp-11.org.ru/misc/HX_Server%20-%20UKNC_Test_1.3.rar) - теперь перед приёмом пакета первичный драйвер пропускает лишние байты, если их шлёт UKNCcomSender.
...
работает только на минимальном варианте "Косички" - на полном варианте даже не реагирует на загрузку С2При использовании дополнительных сигналов надо изменить настройки COM-порта PC в файле Terminal_ComPort_Adapter.ini
---------- Post added at 21:25 ---------- Previous post was at 21:23 ----------
При использовании CTS и RTS, в файле Terminal_ComPort_Adapter.ini нужно установить параметры
fDtrControl = DTR_CONTROL_ENABLE
fRtsControl = RTS_CONTROL_ENABLE
Patron, кстати ошибка в драйвере HX.SYS.
Вместо:
TTKS =: TT.CSR
TTKB =: TKS +2
TTPS =: TKS +4
TTPB =: TKS +6
надо
TTKS =: TT.CSR
TTKB =: TTKS +2
TTPS =: TTKS +4
TTPB =: TTKS +6
а то надписи все так и не выводятся на экран.
А не шлёт ли мой вариант UKNCcomSender один лишний байт..
Сделал отладочную версию HX_Server - UKNC_Test_1.3 (http://zx.pk.ru/attachment.php?attachmentid=39136) - теперь перед приёмом пакета первичный драйвер пропускает лишние байты, если их шлёт UKNCcomSender.
...
http://i.piccy_.info/i7/ed7abd5849edc89e50adc16fd2b8fd6d/4-55-386/26261749/20130105_203948_562_240.jpg (http://piccy_.info/view3/3940570/e000564f212b5099c14966b31c36a16f/)http://i.piccy_.info/a3/2013-01-05-18-29/i7-3940570/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-05-18-29/i7-3940570/240x180-r)
работает
ошибка в драйвере HX.SYS - надписи все так и не выводятся на экран.Горе мне - никудышний я программист :)
Щас попробую всё сделать как надо..
[/COLOR]При использовании CTS и RTS, в файле Terminal_ComPort_Adapter.ini нужно установить параметры
fDtrControl = DTR_CONTROL_ENABLE
fRtsControl = RTS_CONTROL_ENABLE
изменил конфиг - грузится теперь на полной версии "косички"
Пожалуйста прилепите именно тот образ дискеты который с HX.SYS для УК-НЦ после внесения всех поправок - что бы был в теме и для меня ! ) На основе этой дискеты
можно сборник тестов или игрушек сделать попробовать и ещё в силе вопрос о возможности обращения ко второму устройству? (второй дискете?)
В приложении - HX_Server_-_UKNC_05.01.13_22-47.
Номер используемого COM-порта PC нужно указать в файле UKNC_HX_COM.cfg, в разделе
[ComPort.ini]
PortName = "COM1"
Настройки параметров COM-порта PC - в файле Terminal_ComPort_Adapter.ini.
...
Теперь сжатие по умолчанию включено, а режим сжатия запоминается от запуска к запуску
[HX.ini]
InitialStateOf[PackData] = 1
SaveChangesFor[PackData] = 1
...
Есть еще ошибка. Попробовал я после загрузки просканировать диск с помощью команды DIR/BAD/FIL. В итоге долго и упорно грузился DUP, потом после запроса 18432 слов с блока 0, сразу же запросилось 256 слов с блока 0 и 2048 слов с блока 417, ну и монитор вылетел в пультовый отладчик с сообщением, что "?MON-F-System read failure halt". В регистре 176570 установлен бит 12 - ошибка переполнения.
---------- Post added at 23:28 ---------- Previous post was at 23:02 ----------
Загрузил версию RT-11 V05.07, памяти она жрет больше, поэтому по команде DIR/BAD/FIL захватывается только 16128 слов. Складывается впечатление, что если запрашивается больше 16384 слов, то возникает ошибка.
Есть еще ошибка.По счастью - эта ошибка у меня воспроизводится в точности, поэтому - вскоре я её устраню.
При включенном сжатии ошибка пока не проявилась ( команда ещё выполняется - DUP прочитал уже 7 раз по 18432 ).
Возможно, тут дело в том, что сжатие получилось очень сильным и реальных байтов передаётся мало.
---------- Post added at 22:37 ---------- Previous post was at 22:33 ----------
.DIR/BAD/FIL
?DUP-I-No bad blocks detected HX0:
http://emulator.pdp-11.org.ru/misc/Dir-Bad.png
При включенном сжатии ошибка пока не проявилась ( команда ещё выполняется - DUP прочитал уже 7 раз по 18432 ).
Возможно, тут дело в том, что сжатие получилось очень сильным и реальных байтов передаётся мало.
А УКНЦ при включенном сжатии не работает. Загрузил систему без сжатия, потом включил его. Чуть-чуть прочиталось и на этом все остановилось. При этом даже не работает перезапуск с адреса 0, вываливается в пультовый отладчик с сообщением о невозможности прочесть систему. После отключения сжатия перезапуск по нулевому адресу прошел нормально.
Есть тут еще проблема. Все дело в том, что на 1801ВП1-065 контроль линий передачи аппаратный, а на PC он программный. Соответственно после того как с на УКНЦ мы вывалились в пульт, то PC может послать очередной байт, и соответственно возникнет ошибка переполнения. Приходится в пультовом отладчике много раз читать регистр 176572, до тех пор, пока его значение не устаканится, т.е. с PC больше ничего не идет. После этого и перезапуск с нулевого адреса нормально проходит. Поэтому неплохо было бы в сервере сделать контроль по тайм-ауту, если пауза большая, то прерывать передачу и входить в режим восстановления связи.
В приложении - HX_Server_-_UKNC_06.01.13_00-18.
Номер используемого COM-порта PC нужно указать в файле UKNC_HX_COM.cfg, в разделе
[ComPort.ini]
PortName = "COM1"
Настройки параметров COM-порта PC - в файле Terminal_ComPort_Adapter.ini.
...
Проблема была в драйвере HX.SYS - при чтении несжатых данных с размером пакета > 32767.
...
неплохо было бы в сервере сделать контроль по тайм-ауту, если пауза большая, то прерывать передачу и входить в режим восстановления связи.Это невозможно.
Но при посылке Break все буфера очищаются. Посылать Break в мультиплексор HX пока можно только с терминала ( кнопкой клавиатуры [Pause/Break] ).
Чтобы подключить к мультиплексору HX терминал - нужно добавить следующие строки в разделы UKNC_HX_COM.cfg:
[modules]
Terminal_module = Terminal_module.em
[objects]
VT52 = Terminal_module:Terminal
[links]
HX [TTY] <==> VT52
Можно ещё добавить секцию настроек для терминала:
[VT52.ini]
TabTitle=""
nFocusOnFirstOutput = 1
CURSOR_Y_START_% = 85
TerminalStatusBar_Part[CPS_Limit]= nPosition[2] | nPriority[6] | bHidden[1]
InitialStateOf[RusKeys] =1
SaveChangesFor[RusKeys] =0
InitialStateOf[GoldMode]=0
SaveChangesFor[GoldMode]=0
InitialStateOf[Log] =0
SaveChangesFor[Log] =0
InitialStateOf[Lc] =0
SaveChangesFor[Lc] =0
InitialStateOf[Bold]=0
SaveChangesFor[Bold]=0
InitialStateOf[RusLat]=0
SaveChangesFor[RusLat]=0
FontSize =0
FontFace ="Courier New"
bFontAntialiasDisable = 1
InitialStateOf[StatusBar] = 0
SaveChangesFor[StatusBar] = 0
InitialStateOf[ControlBar] = 0
SaveChangesFor[ControlBar] = 0
InitialStateOf[TerminalStatusBar]= 1
SaveChangesFor[TerminalStatusBar]= 0
InitialStateOf[SlowMultiByte]=1
SaveChangesFor[SlowMultiByte]=0
Cursor_OFF_Latency_MS=30
Проблема была в драйвере HX.SYS
Образ дискеты с поправленным 100% драйвером просьба отдельно прилепить в этой теме к любому сообщению )
Проблема была в драйвере HX.SYS - при чтении несжатых данных с размером пакета > 32767.
Да, проблема исчезла. Команда DIR/BAD/FIL отработала без проблем. Далее я решил нагрузить канал командой DIFF/BIN/DEV HX0: HX1:. Удивительно то, что BINCON не запросил размер дисков, ну да ладно. Более удивительно, когда BINCON полез за границу диска, т.е. запрашивал номер блока, больше чем 1600. Со стороны HX-сервера соответственно была ошибка "HX:ReadDSK -- ОШИБКА". Далее был запрос блоков 417 (длина 2048 слов) и 401 (длина 6144). Во время этого чтения возникла ошибка TRAP10 по адресу 157520. Соответственно код там такой:
157512: 122323 CMPB (R3)+,(R3)+
157514: 004767 CALL 157002
157516: 177262
157520: 005303 DEC R3
157522: 001375 BNE 157516
Этому соответствует код из драйвера:
Skip:
CmpB (R3)+, (R3)+ ; R3 += 2;
Call ChIn
SOB R3, .-4. ; Get packet bytes.
Но в данном драйвере SOB является макросом, поэтому конструкция ".-4." срабатывает не на начале макроса, а на команде BNE, поэтому переход осуществляется не на команду CALL, а на ее аргумент, отсюда и TRAP10.
Можно ситуацию убыстрить командой DIFF/BIN/DEV HX0:/ST:1590. HX1:/ST:1590..
SOB является макросомСупер-ошибка, сейчас исправлю.
Кстати, т.к. сервер выполняет атомарные операции, то лучший способ всё сбросить - перезапустить сервер.
Теперь при запуске сервера он будет чистить выходной буфер COM-порта, но не трогать входной, поэтому (по идее) сервер можно будет запускать даже после отправки запроса драйвером ( типа, срубать сервер после начала показа каждого блока дампа по команде DUMP/TERM HX0:, а когда драйвер HX.SYS посылает запрос чтения следущего блока - опять запускать сервер и всё должно работать ).
В архиве - HX_Server_-_UKNC_06.01.13_02-23 (http://emulator.pdp-11.org.ru/misc/HX_Server_-_UKNC_06.01.13_02-23.rar)
Номер используемого COM-порта PC нужно указать в файле UKNC_HX_COM.cfg, в разделе
[ComPort.ini]
PortName = "COM1"
Настройки параметров COM-порта PC - в файле Terminal_ComPort_Adapter.ini.
...
- Исправлен SOB-bug ( надеюсь );
- Теперь при запуске сервера выходной буфер COM-порта очищается, а входной - нет.
...
Мне видится следующее:
1. Проблемы с использованием сжатия вызваны тем, что драйвер распаковывает сжатые данные в момент поступления, поэтому при большом сжатии, большой скорости порта и медленном процессоре - "онлайновая" распаковка невозможна ( PDP-11/83 на скрости порта 9600 справляется без проблем ). Думаю, если разработать комбинированный "онлайн-офлайновый" алгоритм распаковки - максимальное сжатие в протоколе HX v2.0 можно будет увеличить с 256 до 65535.
2. Без использования сжатия - драйвер HX уже сейчас способен работать по двухпроводной линии без квитирования почти на любом процессоре и любой скорости порта. Максимальное количество байтов в секунду, которое может принимать драйвер зависит (конечно же) от скорости процессора и типа операционки ( при поддержке очереди таймера в ядре RT-11 - максимальная продолжительность критического цикла драйвера, выполняемого при получении каждого байта данных - увеличивается на добрую сотню команд ). Для точного определения максимальной скорости RAW-обмена в HX, в зависимости от используемого процессора и операционки - есть смысл написать тестовую программу HXTST.SAV.
3. Для начальной загрузки с HX0 можно сделать специализированную разновидность Boot-блока HX - BotHX0.bin, при передаче которого в УКНЦ - UKNCcomSender будет впечатывать в него дату и время сервера в формате RT-11 для установки в процессе загрузки.
4. Если научить UKNCcomSender реагировать на произвольно задаваемый промпт, то возможно его совместное использование с ODT_Loader для установки времени сервера в RT-11 при загрузке с HX0 ( при помощи BotHX0.bin ) на ДВК / PDP-11 ( и других компьютерах с Micro-ODT ).
5. В протоколе HX v1.1 не поддерживается формирование ( на стороне сервера ) и использование ( на стороне драйвера ) признака конца файла при операциях вблизи и за пределами границы образа. Исправить это можно и нужно в протоколе HX v2.0.
1. Проблемы с использованием сжатия вызваны тем, что драйвер распаковывает сжатые данные в момент поступления, поэтому при большом сжатии, большой скорости порта и медленном процессоре - "онлайновая" распаковка невозможна ( PDP-11/83 на скрости порта 9600 справляется без проблем ). Думаю, если разработать комбинированный "онлайн-офлайновый" алгоритм распаковки - максимальное сжатие в протоколе HX v2.0 можно будет увеличить с 256 до 65535.
Драйвер можно написать с использованием прерываний. Это правда невозможно, когда для HX используется порт терминала. В случае отдельного канала, как стык С2 на УКНЦ - это возможно. Правда придется вводить приемный буфер и усложнять драйвер. Другой вариант - при поступлении запакованных данных передачу со стороны сервера прекратить и возобновить после того, как HX-драйвер подтвердил, что данные распокавал и можно передавать дальше.
3. Для начальной загрузки с HX0 можно сделать специализированную разновидность Boot-блока HX - BotHX0.bin, при передаче которого в УКНЦ - UKNCcomSender будет впечатывать в него дату и время сервера в формате RT-11 для установки в процессе загрузки.
Здравая мысль. В этот блок еще надо добавить и номер загружаемого устройства.
4. Если научить UKNCcomSender реагировать на произвольно задаваемый промпт, то возможно его совместное использование с ODT_Loader для установки времени сервера в RT-11 при загрузке с HX0 ( при помощи BotHX0.bin ) на ДВК / PDP-11 ( и других компьютерах с Micro-ODT ).
Ну это будет работать только на ДВК и других PDP-11. На УКНЦ регистры терминала внутренние и никуда наружу не выводятся.
5. В протоколе HX v1.1 не поддерживается формирование ( на стороне сервера ) и использование ( на стороне драйвера ) признака конца файла при операциях вблизи и за пределами границы образа. Исправить это можно и нужно в протоколе HX v2.0.
Насколько я помню признак EOF$ монитором SJ не поддерживается. Так написано у меня в книге "Макроассемблер в среде ОС ДВК". Но эта книга еще про 4-ю версию системы, может в пятой и поддержали окончательно, надо читать документацию.
Кстати BINCOM запросил таки размер диска, но уже после того как получил ошибку о том, что невозможно считать блок 1621. Ну что делать, так BINCOM написан.
Драйвер можно написать с использованием прерываний.Это не решит проблему, т.к. распаковка может занимать относительно много времени и никакого внутреннего буфера драйверу не хватит. Но я уже придумал как можно работать со сжатыми и несжатыми данными на одинаковой скорости и без использования большого дополнительного кода ( идея тянет на нобелевскую премию по программированию ).
признак EOF$ монитором SJ не поддерживается. Так написано у меня в книге "Макроассемблер в среде ОС ДВК"Наичная с 5-й версии (насколько я понимаю) все драйвера выдают признак конца файла при попытке работы за пределами устройства.
Вот как, например, выглядит соответствующее место в драйвере псевдоустройства HD из "эмулятора ДВК":
HDREAD:
Mov R1, @#HD$CSR+2 ;
Mov #SetWCn, @#HD$CSR ; Set word count
Tst @#HD$CSR ; Valid?
BPl 5$ ; Yes - OK
Mov HDCQE, R4 ;
BiS #EOF$, @-(R4) ; Else - set EOF bit
5$:
Mov #CmdRea, @#HD$CSR ; Make Read from HD
Программа TSTHX.SAV (http://zx.pk.ru/attachment.php?attachmentid=39161) крутит в цикле ядро драйвера HX.SYS, считая "обороты" и позволяя таким образом определить ту максимальную битовую скорость порта ( в BPS ), на которой драйвер HX.SYS сможет рботать в данной системе по двухпроводной линии без потери байтов.
Для эмулируемой ДВК-1 результаты следующие:
.SH CON
RT-11SJ (Y) V05.04 G
Booted from HD0:RT11SJ
USR is set SWAP
EXIT is set SWAP
KMON is set NOIND
TT is set NOQUIET
ERROR is set ERROR
SL is set ON
EDIT is set KED
KMON nesting depth is 3
LSI 11 or PDP 11/03 Processor
56KB of memory
Extended Instruction Set (EIS)
Floating Instruction Set (FIS)
50 Cycle System Clock
No SYSGEN options enabled
.RU HXTST
HXTST - Check HX port READ speed v1.0
Max HX Port BPS for this OS & CPU: 59'994
Program completed.
RT-11SB (S) V05.07
Booted from HD1:RT11SB
USR is set SWAP
EXIT is set SWAP
KMON is set NOIND
MODE is set NOSJ
TT is set NOQUIET
ERROR is set ERROR
SL is set ON
EDIT is set K52
FORTRAN is set FORTRA
KMON nesting depth is 3
Global .SCCA flag is disabled
CLI is set DCL, CCL, UCL, NO UCF
LSI 11 or PDP 11/03 Processor
56KB of memory
Extended Instruction Set (EIS)
Floating Instruction Set (FIS)
50 Hertz System Clock
SB timer support
Global .SCCA support
.RU HXTST
HXTST - Check HX port READ speed v1.0
Max HX Port BPS for this OS & CPU: 24'610
Program completed.
Понятно, что даже на самых медленных машинах HX.SYS (без использования сжатия) может работать без потери байтов.
Как и предполагалось - в системах с поддержкой очереди таймера быстродействие падает многократно.
...
У меня на УКНЦ скорость в пределах 12400-12500. Скорость порта 9600, 8N2.
У меня на УКНЦ скорость в пределах 12400-12500. Скорость порта 9600, 8N2.1200 циклов чтения порта в секунду ( значение BPS тест получает, умножив на 2 число циклов чтения порта за 5 сек ) - что-то маловато. Может, тест врёт.. ( Там, кстати, ошибка есть, правда не принципиальная - вместо тестируемого порта идёт обращение к ячейке ОЗУ с адресом этого порта - но вряд ли это может снизить скорость тестируемого кода ).
Такое впечатление, будто на векторе таймера куча всего сидит.
А монитор при этом как сгенерён, есть там SJ timer support или SB timer support, что по SH CON пишет ?
А монитор при этом как сгенерён, есть там SJ timer support или SB timer support, что по SH CON пишет ?
Используется образ HXsys54.DSK, который идет в комплекте с HX-сервером. Перекопировал туда HXTST, там и запускаю. По SHOW CONF пишет, что "No SYSGEN options enabled". Да и п/п обработки прерывания таймера состоит из двух команд ADC и одной RTI.
Попробуем начать с малого - без учёта негативного влияния прерываний на процесс чтения порта драйвером HX.SYS.
В приложении - HXUCPS.SAV - тест числа чтений порта 176570 драйвером HX.SYS в секунду (http://zx.pk.ru/attachment.php?attachmentid=39167) ( т.е. измеряется CPS ).
На эмулируемой ДВК-1 результат во всех мониторах такой:
.RU HXUCPS
HXUCPS - Check HX port 176570 READ speed v1.0
Max HX Port CPS for this OS & CPU: 13'063
Program completed.
...
Попробуем начать с малого - без учёта негативного влияния прерываний на процесс чтения порта драйвером HX.SYS.
В приложении - HXUCPS.SAV - тест числа чтений порта 176570 драйвером HX.SYS в секунду (http://zx.pk.ru/attachment.php?attachmentid=39167) ( т.е. измеряется CPS ).
Результат - от 16630 до 16660.
Результат - от 16630 до 16660.Когда УКНЦ обгоняет ДВК-1 - это больше похоже на правду.
Но где же происходит такое резкое падение быстродействия ( если это был не глюк ).
Попробуем добавить в цикл подготовку вызова обработчика прерывания таймера - см. HXUCPS.SAV v1.1 (http://zx.pk.ru/attachment.php?attachmentid=39168)
На эмулируемой ДВК-1 результат такой:
.RU HXUCPS
HXUCPS - Check HX port 176570 READ speed v1.1
Max HX Port CPS for this OS & CPU: 9'822
Program completed.
Попробуем добавить в цикл подготовку вызова обработчика прерывания таймера - см. HXUCPS.SAV v1.1 (http://zx.pk.ru/attachment.php?attachmentid=39168)
Результат - от 12850 до 12950.
Результат - от 12850 до 12950.УКНЦ уверенно лидирует.
Теперь добавим в цикл вызов обработчика прерывания таймера через JMP - см. HXuCPSv1.2 (http://zx.pk.ru/attachment.php?attachmentid=39170)
На ДВК-1 в базовом мониторе это выглядит так:
.RU HXUCPS
HXUCPS - Check HX port 176570 READ speed v1.2
Max HX Port CPS for this OS & CPU: 7'598
Program completed.
УКНЦ уверенно лидирует.
Теперь добавим в цикл вызов обработчика прерывания таймера через JMP - см. HXuCPSv1.2 (http://zx.pk.ru/attachment.php?attachmentid=39170)
У меня получаются только два варианта - 9915 и 9925. Иногда, редко очень, проскакивают 9914 и 9926.
У меня получаются только два варианта - 9915 и 9925. Иногда, редко очень, проскакивают 9914 и 9926.Похоже, что революция отменяется и ДВК-1 так и не обгонит УКНЦ..
Для окончательного теста - заменим вызов обработчика прерывания через JMP на вызов через RTI - см. HXuCPSv1.3 (http://zx.pk.ru/attachment.php?attachmentid=39171)
.RU HXUCPS
HXUCPS - Check HX port 176570 READ speed v1.3
Max HX Port CPS for this OS & CPU: 6'476
Program completed.
Похоже, что революция отменяется и ДВК-1 так и не обгонит УКНЦ..
Для окончательного теста - заменим вызов обработчика прерывания через JMP на вызов через RTI - см. HXuCPSv1.3 (http://zx.pk.ru/attachment.php?attachmentid=39171)
Результат - от 8345 до 8357.
Результат - от 8345 до 8357.Получается, что за секунду драйвер HX.SYS успевает сделать на УКНЦ более 8000 полных "оборотов" ( что соответствует скорости порта ~ 82'000 BPS ), а это значит, что даже если переделать С2 на скорость 57'600 BPS - быстродействия HX.SYS + УКНЦ вполне хватит для синхронной ( без квитирования ) работы даже по простой витой паре.
Получается, что за секунду драйвер HX.SYS успевает сделать на УКНЦ более 8000 полных "оборотов" ( что соответствует скорости порта ~ 82'000 BPS ), а это значит, что даже если переделать С2 на скорость 57'600 BPS - быстродействия HX.SYS + УКНЦ вполне хватит для синхронной ( без квитирования ) работы даже по простой витой паре.
Вся соль ситуации в том, что квитирование особо не помогает. Т.к. на PC оно реализовано программно, плюс еще буфера FIFO (хоть и отключенные), но все равно бывают ошибки переполнения. А ведь если с регистра данных не прочли еще эти данные, то на выходе RR 1801ВП1-065 должен быть неактивный уровень, и по идее противоположная сторона не должна осуществлять передачу. Но увы, передача осуществляется.
противоположная сторона не должна осуществлять передачу. Но увы, передача осуществляется.Настройки адаптера COM-порта полностью соответствуют DCB structure (http://msdn.microsoft.com/ru-ru/library/windows/desktop/aa363214(v=vs.85).aspx). Там куча всяких параметров, неужели ни один не годится..
В принципе - Windows позволяет программно анализировать состояние CTS и DSR и программно изменять RTS и DTR.
А 1801ВП1-065 позволяет "своим" программам то же самое ?
---------- Post added at 22:15 ---------- Previous post was at 22:05 ----------
Что-то мне подсказывает, что параметры
fOutxCtsFlow = FALSE
fOutxDsrFlow = FALSE
могут помочь, если их значение изменить на TRUE
fOutxCtsFlow
If this member is TRUE, the CTS (clear-to-send) signal is monitored for output flow control. If this member is TRUE and CTS is turned off, output is suspended until CTS is sent again.
fOutxDsrFlow
If this member is TRUE, the DSR (data-set-ready) signal is monitored for output flow control. If this member is TRUE and DSR is turned off, output is suspended until DSR is sent again.
---------- Post added at 22:18 ---------- Previous post was at 22:15 ----------
При включённом квитировании - режим сжатия должен заработать без проблем.
Настройки адаптера COM-порта полностью соответствуют DCB structure (http://msdn.microsoft.com/ru-ru/library/windows/desktop/aa363214(v=vs.85).aspx). Там куча всяких параметров, неужели ни один не годится..
В принципе - Windows позволяет программно анализировать состояние CTS и DSR и программно изменять RTS и DTR.
А 1801ВП1-065 позволяет "своим" программам то же самое ?
Во всяком случае проверял в гипертерминале - там все нормально, жму клавишу, на УКНЦ устанавливается бит готовности, но регистр данных не читаю. Жму вторую клавишу, в регистре состояния на УКНЦ никаких ошибок, соответственно и второй символ не передается. Но тут большая пауза между передачей первого и второго символа, а в HX-сервере все льется сплошным потоком, может как-то Windows все это дело плохо отслеживает, хотя в настройках COM-порта буфера FIFO у меня отключены, сам порт реально железный, не переходник на USB. Вот как точно настроить DCB-структуру, чтобы соответствовала аппаратному контролю передачи в гипертерминале?
У 1801ВП1-065 только две линии контроля передачи, которые соответствуют CTS и DSR. Выходная линия RR (receiptor ready) - готовность приемника, означающая, что буферный регистр приемника пуст и противоположная сторона может осуществлять передачу. Входная линия BSYD - приемник на той стороне не готов, если стоит неактивный высокий уровень, то 1801ВП1-065 не будет осуществлять передачу, станет уровень активным низким - посылка пойдет в линию. Соответственно контроль полностью аппаратный, ни на какие битики в регистрах состояния эти линии не выводятся, ну и их состояние никак не изменить программно. Если надо осуществлять прием-передача без квитирования, то BSYD вешается на землю, а RR должен висеть в воздухе.
---------- Post added at 23:24 ---------- Previous post was at 23:20 ----------
Что-то мне подсказывает, что параметры
fOutxCtsFlow = FALSE
fOutxDsrFlow = FALSE
могут помочь, если их значение изменить на TRUE
Сейчас попробую.
Сейчас попробую.Если у 1801ВП1-065 только одна выходная линия квитирования, то надо только какой-то один параметр активировать ( который этой линии соответствует ).
Попробовал всякие варианты, и с HANDSHAKE. Увы, ситуация не изменилась.
Если у мультиплексора HX подключить к сокету [TTY] консоль или терминал - можно будет неторопясь нажимать пробел и анализировать бит Overrun в порту при разных настройках.
При этом интересная ситуация. Я выхожу в пультовый отладчик, в регистре состояния соответственно ошибка переполнения. Читаю регистр данных, HX-сервер показывает, что пересылает два байта, ну и соответственно также ошибка переполнения. Получается, что Windows чувствует эти сигналы управления, но как-то их не так обрабатывает, то ли 1801ВП1-065 поздно снимает сигнал RR, то ли Windows сразу же читает состояние линий, а там еще только старт-бит поехал.
Даже если просто заменить
[links]
ComPort > Port_Dumpна
[links]
ComPort <=> Port_Dumpможно будет из окна Port_Dump посылать нажатия прямо в COM-порт.
если доступно напишите как загрузить и запустить HXUCPS.SAV - охотно протестирую :)
Попробовал снова в гипертерминале, но уже нажал стрелку, она же два кода посылает в режиме VT-52. Ну и соответственно схватил ошибку переполнения. Так что все дело в Windows, как она работает с этими сигналами, хотя может дело и в 1801ВП1-065, неизвестно когда она снимает сигнал RR - при получении стартового бита, или уже при получении стопового, когда байт фактически сформирован.
все дело в WindowsМне кажется, что всё дело может быть в отключенных буферах FIFO. Когда лишний байт негде "заначить" - его приходится передавать.
---------- Post added at 23:19 ---------- Previous post was at 23:17 ----------
если доступно напишите как загрузить и запустить HXUCPS.SAV - охотно протестируюНужно на сервере подключить образ из архива к свободному приводу HX и запустить в RT-11 с этого привода HX файл HXUCPS.SAV
---------- Post added at 23:20 ---------- Previous post was at 23:19 ----------
Или плагином скопировать нужный файл на образ системного диска и запустить оттуда.
Patron, образ то я подключил ,а какую команду запуска писать на укнц?
Ps:эта архитектура для меня темный лес - только начал читать литературу
Если образ ( например ) подключен к HX0, то команда будет
RUN HX0:HXUCPS
Мне кажется, что всё дело может быть в отключенных буферах FIFO. Когда лишний байт негде "заначить" - его приходится передавать.
Не в этом дело, переполнение на стороне УКНЦ. Просто при включенном FIFO со стороны PC можно заполнить буфера с большой скоростью, а потом данные оттуда будут уходить. А ведь сам чип не следит за сигналами, поэтому данные уходят друг за другом, а если на УКНЦ данные не считываются (находимся в пультовом отладчике), то отсюда и переполнение - не успели считать регистр данных, а тут еще прислали очередную порцию. Так что при отключенном FIFO хоть один байт потеряется.
Кстати для информации биты ошибок приемника в 1801ВП1-065 (для УКНЦ это регистр 176570):
15 бит - ошибка паритета. Устанавливается при установленном контроле по четности/нечетности если получен байт с ошибкой.
12 бит - ошибка переполнения. Возникает если получена очередная посылка, а предыдущая не была считана (т.е. был установлен бит готовности 7), посылка теряется.
0 бит - ошибка в стоповом бите. Возникает обычно, когда по линии посылают сигнал BREAK, при этом в регистре данных должно быть число 0 (ноль).
Сбрасываются эти биты ошибок при чтении регистра данных, ну и по сигналу INIT.
Результат - от 8345 до 8357.
результат
http://i.piccy_.info/i7/fa2efe7cbb1a701cd4c392ee05c2f229/4-55-419/56668934/20130106_230324_390_240.jpg (http://piccy_.info/view3/3945138/9212523dfc2b498740421319a396f53e/)http://i.piccy_.info/a3/2013-01-06-20-52/i7-3945138/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-06-20-52/i7-3945138/240x180-r)
Круто - можно смело включать повышенную скорость.
Чтобы задать в порту С2 максимальную для него скорость 57'600 BPS - нужно сделать следующее (http://www.phantom.sannata.ru/forum/index.php?t=2348&a=stdforum_view&o=&st=189).
---------- Post added at 00:15 ---------- Previous post was at 00:12 ----------
сам чип не следит за сигналамиТочно? Как тогда вообще что-то на PC может работать..
Может, разок включить у PC буфера FIFO и сравнить, как обмен будет работать..
Точно? Как тогда вообще что-то на PC может работать..
Может, разок включить у PC буфера FIFO и сравнить, как обмен будет работать..
Включал, картина не меняется. На современных PC огромная скорость процессора, все успевает обрабатываться. К тому же в Windows порты работают в режиме прерываний и полученные символы сохраняются в буфере, а далее функции чтения COM-порта читают из этого буфера.
Интересно, сколько тактов должно пройти после установки бита готовности в регистре статуса чтения 1801ВП1-065, чтобы он снял сигнал квитирования.
в Windows порты работают в режиме прерываний
http://www.usrmodem.ru/serialsys.shtml )
результат
Очень впечатляющий скриншот! )
Интересно, сколько тактов должно пройти после установки бита готовности в регистре статуса чтения 1801ВП1-065, чтобы он снял сигнал квитирования.
А вот это и я хотел бы узнать, в какой момент этот сигнал снимается, в самом начале получения или после.
Хотя по документации на КТЛК (где употребляются тоже 1801ВП1-065) он снимается после получения последнего бита посылки, во время первого стоп-бита.
---------- Post added at 01:49 ---------- Previous post was at 01:44 ----------
Как вариант можно попробовать устанавливать размер FIFO в 1 байт, хотя есть подозрения что эта настройка будет проигнорирована...
Увы, и отключение буфера FIFO не помогает. А так anonymous все верно описал, теперь и я вспомнил, что когда-то он ругался на PC-шные COM-порты. Так что только передавать по одному байту, а после передачи байта читать линии квитирования, но это затормозит передачу.
А вот это и я хотел бы узнатьЕсли точно знать - можно модифицировать драйвер HX.SYS так, чтобы он вызывал снятие квитирования ещё на синхронном этапе работы - тогда потеря байтов не возникнет, но сервер сможет перейти в режим программной поддержки квитирования, не отправляя ни одного байта без "разрешения" от 1801ВП1-065.
Если точно знать - можно модифицировать драйвер HX.SYS так, чтобы он вызывал снятие квитирования ещё на синхронном этапе работы - тогда потеря байтов не возникнет, но сервер сможет перейти в режим программной поддержки квитирования, не отправляя ни одного байта без "разрешения" от 1801ВП1-065.
По документации - при приеме стоп-бита. Т.е. это отослали байт данных в регистр, подождали время, пока он передается, а уже после опросили линии квитирования. Тормоза будут жуткие. Если под DOS, то там пока байт не уйдет весь в линию, также не будет установлен бит готовности, а в Windows работать напрямую с аппаратурой нельзя.
Может я и не прав, но попробую посмотреть на это с другой стороны.
palsw, а как же она у Вас на УКНЦ заработала? Там же вход закрыт для посылок извне, надо на вход 7 (сигнал 109) подавать единицу и вход 8 (сигнал 107) на землю вешать, иначе посылки уходить не будут.
Alex_K, схема кабеля из постаhttp://zx-pk.ru/showpost.php?p=392288&postcount=33
плюс вот эта ссылка
http://www.phantom.sannata.ru/forum/index.php?t=2348&a=stdforum_view&o=&st=189
таким образом как минимум у троих эта схема работает. Теперь прошу обратить внимание что работает при условии замыкания со стороны УКНЦ трех сигналов, что зеркально напоминает три соединенных сигнала со стороны РС, так может быть на УКНЦ выведены не те сигналы на С2, а те которые нужны для RTS CTS как раз и висят один на земле а другой +5 см. (последнюю ссылку первый пост)
Да вот еще у себя нашел "ГОСТ 18145-81 Цепи на стыке С2 аппаратуры передачи данных с оконечным оборудованием при последовательном вводе-выводе данных" см. вложение.
Если коротко то вот:
Настоящий стандарт распространяется на цепи стыка С2 между
оконечным оборудованием данных (ООД) и аппаратурой передачи данных (АПД)
при последовательном вводе — выводе данных
Цепь 105. Запрос передачи
Направление — к АПД.
Сигналы, передаваемые по этой цепи, управляют в АПД
функцией передачи по каналу данных.
При состоянии «Включено» АПД переводится в режим передачи по каналу данных.
При состоянии «Выключено» АПД переводится в режим отсутствия передачи
по каналу данных после того, как закончится передача всех данных,
ранее переданных по цепи 103.
Цепь 106. Готов к передаче
Направление — от АПД.
Сигналы, передаваемые по этой цепи, указывают на готовность
АПД передавать данные по каналу данных.
Состояние «Включено» указывает, что АПД готова к передаче
данных по каналу данных.
Состояние «Выключено» указывает, что АПД не готова передавать
данные по каналу данных.
Цепь 107. АПД готова
Направление — от АПД.
Сигналы, передаваемые по этой цепи, указывают на готовность АПД к работе.
Состояние «Выключено» при наличии в цепи 106 состояния «Включено»
указывает на то, что АПД готова осуществить обмен сигналами данных, связанных
с программированием или управлением последовательным автоматическим вызовом.
Состояние «Выключено» при наличии в цепи 106 состояния «Выключено» указывает,
что:
а)АПД не готова для передачи данных;
б)обнаружено состояние неисправности, которое может быть в сети или в АПД;
в)обнаружено разъединение от удаленной станции или от сети.
Состояние «Выключено» при наличии в цепи 142 состояния
«Включено» указывает, что АПД участвует в проверке со стороны сети
или удаленной станции.
Цепь 108.1. Подсоединить АПД к линии
Направление — к АПД.
Сигналы, передаваемые по этой цепи, управляют подключением к линии связи
или отключением от линии устройства преобразования сигналов
или аналогичного ему устройства.
При состоянии «Включено» АПД должна подключить к линии связи
устройство преобразования сигналов или аналогичное ему
устройство независимо от состояния других цепей стыка.
Состояние «Включено» также может быть использовано для инициирования
процедуры прямого способа установления соединения в
устройстве автоматического вызова АПД.
При состоянии «Выключено» АПД должна отключить от линии связи
устройство преобразования сигналов или аналогичное ему
устройство после того, как закончится передача всех данных,
ранее переданных по цепи 103 или по цепи 118.
Состояние «Выключено» также может быть использовано для прерывания
или прекращения процедуры прямого способа установления соединения
в устройстве автоматического вызова АПД по ГОСТ 28142.
Цепь108.2. ООД готово
Направление — к АПД.
Сигналы, передаваемые по этой цепи, управляют подключением к
линии связи или отключением от линии связи устройства преобразования
сигналов или аналогичного ему устройства.
Состояние «Включено» указывает, что ООД Готово к работе, подготавливает
АПД к подключению к линии связи устройства преобразования сигналов
или аналогичного ему устройства, а также должно указывать на необходимость
сохранения соединения, кото*рое было установлено внешними средствами.
При состоянии «Выключено» АПД должна отключить от линии связи
устройство преобразования сигналов или аналогичное ему устройство
после того, как закончится передача всех данных, ранее переданных
по цепи 103 или по цепи 118.
Состояние «Выключено» также может быть использовано для прерывания
или прекращения процедуры адресного способа установления соединения
в устройстве автоматического вызова АПД по ГОСТ 28142.
Цепь 109. Детектор принимаемого линейного сигнала канала данных
Направление — от АПД.
Сигналы, передаваемые по этой цепи, указывают, находится ли уровень
принимаемого линейного сигнала канала данных в пределах,
установленных соответствующими рекомендациями на АПД.
Состояние «Включено» указывает, что уровень принимаемого сигнала
соответствует установленным пределам.
Состояние «Включено» может быть также во время обмена данными
между АПД и ООД при программировании или управлении
последовательным автоматическим вызовом.
Состояние «Выключено» указывает, что уровень принимаемого сигнала
не соответствует установленным пределам.
а если попробовать такой алгоритмОбъективная реальность такова, что даже при самой высокой скорости в порту С2 - драйвер HX.SYS прекрасно справляется на синхронных участках. Проблемы возникают только тогда, когда нужно распаковать сильно упакованный пакет. Однако, благодаря особенностям протокола HX - драйвер узнаёт о "приближении распаковки" за два байта до того, как ему придётся плотно заняться делом.
В этот момент драйвер вполне может попробовать "инспирировать" снятие сигнала квитирования, но всё же в последний момент прочитать следующий байт из порта и не дать ему пропасть. Сервер же, зная, что сигнал квитирования приходит только перед "большим затыком" - тут же начнёт "цедить байты" по одному, пока драйвер не освободится от забот и не восстановит синхронный обмен.
Всё, что для этого нужно - научить драйвер HX.SYS вытаскивать байт из порта "за один бит до оверрана" - когда стоповый бит уже пришёл, а стартовый ещё не начался.
---------- Post added at 03:25 ---------- Previous post was at 03:22 ----------
Можно сделать ещё круче - ввести в протокол специальный "бросовый байт", приём (и последующий выброс) или пропадание которого можно распознавать по биту переполнения порта.
---------- Post added at 04:06 ---------- Previous post was at 03:25 ----------
А самое простое и правильное - вообще забыть про квитирование и ввести в протокол прекращение передачи байтов сервером после отправки сжатого блока - вплоть до получения от драйвера байта XON.
Таким образом можно будет на любой скорости работать с любым контроллером порта по обычной двухпроводной линии без сигналов квитирования..
Таким образом можно будет на любой скорости работать с любым контроллером порта по обычной двухпроводной линии без сигналов квитирования..
Вот это правильно, ибо на УКНЦ сигналы квитирования не выведены на С2.
А самое простое и правильное - вообще забыть про квитирование и ввести в протокол прекращение передачи байтов сервером после отправки сжатого блока - вплоть до получения от драйвера байта XON.
Таким образом можно будет на любой скорости работать с любым контроллером порта по обычной двухпроводной линии без сигналов квитирования..
Согласен, я это тоже предлагал. К тому же квитирование делается внутри самой Windows, и делается это не совсем корректно.
Вот это правильно, ибо на УКНЦ сигналы квитирования не выведены на С2.
Vamos, а вот здесь я с Вами не соглашусь. Сами сигналы выведены на стык С2, и квитирование в 1801ВП1-065 аппаратное, программно им нельзя управлять. Если Вы соедините пару 1801ВП1-065, используя выводы RR и BSYD, то сможете обмениваться без всякой потери данных.
Интересно, что про скорость процессора и порта С2 скажет программа CPS_v1.8 (http://zx.pk.ru/attachment.php?attachmentid=39182)..
На эмулируемой ДВК-1 результат такой:
.RU CPS
CPS - Check Terminal Output Speed - v1.8
TEST ENGINE RATE FOR THIS CPU
CPS: 9'005
Press ANY KEY to EXIT..
PORT 0176576 TESTED SPEED
CPS: 937
Program completed.
Интересно, что про скорость процессора и порта С2 скажет программа CPS_v1.8 (http://zx.pk.ru/attachment.php?attachmentid=39182)..
Скорость процессора у меня показывает 11940-11990. Скорость порта - 868. При этом в HX-сервере показывается скорость на чтение около 940 символов. Тут еще не стоит забывать, что у 1801ВП1-065 всегда два стоп-бита, ну и в HX-сервере я тоже поставил два стоп-бита.
Скорость порта - 868. При этом в HX-сервере показывается скорость на чтение около 940 символов.Если порт передаёт 10 битов на байт - его "техническая" скорость на 9600 BPS составляет - 960 CPS, а если 11 битов - 872 CPS.
Если сервер при приёме байтов устойчиво показывает 940 в секунду - это странно. Откуда он может получить столько байтов при 11 битах на байт..
в HX-сервере я тоже поставил два стоп-бита.А когда мы вчера квитирование тестировали - COM-порт сервера уже был настроен на 2 стоповых бита ?
А когда мы вчера квитирование тестировали - COM-порт сервера уже был настроен на 2 стоповых бита ?
Да, уже стояло. Я обычно сразу новую версию и настраиваю.
Я тут достал старую литературку, там описан UART 8250. В описании порта 0x3FD есть такие слова - "Бит 5 - регистр хранения передатчика пуст, в него можно записать новый байт для передачи. Бит 6 - регистр сдвига передатчика пуст. Этот регистр получает данные из регистра хранения и преобразует их в последовательный вид для передачи". Это получается в UART можно сразу запихнуть два байта, один будет передаваться, а второй находится в регистре хранения. У меня так и было, когда я был в пультовом отладчике, читался регистр данных, следом HX-сервер передавал два байта и останавливался. Так что квитирование работает, но слишком поздно.
получается в UART можно сразу запихнуть два байтаНасколько я понимаю, у 1801ВП1-065 ситуация почти такая же. Если сдвиговый регистр пуст - бит готовности устанавливается сразу после копирования байта из регистра данных в сдвиговый, поэтому первое прерывание готовности вывода возникает почти сразу после помещения байта в регистр данных.
Это так?
Насколько я понимаю, у 1801ВП1-065 ситуация почти такая же. Если сдвиговый регистр пуст - бит готовности устанавливается сразу после копирования байта из регистра данных в сдвиговый, поэтому первое прерывание готовности вывода возникает почти сразу после помещения байта в регистр данных.
Это так?
Да, у 1801ВП1-065 есть и буферный регистр и сдвиговый регистр. Действительно после записи в буферный регистр при свободном сдвиговом, этот буферный регистр сразу копируется в сдвиговый и начинается передача. Во время этой передачи можно записать очередной байт. Но есть одно НО - это аппаратное квитирование, после передачи из буферного регистра также произойдет копирование в сдвиговый, но если на входе BSYD неактивный уровень, то передача не начнется. После появления активного уровня на входе BSYD передача возобновится.
Это я больше к тому, что у меня в "Эмуляторе ДВК" такая 2-ступенчатая буферизация передаваемого байта не эмулируется, поэтому результаты прогона CPS.SAV сильно отличаются от запусков на реальной ДВК.
Это я больше к тому, что у меня в "Эмуляторе ДВК" такая 2-ступенчатая буферизация передаваемого байта не эмулируется, поэтому результаты прогона CPS.SAV сильно отличаются от запусков на реальной ДВК.
Это может отличаться, если передаются несколько байт, а когда идет сплошной поток, то все упирается в скорость порта.
Это может отличаться, если передаются несколько байт, а когда идет сплошной поток, то все упирается в скорость порта.Вот и я так думал.
Но если байт принимается с шины сразу в сдвиговый регистр ( как в эмуляторе ДВК ), то между установкой IRQ и поступлением нового байта в регистр данных ( он же сдвиговый регистр - в эмуляторе ДВК ) никакая передача не производится.
Я все эти годы не мог понять, почему на реальной ДВК-1 CPS.SAV показывает 960 CPS, а в эмуляторе - максимум 937 CPS ( и это после всех улучшений CPS.SAV в результате которых промежуток между началом обслуживания прерывания готовности вывода и отправкой очередного байта в порт составляет всего несколько тактов CLC ).
А дело оказалось в том, что пока реальный порт передаёт байт из сдвигового регистра - приём следующего байта в регистр данных происходит в то же самое время.
А дело оказалось в том, что пока реальный порт передаёт байт из сдвигового регистра - приём следующего байта в регистр данных происходит в то же самое время.
Здесь я согласен. В реальности при передаче сплошного потока между передаваемыми символами отсутствуют промежутки. А в эмуляторе были промежутки, которые связаны с передачей нового символа в регистр данных, обработки прерывания, потому чуть медленнее и получалось.
palsw, а пробовали что-то УК-НЦшное запускать? Тесты типа TS, TUK изначально вы же что-то такое просили в виде WAVе - интересно посмотреть картинку, что работает УК-НЦшный именно софт, игрушки по шнурочку, а не тесты под RT-11 ? Для этого монтируйте диск с программами и запускайте с него нужные файлы. Всё как с тестами которые ранее запускали.
Vamos, а вот здесь я с Вами не соглашусь. Сами сигналы выведены на стык С2, и квитирование в 1801ВП1-065 аппаратное, программно им нельзя управлять.
Аппаратное не квитирование а паритет по чет/нечет.
Если Вы соедините пару 1801ВП1-065, используя выводы RR и BSYD, то сможете обмениваться без всякой потери данных.
Да только пока программа которая читает и пишет в регистры успевает за скоростью порта что и наблюдается в Ваших экпериментах.
Так что RR и BSYD это DSR и DTR. Так же можно посмотреть временные диаграммы в справочниках и увидеть что RR и BSYD выставляются задолго до начала передачи и после окончания всей посылки, а RTS/CTS работает по старт/стоп битам.
Аппаратное не квитирование а паритет по чет/нечет.
В 1801ВП1-065 квитирование также аппаратное. Я уже писал, чтобы его не задействовать, то надо вывод BSYD посадить на землю, а RR оставить висеть в воздухе. Не верите почитайте этот топик (http://zx.pk.ru/showpost.php?p=565016&postcount=196), пишет специалист anonymous с bk0010.org, который много поработал с нашей советской техникой.
Так что RR и BSYD это DSR и DTR. Так же можно посмотреть временные диаграммы в справочниках и увидеть что RR и BSYD выставляются задолго до начала передачи и после окончания всей посылки, а RTS/CTS работает по старт/стоп битам.
Ссылку на справочники в студию. Кстати выставляется только RR, а BSYD это вообще-то вход, он получается.
Микропроцессоры и микропроцессорные комплекты интегральных схем. Шахнов В.А. Том 2 стр 34-38
МикроЭВМ книга 2 Под ред Л.Н. Преснухина стр 42-46.
Вы же тоже не верите схеме кабеля приведенной tnt23 и мной, а работает, причем работает аналогично схеме с задействованными RR и BSYD.
Микропроцессоры и микропроцессорные комплекты интегральных схем. Шахнов В.А. Том 2 стр 34-38
МикроЭВМ книга 2 Под ред Л.Н. Преснухина стр 42-46.
Vamos, в этих справочниках описана 1801ВП1-035, у нее нету выхода RR, он появился только в 1801ВП1-065. Вся эта эпопея с квитированием связана с тем в какой момент времени исчезает сигнал RR, чтобы PC не пересылала следующий байт на УКНЦ. Кое-какая информация про 1801ВП1-065 есть в ТО на КТЛК, т.к. он построен именно на 1801ВП1-065.
---------- Post added at 19:31 ---------- Previous post was at 19:25 ----------
Вы же тоже не верите схеме кабеля приведенной tnt23 и мной, а работает, причем работает аналогично схеме с задействованными RR и BSYD.
А теперь по поводу кабеля - да он будет работать, но не столь корректно. Все дело в том, что в стыке С2 вход 7 (сигнал 109) закрывает прием информации извне. И если на выходе RR будет неактивный уровень, т.е. получили байт данных в приемник, но еще не успели прочесть, то вход просто закроется. И если в моем варианте кабеля данные пойдут на вход но зафиксируется ошибка переполнения, то в вашем варианте они просто не попадут на вход и об этом Вы не узнаете. Так же останется в неактивном уровне и вход BSYD, а значит посылки не смогут уходить наружу. Т.е. в данном варианте можно работать только в режиме полудуплекса, но не полного дуплекса. Также почему-то вариант вашего кабеля не смог работать с TU58.
Кое-что из интернета:
"Применяемые в IBM PC приемопередатчики 8250/16450/16550 сигнал CTS аппаратно не отрабатывают, а только показывают его состояние в регистре MSR. Реализация протокола RTS/CTS возлагается на драйвер BIOS Int 14h, и называть его “аппаратным” не совсем корректно. Однако существуют и иные приемопередатчики (например, 8251), в которых сигнал CTS отрабатывается аппаратно."
hobot, Еще нет,пока занят был развозкой калачей :)
Интересно, что про скорость процессора и порта С2 скажет программа CPS_v1.8 (http://zx.pk.ru/attachment.php?attachmentid=39182)..
На эмулируемой ДВК-1 результат такой:
.RU CPS
CPS - Check Terminal Output Speed - v1.8
TEST ENGINE RATE FOR THIS CPU
CPS: 9'005
Press ANY KEY to EXIT..
PORT 0176576 TESTED SPEED
CPS: 937
Program completed.
http://i.piccy_.info/i7/280fda6a120c584105d290b2ddf1b334/4-55-450/2885999/20130107_230625_015_240.jpg (http://piccy_.info/view3/3948833/0e84dce3ef70098962697f4df4ca44ec/)http://i.piccy_.info/a3/2013-01-07-20-55/i7-3948833/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-07-20-55/i7-3948833/240x180-r)
---------- Post added 08.01.2013 at 00:19 ---------- Previous post was 07.01.2013 at 23:56 ----------
palsw, а пробовали что-то УК-НЦшное запускать? Тесты типа TS, TUK изначально вы же что-то такое просили в виде WAVе - интересно посмотреть картинку, что работает УК-НЦшный именно софт, игрушки по шнурочку, а не тесты под RT-11 ? Для этого монтируйте диск с программами и запускайте с него нужные файлы. Всё как с тестами которые ранее запускали.
Если просто подставлять образы из ссылки вместо HXsys54.DSK вываливается ошибка
http://i.piccy_.info/i7/ae858d3f988e7f295eba5915f9965771/4-55-450/53887522/20130107_232509_328_240.jpg (http://piccy_.info/view3/3948921/d55d044d6e90d99c6b592c4aa2b9bf56/)http://i.piccy_.info/a3/2013-01-07-21-18/i7-3948921/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-07-21-18/i7-3948921/240x180-r)http://i.piccy_.info/i7/6e3aab355cfb9b90e9b09e2eaf54d1b4/4-55-450/53999056/20130107_231242_375_240.jpg (http://piccy_.info/view3/3948922/f67870c418ab1fa670865e0560ab0abf/)http://i.piccy_.info/a3/2013-01-07-21-18/i7-3948922/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-07-21-18/i7-3948922/240x180-r)http://i.piccy_.info/i7/1218178d46f3087e236265ee2c29d6f4/4-55-450/54107272/20130107_231137_921_240.jpg (http://piccy_.info/view3/3948923/ccacb360c11dcd1c6763e6d8bb0aef3f/)http://i.piccy_.info/a3/2013-01-07-21-19/i7-3948923/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-07-21-19/i7-3948923/240x180-r)
Когда подключаю образы в HX0 - не знаю как сменить текущий привод и прочитать директорию.Командой DIR отлично выводиться директория с диска HX2
http://i.piccy_.info/i7/64ee134e3c5848338da913c4b306a49e/4-55-451/17589719/20130107_233824_515_240.jpg (http://piccy_.info/view3/3948964/867a1d612275f253f5ffb60687fc0d85/)http://i.piccy_.info/a3/2013-01-07-21-27/i7-3948964/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-07-21-27/i7-3948964/240x180-r)http://i.piccy_.info/i7/62cdd4e04f38b30af41db0425b7bb28a/4-55-451/59751541/20130107_235333_828_240.jpg (http://piccy_.info/view3/3949032/f62e432aad95231e98178c18121a3fee/)http://i.piccy_.info/a3/2013-01-07-21-43/i7-3949032/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-07-21-43/i7-3949032/240x180-r)
уже получилось)
TS
http://i.piccy_.info/i7/9421560d6ca62804816998db89d32668/4-55-452/14855565/20130107_235804_390_240.jpg (http://piccy_.info/view3/3949067/96551eaa5e795e4045007b149199925a/)http://i.piccy_.info/a3/2013-01-07-21-55/i7-3949067/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-07-21-55/i7-3949067/240x180-r)http://i.piccy_.info/i7/c0161a17a9da6d81ce3dffcc6dc344e0/4-55-452/18125427/20130108_000228_531_240.jpg (http://piccy_.info/view3/3949072/cfbbcc8ae3ff679d9a8f2a4db19ef436/)http://i.piccy_.info/a3/2013-01-07-21-56/i7-3949072/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-07-21-56/i7-3949072/240x180-r)http://i.piccy_.info/i7/ecdcf2d333cd0d4dd5c7af08664e81b5/4-55-452/18294474/20130108_000154_687_240.jpg (http://piccy_.info/view3/3949073/1db6dfb3d88b1ea7ac7edf2270ff1f12/)http://i.piccy_.info/a3/2013-01-07-21-57/i7-3949073/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-07-21-57/i7-3949073/240x180-r)
TUK
http://i.piccy_.info/i7/4dd306435b3e3d80d153bb0f366e1d60/4-55-452/23398486/20130108_000942_578_240.jpg (http://piccy_.info/view3/3949082/86860c004a9da1e653a9a90f66eae45d/)http://i.piccy_.info/a3/2013-01-07-21-59/i7-3949082/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-07-21-59/i7-3949082/240x180-r)
Bolder
http://i.piccy_.info/i7/75603497fb6e6107713b8128eb3d1834/4-55-452/40262928/20130108_001647_484_240.jpg (http://piccy_.info/view3/3949109/62f958ec4790f6e23e4bc588e5f00aec/)http://i.piccy_.info/a3/2013-01-07-22-08/i7-3949109/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-07-22-08/i7-3949109/240x180-r)http://i.piccy_.info/i7/432497bbead442927adc68dfa6dcafc8/4-55-452/40638621/20130108_001715_109_240.jpg (http://piccy_.info/view3/3949111/f6029d5e1847babde2b3c1e92a425724/)http://i.piccy_.info/a3/2013-01-07-22-08/i7-3949111/240x180-r/i.gif (http://i.piccy_.info/a3c/2013-01-07-22-08/i7-3949111/240x180-r)
уже получилось)
Класс, спасибо!
И это всё через ком шнурочек? Фантастика!
Системное устройство конечно только то где актуальный драйвер HX.SYS
в системе по умолчанию имеет лог.имя SY:
Рабочее устройство имеет логическое имя DK: и его можно назначить на любой
дисковод или раздел или что там у нас AS HDn DK
Запуск с устройства SY: --- R (имя-SAV-файла)
Запуск с устройства DK: --- RU (имя-SAV-файла)
Но у вас и так я вижу всё получилось.
Я почему и просил выложить дискету с актуальным HX.SYS для УК-НЦ что-бы сделать на ёё основе УК-НЦшную дискету, но можно и так обходиться, ведь
так хватает куда монтировать другие образы (в эмуляторе ДВК в смысле).
Веб-архив УК-НЦшный вам в руки! ) Ура! )
Раз уж всё получилось -- сделайте пожалуйста пошаговую инструкцию по загрузке УКНЦ через Стык С2 -- плюс ссылки на софт для обоих сторон.
1.Кабель из поста http://zx.pk.ru/showpost.php?p=201649&postcount=520
2.На PC запустить HX_Server_-_UKNC_06.01.13_02-23.rar из поста http://zx-pk.ru/showpost.php?p=564797&postcount=160
3.Файл конфигурации изменить http://zx-pk.ru/showpost.php?p=564743&postcount=149
4.В архиве уже содержится образ системы с драйвером HX. HXsys54.DSK
5.Со строны УКНЦ вообще нечего не нужно.Только включить питание и выбрать в меню загрузку Стык2.
или есть более простой способ?
- использовать готовый образ;
- использовать готовый образ + подружив его с драйвером HX.SYS нужной версии.
---------- Post added at 17:43 ---------- Previous post was at 17:38 ----------
Со стороны УКНЦ вообще нечего не нужно.Только включить питание и выбрать в меню загрузку Стык2.
Со стороны PC запустить HX_Server_-_UKNC_06.01.13_02-23.rar я этой версией загружал и все.
---------- Post added at 16:06 ---------- Previous post was at 15:56 ----------
Мне вот интересно как загружать программки с расширением SAV.Наверное нужно делать пустой образ dsk и плагином добавлять или есть более простой способ?
Вот ко всему этому в одном сообщении оба (или скольки их) варианта соединения
проводков ) И дискета с HX.SYS УК-НЦшным (актуальным) - вот было бы идеально наверно )
В UKNCBTL_31 загрузка останавливается на этом:
http://zx-pk.ru/attachment.php?attachmentid=39201&stc=1&d=1357655155
palsw, а сколько по времени загрузка на реале?
Сейчас драйвер и сервер HX претерпевают серьёзные изменения, связанные с переходом на 2-е поколение протокола HX, поэтому уделять слишком пристальное внимание текущей версии HX не рекомендуется.
...
Vamos, относительно быстро - минутка может -не замерял :). Скорость то 9600 выставлена,если пнут поменять перемычки на ВП1-065 - тогда полезу с паяльником :)
Patron, Главное ,что все уже работает и софт можно загружать владельцам голых УКНЦ.
Главное ,что все уже работаетРаботает главное, но не всё.
1. Чтение/запись массивов, выходящих за размер диска - отрабатывается неправильно - вместо признака конца файла возвращается ошибка чтения/записи.
2. Чтение в режиме сжатия работоспособно только на очень быстрых машинах ( на УКНЦ не работает ).
Т.к. следующее поколение протокола HX будет абсолютно несовместимо с текущим - чем меньше копий текущего варианта HX расплодится - тем лучше.
Patron, в следующей версии сделайте пожалуйста возможность выбора подключаемого образа в самой программе, как-то ini файл править не удобно.
Vamos, если я правильно понял вопрос - отвечу -в самой программе есть выбор образа и не одного :).Но номер загружаемого образа зависит от самой УКНЦ -у меня например HX2:.
HХ2:есть загружаемый образ и в нем должен быть вставлен диск HXsys54.DSK
В остальные образы можно вставить любой софт на свой вкус - и на самой УКНЦ уже запускать программы с нужного диска.
Извиняюсь, действительно есть.
Ох! Вроде удалось победить проблему ошибки переполнения, теперь грузится при включенном сжатии и если выхожу в пульт при нажатии "СТОП", то в регистре 176570 бит переполнения не устанавливается. При продолжении по нажатию "ИСП" все нормально идет дальше.
Файл Terminal_ComPort_Adapter.ini:
[Main]
BaudRate=CBR_9600
fDtrControl=DTR_CONTROL_ENABLE
fRtsControl=RTS_CONTROL_ENABLE
Parity=NOPARITY
StopBits=TWOSTOPBITS
ByteSize=8
fParity=FALSE
fOutxCtsFlow=TRUE
fOutxDsrFlow=TRUE
fDsrSensitivity=FALSE
fTXContinueOnXoff=FALSE
fOutX=FALSE
fInX=FALSE
fErrorChar=FALSE
fNull=FALSE
fAbortOnError=FALSE
XonLim=512
XoffLim=512
XonChar=021
XoffChar=023
ErrorChar=0
Жирным выделены параметры, которые я изменял. Кабель у меня по управлению сигналами RTS/CTS, поэтому следующие параметры можно оставить такими: fDtrControl=DTR_CONTROL_DISABLE и fOutxDsrFlow=FALSE. Самое главное, чтобы было 2 стоп-бита. В 1801ВП1-065 сигнал RR сбрасывается судя по всему с приходом стоп-бита, а за 2 стоп-бита он успевает обработаться и Windows. Два стоп-бита я ставил при настройках с HANDSHAKE, но оказалось это какой-то модемный протокол с восстановлением связи, естественно с УКНЦ хоть и грузилось, но с ранее описанными глюками.
А как в УКНЦ задаётся число стоп-битов у 1801ВП1-065 ?
А как в УКНЦ задаётся число стоп-битов у 1801ВП1-065 ?
Никак. И у 1801ВП1-035, и у 1801ВП1-065 их железно два.
---------- Post added at 22:15 ---------- Previous post was at 22:05 ----------
Небольшое дополнение. 1801ВП1-035 при выдаче посылки размером 5 бит выдает 1,5 стоп-бита, в других случаях (7 и 8 бит) - два стоп-бита. 1801ВП1-065 умеет выдавать посылки размером только 7 или 8 бит, поэтому стоп-бита всегда два.
Никак. И у 1801ВП1-035, и у 1801ВП1-065 их железно два.А сколько тогда битов на байт передаётся портом терминала ДВК.. Я всегда думал, что 10, а не 11.
И ещё - очень странно, откуда взялось мнение, будто ВП1-065 не может управлять потоком при работе с PC, если достаточно установить в DCB
fRtsControl = RTS_CONTROL_ENABLE
fOutxCtsFlow = TRUE
и сразу всё заработает..
А сколько тогда битов на байт передаётся портом терминала ДВК.. Я всегда думал, что 10, а не 11.
Последовательный порт плат МС1201.01 и МС1201.02 построен на основе 1801ВП1-035, поэтому всегда передается 11 бит.
И ещё - очень странно, откуда взялось мнение, будто ВП1-065 не может управлять потоком при работе с PC, если достаточно установить в DCB
fRtsControl = RTS_CONTROL_ENABLE
fOutxCtsFlow = TRUE
и сразу всё заработает..
Мнение взялось из-за программного управления линиями квитирования со стороны PC. Все в этом случае зависит от алгоритма обработки этих сигналов. Если алгоритм не очень, то видно проблемы и были. Я тоже играл со всеми параметрами два дня, судя по всему чего-то упустил и не получалось.
Но получиться только с полным кабелем. Если кабель будет минимальный, то увы - будут проблемы. С минимальным кабелем надо обрабатывать поступающую информацию в реальном режиме времени, либо использовать протокол XON/XOFF.
Последовательный порт плат МС1201.01 и МС1201.02 построен на основе 1801ВП1-035, поэтому всегда передается 11 бит.За столько лет ещё никто ни разу не запустил программу CPS.SAV ни на одной ДВК ( или хотя бы стандартной материнской плате ДВК ).
получится только с полным кабелемНасколько я понял - достаточно двух дополнительных линий, передающих сигналы RTS и CTS.
Но если эти линии в кабеле есть и паметры DCB выбраны правильно - всё сразу начинает работать. И даже если включить на максимум буфера FIFO в PC - всё работает ( и не просто работает, а работает ещё лучше ).
Насколько я понял - достаточно двух дополнительных линий, передающих сигналы 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-сервер.
Хотя может при включении/выключении FIFO надо Windows перезагружать?Насколько я понял - в режиме RTS_CONTROL_ENABLE квитирование на приём в Windows отключено и независимо от заполненности приёмного буфера FIFO - сигнал разрешения передачи ( RTS ) не снимается.
Если это так и, не запуская сервер - дать какую-нибудь команду чтения HX ( например DIR HX0: ) - то драйвер выдаст запрос и когда приёмный буфер FIFO активен - запрос закешируется и прочтётся сервером после запуска, а когда приёмный буфер FIFO выключен - запрос должен пропасть.
Кстати - если запрос пропал и драйвер HX.SYS висит в ожидании ответа - он отвалится по ошибке, если ему вручную послать Ctrl/C.
Для сигналов RTS и CTS на роль логического анализатора должен хорошо подойти обычный вольтметр.
...
В принципе - при установке
fRtsControl = RTS_CONTROL_HANDSHAKE
Windows как раз должна выставлять сигнал RTS, когда свободна хотя бы половина приёмного буфера FIFO, и снимать его, когда приёмный буфер FIFO заполнен больше, чем на 3/4.
Очевидно, что при отключенных буферах FIFO эта опция нормально работать не может.
Насколько я понял - в режиме 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 включены.
А вот сейчас я выставил fRtsControl = RTS_CONTROL_HANDSHAKE и провожу тест.Тут главная фишка в том, что когда в Windows никто не читает порт - после заполнения входного буфера должен автоматически сниматься сигнал RTS.
Чтобы это проверить - я написал драйвер C2.SYS, который позволяет копировать текстовые файлы из RT-11 в порт C2.
Новый вариант - HX_Server 2.0 - UKNC_09.01.13_19-35 (http://emulator.pdp-11.org.ru/misc/HX_Server%202.0%20-%20UKNC_09.01.13_19-35.rar), где добавлено окно Teletype, на которое выводится терминальный обмен в порту C2.
Если загрузить RT-11 с драйвером C2.SYS не через HX, завершить HX-сервер и дать в УКНЦ команду копирования на C2: какого-нибудь довольно большого ASCII-файла ( больше, чем входной буфер COM-порта в Windows ), то после запуска HX-сервера в окно Teletype должен выйти весь отправленный текст без потери байтов.
...
Тут главная фишка в том, что когда в 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 не отображается.
После запуска HX-сервера готовность в регистре 176574 устанавливается и все, что заносится в 176576, отображается в окне Teletype. Но посланный ранее байт 041 не отображается.Похоже, пока Com-порт не открыт в программе для чтения/записи - Windows не копирует данные из буфера FIFO в потоковый буфер подсистемы ввода-вывода.
Посмотрел код написанных мною полгода назад функций чтения и записи порта (в исходнике адаптера COM-порта модульного API) и понял, что без потоковых буферов Windows эти функции читали бы и писали не больше 60 байтов в секунду. Переписал этот код - теперь и чтение, и запись должны работать немного быстрее.
Новый вариант - HX_Server 2.0 - UKNC_09.01.13_21-02 (http://emulator.pdp-11.org.ru/misc/HX_Server%202.0%20-%20UKNC_09.01.13_21-02.rar) с изменёнными алгоритмами чтения и записи COM-порта.
...
Похоже, пока 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:).
Откуда такая уверенность, что не более 60-ти?Это я слегка утрировал. При записи больших проблем не было. Но при чтении вызов Read производился только 60 раз в секунду, причём без ожидания дополнительных данных. Если бы не потоковые буфера Windows - таким манером нельзя было бы прочитать очень много байтов, а так - 60 раз в секунду адаптер принимал из Windows сразу по нескольку десятков байтов.
В реальной ситуцации ( в которой и старая версия смотрелась неплохо ) новая версия имеет следующие преимущества:
1. Первый байт, поступивший в COM-порт - попадает в байтовый поток модульного API немедленно, а не с задержкой в 15 мс.
2. Если поступили новые байты для вывода за то время, пока адаптер передавал байты в потоковый буфер Windows - новый вывод в потоковый буфер Windows начинается сразу же, а не через 15 мс ( понятно, что это не очень критично, когда в буфер Windows уже "напихано" байтов на минуту передачи ).
Посмотрел код написанных мною полгода назад функций чтения и записи порта (в исходнике адаптера 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 секунды. Так что в предыдущей версии порт использовался на пределе своих возможностей.
да работает же все нормально.зачем еще мучать?
---------- Post added at 20:59 ---------- Previous post was at 20:58 ----------
Alex_K, вп1-065 переключил на укнц на скорость выше 9600?можно фото где эти перемычки искать?
в предыдущей версии порт использовался на пределе своих возможностей.Прикольно.
Вернём предыдущие коды чтения в адаптер порта и добавим туда возможность блокировки чтения: HX_Server 2.0 - UKNC_09.01.13_23-19 (http://emulator.pdp-11.org.ru/misc/HX_Server%202.0%20-%20UKNC_09.01.13_23-19.rar)
Теперь в окне Teletype есть кнопка [Stop Reading], при нажатии которой сервер вообще перестаёт обращаться в Windows за байтами из COM-порта.
На случай, если потоковые буфера Windows имеют размер под сотню килобайт - написана специальная программа SPAM.SAV, посылющая в порт С2 УКНЦ столько байтов - что мало не покажется.
...
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot