bpd@dretor.dciem.dnd.ca (Brian P. Dickson) (01/13/89)
In article <3236@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: [most of souce code to very handy routines deleted] >/* TIMER - Amiga CIA Timer Control Software > > The routine ElapsedTime gets the time by getting the number of > 65536 microsecond ticks that the handler has seen and retrieving > the 0-46911 number of 1.397 microsecond ticks from the CIA timer > registers, scaling them to 1.000 microsecond ticks and returning > the shifted-and-ored result. >*/ After checking the hardware manual, I calculate the actual ticks to be 1.396825 microseconds (clock interval is 279.365 nanoseconds). While the difference is small, it WILL cause clock drift, if you use these routines as a realtime clock as opposed to just a timer. To get a much more accurate clock, the following changes to the code should be made: > >/* timeslice is 46911 intervals. Each interval is 1.397 microseconds, > * this should correspond to a timing interval of 65536 microseconds */ >#define CIA_TIME_SLICE ((unsigned short) 46911) /* timeslice is 40000 intervals. Each interval is 1.396825 microseconds, * this should correspond to a timing interval of 55833 microseconds, * almost exactly */ #define CIA_TIME_SLICE ((unsigned short) 40000) #define CIA_TIME_QUANTITY ((unsigned short) 55833) /* and now replace all occurrences of 65536 with CIA_TIME_QUANTITY */ > >VOID CIAInterrupt() > CIA_Microseconds += 65536; CIA_Microseconds += CIA_TIME_QUANTITY; /* the approximation for the scaling in ElapsedTime is acceptable, since * it will not affect the clock itself */ >-- >-- uunet!sugar!karl | "We've been following your progress with considerable >-- karl@sugar.uu.net | interest, not to say contempt." -- Zaphod Beeblebrox >-- Usenet BBS (713) 438-5018 -- Brian Dickson bpd@dretor.dciem.dnd.ca
bpd@dretor.dciem.dnd.ca (Brian P. Dickson) (01/14/89)
In article <1366@dretor.dciem.dnd.ca> I mistakenly wrote: > * this should correspond to a timing interval of 55833 microseconds, This should read "55873 microseconds". >#define CIA_TIME_QUANTITY ((unsigned short) 55833) #define CIA_TIME_QUANTITY ((unsigned short) 55873) Sorry if this caused anyone problems. -- Brian Dickson
tas@mtuxo.att.com (XMPC2-T.SKROBALA) (01/17/89)
In article <1366@dretor.dciem.dnd.ca>, bpd@dretor.dciem.dnd.ca (Brian P. Dickson) writes: > /* timeslice is 40000 intervals. Each interval is 1.396825 microseconds, > * this should correspond to a timing interval of 55833 microseconds, > * almost exactly */ > #define CIA_TIME_SLICE ((unsigned short) 40000) > #define CIA_TIME_QUANTITY ((unsigned short) 55833) > > /* and now replace all occurrences of 65536 with CIA_TIME_QUANTITY */ One thing I was wondering was whether setting the timer to 40000 would cause the timer period to be 40000 ticks or 40001, i.e. whether it spent any time at 0. The hardware manual was vague, saying only that in continuous mode the latch value was reinstated when 0 was reached, but not saying how long the timer stayed at 0 first. So I wrote a little test program that set the timer to value 100 in continuous mode, and I sat in a tight loop reading the timer 1 million times to see whether it spent any time at 0. And this is what I found: 0 0 1 9901 (or thereabouts) 2 9901 . . 98 9901 99 9901 100 19802 That is, the timer doesn't spend any time at 0, but it *does* seem to spend 1/101 of the time at each of 1 through 99, and 2/101 at 100, which implies that the timer period is in fact 101 ticks, not 100. Which implies that, for Brian to get a timer period of 40000 ticks, he must set CIA_TIME_SLICE to be 39999. Can someone who knows something about the timer's inner workings confirm or deny this? Tom Skrobala AT&T Bell Laboratories mtuxo!tas 201-957-5446