poor performance INKEY in DOS

[Tom Kuurstra]

Hello people,

I'm working on code that needs a way of escaping a loop by pressing
the escape key. I've noticed that testing for the escape key by using
inkey takes up a lot of extra runtime. if i leave the inkey test out
the loop runs about 4 to 6 times faster. i've searched the forum
for some info on this and found some references to time-slice
problems in windows VDM sessions. the offered solutions don't seem
to have any bearing on real DOS sessions (my compiled code does
NOT run in Windows). does anybody know how i can speed up the use
of inkey, or is there another way to escape a running loop (elegantly)
without slowing things down ?
Thanks for anything on this.

Tom

[Gerhard Kropf]

Hi Tom,

if your programm only runs under DOS/Win9x, you can use
directly the keyboard-port &H60

z%=inp(&h60)

should return every key-press without delay. So, you only have to
analyze z% for further loop-control.

do
z1%=inp(&h60)
if z1%=1 then exit loop 'ESC Key pressed
loop

G.



[This message has been edited by Gerhard Kropf (edited January 19, 2004).]

[Paul Dwyer]

If your looping hundreds of times per second can you try putting an if statement in an testing inkey less often?

something like

for i = 1 to 10000
    'do some code
    if i mod 100 = 0 then     'every 100 iterations...
        'inkey etc etc check
    end if
next i

I don't know how quick your loops run so you might need to adjust this of course


------------------
Paul Dwyer
Network Engineer
Aussie in Tokyo

[Gustavo Asplanatti]

I use the following method.

DO
   IF INSTAT THEN 
      PressedKey = INKEY$
      IF PressedKey = CHR$(27) THEN EXIT LOOP
   END IF
   ...
   Your code
   ...
LOOP

This way, I can also manage any other key that is pressed to, for
example, execute other procedures. The more effective way to do it
is using an IF... ELSEIF ... END IF, and not the instruction SELECT
(it is slow).

------------------
Gustavo Asplanatti
[email protected]

[Mike Luther]

In the Forums here are a whole collection of messages having to do
with time slice releasing. This same in-line assembler technique
will, as far as I know, solve this same problem here. What you do
in simple terms is place it above the INKEY$ call. It releases CPU
time slices and breaks up the CPU loop work. There are some cases
when you really want to not do this, but if you need it the thing
looks somewhat like this..

DO
ASR inline release code here
INKEY$
Analysis of return here
Exit if needed or whatever
LOOP

I'm not at my development box, so the actual code illustration is
not provided, please forgive me. But the thought may be enough to
get you going. Plus, if you are operating this code in a Window,
or a Seamless Window in OS/2, there are also some methods to find
out what system it is. You can branch the assembler code to handle
the needed different routines depending on that finding. At least
up until WIN-XP. I do not know, yet, how or if the technique will
work for a window session in XP, if it will at all.



------------------
Mike Luther
[email protected]

[Mel Bishop]

If you have ON TIMER active, put the INKEY in the sub that it
branches to. The following example will check the INKEY only
once each second.

on timer(1) gosub dosomething
timer on
.
.
.
dosomething:
    t$ = inkey$
    if t$ = chr$(27) then abort = 1
...other processing
    return

Of course, if you don't have an ON TIMER, you can easily create
one specific to checking the keyboard.


------------------


[This message has been edited by Mel Bishop (edited January 19, 2004).]

[Mike Luther]

Mel ..

Yes, one can sure do that. And I'll have to look back through the
notes on all this from five or six years ago when this all surfaced.
It's my recall that this is a valid solution for a pure DOS environment
but the TIMER operation, in some forms of multi-tasking, itself, can
introduce the CPU bashing problem from the PB executable. In other
words, if you use the TIMER operation, for example, in am OS/2 seamless
window session, you still generate the CPU race condition with that.

It was the reason why I posted the pointer toward interrupt assembler
techniques. In that way, at least for what I've learned here, I don't
have to use TAME or time slice releasing code on any box which runs
the PB 3.5 executables or think about this. To me, the key to the
thinking is to not only solve the CPU load issue for the internal use
in pure DOS. It is to look forward to how to manage it in multi-tasking,
especially pre-emptive multi-tasking, where THREAD orchestration levels
are also involved even down to their tread prioritization assigned
between full symetric multi-processing amoung more than one CPU.




------------------
Mike Luther
[email protected]

[Mel Bishop]

Originally posted by Mike Luther:
It's my recall that this is a valid solution for a pure DOS environment

Well, since Tom specifically stated that his program does not
run in a windows environment, I just assumed he is running his
program under a DOS environment.


------------------

[Tom Kuurstra]

Thanx for the replies people, there's enough here to sink my teeth into.
i am however not familiar with ASM programming so i am sticking with
the pure PB solutions. thanx again.

Tom


------------------
[URL=http://www.DiyDataRecovery.nl]

[Fred Buffington]

You might try on key also.


------------------
Client Writeup for the CPA