Mail Archives: djgpp/1998/11/03/10:11:29
On Tue, 3 Nov 1998 11:36:50 +0200 (IST), Eli Zaretskii
<eliz AT is DOT elta DOT co DOT il> wrote:
<...>
>If you only need to know whether the key is pressed NOW, and don't mind
>losing all the other keys, even those which were pressed, say, 20
>milliseconds ago, then there might be an easier solution (access the
>keyboard ports directly). But is it indeed what you want? What if the
>user pressed and released a key when you were not looking?
Believe it or not, in my very specialized circumstance, knowing what
is pressed at a given moment is all I'd need. The language I've put
together is meant to facilitate laboratory experiments within a very
narrow scope of activity. Most of that is turning on and off relays
(using ports), listening to button presses (using other ports), and
writing stuff to any of console, files, serialports. Basically, when
an experiment is taking place, there are lots and lots of times when I
want to ignore keyboard presses- and then suddenly windows of need
where I care precisely which button or keypress might be happening at
that instant. I want to treat the keyboard in the same way that I am
treating "button presses" on ports.
From what you say, there is indeed a way to look at a keyboard port
that has a direct relation to keypresses. I mean, for the duration a
key is pressed, there is a particular state reflecting this at the
port. (where is this port!?I want it!)
My assumption was that there was no such thing- that when a key was
pressed, the keyboard only sent one short message of "key pressed",
not to be turned off again until a message "key released" came. But
I'm beginning to think from what you say that I was wrong- probably
some confused notion I got from Windows programming.
>> 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.
>
>You might be haunted by the shadow of a dwarf here; namely, it might well
>be that you are greatly exaggerating how expensive this would be. IMHO,
>this should only be decided based on some measurements. You might be
>surprised how un-expensive polling the keyboard is, especially when
>there's no key in the BIOS buffer.
>
>> 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.
>
>You wanted to avoid messing with hardware interrupts, remember?
>
>If you do want to solve this on the interrupt level, you could modify the
>keyboard handler that the DJGPP startup code installs anyway (look for
>the file exceptn.S in the djlsr201.zip distribution) so that it stashes
>the keystrokes away for you in some large buffer (be sure to lock that
>buffer, or your program will crash).
Thank you very much for this info- I will indeed look at that file, if
only to get a feel for how this sort of things is done.
>> 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.
>
>There is: you need to read the keyboard controller's port. But that
>means you need to do it while the key is still pressed, since that port
>has no memory.
This is fine with me- how do I find out where this port is, and can I
treat it like any old port? I will start tracking it down now that I
know there is one.
Thanks as always, Eli- you always allow me to make some progress at
these imasses.
- Raw text -