Пользуясь случаем вытащил таки последний вариант WD.MAC с винта который готовил falanger'у и на котором собственно и добавил поддержку 64 устройств в одном флаконе. Прошлый вариант который выкладывал был криво считан.
Пользуясь случаем вытащил таки последний вариант WD.MAC с винта который готовил falanger'у и на котором собственно и добавил поддержку 64 устройств в одном флаконе. Прошлый вариант который выкладывал был криво считан.
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
В эмуляторе примерно также, ну может чуть помедленнее. Такая низкая скорость из-за программной обработки прорисовки символов. Был бы чисто символьный экран, то может быть и побыстрее бы было.
В соответствии с этим к Patron-у большая просьба сделать тест, который выводит продолжительное время байт 0, и на основе этого замерить скорость вывода, на УКНЦ должна быть существенно выше (т.к. в данном случае будет отсутствовать прорисовка символов).
Эх, неплохо бы запустить данный тест на КЦГД. Там хоть скорость порта равна 57600, но символы также программно отрисовываются, да к тому же не четко в границах байта, левая половина символа может быть в одном байте, а правая в следующем. Так что тоже должно изрядно подтормаживать.
2500 CPS это 25'000 бод, т.е. примерно в 2.5 раза быстрее, чем на ДВК (там 9'600 бод).
Попробую добавить в начало программы ячейку, чтобы если там -1, то идёт обычный тест, а если старший байт == 0, то 78 раз выводится младший байт, потом <CR> - и так по кругу.сделать тест, который выводит продолжительное время байт 0, и на основе этого замерить скорость вывода
Это позволит измерять скорость отрисовки разных символов.
На ДВК с терминалом (например 15ИЭ-00-013) или КСМ скорость ограничена скоростью последовательного порта. На УКНЦ в 1801ВП1-120 никакого последовательного порта нет, там информация передается параллельно в ПП, так что все ограничено только скоростью программы обработки поступающей информации, поэтому и видна скорость подпрограммы обслуживания текстового терминала. Там есть буфер на 128 символов, но по всей видимости он довольно быстро заполняется и далее скорость равна фактически скорости п/п отрисовки символов.
Буду очень благодарен, думаю скорость в данном случае сильно возрастет, т.к. будет работать п/п обработки управляющих символов, а в памяти существует таблица обработки управляющих и Esc-последовательностей, так что выберется по таблице команда RETURN, и на этом все закончится.
По поводу рисует ужасы - к сожалению есть в подпрограммах обработки текстового терминала и п/п приема информации по К0 два очень слабых места.
Ячейка 7064 служит в качестве индикатора вызова п/п управления текстовым терминалом в диспетчере процессов и одновременно счетчиком принятых по каналу K0 символов. Так вот в п/п управления текстовым есть два забавных пируэта: по адресам 110756 и 111122: там делается сначала INC @#7064, а затем DEC @#7064. На команды DEC есть переходы, туда переходят после обработки очередного символа, а INC делается в самом начале программы обработки, соответственно потом DEC, чтобы не нарушать отчетность. INC делается из-за того, что п/п написана так, что DEC не избежать, сначала увеличили, потом уменьшили и в итоге осталось тоже самое, т.к. еще ничего не обработали.
В п/п обработки приема информации по каналу K0 по адресу 175706 командой CMP @#7064,#177 проверяется переполнение буфера. Нет бы дальше задействовать команду BHIS, но проверяется командой BEQ.
А теперь представим себе, что буфер заполнен, 0177 символов, работает п/п обработки текстового терминала, делается INC @#7064, а после этого производится прерывание по каналу K0. В ячейке соответственно 0200, сравнение не проходит и далее в буфер пишется информация, принятая по каналу K0, @#7064 еще увеличивается на единицу. При отрисовке символов может еще чего нибудь прийти, быстро обрабатываются только некоторые управляющие коды. Ну и т.д. и т.п.
Новая версия программы тестирования скорости портов CPS.SAV ( v1.5 )
Добавлены следующие параметры запуска:
1. В слове по адресу 01020 - байт (младший) для вывода. Если в этом слове установлен знаковый бит - байт не используется и тестирование осуществляется в обычном режиме.
2. В слове по адресу 01022 - длина строки для вывода тестового байта ( строка создаётся в памяти "позади" программы, если затрёт систему - тест не пострадает ).
3. В слове по адресу 01024 - кратность усреднения при "спецрежиме". Допустимые значения: 1, 2, 4.
Если тестирование выводом байта производится для выходного порта с той же базой, что и у входного порта - тогда тестирование проводится в спецрежиме: сначала молча накапливаются данные 2, 3 или 5 секунд (в зависимости от кратности усреднения ) - потом тест сам завершается и выводится результат.
При тестировании "постороннего" порта выводом байта - тестирование идёт непрерывно с непрерывным выводом измеренных значений CPS на "контрольный" терминал. После завершения теста - значение CPS выводится также и в тестировавшийся порт .Код:.GET CPS .E 1000-1024 177560 000060 177564 000064 000000 000000 000062 000100 177400 000116 000002 .D 1020=43 .ST CPS - CHECK TERMINAL OUTPUT SPEED - V1.5 PRESS ANY KEY TO EXIT WAIT SECONDS: 3 CPS: 5738 ############################################################## PROGRAM COMPLETED
В эмуляторе скорость при выводе нулевого байта, длина строки 07777, кратность 4 - 4867 символов в секунду. Да, я надеялся на большее.
С длиной строки 077777 доходит до 5959 символов в секунду.
Кстати, в эмуляторе тоже получил мусор при выводе, заменил в образе СПЗУ команду с BEQ на BHIS - мусора больше не появлялось.
Честно говоря, вряд ли длина строки на что-то может сильно влиять. По сути дела - это просто отношение числа выводимых тестовых байтов к числу выводимых байтов <CR>.
Другое дело, что счётчик выведенных символов 16-битный, поэтому при высокой скорости он переполнится за 4 секунды уже при 16'000 CPS.
Поэтому, начинать тестирование быстрых портов лучше при кратности 1.
Тестовый вариант упрощенного драйвера.
Работает только по прерываниям, только с двусторонними 80-дорожечными дисководами.
Отличие от прошлого варианта - не инсталится если контроллера нету и не занимает системные таблицы.
Требуется RT-11 V05.02 или новее.
Кто с игрушками балуется, просьба помучить на предмет конфликтов с игрушками, грузящими свой код в ПП и ткнуть пальцем если будет найдена несовместимость.
В архиме MZ.SYS для систем без поддержки таймера для драйверов, MZTM.SYS с поддержкой и исходники.
Последний раз редактировалось form; 07.12.2011 в 20:49.
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)