kamath@reed.UUCP (Sean Kamath) (02/13/86)
Hello networld.
I've been trying for some time now to generate interrupts with the mouse
in a //e. My problem seems not to be with generating the interrupt, nor
in handling it, but in quiting the interrupt routine. What I have is a
very simple scheme. I tell the mousecard to send an interrupt when the
mouse button is down. Then I increment a number on the screen. Easy,
no? Well, as soon as my interrupt routine gets called, numbers start
flashing on the screen at machine language rate. I know that what is
happenning is that my routine end with an RTI, but as soon as the RTI is
cleared, the //e thinks that there is still an interrupt pending, and
calls my routine again right away. I know this because My machine locks
up. This doesn't happen on a //c. In fact, things are a LOT simpler on
the //c for mouse programming, i.e. you don't have to load x with $Cn
and y with $n0 (n being the slot #), you don't have to call initmouse,
and the damn thing gives up the interrupt when it's done.
So, anyone out ther with experience with mousecard interrupts? Do I
absolutely need to call servemouse after I get an interrupt? The //e
Technical Reference Manuel states the my routine must clear the
appropriate interrupt softswitch, but conveniently forgets to tell not
only where the softswitches for interrupts are, but that they even
exist. Does anyone know about these? Could perhaps someone send me a
working source for interrupts on a //e w/mouse that doesn't "turn on"
the mouse? You see, I don't want to have the mouse on. Do I have to?
Questions, question, questions. If I get it working I'd love to put out
some PD interrupt software...
Thanks in advance
Sean Kamath
--
________________________________________________________________________________
UUCP {ihnp4,decvax,ucbcad}!tektronix!reed!kamath
And I looked again
And the monster was me...