Timer in DOS

[dasyar]

With older processors (386, 486), and always in DOS, the resolution is 1/18
second.

This is what it says in the docs; I am having a small problem with trying to figure out what number I would have to use to represent a half a second (.5). Does this mean that 1 = 1/18 of second (.05), and (.45) would equal half a second. I must be missing something major here.

I am trying to get a handle in how to use a Timer in DOS.


Thanks

[vdecampo]

Code: Select all

If Timer-LastTime > .5 then 'Half second elapsed
     LastTime = Timer
     'Do stuff
end if

-Vince

[dasyar]

In my terminal program, similar code was tried, when compiled with the windows FBC, and run in a window DOS box, that piece of code acts as expected. When it is compiled with DOS FBC, and run under DOS, or a DOSBOX, the timer goes crazy, it looks like it working 10 times as fast. There is something about that 1/18 resolution that I am not getting.

Thanks

[vdecampo]

In my terminal program, similar code was tried, when compiled with the windows FBC, and run in a window DOS box, that piece of code acts as expected. When it is compiled with DOS FBC, and run under DOS, or a DOSBOX, the timer goes crazy, it looks like it working 10 times as fast. There is something about that 1/18 resolution that I am not getting.

Thanks

The DOS timer may be measuring milliseconds instead of seconds. If that is the case you need to div/1000 or multiply .5 x 1000.

Code: Select all

If Timer-LastTime > 500 Then '500ms = Half second 
     LastTime = Timer
     'Do stuff
End If

[vdecampo]

You can find out how many clicks will pass on the timer per second with this code...

Code: Select all

Dim sclick As Double
Dim clicks As Double

sclick=Timer
Sleep 1000
clicks=Timer-sclick

Print clicks

Sleep

The value in clicks will be what number is equal to 1 second.

-Vince

[dasyar]

There might be a problem with the timer in DOS. Using the previous post code, running it with 'sleep 1000', I got a 3.999 ... When you get it down to 'sleep 50' it shows 1.999 ..., 'sleep 10' it shows 1.999 ... and it does not change. So, 3.999 ... shows real time elapsed, 1000 = 3.999 secs? Can I make the assumption that the Timer command for DOS is kaput?

Thanks

[vdecampo]

There might be a problem with the timer in DOS. Using the previous post code, running it with 'sleep 1000', I got a 3.999 ... When you get it down to 'sleep 50' it shows 1.999 ..., 'sleep 10' it shows 1.999 ... and it does not change. So, 3.999 ... shows real time elapsed, 1000 = 3.999 secs? Can I make the assumption that the Timer command for DOS is kaput?

Thanks

??? That is strange. Perhaps you should post this in the DOS forum for a platform specific answer. It makes no sense to me.

Sorry
-Vince

[counting_pine]

@vdecampo, are "clicks" just supposed to be the difference in seconds between the start and end of the Sleep?


@dasyar, try this program. What sort of values do you get with it? You can play around with sleep_ms for different Sleep times.

Code: Select all

dim as double timer1, timer2
dim as integer sleep_ms, timer_ms

sleep_ms = 100

timer1 = timer
sleep( sleep_ms, 1 )
timer2 = timer

timer_ms = (timer2 - timer1) * 1000

print "Start time (seconds):", timer1
print "End time (seconds):", timer2
print
print "Sleep time (milliseconds):", sleep_ms
print "Actual time (milliseconds):", csng( (timer2 - timer1) * 1000 )

Sleep time and actual time should be quite close - I'm not sure how close on DOS, but probably within 100ms difference. If you're getting numbers like 1999ms for a 50ms sleep, then there's something very wrong...

[vdecampo]

@vdecampo, are "clicks" just supposed to be the difference in seconds between the start and end of the Sleep?

In this instance I use "clicks" to represent an arbitrary timing number system. Since I wasn't sure if the values being returned were seconds or ms, I just wanted to see what values would be returned timing a 1sec sleep.

-Vince

[Loe]

If I recall correctly, timer in dos is about interrupt 1c,
BIOS will call this interrupt 65535 (1 word) times every hour.
so it will about 65535/60/60 times every second, or about 18.204167 times

[MichaelW]

The BIOS timer tick normally counts 65536 cycles of the 1193182 Hz PIT clock. The long-term accuracy of the timer in DOS should be good. The problem is trying to time short periods against a timer with a 54.9…ms resolution. You can improve the situation somewhat by synchronizing with the timer tick before you start timing your event. This should eliminate half of the ~110ms uncertainty.

One possible solution, easy to use but with poor long-term accuracy, is here:

http://www.freebasic.net/forum/viewtopic.php?t=11777

Edit:

To expand on the “uncertainty”:

Timing an interval requires 2 calls to the timer function, and because each call could occur at any point in the timer cycle the uncertainty for each call is equal to the timer period, ~55ms, so the uncertainty for the timed interval is ~110ms. By synchronizing with the timer at the start of the timed interval, so you know that you are at the start of a timer period, the uncertainty in the timed interval is the uncertainty for the second call to the timer function. You can synchronize with the timer using something like this:

Code: Select all

t = timer
do
loop until timer > t

The high-resolution timer at the link above has a negligible uncertainty, but a significant error that in my tests was much smaller than even the ~55ms uncertainty for the timer function.

[Loe]

The BIOS timer tick normally counts 65536 cycles of the 1193182 Hz PIT clock.

yupz I meant to say 16 bit resolution=65536 not max value of word :-(
as PIT is the acronyme of Programmable Interrupt Timer, we can program timer tick as we want (not 65536 cycles anymore)
in the DOS we use to program interrupt 8.
but sorry I should dig my old files files about how to program it.

[dasyar]

So, does FB need a new command, Timer2, to be used with DOS? It seems that there should be some consistency in the commands, especially between DOS, and windows.

I guess now we need a Timer Sub/Function for programs that will be compiled with FBC DOS. Hopefully it will resemble the regular version of Timer. This would be a good place to start, but I need some help with this.

Thanks

[counting_pine]

Also, I'm not sure what you're suggesting about a Timer2 function. If there's a function that provides a better resolution, we'd probably just use that internally for Timer...

Getting back to your previous issue, Timer's 1/18 sec resolution shouldn't be causing you to get almost-multiples of 1 second for a 50ms Sleep. Maybe I misunderstood your earlier post... But anyway, are you happy that there aren't any catastrophic bugs in Timer?

[phishguy]

I finally figured out the problem with the timer code for your terminal program in DOS. Evidently, the DOS version of the compiler doesn't like assigning a timer value to anything other than a double. So, if you dim t as double it should work fine. This was driving me nuts and I was getting all sorts of wierd problems. It's strange that the Windows version doesn't care about the timer assignment.