On Mon, Jun 11, 2012 at 12:55 AM, Wolfgang Lenerz <[email protected]> wrote: > Hi, > >>>> >>>> If I create a REPeat loop thus: >>>> >>>> 100 Frame=0 : Keypress=0 >>>> 110 REPEAT loop >>>> 120 a$=INKEY$ >>>> 130 Frame=Frame+1 >>>> 140 IF a$<>"" THEN Keypress=Keypress+1 >>>> 150 AT 0,0 : PRINT Frame, Keypress >>>> 160 END REPeat loop >>>> >>>> ...I reasonably expect that when a key is pressed, the Keypress value >>>> will increase in step with the Frame value (every time the loop >>>> repeats, a keypress is detected) but no. I can type run, and hold down >>>> the enter key, and Frame will increment 55 times for each detected >>>> Keypress. It seems INKEY$ is limited to approx 15 keyboard scans/sec. >>>> On my original QL, with or without GC, they increment together, 1:1. >>>> > OK, i'm going out on a limb there. > That's probably because the emulator you use is so much faster. > So the loop gets called much more often, but the keys are only input into > the "machine" at "normal" speed (probably every 50th of a second?). > Moreover, the QL will probably generate an interrupt for every key pressed, > wheres again, the emulator probably will only generate an interrupt every > 50th of a second (guessing here). > > Wolfgang
That does seem to be what's going on, yes. I believe the keyboard buffer gets updated every 1/15th of a second, and that even the Gold Card isn't fast enough to do all the calculations and check the buffer. That being said, it's still a "wrong behavior" in the sense that INKEY$ is not like INPUT but is more like KEYROW - both should instantaneously check if a key is pressed and report if so. Just a curiosity of the way the IS interacts with the hardware, I guess. :) A good thing to know, though. *scribbles in "Book Of Ql Weirdnesses!" Dave _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
