Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!dog.ee.lbl.gov!nosc!crash!pro-sol.cts.com!mdavis
From: mdavis@pro-sol.cts.com (Morgan Davis)
Newsgroups: comp.sys.apple2
Subject: Re: CPU speed detection
Message-ID: <6129@crash.cts.com>
Date: 6 Dec 90 18:16:03 GMT
Sender: root@crash.cts.com
Lines: 79

In-Reply-To: message from barcan@CPSC.UCALGARY.CA

} I'm currently working on an application that is timing dependent.
} A wrench is thrown into the mechanism when the computer happens
} to be accelerated beyond the normal 1 Mhz range of an Apple II.
} 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?

Using the VBL signal is about as accurate as you're going to get.

} 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.

Not really.  A two-byte "tick" counter will count ticks from 1/60 second
to about 18 minutes, regardless of the CPU's speed be it 1MHz or 100Mhz.
That kind of range is acceptable for various delays and pauses within a
program.  Adding another byte to your counter brings you up to 77 hours
capacity.

A tick is the amount of time, roughly 1/60 second, between the leading
edge of each VBL signal.  Counting one tick goes something like this:

        ticka   bit     $c019           ; Loop while VBL signal is low
                bpl     ticka
        tickb   bit     $c019           ; Loop while VBL signal is high
                bmi     tickb
                                        ; A full tick cycle has passed here
                <increment counter here>
                <compare counter to delay>
                <if less than, goto ticka>

} 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).

Fortunately, reading $C019 in the manner given above works correctly on
both the IIe and IIGS.  Since the IIc doesn't have a polled VBL signal,
you'd have to write a VBL interrupt handler which did your tick counter
incrementing.  On the II+, I designed a method by which a VBL-like signal
can be mapped to a different hardware location ($C060).  The article
describing this scheme was posted a few months ago.  Let me know if you
want it.

} Does anyone have a procedure for determining CPU speed?  Or better yet,
} a wait routine that isn't affected by different CPU rates?

The VBL method is about as clean as you're going to get.  The only other
method I can think of is to make use of some other hardware benchmark
that you might have access to.  For example, (and this certainly isn't
a "clean" method) if you have access to a serial port:

o       Set the port's speed to a known rate (e.g. 300bps)
o       Write a character directly to it (don't use firmware)
o       Begin incrementing a counter until the serial port tells
        you that it is ready for another character

This give yours program a value that will be different on machines with
different CPU rates.  Unfortunately, you won't end up with a perfectly
consistent constant.  You'll have to match what you get with a range of
likely values to determine the approximate CPU speed.  You also aren't
assured of having a serial device to work with (unless your program is
a communications package that requires one).

The last and most undesirable step is to allow the user of your program
to configure it for different speeds.  This is how Talk is Cheap currently
does it, because there really aren't any perfect solutions to this kind
of problem.

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

--Morgan Davis

UUCP: crash!pro-sol!mdavis           AOL, BIX: mdavis  
ARPA: crash!pro-sol!mdavis@nosc.mil  GEnie:    m.davis42
INET: mdavis@pro-sol.cts.com         ProLine:  mdavis@pro-sol