Date: Tue, 3 Nov 1998 11:36:50 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Mapson cc: djgpp AT delorie DOT com Subject: Re: Keyboard access In-Reply-To: <363e8d3c.31851429@news.cis.yale.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com 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.