Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!swrinde!mips!pacbell.com!tandem!zorch!amiga0!mykes From: mykes@amiga0.SF-Bay.ORG (Mike Schwartz) Newsgroups: comp.sys.amiga.programmer Subject: Re: Checking for a Keystroke (in C) Message-ID: Date: 28 Jun 91 09:29:12 GMT References: <1991Jun27.013554.11040@cccan.uucp> Organization: Amiga makes it possible Lines: 77 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. * ****************************************************