Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!stanford.edu!leland.Stanford.EDU!repair.stanford.edu!hinds From: hinds@repair.stanford.edu (Alexander Hinds) Newsgroups: comp.sys.amiga.programmer Subject: Re: Checking for a Keystroke (in C) Message-ID: Date: 28 Jun 91 20:17:41 GMT References: <1991Jun27.013554.11040@cccan.uucp> Sender: news@leland.Stanford.EDU (Mr News) Organization: AIR, Stanford University Lines: 83 mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >In article <1991Jun27.013554.11040@cccan.uucp> entity@cccan.uucp (Cybernetworx) writes: >>In article Alex_Topic@tvbbs.UUCP (Alex Topic) writes: >>> >>> Well about keyboard scan..heh Well one time when I was makeing one of >>>those take over the machine demos, I wanted to have keyboard control. For >>>instance >>>I want 2 keys that would switch to NTSC or PAL right away.. just a test >>>thingy I wanted to do/ >>> >>> You scan the CIA chip.. $bffd00 something not too sure..hmm let me >>>check the manual..heh >> >>Heh..nice way of checking the keyboard :-) Anyhow, what you are looking >>for is $bfec01. This holds the char as its transmitted from the keyboard. >> >YUP > >>> Not too sure on what it is. What you get is a RAW keyvalue..and just >>>take the value and compare it to what you want it to do. ONly problem I get >>>different values..Its weird..hmm later.. >> >Not the same as what intuition gives you for RAWKEYs at all. >>Actually, the different values you got were dependant on whether the key >>was pressed down or was still up. I can't remember off hand, but I think >>the high bit was set if the key was up, and cleared if it was down. (It >>might not have been the high bit...as a matter of fact, I think it was >>bit 0.) >> >YUP, it is bit 0. If you want it to be in bit 7 for some reason, you >can do a ror.b instruction... >>> >>> A.t. >> >>One other thing, this method of checking the keyboard is totally unadvised! >>If you want to maintain system multitasking and everything, there are many >>other ways of reading the keyboard. In fact, C has several functions >>built right in, if you don't care to go through the system routines. The >>above method would only be useful in something where you don't want an >>input.handler hogging CPU time, and where you are definitely taking over >>the machine. If you are going this route, make sure CIA-A, Timer A is >>left running, since this is what performs the serial transmission from the >>keyboard. >> >You can read the keyboard port without harming multitasking in any way. >All you need to do is to check $bfe001 periodically and if it changes, >a new key event has happened. There are drawbacks to this, since the >keycodes for future keyboards might be different (doubtful, but assume >it anyway). >The stuff about CIA-A timer is news to me. If the system isn't running, >then it should be free to use. If the system is running, you must also >be sure not to read the CIA ISR register, because it clears the bits >and can get the OS in a confused state. >By the way, if you want to work the keyboard directly, you need to wait >at least 200 microseconds on the handshake to work with all keyboards. >Actually, I might be mistaken in that it might be 300 microseconds... >DO NOT USE THE CPU to time this out. You'd be better off looking at the >beam position register and waiting a few scanlines... >>-- >> __ >> __ /// >> \\\ /// UUCP: ...uunet!utai!lsuc!becker!cccan!entity >> CYBERNETWORX INET: entity@cccan.UUCP >-- >**************************************************** >* I want games that look like Shadow of the Beast * >* but play like Leisure Suit Larry. * >**************************************************** Could somebody post some (C) code detailing the above? I've been wanting to do this for a while, but I can't seem to make sense of the keyboard/CIA stuff in the hardware manual. Thanks.