johnl@ima.ima.isc.com (John R. Levine) (01/18/89)
Looking at my copy of the PS/2 technical reference, I see that you need to
do a little more to dismiss an interrupt than previously. In general:
... tell the device to turn off the interrupt request
JMP $+2 ; delay
... send EOI to the interrupt controller
JMP $+2 ; delay some more
STI ; turn interrupts back on
IRET ; go back to where you were interrupted
This code is supposed to work on ATs as well.
In the particular case of the diskette controller, the manual says nothing
about how you trigger and reset interrupts, but I suspect that the interrupt
request goes away when you read all of the status bytes back from the
controller. You may need the JMP $+2 between IN instructions when reading
back the status bytes. Also, the high bit of the status byte at port
address 3F0 tells whether there's an interrupt pending. Perhaps a few
experiments with "debug" would show how to make the interrupt request go away.--
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869
{ bbn | spdcc | decvax | harvard | yale }!ima!johnl, Levine@YALE.something
You're never too old to have a happy childhood.crew@pitt.UUCP (Al Crew) (01/18/89)
Yes, I/O devices often spec a "recovery time" between successive accesses to controller chips. (I know this to be true of most of Intel's controllers - 8255/8253/8254/etc). In most cases it is on the order of 1 microsecond. Successive I/O operations to an I/O controller can violate this spec. The wait states inserted by the old pc bus may have "masked" a problem.