No announcement yet.

Small increments of time?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Small increments of time?

    Is it possible to force the program to wait X time? "X" in this
    case is measured in one/one thousandths of a second. I would
    appreciate being able to do:

    Wate = 6 :' goto to function/sub and wait 6/1000 of a
    ' second before continuing

    y = Waiter(Wate)

    The best I can do so far is wait one full second, too slow
    sometimes. In Quickbasic, there is a way to use "tick marks"
    to get small amounts of time- can I do the same in Powerbasic?

    Thank you.


  • #2
    Is your PB/DOS program running on a DOS computer, or on a Windows computer?

    -- Eric

    Perfect Sync Development Tools
    Perfect Sync Web Site
    Contact Us: mailto:[email protected][email protected]</A>
    "Not my circus, not my monkeys."


    • #3
      PowerBasic for Dos, 3.5. Sorry to that leave out.


      • #4
        You didn't really leave it out, because you posted your message in the PB/DOS forum.

        I was asking whether or not your program was being run on a Windows computer or a DOS computer. It is very difficult to perform accurate "delay" operations on a Windows machine, regardless of the language, because of the way Windows works.

        -- Eric

        Perfect Sync Development Tools
        Perfect Sync Web Site
        Contact Us: mailto:[email protected][email protected]</A>
        "Not my circus, not my monkeys."


        • #5
          Got you. Ok, I am running a Windows Me, but running Powerbasic
          Dos mode. We will get there yet! This problem is driving me
          nuts, I am 99 percent sure there is a way to do it.



          • #6
            look here:



            • #7
              Robert --

              > Powerbasic Dos mode

              If you mean that you have rebooted the computer in the DOS mode, you should be ok. If you mean that you are running your PowerBASIC program in a "DOS box", probably not.

              Here's the problem...

              Windows performs multi-tasking by giving programs "time slices". First one program runs for around 1/100 of a second, then another, and so on. When every program has had its chance, the first program gets another time slice. Even under the best of circumstances this can make it impossible for a program to perform millisecond-accurate timing operations.

              If another program "hogs" the processor -- and this is especially true on Windows 95/98/ME -- your program can be prevented from getting any processor time at all for several seconds or minutes.

              Additionally, waiting for something to happen can be very tricky. For example...

                  IF SomethingHappens THEN
                      EXIT LOOP
                  END IF
                  IF TimeOut(1) THEN
                      EXIT LOOP
                  END IF
              Imagine that you want to wait up to 1 second for some kind of event. The loop checks for SomethingHappens after .01 second and it is not True. Then, in the "space" between the two if-tests, Windows gives the processor to another application, and your app doesn't get it back for 5 seconds. When your program gets the CPU the TimeOut(1) has expired and the loop exits, even though the "something" may well have happened within the one second timeout.

              It's possible to perform accurate timing on a Windows system, but you must use a Windows programming language. DOS programs can't control Windows like that.

              -- Eric

              Perfect Sync Development Tools
              Perfect Sync Web Site
              Contact Us: mailto:[email protected][email protected]</A>

              [This message has been edited by Eric Pearson (edited August 11, 2001).]
              "Not my circus, not my monkeys."


              • #8
                Thank you everyone. -Robert



                • #9
                  Be sure that you test out & calibrate any timer routine you
                  get -- including those you might get from this forum. I
                  tested more than a dozen myself before settling on this
                  one (for short delays) & ALL have "side effects" or quirks
                  of some sort, especially if you run under Windows, as Eric says.


                  'WaitaTinyBit -- by E.W. Menzel, Jr. for PB 3.5
                  'pseudo-clock for short pauses
                  'accurate to < 1 millisec in DOS; less accurate in Windows
                  'NOTE THAT THIS SUB MUST CALIBRATE on first call
                  SUB WaitaTinyBit(seconds AS DOUBLE) STATIC
                  DIM LoopsPerSec as double
                  DIM finish as double, X as double
                  DIM counter as long, N as long

                  'If we haven't yet calibrated clock, then do it
                  IF LoopsPerSec = 0 then
                  counter=1& ' make it >0 to fool calib. loop below
                  N=5& 'in DOS N=1 might do, but Windows is more variable
                  X=.05492549#*N 'must not be any MORE than N clock tics
                  finish=TIMER +.01#
                  WHILE TIMER < finish: WEND 'wait til next tic
                  finish=TIMER + X

                  WHILE TIMER < finish and counter > 0
                  incr counter
                  LoopsPerSec=(1193180#/65536#)* (counter/N)
                  '''LoopsPerSec=LoopsPerSec/.9519365# 'fudge factor
                  '''? "Loops Per Millisec";INT(LoopsPerSec/1000)
                  END IF

                  finish = TIMER + seconds 'or make it 86401, a dummy value
                  counter= -(LoopsPerSec * seconds)
                  WHILE TIMER < finish and counter < 0
                  incr counter
                  END SUB



                  • #10
                    You bet Eric..

                    if another program "hogs" the processor -- and this is especially
                    true on Windows 95/98/ME -- your program can be prevented from
                    getting any processor time at all for several seconds or minutes.
                    This is terribly important where anything depends on the ability
                    to keep that data coming in and you can't control the sending
                    source. A prime example is in satellite down-link connections!
                    The bird is going to send you data .. period.

                    It is *EXACTLY* why every DOS application now, including all the
                    tools we use, *MUST* be able to give up time slicing to other
                    tasks that may be needing them!

                    It is also, per my feeble understanding of all this, precisely why
                    the entire WIN operations game is disasterous for the big time
                    heavy mission telecommunications applications which are SMP
                    box targets. I'm perfectly willing to be educated here, in fact
                    I want to be told I'm wrong, if I am, please, please!

                    The entire WIN game has no capacity to orchestrate CPU assignment
                    for task switching on the basis of THREAD needs. It can only
                    assign a CPU to a PROCESS need level.

                    Thus if you expand this question into precision timing for an
                    application into the future, and project it onto a box which we
                    WILL see in common use, sooner than later, solving this problem
                    in some sort of a standardized way for us in the PowerBASIC user
                    set is terribly important, I think.

                    In less time than I think most of us realize, we will be confronted
                    with task switching requirements for THREAD coordination, even
                    at the home desktop level, per processor. Yes, that's a bold
                    statement. But I think it's true.

                    I know it is hard to realize in many places outside the United States,
                    but, for all practical purposes, unlimited bandwidth is coming to
                    many of us sooner than we might think. Glass down to home sites is
                    far closer to installation in the USA than most folks imagine. I
                    think the statement I heard a couple years back, which I dismissed
                    as, "Oh well", is suddenly, introspective! One fiber strand will
                    carry the entire content of the Library of Congress in about five minutes,
                    if you ask for it, and they can deliver it!

                    One second on fiber will carry more than the internet carried in total
                    data on a month a few years back ... to each and every home!

                    There is no way, as I distinctly recall the President of Western
                    Digital tell the Houston Area PC User group less than two years
                    ago, for storage devices to keep up with processor horsepower
                    and multi-tasking in the even near-term foreseeable future. He
                    noted that the average box delivered to the average customer,
                    by the end of 2001, would be delivered with a 39 MB hard disk,
                    and that most decent boxes would have two of them.

                    This was said two years ago near Christmas time in Houston.

                    A member of the audience (not Mikey!) hollered out, "What for?"

                    He shot back without even a ripple in his voice, "You'll need
                    it and it will all be full!"

                    Processor and task orientation is, as he noted, always two to
                    three years behind the hardware for storage. He forecast that
                    this would continue or get worse for long into the future after
                    the 2001 date he spoke towards.

                    Thus the only way to work, with what is actually coming in the
                    way of glass embeddment in home use, is to solve the microsecond
                    time slice and task re-alignment game ..


                    It is in my feeble way of looking at it one VERY good reason that
                    we can't afford to look at all the eggs through the Windows. As
                    PowerBASIC takes the leap toward UNIX and so on .. hopefully, our
                    toolset and those around it will somewhat standardize on what must
                    be done for all to use even older apps, in harmony..


                    We simply won't be able to store it all just to look at it and use
                    it .. in my opinion.

                    Hej! I just discovered that OS/2's Spell Checker keyboard shim works
                    while I'm writing this stuff into the reply window! Gee, maybe
                    my spelling will improve in this thing where it will trap some
                    of the misteaks (caught it!) that I always make!!

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


                    • #11
                      I use the following code to wait one millisecond for my morse
                      tutor programs, it seems to work OK on most Windows versions for
                      my DOS programs but I would welcome comments from those more
                      knowledgable than I! It uses the hardware timer.
                      sub onems
                       ! pushf         ; save flags
                       ! cli           ; stop interrupts
                       ! xor al,al     ; set al=0
                       ! out &h43,al   ; latch timer 0
                       ! xor al,al     ; delay
                       ! in al,&h40    ; input lo byte of counter
                       ! mov dl,al
                       ! in al,&h40    ; input hi byte of counter
                       ! popf          ; enable interrupts
                       ! mov dh,al     ; count now in dx
                       ! pushf         ; save flags
                       ! cli           ; stop interrupts
                       ! xor al,al     ; set al=0
                       ! out &h43,al   ; latch timer 0
                       ! xor al,al     ; delay
                       ! in al,&h40    ; input lo byte of counter
                       ! mov ah,al
                       ! in al,&h40    ; input hi byte of counter
                       ! popf          ; enable interrupts
                       ! xchg ah,al    ; count now in ax
                       ! mov bx,dx     ; copy intial count
                       ! sub bx,ax
                       ! cmp bx,&h938  ; 1 millisec
                       ! jl w1ms
                      end sub
                      You can build this into a function or sub to select the delay.


                      Don Ward



                      • #12
                        Oh Thank you Don! Bless you!

                        What a perfect example to use for a demonstration of the absolute
                        destruction of CPU performance by the PB IDE that you can't break
                        into giving you time slice releases! Add a little BASIC test snip
                        to Dan's suggested code as in:

                        PRINT TIME$
                        FOR NJ% = 1 TO 2000
                           ' IF NJ% = 990 THEN PRINT " -> "; TIME$
                           CALL onems
                        NEXT NJ%
                        PRINT TIME$
                        The couple of PRINT statements may keep the results from rolling
                        off the screen if you run it in an compiled executable, that's all.

                        You may find that in a DOS-VDM session in OS/2 that you have to
                        set the HW_TIMER=ON in the session setting commands. In OS/2 we
                        have the option to let any specific session have access to the
                        hardware ports, on an optional basis, in stark contrast to what
                        is offered in the WIN arena, as I am told. At any rate, one way
                        or the other you will get the following output on your screen:


                        Interestingly, it also opens a path to proving up system capability
                        to, at least from a per second basis, to resolve TIMER issues, even
                        perhaps to the millisecond, in your operating system, even though an
                        integer loop is making 2000 CALLS to that routine. Let's not get
                        into the game of how many milliseconds this may be off in precision
                        loops for gating EG&G trigger switches used for the detonation of
                        nuclear devices, please! (I have used them for peaceful purposes!)
                        Uncomment the step print comment above and exxpand on it if you want
                        to play and think about how to prove a millisecond might or might
                        not be critical from one second to the next.. whatever.

                        I got the above, for example, with 18 active tasks, 36 processes,
                        and 152 threads running simultaneously on the box on which this
                        demo was run. It's a good demonstration of the real capabilities
                        of OS/2, as well as both PowerBASIC's absolute superiority in speed
                        as well as it's brilliance in the use of inline assembler!

                        Now, watch the total destruction of the system from the use of the
                        PB IDE as to timing.

                        Load TWO instances of the PB product in SEPARATE DOS-VDM sessions in
                        OS/2. Bring up the IDE in both! That gives you two loads of the IDE
                        just for demo purposes. In ONE of them just execute the little snip
                        above for you mystical trip into two second timer land, whilst the
                        other one is still sitting in the IDE waiting your command. Voila!


                        Total destruction of all timing relationships for EVERYTHING, including
                        even native OS/2 applications!

                        It's not possible in this forum to demonstrate the exact destruction in
                        native OS/2 applications that are important to me. I don't have the
                        source to provide the step output to do that for them, but the malady
                        *CAN* be shown with nothing other than the above which is only a very
                        few lines of code.

                        Now, PLEASE, PLEASE, PLEASE .. may we have some help to be able to
                        break up the polling problem in the PB IDE and DEBUGGER. You simply
                        can't afford to go off and leave the IDE or DEBUGGER up on any time
                        sensitive box. Even a suggestion as to a utility that will break it
                        up, while still leaving control for other applications that do respond
                        to the tools I know about, will be fine.

                        Thanks ..

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


                        • #13
                          In the Windows world, you can coarsely adjust the amount of CPU time that is allocated to a DOS application through the Properties box. However, since the quantum is usually 10mSec or more, reliable 1mS timing in Windows is difficult to guarantee. Using a critical section interrupt can help, but not recommended for long durations.

                          Basically, if you need tight millisecond timing, running a multi-tasking O/S is not recommended.

                          In any case, Mike, doesn't OS/2 allow you to set the Idle-detect and/or time slices for DOS applications in the same way? (Even Windows 3.x provided this ability)

                          If not, why not?

                          PowerBASIC Support
                          mailto:[email protected][email protected]</A>
                          mailto:[email protected]


                          • #14
                            As a matter of fact, Lance ..

                            In any case, Mike, doesn't OS/2 allow you to set the Idle-detect
                            and/or time slices for DOS applications in the same way?
                            (Even Windows 3.x provided this ability)
                            It DOES! It's not well known, but there are two lines you can add in
                            your CONFIG.SYS for OS/2 that, as I understand it, changes the
                            entire PRE-EMPTIVE multi-tasking for OS/2 to what it was/is like
                            in WIN and, particularly, in Desqview. For those interested, the
                            command line you may add in your OS/2 CONFIG.SYS file are:

                            REM ** Is the standard PRIORITY=DYNAMIC
                            OS/2 is a PRE-EMPTIVE multi-tasker and a fantastic one at that! One
                            of the major reasons that it failed to gain the huge following in
                            the single user market place it that it's very difficult to play
                            games on it that were DOS or WIN oriented. Arguably, everthing's an
                            argument, DOS in OS/2 is a better DOS, a far better DOS, than DOS! And
                            with that comes the flip side that, for timing purposes, DOS and,
                            Windows needed/s a much different operating set of thinking for
                            applications in multi-tasking than it had/has .. in certain of its
                            versions. This is *NOT* a comment in respect to WIN-NT, nor some
                            of the later versions of the user enablement of the NT-style code at
                            all which have come much, much later down this pig trail.

                            Part of the reasons why PoweerBASIC applications fail miserably in
                            telecommunications applications when loaded for more than just a few
                            of them at any given time in WIN-95 and WIN-98 boxes is related to
                            just how poorly the WIN operations handle all this for them.

                            Those limitations simply do not exist in OS/2 DOS emulations, and, yes,
                            DOS is nothing more than an emulation, an OBJECT, if you please, while
                            in the OS/2 arema.

                            In the case of the use of the above switches in your CONFIG.SYS line,
                            what you are doing is to change OS/2 from its very well thought out
                            PRE-EMPTIVE format, again, to a fixed time slice format. The second
                            line in the suggested change to CONFIG.SYS provides for a specific
                            number of task switches, in milliseconds, that the CPU is expected
                            to give to the foreground and the background, respectively. Early on
                            as all this multi-tasking developed in respect to desktop units as
                            CPU's began to gain horsepwer and re-entrancy was defined for the
                            better operating systems to make use of them, those of us in the DOS
                            BBS world worried and experimented at length with this!

                            We came to the very valid conclusion that OS/2 could do a far better
                            job of deciding on what was a valid pre-emtive need for the various
                            applications running under the operating system than we, or Desqview,
                            or any WIN application could do. That wealth of experience which IBM
                            had/has in relation to mainframe operations shows over and over again
                            in all this, for many years. It took Microsoft many, many years to
                            even come close to this, in my opinion, until at least WIN-NT3.

                            The actual crucial reason that this is still far more important than
                            most folks believe and why it MUST be solved for those of us who
                            write applications which are DOS based is this! More and more we
                            will be using them on the mulit-tasking systems. That is going to
                            happen; period. In fact, a pure DOS based suite of many many programs
                            can do a perfectly fantastic job in OS/2, written in entirely the 3.5
                            PowerBASIC product. You can run a dozen applications in separate
                            sessions on an embedded box, including telecommunications applications
                            at the same time. To the extent that you solve the inter-related file
                            and comm I/O problems with semaphore technques, who cares?

                            In fact, a semaphore at the file I/O level, is much the same thing,
                            as a semaphore at code level, wherein the actual code can create
                            THREADS too. It is in this THREAD level code that we see the rest
                            of the meed for DOS applications to be able to leave the operating
                            system a chance for task switching!

                            You see, OS/2 and UNIX also, so I am told. have the ability to do full
                            Symetric Multi-tasking of the CPU on a PER-THREAD basis! As far as I
                            have been able to learn from lurking, but do not know from experience,
                            that is precisely the reason that the entire WIN operations are closed
                            to the really huge transaction processing game. They can only be used
                            for SMP at the PROCESS per CPU level! In other words, in the arena
                            of the SMP game, a PowerBASIC application written for DOS, will take ]
                            a single CPU to run it, irrespective of how many people, on a thread
                            basis, might be assigned to that same task!

                            That same sort of logic, is the reason, we were told, in the data that
                            was released in the OS/2 groups, that even Microsoft was forced to
                            abandone their entire world-wide barrage of some 1700 WIN-NT servers
                            amd go right back to the same twenty-three (23) AIX-400's that had
                            been handling the entire world-wide operations for them! The issue of
                            THREAD based CPU and task alignment, even when carried down to the
                            individual DOS level program, is terribly critical as these CPU's,
                            boxes, and operating systems get better and better.

                            Please do NOT shoot the messanger. I don't pose to be any sort of
                            expert at all at this. You asked:

                            If not, why not?
                            As a very lowely peon at all this, I have done my best to tell you
                            exactly why not, as I understand all this at my level of awareness.

                            Please .. may we have some help for the IDE and DEBUGGER at this?

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


                            • #15
                              if you are operating in 'real' dos the following snippet my be of use:
                                   sub delaymsec(byval msc??) public
                                       local usec???
                                       shift left usec???,10
                                       ! push ds
                                       ! mov ax,&h8600
                                       ! mov cx,usec???[02]
                                       ! mov dx,usec???[00]
                                       ! int &h15
                                       ! pop ds
                                   end sub
                              if in windows then the code i posted works well with the noted provisos:



                              You're never too old to learn something stupid.


                              • #16
                                That's a very interesting millisecond delay Dave. My DOS bible
                                doesn't list that function for INT &H15. I have tried it and
                                it works for me but it does n+1 milliseconds so a 1 millisecond
                                delay needs a call with zero. Where can I find this function



                                • #17
                                  I have it listed in a number of books, including:

                                  PC Intern by Michael Tischer ABACUS 1992

                                  The undocumented PC by Frank van Gilluwe Addison-Wesley 1994
                                  ISBN 0-201-62277-7

                                  I've never experienced the n+1 problem, except to say that
                                  the first time it's called there sometimes is a slight delay,
                                  varies from computer to computer, after that it's pretty good.
                                  I always do a dummy call somewhere at the start of the program
                                  where it's not important.



                                  You're never too old to learn something stupid.


                                  • #18
                                    I put it in a 1000 loop called with zero (I cheated and set cx,dx
                                    to zero) and printed a count versus time$. It went slightly faster
                                    than time$.



                                    • #19
                                      <Quote from Dave>
                                      PC Intern by Michael Tischer ABACUS 1992

                                      The undocumented PC by Frank van Gilluwe Addison-Wesley 1994
                                      ISBN 0-201-62277-7
                                      <End quote from Dave>

                                      Dave, please verify that ISBN number for me. The local bookstore
                                      drew a blank with that number. If it is accurate, I will just go
                                      to another bookstore or get it off an online bookstore.

                                      Thank you.




                                      • #20
                                        When normal bookshops fail, try


                                        PowerBASIC Support
                                        mailto:[email protected][email protected]</A>
                                        mailto:[email protected]