💾 Archived View for mirrors.apple2.org.za › archive › apple.cabi.net › FAQs.and.INFO › CPUandMore › … captured on 2023-05-24 at 23:46:26.
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
Newsgroups: comp.sys.apple2.programmer Path: news.uiowa.edu!chi-news.cic.net!newsfeed.internetmci.com!news.msfc.nasa.gov!pendragon!ames!waikato!comp.vuw.ac.nz!actrix.gen.nz!dempson From: dempson@atlantis.actrix.gen.nz (David Empson) Subject: Re: Control key Message-ID: <DMps0s.B8r@actrix.gen.nz> Sender: news@actrix.gen.nz (News Administrator) Organization: Actrix - Internet Services Date: Tue, 13 Feb 1996 12:29:15 GMT References: <4fb59l$4kc@lastactionhero.rs.itd.umich.edu> <4fcats$hvt@tuba.cit.cornell.edu> <4fk52s$l8q@lastactionhero.rs.itd.umich.edu> <4fmt3p$nu9@nnrp1.news.primenet.com> X-Nntp-Posting-Host: atlantis.actrix.gen.nz Lines: 82 In article <4fmt3p$nu9@nnrp1.news.primenet.com>, John Bowling <johnlb@primenet.com> wrote: > >In article <4fcats$hvt@tuba.cit.cornell.edu>, > >Jay Krell <jmk3@crux4.cit.cornell.edu> wrote: > >>mcafee@umich.edu (Sean McAfee) writes: > >>>How is it that the Event Manager is able to determine that the Control key > >>>was being pressed during the last keydown event? > > > >>C025 (don't use it) is well documented to hold the status of > > ^^^^^^^^^^^^ > >>control, shift, apple, option, keypad, etc., though with slight > >>inaccuracies wrt control and the arrows. I don't understand this comment about control/arrow inaccuracies. It has always worked fine for me - the arrow keys by themselves do not indicate that the control key is down, so they can be detected (because the ASCII code was a control character). If Control-Arrow is pressed, it cannot be distinguished from Control and the corresponding letter. (This could be avoided by bypassing the standard keyboard handling provided by the keyboard microcontroller, and processing key up/down sequences directly, using the ADB service request mechanism - you then get scan codes for the keys, so every key can be identified correctly.) > I've used it in a few programs that need to get around the C crap of > requiring a <return> key on every entry, and I've never had a problem > with it. > > So, why not? Compatibility. If you access the hardware directly, you will reduce the number of situations in which your program will work properly. In particular, it will NOT work properly in the background under GNO or another multitasking system. It also might not work reliably if something else has enabled the Event Manager - keys might be swallowed behind your back as the Event Manager's interrupt handler picks them up. If you get keys using the Event Manager, then it will always work. In shell programs, another option is to use the new calls provided by ORCA/Shell 2.0.1 and later, and recent versions of GNO. The ORCA/Shell implementation of the calls "KeyPress" and "ReadKey" will use the Event Manager if it is active, or access the hardware directly. The GNO implementation also copes with programs that have been switched into the background, not providing them with any keypresses. I wrote my own keyboard read routines that do the following: 1. Try the ORCA/Shell call. 2. If an error occured (older version of the shell, or no shell present), and the Event Manager is active, then use it. 3. If all else fails, access the hardware directly. This should work in any 16-bit environment (GNO, ORCA/Shell 2.0.1 or later, older shell versions, a standalone application, CDA, etc.) Note that if you do choose to access the hardware directly, make sure you use $C025, $C000 and $C010 correctly. The proper sequence for detecting a keypress and reading the modifiers is: - Check for a keypress by looking at bit 7 of location $C000. - If a key is available, read the modifiers from $C025, with the associated key value from $C000. - Reset the keyboard strobe by accessing $C010. Note that if keyboard buffering is enabled, the modifiers will be stable until the associated key is cleared. If keyboard buffering is disabled, the modifiers can change on the fly (this is also the case when buffering is enabled and no non-modifier has been pressed yet). -- David Empson dempson@actrix.gen.nz Snail mail: P.O. Box 27-103, Wellington, New Zealand