dm2368@eecs1.eecs.usma.edu (Fichten Mark CPT) (06/28/91)
> From: Carl David <DAVID1%UCONNVM.bitnet@vm.its.rpi.edu> > [ interrupt 9 discussion deleted] > > I am creating a cryptogram, such that each letter typed by the user > is substituted from a table in memory, such that to get the computer to > operate the player would need to solve the cryptogram, how would I handle > the multiple keys and uppercase lowercase problems? > Thanks for any help you can give me. > I think that you can avoid the interrupt situation completely and just write a program using the ReadKey and KeyPressed routines in TP. When you get a character from ReadKey, change it according to the table you have set up previously (probably an array of some sort) and then write it to the screen. Am I oversimplifying your situation or will this work for you? ____________________________________________________________________________ CPT Mark Fichten | INTERNET: fichten@eecs1.eecs.usma.edu | Captain U.S. Army | @trotter.edu:dm2368@eecs1.eecs.usma.edu | Work: (914) 938-5580 | USENET: rutgers.edu!trotter!eecs1!dm2368 | | harvard.edu!trotter!eecs1!dm2368 | ____________________________________________________________________________
amead@s.psych.uiuc.edu (alan mead) (06/28/91)
dm2368@eecs1.eecs.usma.edu (Fichten Mark CPT) writes: >> From: Carl David <DAVID1%UCONNVM.bitnet@vm.its.rpi.edu> >[ interrupt 9 discussion deleted] >> I am creating a cryptogram, such that each letter typed by the user >> is substituted from a table in memory, such that to get the computer to >> operate the player would need to solve the cryptogram, how would I handle >> the multiple keys and uppercase lowercase problems? >> Thanks for any help you can give me. >I think that you can avoid the interrupt situation completely and just >write a program using the ReadKey and KeyPressed routines in TP. >[and then what to do] >CPT Mark Fichten | INTERNET: fichten@eecs1.eecs.usma.edu | >Captain U.S. Army | @trotter.edu:dm2368@eecs1.eecs.usma.edu | >Work: (914) 938-5580 | USENET: rutgers.edu!trotter!eecs1!dm2368 | Well. Readkey and KeyPressed won't respond to the "shift" keys. I have a couple excellant articles on INT 09---if you want a citation, please email me. [From memory] When a key is pressed or released, the keyboard controller generates a hardware interrupt. The BIOS routine at INT 09 services the keyboard at that time. Servicing a hardware interrupt is somewhat complex (like you have to send a code to the right port when you're finished). I don't pretend to know those details, but I've seen code that appears to work. The BIOS throws away a lot of useful keystrokes--most notibly the KEY RELEASED signals. It also refuses to differentiate between left and right "shift" keys for the sake of backwards compatibility. So to get on with an answer to the original question: What happens in INT 09 when it services the keyboard? The BIOS scans the shift status byte (I don't know which one, but I'd be suprised if it bothers with the more recent one). It ignores many combinations. For those lucky enough to be reported, the BIOS: 1 checks to see if the circular buffer is full; 2a if not--increments the pointer 2a1 places the SCAN code in the high byte of the current word in the keyboard buffer; 2a2 places the ASCII character (well, the IBM ASCII version) into the lo byte of the current word; 2b if so--beeps at you I don't remember how the shift status of the key is incorporated. I *think* the scan code is shifted. I believe the main use of the scan code is to determine which of two identical keys were pressed (ie, on an extended keyboard, was it the "grey +" or the "white +"), and as such hasn't been that much help to me. Somewhere I have a list (not electronic) of what is where. The TP manual has a brief list as well (appendix C). So, to capture each key and especially to "trick" the computer, you will need to install your own INT 09 handler. But if you don't want to write your own, the code from a Turbo Technix article used to be available by anon FTP. I didn't see any familiar names on GArbo or Wustl, but the package below at wuarchive.wustl.edu might be useful, or I could make the above package available to a FTP site. TPENHKBD.ZIP B 8031 901116 TP unit enabling extended keys for std/enh kbd I hope this helps. -alan mead : amead@s.psych.uiuc.edu
bobb@vice.ICO.TEK.COM (Bob Beauchaine) (06/28/91)
In article <1991Jun27.234613.6472@ux1.cso.uiuc.edu> amead@s.psych.uiuc.edu (alan mead) writes: > [stuff, mostly correct, about keyboard processing] >So, to capture each key and especially to "trick" the computer, you >will need to install your own INT 09 handler. But if you don't want to >write your own, the code from a Turbo Technix article used to be >available by anon FTP. I didn't see any familiar names on GArbo or >Wustl, but the package below at wuarchive.wustl.edu might be useful, or >I could make the above package available to a FTP site. > IMHO, the only time that you need to actually trap the interrupt 9 vector is when you want to 1. Trap the shift,alt,ctrl,caps,or numlock keys BY THEMSELVES or 2. You want to keep a key press from reaching another application that might be running, like when you press the hot key for a TSR. At almost all other times, you can get the same functionality by using the BIOS interrupt $16 and monitoring the keyboard status byte in low memory. Far,far simpler, and probably more portable. I have an interrupt 9 handler written in TP, and I never use it except in TSR's. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Bob Beauchaine bobb@vice.ICO.TEK.COM C: The language that combines the power of assembly language with the flexibility of assembly language. "It seems that the less a statesman amounts to, the more he appears to love the flag".