В следующей версии сервера и драйвера HX сжатие будет работать без квитирования.
Вид для печати
Трудно представить, каким образом наличие в кабеле проводов квитирования может мешать вести обмен, который без проблем идёт при отсутствии в кабеле проводов квитирования. Ведь единственный эффект квитирования - задержка обмена. Но если обмен нормально идёт без задержек - он должен так же нормально идти и с любыми задержками.
Получается, что дело не в алгоритме штатного изменения сигналов, а чисто в физике токов и напряжений между передатчиком и приёмником.
- - - Добавлено - - -
Кстати, если тестовый загрузчик не говорил про потерю байтов - значит вредное влияние проводов квитирования заключалось в искажении битов в проводе 104.
- - - Добавлено - - -
Вряд ли конечно принимаемые биты искажались непосредственно в проводе - скорее электрическая связь PC и УКНЦ не только по уровню 0V, но и по уровню 12V через провода квитирования - как-то нарушает работу приёмника ВП1-065.
Уф! Кстати очень давно не обновлялось С2 сервер для УК-НЦ, я даже уже не уверен в актуальности архива по ссылке на сайте
http://archive.pdp-11.org.ru/ у меня там висят такие вот варианты:
- вариант сервера для загрузки УК-НЦ через стык С2.
- вариант сервера для загрузки через доработанный СА УК-НЦ.
Цитата:
Сообщение от Vamos
offtop
Я на видео честно не вижу потерянных строк, разве ЛАТ (высота шрифта УК-НЦ 11 точек) не в притык к экрану должна быть? Свою картинку с USB тюнера я в теме по восстановлению не 1 раз выкладывал и в теме по переходнику дублировал.
Это из эмулятора
http://smages.com/thumbs/latemul.png
Это мой тюнер + какое-то там ПО
http://smages.com/thumbs/games.jpg
Vamos, я бы согласился на такую картинку по композиту в любом ТВ !!! Для работы эти пару пикселей сверху
не критичны, а вот столбцы слева пропавшие это мега-неудобство )
[свернуть]
RABBIT-1, Попробуйте вот такой вариант схемы переходника
Код HTML:Разъем Разъем
Стык С2 DB9S
1,10 (102) ■─────────────────────■ 5 (GND)
5 (103) ■──────────┐ ┌────■ 3 (TD)
┌────■│■────┘
6 (104) ■────┘ └──────────■ 2 (RD)
7 (109) ■─────────────────────■ 4 (DTR)
┌────■ 1 (CD)
3 (+5В) ■────────────────┤
└────■ 6 (DSR)
2 (108) ■──────────┐ ┌────■ 7 (RTS)
┌────■│■────┘
9 (107) ■────┘ └──────────■ 8 (CTS)
Вообще-то я уже не собирался переделывать тот который работает, но если Вам надо для понимания процессов сделаю.
пробовал включать сжатие - не грузиться (но я так понимаю, и не должен :) )
у него от начала загрузки до приглашения - 24 сек.
у меня при 9600 - 1:09, то есть быстрее не в пять раз, но почти в три. Плюс у нас загрузчики немного разные.
offtop
Вы начали обсуждать вывод изображения, я подключил через SCART, и меня очень угнетает обрезанная справа картинка, а есть ли нормальный вариант подключения? я так понял что нет.[свернуть]
Было бы хорошо.
вот если заработает по схеме с квитированием то можно будет использовать сжатие, что заметно ускорит
Через USB ТВ тюнер или еще какой видео захват по композиту ч/б картинка. EGA монитор или искать ЖК телевизор который не будет обрезать такие вроде бывают. А так вопрос обсуждается здесь http://zx-pk.ru/showthread.php?t=25871
А как вообще может работать квитирование при подключении ВП1-065 к писюку? Пои подключении двух 65-х друг к другу, входы BSYD (29) крест-накрест соединяются с выходами RR (31), если первый ЦП не заберет вовремя принятый байт, на выходе RR его 65-го появится сигнал "Занято", высокого (если не врет мой склероз) уровня, получив его на вход BSYD второй 065-й аппаратно не начнет передачу, пока этот сигнал не снимется. То есть, реакция на него мгновенная.
А у писюка все эти сигналы сопровождения - обычные биты в каком-то, читаемом ЦП регистре, возможно, вызывающие прерывание. Да еще и буферизация - не помню, сколько там у писюшных компортов длина буфера, но он точно есть, да, если не врет мой склероз, еще и не везде отключаемый, помню, для ДИАМСа (писюшного, который MSM) приходилось искать мультипортовки на чипах 8252, небуферизованных, ибо на более свежих были проблемы с потерей символов. Так вот, мне интересно: как справились с этой проблемой?
У меня сложилось такое впечатление, что за счёт буферизации порты PC могут использовать квитирование при работе с меньшим количеством стоповых битов на передающей, чем на принимающей стороне - тогда при каждом включении квитирования проходит ещё один байт, который должен быть принят в буфер.
Когда у приёмника нет места в буфере для ещё одного байта - количество стоповых битов у передатчика должно быть не меньше двух, тогда при включении квитирования передача останавливается до начала передачи следующего байта и дополнительное свободное место в буфере приёмника не требуется.
Patron, можно ли программно управлять сигналами DTR и RTS не зависимо от передачи данных?
Можно.
Ещё у объекта Terminal_ComPort_Adapter есть состояния Out_DTR и Out_RTS, на которые можно вешать кнопки, чтобы вручную переключать у COM-порта состояние выводов DTR и RTS.Код:DTR_CONTROL_DISABLE : DTR = FALSE ; программно: EscapeCommFunction( hComPort, CLRDTR )
DTR_CONTROL_ENABLE : DTR = TRUE ; программно: EscapeCommFunction( hComPort, SETDTR )
RTS_CONTROL_DISABLE : RTS = FALSE ; программно: EscapeCommFunction( hComPort, CLRRTS )
RTS_CONTROL_ENABLE : RTS = TRUE ; программно: EscapeCommFunction( hComPort, SETRTS )
Попробовал. Пробовал менять параметры fDtrControl, fRtsControl, StopBits, fOutxCtsFlow, fOutxDsrFlow в разных комбинациях, ничего не дало. Комп не грузиться, хотя тест http://zx-pk.ru/showthread.php?t=160...l=1#post847144 проходит и приглашение @ в консоли появляется. То есть РС понимает что дает УКНЦ, а наоборот нет.
offtop
Еще нашел кое-какую документацию http://retropc.org/index.html?action..._razdel=31#c15. Может она конечно у всех есть, но она мне здесь не попадалась.[свернуть]
Тогда последний вариант схемы
Код HTML:Разъем Разъем
Стык С2 DB9S
1,10 (102) ■─────────────────────■ 5 (GND)
5 (103) ■──────────┐ ┌────■ 3 (TD)
┌────■│■────┘
6 (104) ■────┘ └──────────■ 2 (RD)
┌────■ 4 (DTR)
7 (109) ■────────────────┤
├────■ 1 (CD)
3 (+5В) ■─ └────■ 6 (DSR)
2 (108) ■──────────┐ ┌────■ 7 (RTS)
┌────■│■────┘
9 (107) ■────┘ └──────────■ 8 (CTS)
Судя по симптомам - работать сможет только такой кабель, в котором от PC не передаются постоянные уровни, кроме 0в.
Значит, единственный возможный вариант кабеля с квитированием - такой:
Код HTML:Стык С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)
Т.е. вообще загрузка не стартует или как в начале появляются ошибки при загрузке ОС?
- - - Добавлено - - -
Можно еще вариант попробовать:
Код HTML:Разъем Разъем
Стык С2 DB9S
1,10 (102) ■─────────────────────■ 5 (GND)
5 (103) ■──────────┐ ┌────■ 3 (TD)
┌────■│■────┘
6 (104) ■────┘ └──────────■ 2 (RD)
7 (109) ■──────────┐ ┌────■ 4 (DTR)
│ │
│ ├────■ 1 (CD)
3 (+5В) ■─ │ │
│ └────■ 6 (DSR)
│
2 (108) ■──────────┤ ┌────■ 7 (RTS)
┌────■│■────┘
9 (107) ■────┘ └──────────■ 8 (CTS)
Есть два аргумента против:
1. В реальной жизни PC невозможно заставить снять квитирование ( даже если программа вообще не читает COM-порт - драйвер Windows успевает принять 3 Кб в системный буфер, прежде чем снимает квитирование ).
2. На линии 107 всегда будет постоянное напряжение с чужого блока питания - а это единственное, чего нет в рабочем кабеле без квитирования.
?
С СЭМЗ-овской схемотехникой квитирование работает, У Alex_K и palsw http://zx-pk.ru/showthread.php?t=160...l=1#post564725 только вот не известно унего СЗМЗ или Квант.
Исходя из этого проблемная линия 109 причем для СЗМЗ это TTL уровень, а в Кванте 109 подтянут через резистор к -12В при этом по схеме он должен быть подтянут к +12
- - - Добавлено - - -
Вероятнее всего у palsw Квант, у RABBIT-1 тоже работает все кроме квитирования, предполагаю что проблемы на стороне СОМ порта РС, он может быть "урезанный", видел такие, только для мыши Rx Tx GND и еще что-то для питания. И может получится вот такая картина:
тестером бы прозвонить СОМ на РСКод HTML:Разъем Разъем
Стык С2 DB9S
1,10 (102) ■─────────────────────■ 5 (GND)
5 (103) ■──────────┐ ┌────■ 3 (TD)
┌────■│■────┘
6 (104) ■────┘ └──────────■ 2 (RD)
7 (109) ■─────────────────────■ 4 (DTR)
│
─■ 1 (CD)
│
3 (+5В) ■─ ─■ 6 (DSR)
2 (108) ■──────────┐ ┌────■ 7 (RTS)
┌────■│■────┘ │
9 (107) ■────┘ └──────────■ 8 (CTS)
вообще не стартует загрузка.
а какие параметры выставлять в Terminal_ComPort_Adapter?
и при таком?
дело в том, что это возможно один и тот же комп. свой я купил как раз у palsw :)
а что звонить?
Крайне маловероятно. Такое могло быть на 286-386, уже на последних 486-х (которые с PCI) такого точно не было.
ИМХО, единственно правильное решение - это промежуточный микроконтроллер с двумя USART'ами и несколькими кБ памяти на борту. Что-нибудь, вроде STM32F103, пробная платка с которым на Алиэкспрессе дешевле $4 с доставкой. Прицепить к ней пару MAX232, один конец в писюк, второй в УКНЦ. Получили RR от УКНЦ, сняли DSR или CTS, что там надо, и пихаем все, что прилетело от писюка в буфер, рано или поздно, оно иссякнет, ибо просигналили, что неготовы. Когда УКНЦ снимет RR, отсылаем буфер, кончится - сигналим DSR/CTS, мол давай дальше. Если взять платку, вроде этой http://ru.aliexpress.com/item/STM32F...le-For-Arduino (не сочтите за рекламу, к ней, правда, придется прикупить ST-Link V2, еще чуть меньше $3), то, вероятно, можно подключить ее прямо в USB, если справишься с софтовой поддержкой со стороны писюка. Для STM32 у ST Microelectronics есть библиотеки и (почти) готовые решения.
Вот как раз на последних такое и началось, когда китайцы начали штамповать РС а внешние модемы которые требовали "полного" СОМ канули в лету.
- - - Добавлено - - -
Те же с которыми все работало.
уточните у него тот или не тот
можно не звонить, вероятнее всего проблемы на стороне РС. Может проще найти другой РС или USB-COM адаптер (только не на PL23XXX он же ProLific, глючные они)
Да! Я знал! Там яркая такая приметка не пропустишь )
http://storage1.static.itmages.ru/i/...ef7360199d.png
Ну наверняка конечно не знал ) Но догадывался.
- - - Добавлено - - -
Просто такая плата действительно редкость. Я вот только 1-у пока такую видел и то только на фото (похоже сменила владельца).
Не-а! Экономили-то на м/с 1488/1489, вон, в хламовнике валяется какая-то 486-я маманя, так там драйверы компортов - 14185, полный комплект, 3 передатчика, 5 приемников в одной м/с. Согласен, таких 486-х было мало. Но уже П-2 такие, практически, все. Компорты в составе чипа Multi-IO, оба, а ИС драйверов - 14185 или 75232, что то же самое. На чем прикажете экономить?
Такие:
- - - Добавлено - - -Код:fDtrControl = DTR_CONTROL_ENABLE
fRtsControl = RTS_CONTROL_ENABLE
Parity = NOPARITY
StopBits = TWOSTOPBITS
ByteSize = 8
fParity = FALSE
fOutxCtsFlow = TRUE
fOutxDsrFlow = FALSE
В обсуждаемой ситуации всё прекрасно работает на максимальной скорости вообще без квитирования - это означает, что за всё время работы ни одна из сторон ни разу не снимает квитирование и поэтому наличие проводов квитирования в кабеле вообще не требуется.
Почему же после добавления в кабель проводов квитирования - приёмник УКНЦ перестаёт ( в менее чем 1% случаев ) отличать 0 от 1 и контрольные суммы переданных пакетов перестают совпадать.
Очевидно, что решить проблему может не только промежуточный контроллер между передатчиком и приёмником, но и вообще любая гальваническая развязка.
PC без проблем принимает 100% байтов на любой скорости и при наличии, и при отсутствии в кабеле проводов квитирования, а УКНЦ принимает байты на любой скорости только когда проводов квитирования в кабеле нет - поэтому скорее всего проблема в том, что при подаче постоянного напряжения с PC через какой-то из проводов квитирования приёмник УКНЦ теряет калибровку нуля.
При реальной работе PC не снимает квитирование вообще НИКОГДА, поэтому использование в кабеле "квитирования на передачу в PC" реально бессмысленно.
Вообще-то проблема может быть еще и в проводах, простой пучок из 5-6-8 проводов - крайне благоприятная среда для взаимных помех и прочей ерунды. По-хорошему, все сигналы надо передавать витыми парами, каждый сигнальный провод свить с земляным, все земляные обязательно заземлить с обеих сторон. То есть, взять кусок UTP, все, допустим, белые провода использовать в качестве земляных, а все цветные - в качестве сигнальных. Очень способствует. Как вариант - ленточный кабель с чередованием земля-сигнал-земля-сигнал...
Помеха в проводе квитирования не может помешать приёмнику УКНЦ больше, чем постоянный уровень в этом же проводе. Можно провести эксперимент - отключить провод квитирования только со стороны PC ( при этом он превратится в АНТЕННУ, специально принимающую помехи ) и убедиться, что все "ошибки чтения" в УКНЦ тут же пропали.
Помехи же в проводах передачи и приёма на работу очевидно не влияют, потому что иначе обмен всегда бы шёл с ошибками.
Так как же тогда работает Объясните пожалуйста, если нужно управлять еще чем-то помимо передачи данных с помощью RTS
- - - Добавлено - - -
RABBIT-1, если не лень попробуйте что-нибудь из предложенного (лучше все :) ), пока мы тут гадаем на кофейной гуще.
Драйвер Windows принимает данные из COM-порта в реальном времени ( вне зависимости от работы программы ) и из-за этого приём COM-порта в PC работает вообще без снятия сигнала квитирования ( и при включённом, и при выключенном квитировании ), поэтому соответствующие провода в кабеле избыточны.
Пример есть в файле конфигурации COM_4.cfg из комплекта эмулятора терминала типа VT52 - там показано, как создавать и использовать лампочки для всех входных сигналов и кнопки для всех выходных сигналов COM-порта.
я так понимаю надо попробовать:
А. Следующие варианты кабеля:
1. http://zx-pk.ru/showthread.php?t=160...l=1#post848179
2. http://zx-pk.ru/showthread.php?t=160...l=1#post848186
3. http://zx-pk.ru/showthread.php?t=160...l=1#post848192
4. http://zx-pk.ru/showthread.php?t=160...l=1#post848208
для всех вариантов использовать настройки:
Б. восстановить схему http://zx-pk.ru/showthread.php?t=160...l=1#post392288 в которойКод:fDtrControl = DTR_CONTROL_ENABLE
fRtsControl = RTS_CONTROL_ENABLE
Parity = NOPARITY
StopBits = TWOSTOPBITS
ByteSize = 8
fParity = FALSE
fOutxCtsFlow = TRUE
fOutxDsrFlow = FALSE
Провод квитирования это Стык С2:7 (109)?
Нужно пробовать все варианты или для понимания можно только некоторые?
результат вида работает/не работает? или еще что-то?
попробовать смогу только на следующей неделе :(
Использовать новый файл загрузчика Boot_RT-11_from_HX0_(176570).bin из архива: Boot_RT-11_from_HX0_(176570_OV4_).zip.
Этот загрузчик сообщает о трёх разных ошибках:
1. Bad Packet - ошибка контрольной суммы.
2. Overrun - ошибка квитирования.
3. Timeout - пакет не передан целиком.
Если при загрузке будут сообщения об ошибках - указать, какие именно.
- - - Добавлено - - -
Проблема в том, что входные выводы квитирования у -065 ( 107 и 109 ) не могут висеть в воздухе - их надо соединять или с COM-портом, или с выводом 108. Поэтому в качестве "антенны" можно взять рабочий кабель ( где соединены выводы 108, 109 и 107 ) и подключить к этой группе все свободные провода в кабеле.
Возникла проблемка :( Когда переобжимал кабель, раздавил разъем IDC-10, так что попробовать варианты кабеля смогу только когда куплю новый. будет это скорее всего после праздников - когда доберусь до радиорынка.
Patron, при загрузке по С2 загрузчик вылетает в СТОП, что ему не нравится?
Подскажите пожалуйста какой вариант схемы подключения использовать а то смотрю приводится куча вариантов? Помню в школе изначально УКНЦшки грузились с УКНЦ у которой был дисковод, а потом поставили PC(Pentium 233 MMX) где была установлена карта к которой были подключены все УКНЦшки в классе и таким образом это всё грузилось) что это за карта была? :) реально купить где-то?
Вбил код из скриншота, ввёл 1000G - и загрузился. Возможно, в ходе загрузки возникает какое-то прерывание ( например, по вектору 0100 ), а обработчика нет - вот и вылетает.
Если в загружаемом блоке по адресу 0100 уже записано 0102, а по адресу 0102 уже записано 2, то надо просто вручную записать то же самое в эти же самые адреса ОЗУ перед запуском загрузчика - и тогда в какой бы момент не произошло прерывание таймера, обработчик для него уже будет на месте.
- - - Добавлено - - -
ТАКОЙ.
Это через штатный СА (сетевой адаптер)
Это делал какой-то кооператив.
Думаю что СА купить/достать легче и дешевле.
Если УКНЦ из школы вероятно он (СА) уже есть, а здесь тема про загрузку через Стык С2, обычно в школьных отсутствует микросхема для работы с С2
Направление было правильным. Проблема на стороне РС, только не в железе, а в программе HX_Server. Перечитал всю тему, потестировал HX_Server и да до сих пор он не реагирует на сигнал RTS т.е. лампочка CTS гаснет но HX_Server продолжает слать байты, отсюда и проблемы с переполнением не только при сжатии.
начало проблемы
http://zx-pk.ru/showthread.php?t=160...l=1#post564770
http://zx-pk.ru/showthread.php?t=160...l=1#post564966
http://zx-pk.ru/showthread.php?t=16001&page=25