Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!maverick.ksu.ksu.edu!unmvax!nmt.edu!nraoaoc
From: nraoaoc@nmt.edu (Daniel Briggs)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Reading multiple keypresses at once
Message-ID: <1990Jul18.231501.9736@nmt.edu>
Date: 18 Jul 90 23:15:01 GMT
References: <11396@hydra.gatech.EDU> <204@sc2a.unige.ch> <7826@tekgvs.LABS.TEK.COM>
Reply-To: dbriggs@nrao.edu (Daniel Briggs)
Organization: National Radio Astronomy Observatory, Socorro NM
Lines: 20

>[much discussion of reading the keyboard and maintaining state tables, etc..]

Since we're on the subject, I'll toss out a question that I have been
wondering about.  I have a little V20 based laptop that runs at 7.2 MHz.
I also have a few games for this bugger that use some variant of the technique
that we are talking about.  (I hang my head in shame, but hey!  I take lunch
hours too!)  What interests me is that even with a completely vanilla system,
naked in all respects, these games still appear to occasionally miss break
codes.  This is a drag, in that it has the effect that a key is 'stuck' on.
If I had to guess, I presume that this is due to several keys raising an
interrupt at once, while the processor has interrupts disabled.  The 8259A
can only buffer one, so somebody has to lose.  Does anybody happen to know
just what the keyboard processor will do in this situation?  How robust
have people found this technique to be for fairly demanding applications?
Does my clone maybe have a poor BIOS that spends longer than it should with
interrupts disabled?
-- 
This is a shared guest account, please send replies to
dbriggs@nrao.edu (Internet)
Dan Briggs / NRAO / P.O. Box O / Socorro, NM / 87801  (U.S. Snail)