Announcement

Collapse
No announcement yet.

poor performance INKEY in DOS

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • poor performance INKEY in DOS

    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
    [URL=http://www.DiyDataRecovery.nl]

  • #2
    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).]

    Comment


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

      something like

      Code:
      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

      Comment


      • #4
        I use the following method.

        Code:
        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]
        Gustavo Asplanatti
        gustavoa at computecsrl.com.ar

        Comment


        • #5
          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]
          Mike Luther
          [email protected]

          Comment


          • #6
            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.

            Code:
            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).]
            There are no atheists in a fox hole or the morning of a math test.
            If my flag offends you, I'll help you pack.

            Comment


            • #7
              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]
              Mike Luther
              [email protected]

              Comment


              • #8
                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.


                ------------------
                There are no atheists in a fox hole or the morning of a math test.
                If my flag offends you, I'll help you pack.

                Comment


                • #9
                  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]
                  [URL=http://www.DiyDataRecovery.nl]

                  Comment


                  • #10
                    You might try on key also.


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

                    buffs.proboards2.com

                    Links Page

                    Comment

                    Working...
                    X