No announcement yet.

Time running fast

  • Filter
  • Time
  • Show
Clear All
new posts

  • Time running fast

    I have a PBDOS program that displays the time on the screen.
    The program is running on a WIN2K SP3 machine. After the program
    runs for a while (20-30 minuites) the time is several minutes
    ahead of the time displayed on the task bar.

    Any ideas why?


  • #2
    Talking about TIME$ or TIMER or other ?

    Is it the time showed by your program that runs faster, or the time in the taskbar that becomes slower ? Might it be that your program running in the DOS box takes too much CPU giving problems to Windows ?

    Davide Vecchi
    [email protected]

    [This message has been edited by Davide Vecchi (edited November 27, 2002).]


    • #3
      Here is the code I using to displat the time

      Locate 1,72
      Print GoodTime(Time$)+" "+Toggle$

      FUNCTION GoodTime(EdStr As String) As String
      If Len(EdStr)=8 Then A=Left$(EdStr,2)+Mid$(EdStr,4,2) Else _
      REPLACE " " WITH "0" IN A
      If Hour>12 then 'Takes time in HH:MM:SS or HHMM format and
      DECR Hour,12 'returns in HH:MM{am|pm} non-military
      ElseIf Hour=12 then
      ElseIf Hour=0 then
      End If
      End FUNCTION



      • #4
        The "DOS" you see under NT-based operating systems (like Win2k) is
        actually a virtual DOS box. Each "box" gets its own pretend copy of
        the whole computer, with certain safeguards in place to avoid having
        the "box" conflict with other programs. As part of this virtual DOS,
        your "DOS" programs get their own copy of the system time and date,
        which runs separately from the real system time and date.

        Try setting TIME$ to something different in your DOS program, and
        note that the Windows time doesn't follow suit.

        PB/DOS needs to do some twiddling with the timer chip in order to
        provide better timing resolution. It has secondary routines in place
        that keep the time/date value at its normal speed, regardless. But,
        these routines were designed for a real timer chip, not the virtual
        timer chip provided by the DOS box. My guess would be that Win2k is
        not emulating the timer chip with perfect fidelity, causing some
        drift in the apparent time/date value. That's just a guess, though.

        Tom Hanlin
        PowerBASIC Staff


        • #5

          Would this Windows-"virtualized" system time also apply to directly
          reading the system clock with INT &H21 service &H2C? I have a
          PBU function that does that, and if you think it'll help, I can post
          the code for Doug? Doug - please note that my PBU code has ONLY
          been tested under my Win98SE, so USE AT YOUR OWN RISK! Also, I have
          not run it cyclically for long periods of time, so I do not know if
          it would have the same problems as the PB/DOS TIME$ command. Might
          be an idea to wait for Tom to answer.



          • #6

            Here's a "beefed up" version of my PBU code. My original code only
            returned the same info that the native PB/DOS TIME$ does. This code
            will retrieve the time from the system clock, convert it to 12-hour
            clock, and append the appropriate "AM" or "PM".

            USE AT YOUR OWN RISK! It has NOT been tested on a Platform 2 OS!
            I also do not know if it will return better results than the TIME$

            $COMPILE UNIT
            DEFSTR S
            DEFINT I
            %FLAGS = 0
            %AX    = 1
            %BX    = 2
            %CX    = 3
            %DX    = 4
            %SI    = 5
            %DI    = 6
            %BP    = 7
            %DS    = 8
            %ES    = 9
            FUNCTION GetTime2$() PUBLIC
                I1 = 0
                I2 = 0
                ! PUSH DS
                REG %AX, &H2C00
                CALL INTERRUPT &H21
                I1 = REG(%CX)
                I2 = REG(%DX)
                ! POP DS
                IHour = (I1 AND &HFF00)
                SHIFT RIGHT IHour, 8
                IMinutes = (I1 AND &H00FF)
                ISeconds = (I2 AND &HFF00)
                SHIFT RIGHT ISeconds, 8
                SELECT CASE IHour
                    CASE 0
                        SHour = "12"
                        SAMPM = " AM"
                    CASE 12
                        SHour = "12"
                        SAMPM = " PM"
                    CASE 1 TO 11
                        SHour = TRIM$(STR$(IHour))
                        SAMPM = " AM"
                    CASE > 12
                        SHour = TRIM$(STR$(IHour - 12))
                        SAMPM = " PM"
                END SELECT
                SMinutes = USING$("##", IMinutes)
                SSeconds = USING$("##", ISeconds)
                REPLACE " " WITH "0" IN SMinutes
                REPLACE " " WITH "0" IN SSeconds
                FUNCTION = SHour + ":" + SMinutes + ":" + SSeconds + SAMPM
            END FUNCTION


            [This message has been edited by Clay Clear (edited November 27, 2002).]


            • #7
              The same app runs on several machines that are part of win2k
              peer to peer network, the other machines use the following

              NET TIME \\"+TimeServerName+" /SET /YES"

              to keep their clocks at the same time. The app skips the above
              code if it is running on the "timeserver". The other machines
              time stays the same as the time on the task bar.

              I will have the timeserver shell to net time every few minutes
              and see if that resolve the problem.



              • #8
                Clay, DOS only "directly" reads the system clock on start-up. After
                that, it maintains its own cheap imitation copy. It's a legacy thing
                from the days when a "real-time clock" was an optional add-on card,
                without which you were expected to enter the time and date whenever
                you started up DOS. Ah, the good old days!

                It's this software copy of the real clock that's getting messed over.
                Doug's NET TIME approach should work fine, although it's probably
                overkill-- Windows still knows what the real time is, so the program
                just needs to ask Windows every now and then.

                Tom Hanlin
                PowerBASIC Staff