jimb@tekcbi.UUCP (05/27/86)
I know that the keys on the IBM PC all emit strange codes and that according to the DOS manual, all keys have an extended ASCII code. If I run a program that "quotes" a key that is typed, I can see all keys except "5". How do you detect that key. I know it can be done as Crosstalk, Smarterm, etc. detect it but I don't know how they do it. How is it done??? I want to add it to my MicroEmacs. Thx. Jim Boland tektronix!tekcbi!jimb
bc@cyb-eng.UUCP (Bill Crews) (06/01/86)
> I know that the keys on the IBM PC all emit strange codes and that according > to the DOS manual, all keys have an extended ASCII code. If I run a program > that "quotes" a key that is typed, I can see all keys except "5". How do > you detect that key. I know it can be done as Crosstalk, Smarterm, etc. > detect it but I don't know how they do it. > > How is it done??? I want to add it to my MicroEmacs. > > Jim Boland DOS calls stick to ASCII or "extended ASCII". To get to all keys, you must use BIOS and deal with the scan codes. This is something I have done a lot, but it must be understood that compatibility with other MS-DOS machines is sacrificed, and it is possible to have problems maintaining compatibility with other programs concurrently contending for the keyboard (like, maybe Sidekick). Try looking at int 16 in the BIOS listings of the IBM PC Technical Reference Manual. -- - bc - ..!{seismo,topaz,gatech,nbires,ihnp4}!ut-sally!cyb-eng!bc (512) 835-2266
nather@ut-sally.UUCP (Ed Nather) (06/03/86)
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 was done. The IBM manual tells you the mapping between these "NULL- escaped" codes and the ASCII character set, but their chart is thoroughly confusing and I couldn't figure it out; I wrote a small program to print out this "second code" when a keypad or function key was pressed. Works like a champ. And, look ma! No bios calls! -- Ed Nather Astronomy Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather@astro.AS.UTEXAS.EDU
bc@cyb-eng.UUCP (06/03/86)
> 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 > was done. The IBM manual tells you the mapping between these "NULL- > escaped" codes and the ASCII character set, but their chart is thoroughly > confusing and I couldn't figure it out; I wrote a small program > to print out this "second code" when a keypad or function key was > pressed. Works like a champ. And, look ma! No bios calls! > -- > Ed Nather You cannot get *all* keys with these codes, Ed. For instance, the original article asked about how to get at the 5 key when all modes are off, and there is no such code for that key. What you have just described is IBM's definition of "extended ASCII", which is what I was referring to. These codes are documented in the BASIC manual (page D-7 in the 3.0 BASIC manual) and maybe somewhere else. The only confusing part to me relates to new or Brand X keyboards and how keys such as keypad keys that have been separated from cursor keys return values. But then I have the same confusion with respect to scan codes (BIOS) for these keyboards. Maybe if I were to buy a new Tech Ref . . . (or such a keyboard). -- - bc - ..!{seismo,topaz,gatech,nbires,ihnp4}!ut-sally!cyb-eng!bc (512) 835-2266
jrv@siemens.UUCP (06/04/86)
Whether you use DOS calls or ROM BIOS (Int 16) calls you are *not* going
to get anything for the "5" key on numeric pad unless the key pad is in
numeric mode. The ROM BIOS keyboard interrupt handler prevents this. A
make/break code is sent from the keyboard but nothing gets put into the
ROM BIOS keyboard buffer. To get this information you will have intercept
the keyboard interrupt (Int 9) and handle scan codes directly. I have done
this and used the ROM BIOS interrupt service to process all those scan
codes which were not of special interest. Then use the original Int 16
routine to get the processed codes from the ROM BIOS keyboard buffer. This
data along with my processing of the special scan codes went into my
own keyboard buffer for access by a new Int 16 routine.
Jim Vallino
Siemens Research and Technology Lab.
Princeton, NJ
{allegra,ihnp4,seismo,philabs}!princeton!siemens!jrvcurl@wjvax.UUCP (06/07/86)
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