[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Programming Question
Edhel Iaur, Esq. (edhel@LOSETHECAPITALWORDSbigfoot.com) wrote:
: On 29 Nov 1997 21:36:54 GMT, retromod-Apple-II-newsgroups; rm -rf
: ~;@vuse.vanderbilt.edu (Tilghman Lesher) wrote:
: >What you need to do is to program a loop, either a GOTO, if you need a main
: >programming loop or a FOR if you want timed response. Inside the loop,
: >place the following code (or GOSUB to it, if you want).
: >
: >IF PEEK(-16384) > 128 THEN KEY$ = CHR$(PEEK(-16384)):POKE -16368,0
: I just use "...THEN GET A$ : POKE..." :)
Actually, there is an added benefit to this method...
What Edhel is doing is as follows, for clarity...
IF PEEK(-16384) > 128 THEN GET A$:GOTO keyPressedHandler
What this does is wait until there is a keypress in the keyboard input
latch. Once there is a keypress, GET is called. GET doesn't have to wait
for the keypress because it is already sitting in the keyboard byte.
Note that I omitted the "POKE -16368,0".
It turns out that one of the first things that GET does is to check the
keyboard to find out if there is a keypress waiting. If not, it displays
the cursor and waits for the keypress. Of course, we've already verified
that there is a keypress for GET to get before calling GET.
Once GET finds a keypress, it passes the keypress to the specified
variable. But then, GET clears the keyboard strobe for you, so it is not
necessary to clear it again! In fact, if you do clear it again, there is
an extremely remote chance that you will actually lose the next keypress,
if that keypress comes between the time the GET routine clears the
keyboard strobe, and the time that you clear it again with the POKE statement!
--Dave Althoff, ][.
--
/-\ _ _ *** Thanks for a great season!!! ***
/XXX\ /X\ /X\_ _ /X/|_ _ _ _____
/XXXXX\ /XXX\ _/XXXX\_ /X\ <#&/XXX\ /X\ /X\ /XXXXX
_/XXXXXXX\__/XXXXX\/XXXXXXXX\_/XXX\_o==oXXXX\__/XXX\_/XXX\_/\_/XXXXXX