From Maurice.Prather@f3.n3673.z1.fidonet.org
Date: Wed, 21 Jun 95 11:53:00 -0700 
From: Maurice Prather <Maurice.Prather@f3.n3673.z1.fidonet.org>
Newsgroups: fido7.80xxx
Subject: Scan Codes 


CW-> Or, it could be that the Pause key never returns a break code, because (ano
CW-> guess) the break code would end the pause state that the computer is in.  D
CW-> this one sound better?

CW-> Anyway, why didn't you state a reason why you disagree?  I am not going to
CW-> take your word for it, and I would like some proof, or at least another
ide
CW-> guess.

You're right.... I do need to make a better argument.

When you press a key, the keyboard generates a unique 1-byte scan code
that identifies the key (i.e. actual key location).  The leftmost bit of
the scan code is always zero.  When you release the key, *another* scan
code is generated.  The release scancode is simply the press scan code
with the leftmost bit (#7) set to 1 (essentially adding 128).

 Example:  F4 key                Hex             Bin
           press scan code:      0x3E            00111110
           release code:         0xBE            10111110
                                                 ^
                                                 |--- leftmost bit

Please note that these scan codes have no relationship to the
keyboard character's ASCII codes.

In addition to the corresponding scan code, the keyboard also triggers
the Int 0x09 each time a key is pressed or released.  Execution then
passes to the ROM BIOS keyboard interrupt sercive routine.  This routine
reads the scan code from the port (#60).  From there, BIOS will interpret
the scan code and take one of three actions:

 + Special key sequences such as ctrl-break, sys req (alt-sys req for
   101-key), shift-printscreen generate other interrupt requests for
   further processing.

 + Ctrl, Alt, Shift or the "lock" keys will force BIOS to set the
   appropriate bit in the keyboard byte flag.

 + Otherwise, the BIOS interprets the scan code and place a 2-byte code
   into the keyboard buffer.  Every programmer should be able to
   dissect this 2-byte code ....  ascii first, scan code second.

Also, don't forget that all pc keyboards have a built-in repeat feature.
When you hold down a key for a period of time, the scan code is repeated
until the key is released.

Although this is somewhat long winded, you should be able to see why
your system is not paused until you release the ctrl key when you press
the ctrl-brk combination.   Look at a small time slice of the incoming scan
codes...

      ctrl         0x1d   -|
      break        0xe0   -|  press sequence
                   0x46   -|

                   ** ctrl-brk is now complete **

                    0xe0   ---------|    break release sequence automatically
                   0xc6   ---------|    occurs even though you may
                                        not have released the pause/break
                                        key.  I believe that this the
                                        only key which automatically
                                        generates a release code even
                                        though it may not have been
                                        released.

                   0x9d   -|  ctrl release code

If only the pause key were pressed, the scan codes 0xE1, 0x1D, and 0x45
would be generated as the press codes.  Thus, an entirely different
process would occur.

Hope this helps,
Maurice

ps.  In another message, I made reference to #define statements used in
    some of my programs.  I forgot to mention that in order to
    accurately interpret ctrl-c/ctrl-brk sequences, one must monitor
    the previously received scan code (specifically monitor for 0x1d
    and 0xE0).


* OLX 2.1 TD * We are born naked, wet and hungry.  Then things get worse

