Specifications

42 Software Interface
3.3.2 Interrupts
There are two ways to manage data flow between the host and the DTC04
module. One way is to use the fixed fields at the beginning of each data
buffer in the command and message rings. This method is described
in Section 3.3.1. Using these fixed fields, the host can perform all ring
management by polling each ring to find out when buffers are full or
empty.
The other way to manage data flow is to use interrupts. The DTC04
module implements interrupts. This lets the host manage the rings by
using interrupts instead of by polling. This is the recommended way to
manage data flow.
3.3.2.1 Interrupt Scheme
The interrupt scheme works as follows. The module sets the HA (host
alert interrupt) bit in the CSR to alert the host that data movement has
occurred in the rings. The host should check the flag fields of the buffers
at its load and unload pointers to determine the appropriate action.
Because the module microcode is interrupt driven, the host must set the
MA (module alert interrupt) bit in the CSR to alert the module that the
host made changes to the rings.
The interrupt handler on the interrupted device must acknowledge
(reset) the appropriate alert interrupt before checking the rings. The
interrupting device must request (set) the appropriate alert interrupt
after changing the rings.
Interrupt handlers must be able to handle extra interrupts. It is possible
for the interrupting device to request an interrupt after the interrupted
device has ackowledged the interrupt, but before the interrupted device
checks the rings. In this case, the first interrupt handles any changes to
the rings and the second interrupt is extra.
The module requests a host alert any time it changes the module status
(MS) field in the control and status register. This informs the host of a
change in module status and lets the host initialize the module in an
interrupt-driven manner. The module interrupts the host using BIRQ4,
which is VAX IPL 20.