Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!ukma!rutgers!att!mtuxo!tas
From: tas@mtuxo.att.com (XMPC2-T.SKROBALA)
Newsgroups: comp.sys.amiga.tech
Subject: Re: ciatimer.c ...
Summary: the timer period may be (CIA_TIME_SLICE + 1)
Message-ID: <4040@mtuxo.att.com>
Date: 17 Jan 89 12:30:53 GMT
References: <3236@sugar.uu.net> <1366@dretor.dciem.dnd.ca>
Organization: AT&T, Middletown NJ
Lines: 35

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