(2<FPZdefnx‚ƒŒ– ª«´¾ÈÒÜæðú
The protocol is implemented in

the form of a driver under both RSX-11M and RT-11.  During

testing of this software we came across a strange problem.  From time
"
to time, under some timing conditions, the DR11-W became interrupt
,
disabled.
6
  Although the IE bit in the hardware was set, the raising of the
@
ATTN bit failed to cause the ERROR bit to be set and so failed to
J
cause the device to interrupt.  Once this situation occurred we 
T
found that the only way to re-gain the interrupt capability was
^
to either do a bus reset or to reset the device, by setting the
h
maintainence mode bit and clearing it again.
r
   This latter type of reset itself led us to discover a further
|
unpleasant feature of the device, which we will describe below.
†
.sk 2
�
.hl 1 Losing Interrupt capability
š
We investigated the problem in some depth.  Such features as
¤
reading out the error register (by writing the error bit of the
®
CSR) and then resetting the CSR, reading back the last data word
¸
read in on a DMA were investigated.  In fact none of these seemed
Â
to be related to the problem.  We believe that the problem can
Ì
be demonstrated by the following test - either as a privileged
Ö
task under RSX-11M, or as a standalone test.
à
.sk 2
ê
A task connects to the DR11W interrupt vector and supplies an
ô
interrupt handler routine.  In the interrupt routine it 
þ
immediately resets the CSR of the device - re-enabling the
interrupt, by resetting with octal 100.  
The interrupt routine now delays for a few hundred instructions
before exiting from the interrupt.
&The main loop of the
0program can loop reading the CSR of the device and perhaps
:writing it out to a display register.
DIf desired it may check for the error condition, which shows itself
Nas a persistent condition where the ATTN bit is set, but the ERROR
Xbit is not.  This can also be seen from the display register if used.
bA program on the partner machine should repeatedly toggle the FNCT2
lbit in its CSR in order to attempt to repeatedly interrupt the 
vother machine.  Some variable time delay between attempted interrupts
€can be introduced.  By varying both the delays between repeated
Šattempts to interrupt 
‹on one machine, and the amount of time spent in the interrupt
”routine on the other machine 
•(at device priority), the symptoms of the problem can be
žproduced.
¨We therefore believe that this problem is not connected with the
²process of using the device to do DMA's but rather with the
¼timing of the interrupt handling versus the interrupt production.
Æ 
Ð  We have modified our software to whenever possible avoid the
Úsituation of having a machine interrupt its partner machine very
äsoon after the partner machines DR11-W is already "interrupting".
î.sk 2
ø.hl 1 Reset Problem
Since we could not be sure to avoid the above problem we decided to
also use the maintainence mode bit reset mechanism whenever we 
had to restart our protocol on the link.  In doing this we discovered
 the following feature.  If the IE bit on the device is set 
*immediately after or at the same time as clearing the MAINT bit then
4the device does not remain interrupt enabled.  The IE bit 'fades' away.
>A delay of at least 5 instructions must occur after resetting the
HMAINT bit, before attempting to set the IE bit.  This feature can
Rbe easily demonstrated on a single machine with a test program
\which sets the MAINT mode bit, clears the CSR then waits for some
fnumber of instructions before setting the IE bit, then reads back
pthe CSR immediately and after some long time delay.