Mail Archives: djgpp/1998/11/03/01:17:00
On Thu, 29 Oct 1998 17:54:58 +0200 (IST), Eli Zaretskii
<eliz AT is DOT elta DOT co DOT il> 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.
- Raw text -