Это я на будущее. Ведь, если исправить эмуляцию прерывания вывода, но не исправить эмуляцию прерывания ввода - "эмуляторная засада" может стать только глубже.
Алгоритм простой: передатчику терминала устанавливается разрешение прерывания после чего выполняется некоторый цикл ожидания, дочтаточный для возникновения прерывания при наличии готовности передатчика (которая обязана наступить независимо от того подключено что-то к устройству или нет). При этом постепенно понижается приоритет процессора (для УКНЦ собственно вариантов нет - так только 4 и 0 бывают).
Vamos, внимательно почитайте, что писал Patron. Он написал абсолютно правильно, что запрос на прерывание возникает, когда предыдущее состояние бита готовности и бита разрешения прерывания по AND было равно нулю, а текущее стало равно единице.
В конце концов посмотрите эмуляцию канала К0 со стороны ЦП (регистры 177560-177566), они по алгоритму установки/снятия запроса на прерывание работают аналогично 1801ВП1-065.
Это был последний релиз эмулятора ?
Вот собственно демонстрация. VDT работает на уровне программы с приоритетом 0. Прерывания не произошло ни при включении прерываний (при наличии готовности) ни при записи в порт...
Смотрел я туда уже, если Вы думаете что копаться в исходниках которые не сам писал, да еще с моими познаниями в программировании на С++ (я даже книжки не одной не читал)... Кому то понятно что написал Patron, а мне нужно разложить подробно по полочкам, пока я не до конца понимаю как это происходит.