Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!agate!ucbvax!CPSC.UCALGARY.CA!barcan
From: barcan@CPSC.UCALGARY.CA (Davor Barcan)
Newsgroups: comp.sys.apple2
Subject: CPU speed detection
Message-ID: <9012052301.AA15585@cs-sun-fsa.cpsc.ucalgary.ca>
Date: 5 Dec 90 23:01:42 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 33

I'm currently working on an application that is timing dependent.
For example, I'd need to be able to closely estimate a wait for
approximately thirty seconds (this is all hypothetical).  This
isn't necessarily a problem and is easily accomplished with the
Apple II ROM Wait routine; just pop a value into the accumulator
and do a JSR to the routine.

A wrench is thrown into the mechanism when the computer happens
to be accelerated beyond the normal 1 Mhz range of an Apple II.
This is the case when I execute the code on my //e with a 10 Mhz
RocketChip.  I need to know a way to estimate the speed that the
CPU is operating at without being dependent on a certain type of
accelerator.

I know that this is possible because ProTerm doesn't seem to be
bothered by the fact that my CPU is cruising at 10 Mhz.  In fact,
its timing is just like it is when I'm running it at 1 Mhz.  I'm
assuming that ProTerm uses a routine to determine the speed of
the CPU.  One method that I can think of is by using the VBL and
keeping a counter until the VBL changes again.  Would this be an
accurate method?  I'd probably have to keep a very big counter
a very big counter if one happens to be running at 10 Mhz,
assuming that this is an effective method.

There's a further complication in that the VBL is handled
differently on a //e and a GS, and as far as I know the //c
doesn't have a VBL (or at least one that works).  Does anyone
have a procedure for determining CPU speed?  Or better yet,
a wait routine that isn't affected by different CPU rates?

Davor Barcan
barcan@cpsc.UCalgary.CA
University of Calgary