From: mauch AT uni-duisburg DOT de (Michael Mauch) Newsgroups: comp.os.msdos.djgpp Subject: Re: testing uclock() Date: Mon, 05 May 1997 12:31:19 +0200 Organization: Home, sweet home (via Gesamthochschule Duisburg) Lines: 131 Distribution: world Message-ID: <336ea503.189123@news.uni-duisburg.de> References: NNTP-Posting-Host: ppp91.uni-duisburg.de To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk On Sun, 4 May 1997 10:34:10 GMT, Eli Zaretskii wrote: > > On the other hand: isn't it possible that this default mode is just > > the same as the one set by the first call to uclock()? The > > difference between two consecutive calls to uclock() remains the > > same, even after that single negative difference. > > No, you can't work with the default mode at all. Under that mode, the > timer counter goes up and down twice during the 54 msec period, so you > cannot reliably compute the interval. Oh, that's bad. > > I removed the first three outportb() calls from the uclock source > > code, and now I don't get any negative differences anymore. > > I think that is specific to the time that your test program waited > between two calls to `uclock'. Try different intervals and you will > see the problem again. Yes, you are right, unfortunately. In the meantime I translated my 16 bit source code to work with DJGPP. It uses the Virtual Timer Device of Win3.1/Win95 if this is available, otherwise it calls the original uclock(). Although it seems to work, I'm not sure how accurate it is - as much as we can expect timing accuracy in Windows. I looked at the output of a test program (with different intervals, this time) using gnuplot, and it shows up that it is a lot slower than uclock(), and there are a lot of peaks (some of them up to 60000 tics, i.e. 50ms), but there a no negative values anymore. Another question is, if there is a wrap-around anywhere (there's none at midnight). Ralf Brown's Interrupt List says that the VTD API gives the time since Windows was started, so there should be a long time before the 63 bit signed long long (returned in edx:eax by the VTD API call) would need a wrap around. But you never know. And I don't know why the original uclock() source uses __bss_count (what is __bss_count?): if (uclock_bss != __bss_count) { /* timer chip initialization here */ uclock_bss = __bss_count; } Is it simply a flag to do the initialization only once or what's the magic with __bss_count? Regards... Michael begin 644 Puclock.h M(VEF;F1E9B!054-,3T-+7T@-"B-D969I;F4 AT 4%5#3$]#2U](#0H-"B-I;F-L M=61E(#QT:6UE+F@^#0H-"F5X=&5R;B!U8VQO8VM?="`H*G!U8VQO8VLI*'9O 0:60I.PT*#0HC96YD:68-"F5X ` end begin 644 Puclock.c M(VEN8VQU9&4@/'-TF5R;RX@(%1H92!N=6UB97(@;V8@=&EC7,@=&AA="!T:&4 AT 5E1$ M(')E='5R;G,@=&AE#0HJ*B`B8VQO8VL@=&EC:R!T:6UE(&EN(#@T,&YS('5N M:71S('-I;F-E(%=I;F1O=W,@=V%S('-T87)T960B#0HJ*B`M('-E92!486)L M92`Q.38Y(&EN($EN='=I;C4S+FAL<"P@2!T:&4@=&]P M:6,-"BHJ("))3E0@,D8@,38X-"`M($U3(%=I;F1O=W,@+2!65$0@+2!'150@ M05!)($5.5%)9(%!/24Y4(BX-"BHJ#0HJ*B!)(&AO<&4@=&AA="!T:&5S92`B M.#0P;G,@=6YI=',B(&%R92!T:&4@2!P;VEN=',@=&\@=W5C;&]C:U]WPT*("!S=&%T:6,@5!O:6YT.PT*("!S=&%T:6,@=6-L;V-K M7W0 AT 8F%S93L-"B`@=6-L;V-K7W0@"YA>"`](#!X,38X-#L-"B`@ M("!R96=S+G AT N8G@@/2`P>#`P,#4[#0H@("`@"YCPT*("!U8VQO M8VM?="!R(#T@=W5C;&]C:R AT I DOT R`@+RH@=&5S="!I9B!65$0 AT 05!)(&ES(&%V M86EL86)L92`J+PT*("!I9BAR/#`I#0H@("`@