No announcement yet.

INKEY$ and INSTAT Timing

  • Filter
  • Time
  • Show
Clear All
new posts

  • Donald Darden
    The timing associated with the video card is the most critical
    time of all. It HAS to be stable at a specific frequency, or the
    monitor will show jitter and waivy lines, or other distortions on
    the screen. Under DOS, many programmers have resorted to checking
    the Vertical Resync or Horizontal Resync signals and establishing
    a lapsed time reference based on either of these.

    Aside from that, you can look for and find code that already gives
    you the type of stable and rapid timing reference that you seem to
    be looking for. Gaming languages already employee these in their
    structure, and also offer alternate keyboard mapping schemes so
    that the keyboard is a more effective instrument for user input
    during game play. They allow for simultaneous key depressions,
    where normally you need sequential key inputs when typing.

    Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

    Leave a comment:

  • Paul Dixon
    mtimer itselt waits for the 55msec. If you call any fast code repeatedly it'll always take 55msec / call.
    Use mtimer once, and measure just 1 loop OR start mtimer, do 20 loops THEN read mtimer for the result and see it that shows the difference.

    As I remember it (perhaps not very well) the initial MTIMER statement waits for the internal timer to roll over. The subsequent mtimer function call just reads the timer to see how far it got since it rolled over.



    Leave a comment:

  • Jim Martin
    Emile -

    As stated in the first post, W98SE. And, yes, I know that Windows
    produces variable timing. All that background stuff that the OS
    just _has_ to do.

    That misses the point, I think. According to the docs, MTIMER uses
    a hardware counter. I'll buy the idea of long duration for a simple
    loop if the OS interrupts it to handle background tasks, but how do
    you get the extremely short readings?

    And to get back to my original findings, I note that making 25 loops
    and printing each result on a new line takes well over a second.

    This is consistent with a 55 msec response time for INSTAT, and is
    hard to understand if INSTAT only takes 5 microseconds. Printing a
    value to screen doesn't take THAT long.



    Leave a comment:

  • Emil Menzel

    Are you using pure DOS or are you running under Windows? My
    bet is that it is the latter. Timing is much more variable
    under Windows.

    By the way, I have a cute routine for speeding up the clock;
    if anyone is interested I'll post it. Windows will not allow
    this routine to run, but under DOS you can literally see the
    time (and calendar) fly by.


    Leave a comment:

  • Jim Martin
    Mel -

    Your results were so at odds with my own that I rechecked.

    I'm afraid I don't believe MTIMER.

    I set up a loop that uses MTIMER to measure 10 successive calls of
    INSTAT, and does it 25 times in succession, printing out the result
    on a different line each time. I ran this repeatedly.

    The result is often an average of about 4-6 microseconds per INSTAT,
    but sometimes as high as 40.

    And sometimes 0 or 1 for the entire loop, indicating .1 usec per isntruction.

    Like I say, I don't think MTIMER is credible here. I reran my hardware test
    on a loop which only calls INSTAT and writes to a port, and I get 55 msec

    Does anybody have any idea what's going on?



    Leave a comment:

  • Mel Bishop
    Wrote up a small test program:
    $lib all off
    color 14,1
    If Instat > 0 then
    a$ = inkey$
    end if
    The print statement showed an elapsed time of an average of
    5 microeconds over several runs. Of course, in this example,
    inkey$ is never executed. All it tests is the speed of the
    INSTAT function.


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

    Leave a comment:

  • Donald Darden
    The operating system polls various activities, including the
    keyboard for key presses, so the updates are based on when the
    OS gets around to checking on them. Some gamerz crank up the
    cycle rate of this polling proces for faster reaction times.
    Your approach is the first I've heard of its kind.

    Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

    Leave a comment:

  • Jim Martin
    started a topic INKEY$ and INSTAT Timing

    INKEY$ and INSTAT Timing

    howdy, all.

    a year ago, tom kuurstra posted a question about how to get faster
    keyboard response. various suggestions were made, but no conclusions
    were drawn.

    i've recently had to look into the same question and have come up with
    some answers. i'm doing a dedicated test unit and use a soyo k7vem motherboard
    with a 1 ghz piii, w98se, and use the isa bus for hardware control.
    this allows me to look at system performance on a scope by issuing io writes and
    looking for the pulses.

    first, both inkey$ and instat give the same abysmal performance.

    do while instat
    out &h210,0
    a$ = inkey$

    runs in about 55 milliseconds.

    using inkey$ produces the same result.

    and i don't think that it's a coincidence that this is an 18-hz rate. it seems clear
    that both functions are mediated by the system clock. presumably, either command
    causes a wait until the system clock occurs, which will be essentially a random wait
    of from 0 - 55 msec, depending on exactly when the command occurs.

    if, instead, i look at io address &h60, things get a _lot_ better. the following loop:

    do while ((x% <> 0) and (x% < 128)) 'looking for x% < 128 avoids responding to key release
    x% = inp(&h60)
    out &h210,0 'this is just my port write address
    a$ = inkey$ 'remember to flush the buffer

    runs in 8 microseconds. that's nearly 4 orders of magnitude improvement.

    i hope this comes in handy for someone.

    jim martin