Using the timer function I can create a time based delay of a minimum of .01 seconds.
PAUSETIME# = .01
TIME# = TIMER
DO: LOOP UNTIL TIMER >= TIME# + PAUSETIME#
Unfortunately this ain't short enough.
Is there any easy way to get a shorter delay ?
I have searched for something like this, and I'm sure someone responded years ago to one of my queries. Unfortunatly I didn't need such a short time delay and didn't bother to write the code down. BTW, I have tried changing PAUSETIME# to less than .01 !!
you can read the timer at a higher rate using this code, compliments of seav and qbtm magazine:
Code:
FUNCTION CLOCK&
' Get the number of timer ticks at
' 0000:046C
DEF SEG = 0
Ticks& = PEEK(&H46C)
Ticks& = Ticks& + PEEK(&H46D) * 256
Ticks& = Ticks& + PEEK(&H46E) * 65536
DEF SEG
' Latch the counter and obtain the PIT
' countdown status.
OUT &H43, &H4
LSB = INP(&H40)
HSB = 255 - INP(&H40)
' Compute the CLOCK& value
CLOCK& = Ticks& * 256 + HSB
END FUNCTION
'to test it:
CLS
DO
TimerVal! = TIMER
ClockVal! = CLOCK / 4660.859#
LOCATE 1
PRINT USING "CLOCK: #####.###"; ClockVal!
PRINT USING "TIMER: #####.###"; TimerVal!
LOOP UNTIL LEN(INKEY$)
This routine should be in the FAQ...
Quote:Using the timer function I can create a time based delay of a minimum of .01 seconds.
PAUSETIME# = .01
TIME# = TIMER
DO: LOOP UNTIL TIMER >= TIME# + PAUSETIME#
Unfortunately this ain't short enough.
Is there any easy way to get a shorter delay ?
I have searched for something like this, and I'm sure someone responded years ago to one of my queries. Unfortunatly I didn't need such a short time delay and didn't bother to write the code down. BTW, I have tried changing PAUSETIME# to less than .01 !!
The other (less classy) way to do it is to use TIMER at the beginning of your program to time how many cycles an empty loop completes in one second, and then divide that number by 100 for the number of cycles to get .01 seconds.
EDIT: Also, you can do a vertical retrace wait to lock your framerate at 60. It accomplishes the same thing.
Not always, on some computers, the vertical retrace happens more times per second, e.g. 100 Hz. That will make the program faster
Nope. VGA Vsync is always 60Hz to 70Hz. This has nothing to do with the info that pops out in your monitor.
Seav's solution is only accurate in plain DOS.
In a dos box there is a delay between the PIT rollover and the dos clock update. If your routine executes during this delay you have a reading wrong by +- 1/18.2 second. In a dos box you should save the last good reading and keep reading until the time you have is bigger than the saved time.
I'm now running QB in a W2000 box and the problem is even worse than in W98
Quote:This routine should be in the FAQ...
Theirs an FAQ? Wow. Where, Oh I see it. Hmmm lovely.
Why can't I access everything