Mail Archives: djgpp/1998/11/03/04:38:22
On Tue, 3 Nov 1998, Mapson wrote:
> 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.
My point is that today's machines are so fast that *just after* the time
you check the keyboard is so close to the next time you check it, that
the delay is negligible.
> 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.
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?
> 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).
> 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.
- Raw text -