From: mapson AT mapson DOT com (Mapson) Newsgroups: comp.os.msdos.djgpp Subject: Re: Keyboard access Date: Tue, 03 Nov 1998 06:00:40 GMT Organization: Yale University Lines: 82 Message-ID: <363e8d3c.31851429@news.cis.yale.edu> References: NNTP-Posting-Host: psych-09.eng.yale.edu X-Newsreader: Forte Free Agent 1.1/32.230 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Thu, 29 Oct 1998 17:54:58 +0200 (IST), Eli Zaretskii wrote: >On Wed, 28 Oct 1998, Mapson wrote: <...> >In particular I don't understand what do you mean by ``direct access'' to >the keyboard buffer. How would such a thing help you when you say the >problem is that you don't *know* when the program will be *able* to >access the keayboard? Basically, I just want to see what is being pressed at any given instant, and have no interest in stored characters. Perhaps this isn't possible the way the hardware works. If so, then I need to settle with simply emptying out the buffer at a regular and rapid rate. But then I still end up in a situation where I will have the keyboard press *just before* (proportionate to how often I empty) I decide to check it. This isn't ideal, since timing is important in the circumstances these programs will be used, and keyboard isn't really important enough to deserve the expensive maintainence I'd need to give it to keep latencies short. BTW- the reason I don't know when the program might want to access the keyboard is simple- the hypothetical "program" in question is the output of a compiler I've written, and I can't know what programs people are going to write with it, or whether or not they'll even want to use the Keyboard in every program- it isn't a central component. But I can say this: in the circumstances people will be using keyboard, there is never an occasion where it is useful to know anything but the key being pressed at a particular instant. >One way of solving similar problems is to build a program around an idle >loop that checks for keystrokes, and if there are some, stashes them away >in a large circular buffer for later use by other parts of the program. >Since today's machines are so fast, a typical PC can run circles around >even the fastest typist. I've been considering a recirculating buffer- for the sole reason that as it stands, I could be sloppy and just decide to empty the whole buffer to look for the last character when I can know that the user has a keypress check coming. Problem: as the buffer is by default, it could potentially fill up before the user wants to use it, giving the worst of all possible results: system beeps informing of keyboard buffer overflow! Can't have that. Recirculating buffer would solve that. My problem with building the programs around a loop is that keyboard is not a focus of the usage of this compiler- in fact, 90% of programs probably won't use keyboard (people use port states, generally)- so I hate to build something expensive in to everybody's programs that they just won't be using a lot. >Another possibility is to use the timers: you set it up to trigger a >periodic alarm signal that is caught by a SIGALRM handler, and the >handler looks at the keyboard and stashes away or throws away, actually, since I only care about the concurrent presses. > any keystrokes that might >be pending. (If you go for this solution, be sure to read the fine print >about the subtle aspects of DJGPP signal handling, at the end of the docs >for the library function `signal'.) I'll have to look in to this- sounds good, and reminds me of game programming using the timer to some extent. Still seems a waste, though- like I am wasting time fighting with the buffer rather than somehow just replacing it with my own recirculating buffer ISR. And I still don't get much accuracy if people want to use the keyboard for marking timepoints in their program. >Anyway, there *is* a way to access the keyboard buffer directly, since >the pointers maintained by the BIOS to its head and tail are at known >addresses. I just don't see how that would help to solve your problems. Well, if I could peek at what if anything is being pressed at a given moment, I'd be golden. Fact is, I suppose there is not a "steady state" representing a keypress, like I get with ports. Thanks for these ideas- they are excellent, and probably will in some way or another mix and match up to be a useable solution.