Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!ut-sally!utastro!nather
From: nather@utastro.UUCP (Ed Nather)
Newsgroups: net.arch,net.micro.mac,net.micro.68k
Subject: Re: timing loops
Message-ID: <378@utastro.UUCP>
Date: Mon, 17-Feb-86 11:35:27 EST
Article-I.D.: utastro.378
Posted: Mon Feb 17 11:35:27 1986
Date-Received: Tue, 18-Feb-86 04:18:52 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <647@oakhill.UUCP>
Organization: U. Texas, Astronomy, Austin, TX
Lines: 41
Xref: watmath net.arch:2542 net.micro.mac:4708 net.micro.68k:1489

In article <647@oakhill.UUCP>, davet@oakhill.UUCP (Dave Trissel) writes:
> Of course, the problem is that the basic clock frequency driving the chip
> is variable depending on the system.  If we implemented on-chip a clock
> or timer register from where would it derive its frequency?  Having an
> "adjust divisor" register setup by the system to factor the system clock
> would just push the problem right back into the hands of the O.S. coders
> where it is now since code somewhere would have to then setup the proper
> divisor.
> 
> We currently have one customer running the MC68020 at 15 Meghertz, so we can't
> assume that the "standard" test frequencies of 12.5 and 16.6666 will be used.
> Customers are already preparing for the 20 and 25 Megahertz versions but
> there is no way to know now what their exact frequencies will end up.
> 
> If you or anyone else has any suggestions on how to do this give a yell.

Some years ago I was faced with the problem of "upgrading" to a faster mini
and wanted to use the same program for the "old" and "new" ones.  They were
enough different internally to require code to identify which was which, and
adapt accordingly.

I used a counting loop (once, on program start-up) to see whether the program
was running in the fast or slow machine, by checking to see how far it got in
a known amount of time.  In that case, I used an attached teletype machine
as a timer, since it took about 0.1 sec to print a character, and I watched
its "busy" flag in the counting loop.

I'm not proposing to put a TTY on a chip alongside the CPU (I doubt you can
do that ...) but rather a simple, independent (and not very accurate) timer
whose sole job would be to find out how fast the CPU clock is running.
Simple software could then set the proper value into an adjustable count-
down divider so a built-in timer, running off the divided CPU frequency,
would be practical.  The built-in timer need only be accurate enough to
choose among a set of (quantized) clock frequencies.


-- 
Ed Nather
Astronomy Dept, U of Texas @ Austin
{allegra,ihnp4}!{noao,ut-sally}!utastro!nather
nather@astro.UTEXAS.EDU