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
HX прерывания не запрещает, поэтому таймаутов не будет только при работе с ним самим.
Насколько я понял - добавить в HX возможность использования прерываний несложно, но всё равно - чтобы HX успешно работал на скорости 57600 без квитирования - нужно, чтобы в обработчике прерывания таймера не запрещались прерывания.
А толку с этих прерываний? Программа-то заблокирована напрочь.
---------- Post added at 16:22 ---------- Previous post was at 16:19 ----------
А может нужно правильно писать обработчики прерываний?
Есть четкие рекомендации сколько инструкций может выполнить обработчик на уровне прерывания. Если обработчик в них не вписывается, надо использовать FORK.
Обрабочтк таймера на уровне прерываний очень мало времени проводит и мешаться не должен нигде.
Последний раз редактировалось form; 25.02.2013 в 13:24.
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
Если работа c HX идёт через общий порт с терминалом - программа будет заблокирована и при поддержке в HX прерываний.
Только когда HX работает через свободный порт - поддержка прерываний может иногда дать выгоду.
Но и тогда - работа без квитирования на скорости 57600 будет возможна только при разрешённых прерываниях в обработчике прерывания таймера.
Неверно.
Неблокировка программы не обязательно подразумевает ее работу с терминалом. Кроме того в 5.6 и 5.7 даже без переделки системы легко реализуется и работа с терминалом без блокировки (ну или с задержками за счет неудобного протокола).
А зачем их запрещать?
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
Размещение рекламы на форуме способствует его дальнейшему развитию
Патч для IND, исправление <DATE>.
Теперь SYSGEN под ним можно делать...
Применение:Код:.UNP IND.SAV [email protected]
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
А можно вот эти релизы в той теме про Y2K с опросом делать?
Просто что-бы удобней было собрать потом все нароботки в рамках одной темы,
по форуму искать - затеряются через пару месяцев, я тут кстати что-то вроде
справочника по сообщениям в этом разделе из разных тем (типа закладок) собираю потихоньку, потому-что столько софта и программ раскидано и есть очень полезные авторские комментарии, другой момент что некоторые вещи уже довольно глубоко зарыты, особенно для совсем-совсем вновь прибывших, ну ты и сам понимаешь.
На использовании именно мной созданной темы я не настаиваю, просто подумал,
что так было бы удобней. Для TSX так-же (что бы отдельную не создавать - ведь
это грубо говоря очередной этап развития RT-11) предлагаю в ту же тему постить. В шапке можно будет ссылки с других тем ещё добавлять и обновлять.
Драйвер XL.SYS испытывает проблемы при работе через IP ( а также через пакетные варианты адаптеров USB-COMport ) когда его внутренний буфер не может принять все байты, приходящие в пакете за один раз.
Возможно два решения:
1. Увеличить размер приёмного буфера (необходимый размер зависит от многих факторов - нужно собрать статистику ).
2. Отключать прерывания в приёмном порту при исчерпании буфера (хуже не станет) и снова включать при освобождении буфера - это радикально поможет на портах с квитированием.
---------- Post added at 21:40 ---------- Previous post was at 21:24 ----------
Проблемы также возникают при любом размере буфера, когда оставшееся в нём свободное место недостаточно для размещения данных очередного пакета.
В качестве возможного решения проблемы предлагается вариант драйвера XL.SYS с буфером 512 байт и отправкой Xoff после накопления в буфере 32 байт.
...
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)