Opie Pecheux wrote:
Delay is a loop I think. It's well known in BP beacause of the famous error 200 on the 200Mhz PC.
That's called busy waiting (as I mentioned in my other mail) and is generally a Bad Thing (tm). Even Dos programs often run in multitasking environments today (MS-Windows, Linux DosEmu, etc.), and burning CPU cycles when waiting is quite inefficient. Also, as I mentioned, calibrating a delay loop exactly is a difficult thing. Borland actually did quite a clever thing there, but the more sophisticated processors have become, the more inaccurate this method has become (I'm not talking about the bugs, but about the general issue of doing exact timing by a programming loop).
I dont mind that delay is realy or not one ms, but I want a time and 1/18 s is too big.
I forgot to say I work with Win95/gpc2952b.zip found on agnes.dida.physik.uni-essen.de/home/maurice/
The test program is:
Program test_delay; Uses Crt; Procedure DelayC(Temps:Integer); AsmName 'delay'; Var N,I:integer; Begin For N:=15 Downto 1 Do For I:=1 To 20 Do Begin Write(N:4); Delay(N); Delay(N) End End.
If i use delay, the end is done quickly. If i remplace by delayC (from the C library), it works.
Interesting. :-)
This should make it possible to fix/work-around the problem in CRT...
What I'm wondering is, if DJGPP's libc contains a delay() function which does handle short delays well (and even seems to use microseconds internally AFAICS), why doesn't its usleep() function do the same thing?
Are there any issues with the interrupt call used in delay() (that I probably should be aware of when using it in CRT), or what is the reason? Anyone knows?
Frank