home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / msdos / programm / 11446 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  1.4 KB
  1. Path: sparky!uunet!news.tek.com!sail!toma
  2. From: toma@sail.LABS.TEK.COM (Tom Almy)
  3. Newsgroups: comp.os.msdos.programmer
  4. Subject: Re: Bypassing BIOS key interrupts...
  5. Message-ID: <13053@sail.LABS.TEK.COM>
  6. Date: 16 Dec 92 17:07:08 GMT
  7. References: <eball12.724465747@ursa>
  8. Reply-To: toma@sail.labs.tek.com
  9. Organization: Tektronix, Inc., Beaverton,  OR.
  10. Lines: 27
  11.  
  12. In article <eball12.724465747@ursa> eball12@ursa.calvin.edu (Edward Ball) writes:
  13. >I've noticed that in some games (Star Control II, for example) multiple
  14. >key presses can be detected at the same time, on or off.  I can only
  15. >assume they use the BIOS key scan codes for pressing and releasing keys.
  16. >My questions is, how do you bypass the standard keypress buffer (or 
  17. >whatever it is called) and just read the scan codes without having to
  18. >worry about pulling such keypresses off the buffer or worrying about
  19. >repetition speed or anything like that?  
  20.  
  21. For any system but the original PC and PC/XT, there is a software int
  22. you can monitor.
  23.  
  24. Link into int 15H, and check for AH=4FH (if not, jump to original handler).
  25. AL=key scan code (MSB is set for key release, clear for key press)
  26.  
  27. Return with carry clear on keys you handle, return with carry set if you
  28. want the BIOS to handle the key.
  29.  
  30. Note that because of typematic, there can be multiple press codes for each
  31. release code.
  32.  
  33.  
  34.  
  35. -- 
  36. Tom Almy
  37. toma@sail.labs.tek.com
  38. Standard Disclaimers Apply
  39.