Message-Id: <199808271938.VAA21204@ieva06.lanet.lv>
From: "Andris Pavenis" <pavenis AT lanet DOT lv>
To: djgpp AT delorie DOT com, "Alexander S. Aganichev" <asa AT lan DOT eed DOT miee DOT ru>
Date: Thu, 27 Aug 1998 21:41:57 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: uclock ()
In-reply-to: <Pine.BSF.3.96.980827201415.6189B-100000@lan.eed.miee.ru>
Precedence: bulk

Date sent:      	Thu, 27 Aug 1998 20:15:55 +0400 (MSD)
From:           	"Alexander S. Aganichev" <asa AT lan DOT eed DOT miee DOT ru>
Subject:        	uclock ()

> Greencity'ngs, dear all!
> 
> During debugging my program i found that in rare conditions return value
> of second call to uclock is lesser than first. I made patch, that works on
> all my boards, but I'm still unsure if *ALL* PC with i386 or higher
> contains RTC8254. Could anyone comment my patch, so i could rebuild all my
> applications with patched library?

At first it is NECESSARY to disable interrupts when reading PIC 
counter. Otherwise if some TSR will do the same timer will be 
messed up (I cannot say about 2 DOS sessions under Win9X
but it's possible that also there is small possibility of conflicts 
[maybe])

Perhaps I should sometimes port to DJGPP my time reading code 
I wrote some years ago for Borland C (used inline assembler).
If we want to get right result up to 99.9% of calls than there is no 
problems. If we want 99.99999% (or 100%) than things are not so 
simple. For example if PIC channel is programmed to work in mode
3 than if the counter walue is 0 then output status is undefined
(sometimes 0 , sometimes 1) and should be reread. My procedure
supported both modes 2 and 3 without reprogramming PIC.
Of course if divider is not 2^16 I have trouble. 

I didn't get failures (next reading less than previous) at all on 
computers I tested (the time of some tests were about some 
hours).

Andris