Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!pyramid!pesnta!wjvax!curl
From: curl@wjvax.UUCP
Newsgroups: net.micro.pc
Subject: Re: READING PC/XT KEYPAD
Message-ID: <707@wjvax.wjvax.UUCP>
Date: Fri, 6-Jun-86 17:15:44 EDT
Article-I.D.: wjvax.707
Posted: Fri Jun  6 17:15:44 1986
Date-Received: Sat, 7-Jun-86 13:42:26 EDT
References: <728@tekcbi.UUCP> <868@cyb-eng.UUCP> <5059@ut-sally.UUCP>
Reply-To: curl@wjvax.UUCP (Jim Curl)
Distribution: na
Organization: Watkins-Johnson Co., San Jose, Calif.
Lines: 18

In article <5059@ut-sally.UUCP> nather@ut-sally.UUCP (Ed Nather) writes:
>In article <868@cyb-eng.UUCP>, bc@cyb-eng.UUCP (Bill Crews) writes:
>> DOS calls stick to ASCII or "extended ASCII".  To get to all keys, you must
>> use BIOS and deal with the scan codes.  
>
>Not so.  Read in a keyboard character using, say, "c = fgetc(stdin)" or
>whatever, then test for "c == NULL".  If it IS NULL, then bring in the
>character following, which tells you which "extended code" keystroke

The BIOS keyboard interrupt service routine does not translate all possible
keys into ascii or extended ascii (i.e. NULL + a code) sequences.  The keypad
`5' key is one such example.  Doing a "c = fgetc(stdin)" will produce no result
if this key is struck since the BIOS simply ignores the key.

I believe that the only way to read such keys is to intercept the keyboard
interrupt and process the raw scan codes yourself (probably painful).

Jim Curl