Это может отличаться, если передаются несколько байт, а когда идет сплошной поток, то все упирается в скорость порта.Цитата:
Сообщение от Patron
Вид для печати
Это может отличаться, если передаются несколько байт, а когда идет сплошной поток, то все упирается в скорость порта.Цитата:
Сообщение от Patron
Вот и я так думал.Цитата:
Сообщение от Alex_K
Но если байт принимается с шины сразу в сдвиговый регистр ( как в эмуляторе ДВК ), то между установкой IRQ и поступлением нового байта в регистр данных ( он же сдвиговый регистр - в эмуляторе ДВК ) никакая передача не производится.
Я все эти годы не мог понять, почему на реальной ДВК-1 CPS.SAV показывает 960 CPS, а в эмуляторе - максимум 937 CPS ( и это после всех улучшений CPS.SAV в результате которых промежуток между началом обслуживания прерывания готовности вывода и отправкой очередного байта в порт составляет всего несколько тактов CLC ).
А дело оказалось в том, что пока реальный порт передаёт байт из сдвигового регистра - приём следующего байта в регистр данных происходит в то же самое время.
Здесь я согласен. В реальности при передаче сплошного потока между передаваемыми символами отсутствуют промежутки. А в эмуляторе были промежутки, которые связаны с передачей нового символа в регистр данных, обработки прерывания, потому чуть медленнее и получалось.Цитата:
Сообщение от Patron
palsw, а пробовали что-то УК-НЦшное запускать? Тесты типа TS, TUK изначально вы же что-то такое просили в виде WAVе - интересно посмотреть картинку, что работает УК-НЦшный именно софт, игрушки по шнурочку, а не тесты под RT-11 ? Для этого монтируйте диск с программами и запускайте с него нужные файлы. Всё как с тестами которые ранее запускали.
Аппаратное не квитирование а паритет по чет/нечет.Цитата:
Сообщение от Alex_K
Да только пока программа которая читает и пишет в регистры успевает за скоростью порта что и наблюдается в Ваших экпериментах.Цитата:
Сообщение от Alex_K
Так что RR и BSYD это DSR и DTR. Так же можно посмотреть временные диаграммы в справочниках и увидеть что RR и BSYD выставляются задолго до начала передачи и после окончания всей посылки, а RTS/CTS работает по старт/стоп битам.
В 1801ВП1-065 квитирование также аппаратное. Я уже писал, чтобы его не задействовать, то надо вывод BSYD посадить на землю, а RR оставить висеть в воздухе. Не верите почитайте этот топик, пишет специалист anonymous с bk0010.org, который много поработал с нашей советской техникой.Цитата:
Сообщение от Vamos
Ссылку на справочники в студию. Кстати выставляется только RR, а BSYD это вообще-то вход, он получается.Цитата:
Сообщение от Vamos
Микропроцессоры и микропроцессорные комплекты интегральных схем. Шахнов В.А. Том 2 стр 34-38
МикроЭВМ книга 2 Под ред Л.Н. Преснухина стр 42-46.
Вы же тоже не верите схеме кабеля приведенной tnt23 и мной, а работает, причем работает аналогично схеме с задействованными RR и BSYD.
Vamos, в этих справочниках описана 1801ВП1-035, у нее нету выхода RR, он появился только в 1801ВП1-065. Вся эта эпопея с квитированием связана с тем в какой момент времени исчезает сигнал RR, чтобы PC не пересылала следующий байт на УКНЦ. Кое-какая информация про 1801ВП1-065 есть в ТО на КТЛК, т.к. он построен именно на 1801ВП1-065.Цитата:
Сообщение от Vamos
---------- Post added at 19:31 ---------- Previous post was at 19:25 ----------
А теперь по поводу кабеля - да он будет работать, но не столь корректно. Все дело в том, что в стыке С2 вход 7 (сигнал 109) закрывает прием информации извне. И если на выходе RR будет неактивный уровень, т.е. получили байт данных в приемник, но еще не успели прочесть, то вход просто закроется. И если в моем варианте кабеля данные пойдут на вход но зафиксируется ошибка переполнения, то в вашем варианте они просто не попадут на вход и об этом Вы не узнаете. Так же останется в неактивном уровне и вход BSYD, а значит посылки не смогут уходить наружу. Т.е. в данном варианте можно работать только в режиме полудуплекса, но не полного дуплекса. Также почему-то вариант вашего кабеля не смог работать с TU58.Цитата:
Сообщение от Vamos
Кое-что из интернета:
"Применяемые в IBM PC приемопередатчики 8250/16450/16550 сигнал CTS аппаратно не отрабатывают, а только показывают его состояние в регистре MSR. Реализация протокола RTS/CTS возлагается на драйвер BIOS Int 14h, и называть его “аппаратным” не совсем корректно. Однако существуют и иные приемопередатчики (например, 8251), в которых сигнал CTS отрабатывается аппаратно."
hobot, Еще нет,пока занят был развозкой калачей :)