rbannon@mira.acs.calpoly.edu (Roy Bannon) (05/29/90)
Greetings folks. I am trying to write a interrupt handler for the keyboard. I want to make the function keys on the extended keyboard do something. Here's the problem in a nutshell. I install my handler with SetVector and it returns fine. The problem is that after its installed and the interrupts are enabled, IntSource, I don't get an interrupt with every key press. I put a brk instruction as the first line of code, and it doesn't break until several keys have been pressed, and then doesn't break again for several more chars. Anybody got any ideas? Anybody at all? Any and all help greatly appreciated. Thanks, Roy rbannon@cosmos.acs.calpoly.edu
crew@pro-harvest.cts.com (Chris Wicklein) (06/05/90)
In-Reply-To: message from rbannon@mira.acs.calpoly.edu I've been trying to do something similar with the //e's keyboard. I don't think either of our keyboards generate interrupts (not sure about your's, though). I would like to design a 'CDAs //e' (wasn't someone else doing this too?), and preferably use both normal ASCI keys and an Apple key as the 'hot key' (OA-ESC maybe). Since the keys and the paddle buttons (Apple keys) don't generate interrupts, how else could I do this? ARPA: crash!pro-harvest!crew@nosc.mil INET: crew@pro-harvest.cts.com BITNET: crew%pro-harvest.cts.com UUCP: crash!pro-harvest!crew "This message is strictly fact or my opinion."
dlyons@Apple.COM (David A. Lyons) (06/27/90)
In article <266201eb.2a84@petunia.CalPoly.EDU> rbannon@mira.acs.calpoly.edu.UUCP (Roy Bannon) writes: > I am trying to write a interrupt handler for the keyboard. I want to make >the function keys on the extended keyboard do something. Here's the problem >in a nutshell. I install my handler with SetVector and it returns fine. The >problem is that after its installed and the interrupts are enabled, IntSource, >I don't get an interrupt with every key press. I put a brk instruction as the >first line of code, and it doesn't break until several keys have been pressed, >and then doesn't break again for several more chars. Anybody got any ideas? >Anybody at all? Any and all help greatly appreciated. > >Thanks, >Roy >rbannon@cosmos.acs.calpoly.edu I couldn't see what was going wrong for you until I tried it, but now it makes sense: you were sitting in an environment that was polling for keys, and it was stealing most of them *before* the keyboard-interrupt mechanism got a chance to see them. "Keyboard interrupts" are currently implemented with a heartbeat task that checks for a keypress once every 1/60th of a second & calls the Keyboard Interrupt vector (with the appropriate environment set up) when it sees a key has actually been pressed. (Of course, you shouldn't *assume* that IntSource handles keyboard interrupts this way--some day it might work differently.) Anyway, there's another obstacle in your way: SetVector is not going to give you permanent ownership of keyboard interrupts. You'll lose them whenever the Event Manager is started up or shut down. I don't see a clean way around this, but I can think of at least one hacky way: patch SetVector to check for vector number $000f, handle all the others by passing control to the Real SetVector code, and handle $f by keeping the passed handler for your own use & giving YOUR address to the real SetVector. When your handler is called, you can call the Real vector if you don't want the keypress. Of course, there are no guarantees about doing weird patching like this. -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II Developer Technical Support | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
shatara@islnds.enet.dec.com (Chris Shatara) (06/28/90)
In article <42395@apple.Apple.COM>, dlyons@Apple.COM (David A. Lyons) writes... >-- >David A. Lyons, Apple Computer, Inc. | DAL Systems >Apple II Developer Technical Support | P.O. Box 875 >America Online: Dave Lyons | Cupertino, CA 95015-0875 >GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 >Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons > Good to have you back Dave. You and rest of the gang at Apple DTS have been missed. /chris ============================================================================= | Chris Shatara | Internet: shatara@islnds.enet.dec.com| | Opinions expressed are | DEC Easynet: islnds::shatara | | mine and mine only! | UUCP: ...!decwrl!islnds!shatara | =============================================================================
jason@madnix.UUCP (Jason Blochowiak) (07/03/90)
In article <42395@apple.Apple.COM> dlyons@Apple.COM (David A. Lyons) writes: >In article <266201eb.2a84@petunia.CalPoly.EDU> rbannon@mira.acs.calpoly.edu.UUCP (Roy Bannon) writes: >> I am trying to write a interrupt handler for the keyboard. I want to make >>the function keys on the extended keyboard do something. [Problems with >> SetVector, etc., deleted] >>Roy - rbannon@cosmos.acs.calpoly.edu > [Deleted Dave mentioning the way key pseudo-interrupts are dealt with] > [ and about SetVector patches only being valid between Evt Mgr status changes] > [...] but I can think of at least one hacky way: patch >SetVector to check for vector number $000f, handle all the others by passing >control to the Real SetVector code, and handle $f by keeping the passed >handler for your own use & giving YOUR address to the real SetVector. When >your handler is called, you can call the Real vector if you don't want the >keypress. Oooh, ick! Then wouldn't it also be necessary to watch for EMStartUp & EMShutDown calls, so that any app that relied on the vector patches being purged on EMShutDown wouldn't cause a post-run crash? My somewhat hackish approach to nabbing keypresses for FKeys GS is to patch PostEvent. If the event being posted is a keyDownEvt or autoKeyEvt, then I nab the keycode (and the modifiers), and call an internal routine called CheckKey. If CheckKey says that it doesn't want the keypress, then the patch lets the call go through. If it did want the keypress, then I munge the stack myself and return to the caller as if the thing was successfully posted. A coupla' caveats: This will only work for things that use the Evt Mgr. Actually, FKeys GS only works with desktop applications - because the specific PostEvent code is called during an interrupt (or at least I have to assume it is), it'd be a really bad time to run a whole bunch of code, not to mention the machine state... So, CheckKey, if it determines that it wants the keypress, sets some internal variables, and a Run Queue entry actually runs the appropriate FKey. It'd probably be simpler for you to actually buy FKeys GS and write your own FKey than it would for you to write all the support code, etc., that I had to. This is, quite honestly, less of a sales pitch than it is a "Warning: Wheel has already been invented" type message. Disclaimer: I wrote FKeys GS, and sold it to Softdisk G-S. I'd give you the source code if I wouldn't be decapitated for doing so... >David A. Lyons, Apple Computer, Inc. | DAL Systems >Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons -- Jason Blochowiak - jason@madnix.UUCP or, try: astroatc!nicmad!madnix!jason@spool.cs.wisc.edu "Education, like neurosis, begins at home." - Milton R. Saperstein
dlyons@Apple.COM (David A. Lyons) (07/05/90)
In article <1415@madnix.UUCP> jason@madnix.UUCP (Jason Blochowiak) writes: >In article <42395@apple.Apple.COM> dlyons@Apple.COM (David A. Lyons) writes: >> [...] but I can think of at least one hacky way: patch >>SetVector to check for vector number $000f, handle all the others by passing >>control to the Real SetVector code, and handle $f by keeping the passed >>handler for your own use & giving YOUR address to the real SetVector. When >>your handler is called, you can call the Real vector if you don't want the >>keypress. > >Oooh, ick! Then wouldn't it also be necessary to watch for EMStartUp & >EMShutDown calls, so that any app that relied on the vector patches being >purged on EMShutDown wouldn't cause a post-run crash? I don't see the difficulty--EMShutDown call SetVector to restore the keyboard interrupt vector to its pre-EMStartUp value. (I suppose you would also have to patch GetVector to return the "real" value instead of the patch.) This approach works with keyboard interrupts (as enabled and disabled with IntSource) whether or not the event manager is used. -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II Developer Technical Support | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.