При каких условиях возникает прерывание IRQ 7 ?

Пишется обработчик для прерывания от LPT  (ассемблерная вставка).

Сейчас отлаживаю это под ДОС.

Перехватываю прерывание int 0Fh через 25-ю функцию ДОС, но написанный обработчик управление почему-то не получает.
Баги в коде более чем возможны; их поиском я занят. Но хотелось бы услышать, когда именно это прерывание возникает? Реально, а не теоретически.
Какие сигналы и условия.
У меня оно и раньше никогда не работало (но и не нужно было).

Когда оно разрешено (см. порт 21h контроллера прерываний). 
В ДОСе оно обычно маскировано, принтер обслуживается по поллингу. Из общеизвестных программ его используют только программы передачи файлов через принтерный порт.

Прочитал 21-й порт. Старший бит соответствующий IRQ 7 - установлен.
Порт 37A, бит 4 (Еnable) устанавливал как в 0, так и в 1 -никакой разницы.
Сигнал ACK (контакт 10 разъема) подаю в ручную.

Можно конечно думать, что что-то в коде, но если б баг, то зависание какое-нить, глюк хоть какой-нибудь был бы, а то - ноль эмоций!
Полное впечатление, что прерывание не возникает.

Чтобы избавится от сомнений в корректности кода и проверить: способен ли написанный обработчик хоть что либо возвращать в программу, по чему можно понять что он запускался, я сделал следующее.
Вызвал int 0Fh из совсем другого места программы штатными средствами языка. Обработчик запустился и возвратил результат, который был принят в программе, как и ожидалось.
Таким образом, могу с уверенностью говорить, что обработчик работоспособен; это прерывание не возникает.

  Помогите понять, почему.

посмотрите вот это
http://www.pcports.ru/xDRV_sys.php

Какое именно событие, по Вашему мнению, должно привести к возникновению запроса на это прерывание?

Если верить справочнику, то оно должно происходить, когда ACK (конт. 10) устанавливается в 0.
Но на практике этого не происходит. Во всяком случе мне не удалось получить ни разу.
А у кого-нибудь реально происходило? Реально на компе, а не по литературе?

airyashov: очень интересная статья! Вот бы под VB это прикрутить.
Но пока все-таки я предпочту DOS, потому что прерывание мне нужно для возможно более быстрого считывания состояния порта по стробу. А Винда, прежде чем передать управление драйверу, много всяких операций делать будет, а потом еще сам драйвер, пока функцию вызовет, а потом еще само приложение, пока выполнит команду чтения с порта, опять же через драйвер...
Так что этот вариант я отложу на вторые роли, в случае если заработает первый.
Я думаю, что гораздо меньшее время я получил бы, если бы сделал в досе простой цикл непрерывного опроса порта на асме.

если вы пользуетесь принтером, то под DOS встречал такое в "Брэдли Д.Программирование на  языке ассемблера для  IBM PC":
Один из управляющих битов порта 3BEH (или 37AH) управляет
    линией прерывания от печатающего устройства. Для того, чтобы
    печатающее устройство могло посылать свой сигнал прерывания в
    контроллер 8259, этот бит нужно установить равным 1. Однако адаптер
    печатающего устройства выдает неверный сигнал прерывания, т.е.
    выбранный для этой цели сигнал не вызывает правильного прерывания.
    Поэтому не стоит и пытаться писать программу, которая бы
    использовала возможности прерывания от адаптера печатающего
    устройства (если вы не захотите физически изменить плату
    печатающего устройства). Далее мы приведем пример, который обходит
    эту проблему с помощью системного таймера.
Возможно в BIOS отключено прерывание для LPT, думаю Вам ничего не мешает проверить и под Windows.

Во-первых, этот бит, как я выше уже писал мною устанавливался. (Кстати, в справочнике написано, что должно быть 0. Я пробовал и 0 и 1).
Во-вторых, сигнал прерывания формируется мною сейчас в ручную (на резисторе), и может быть сделан как в 0, так и в 1, что я тоже испробовал, и так же безрезультатно.
В третьих, в БИОС я залез. Там есть настройка периферии, и LPT на выбор можно установить IRQ. У меня выбрано 7.
Кроме того в БИОСе есть переключение режимов порта: Normal, Bi-Dir, EPP, EPP+ECP. Я попробовал каждый. Прерывание не возникало ни в одном.

Если Бредли так категоричен, что "не стоит и пытаться", это наводит на размышления. Очевидно у него тоже не заработало и он не нашел причину этого.

А Вы сами лично, уважаемый airyashov, работали собственноручно с прерыванием от LPT или нет?

Добавлено через 5 минут и 45 секунд
ЗЫ. 
Нет, не пользуюсь принтером, а делаю прогу для приема данных через LPT, причем передающее устройство не квитируется(((((
А принтер и без прерываний хорошо работает.

Не, я ща помру! 

Прерывание не имеет никакого отношения к событиям на контактах разъема! Прерывание происходит  по окончании  вывода символа  (на печать) - т.е. оно свидетельствует, что помещенный в регистр данных байт выставлен на внешних цепях! Все!

Значит справочники врут?..
Пожалуйста посмотрите статью, на которую дал ссылку airyashov выше; особенно ее конец.
И, умоляю Вас, не помирайте. Вы нам нужны даже такой  

Это сообщение отредактировал(а) JusTalionis - 28.7.2008, 13:00

Смотрел. Если учесть что С++ (да и Дельфи) для меня тёмный лес... но даже мне понятно, что сам драйвер предлагается в форме черного ящика. На что он там реагирует - я лично не в курсах, и соответственно понятия не имею, что вызывает возникновение вызова обработчика прерывания, если оно вообще возникает на самом деле за счет генерирования IRQ7.

Тем не менее, автор статьи тоже считает, что прерывание должно вызываться сигналом на 10-ом контакте.
Может быть он заблуждается?

Запрос аппаратного прерывания (обычно IRQ7 или IRQ5) вырабатывается по отрицательному перепаду сигнала на выводе 10 разъема интерфейса (Ack#) при установке CR.4=1. Во избежание ложных прерываний контакт 10 соединен резистором с шиной +5 В. Прерывание вырабатывается, когда принтер подтверждает прием предыдущего байта. Как уже было сказано, BIOS это прерывание не использует и не обслуживает.
http://www.sibsutis.ru/~mavr/PC/LPT/1.HTM