Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rice!uw-beaver!zephyr.ens.tek.com!tektronix!percy!parsely!bucket!leonard
From: leonard@bucket.UUCP (Leonard Erickson)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: Sys Req - key.
Keywords: SysReq
Message-ID: <1806@bucket.UUCP>
Date: 10 Dec 89 02:47:55 GMT
References: <187@nmtvax.nmt.edu> <1989Dec5.190738.17084@ux1.cso.uiuc.edu> <20358@pasteur.Berkeley.EDU>
Organization: Rick's Home-Grown UNIX; Portland, OR.
Lines: 29

cs9a-ax@dorothy.Berkeley.EDU (Mike Morrison) writes:

>This is at least partially false.  On my machine, an XT clone, the sys-req
>key DOES use int 09.  (int 15h is for cassette io).  It generates ascii 00, 
>scan code 37h.  When num-lock is on it generates ascii 77h, scan code 54h.
>The rest of the posting sounds ok to me, though -- I don't have any idea what
>the key is supposed to be used for.

The SysReq key first appeared on the AT, thus it's operation on the PC, XT,
and clones on them is non-defined. The scan codes don't matter. The BIOS
processes the scan codes, and that is where an AT BIOS would use INT 15h.
(remember, the AT didn't have a cassette port). 

A similar situation situation exists with respect to using an extended
keyboard on one of these machines. The keyboard may have the extended
layout, but the scan-codes it sends are those that the XT understands.

BTW, 00h 37h is *not* the scan code for SysReq. It's the keycode. That's
what the BIOS translates the scancode to. Except for a couple of keys on
the extended keyboard, the scan code for a key is always the same. 
The code for SysReq is 54h. But it takes an incredibly low-level access
to the keyboard to ever see scancodes. (hint: the shift keys send scan
codes, so if hitting shift doesn't result in a value, you aren't getting
the scancodes.
-- 
Leonard Erickson		...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I'm all in favor of keeping dangerous weapons out of the hands of fools.
Let's start with typewriters." -- Solomon Short