Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!ames!haven!decuac!shlump.nac.dec.com!sousa.enet.dec.com!pinbot.enet.dec.com!ervin
From: ervin@pinbot.enet.dec.com (Joseph James Ervin)
Newsgroups: comp.sys.handhelds
Subject: Re: (HP48SX)  Strange behavior...bug?
Message-ID: <994@sousa.enet.dec.com>
Date: 22 Mar 91 16:39:11 GMT
References: <990@sousa.enet.dec.com> <21361@shlump.nac.dec.com>
Sender: newsa@sousa.enet.dec.com
Reply-To: ervin@pinbot.enet.dec.com (Joseph James Ervin)
Organization: Digital Equipment Corporation
Lines: 29

In article <21361@shlump.nac.dec.com>, edp@jareth.enet.dec.com (Eric
Postpischil (Always mount a scratch monkey.)) writes:

|> It happens on my 48 (Revision E) as well.  I tried changing "DO UNTIL
|> KEY END" to "0 WAIT".  The problem vanishes then.  Perhaps KEY locks out
|> recognition of key presses briefly during its execution.
|> 
|> (BTW, you could use "START" instead of "FOR I" in the above.)
|> 
|> 
|> 				-- edp (Eric Postpischil)
|> 				"Always mount a scratch monkey."
|> 				edp@jareth.enet.dec.com
|> 

Thanks for trying it, Eric.  It comes as no surprise that it works when
you use WAIT instead of KEY.  The WAIT command halts the loop until a
key is pressed, so it is probably a lot easier for the internal code to
detect when the key is released.  The KEY command (and possibly WAIT as
well) apparently makes some attempt to communicate information
internally from one invokation to the next, thus making it theoretically
possible for the KEY routine to determine, when it detects a pressed
key,  whether this is a _new_ key depression, or if the KEY command is
just seeing the same key pressed as it did the last time through the
(RPL) loop.  I suspect that this is the cause of the problem.

Sure would be nice to hear from HP on this....

>>>Joe Ervin