From:	"A.Appleyard" <A DOT APPLEYARD AT fs2 DOT mt DOT umist DOT ac DOT uk>
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Date:	Fri, 17 Feb 1995 09:31:08 GMT
Subject:	Re: interrupt handlers

Kimberley Burchett <OKRA AT max DOT tiac DOT net> wrote:-
> I have a kind of interrupt handler. It's for the mouse so what happens is
> the mouse driver is called (in real mode) and then it calls my handler (via
> a real mode callback). All of this works just fine until I call another
> function from inside my handler. ...

I recently found about this interrupt call:-
AH = 5, CH = xx, CL = yy, int 0x16
inserts into the keyboard keypress buffer an entry as if you had pressed a key
with scan code xx, ascii code yy. If yy==0, it is treated as a `special key'
like F1-F12 etc (which on some read-a-keystrokes read first 0 and then the
scan code).
On exit, al = 0 for success, 1 if the keyboard buffer was full.

I call it thus:-

int inject(int C){
_ax=0x500;
_cx=C<0?((-C)&0xff)<<8:((C&0xff)<<8)+(C&0xff);
int16();
return !(_ax&1);}

where C is 0 to 255, and `-C' represents the special keycode numbered C.

My mouse interrupt handler merely examines the mouse status and calls
inject(). The effect is to treat the mouse as a number of extra keyboard keys,
e.g. left button click could be treated as `special key 255'. All intricate
program work is done not in interrupt while the system is kept waiting, but
outside the mouse interrupt call after the next call of read-a-keystroke.

(A book of interrupt info that I have says that on a PCjr `AH=5, int 0x16'
instead means `change keyboard layout language'. What is a PCjr and how common
are they? This incompatibility between makes of PC threatens to be slightly
disastrous to me.)

- Raw text -