Re: Applesoft limitation

["Michael J. Mahon" <mjmahon@aol.com>]

mojoehand wrote:
> Speaking of how fast or slow any of these methods would be, there
> doesn't seem to be any easy way to time such differences in Applesoft.
> I saw an old discussion about this on CSA2 when I was reading the
> archives, but didn't see any easy solution. I'm not too fond of the
> stopwatch method of timing software.

Since there is no real-time timing capability in a stock Apple II,
the "stopwatch method" is the most common.  (Yes, there are some
esoteric methods for the //e for times under 16ms., but that probably
doesn't apply to your problem.)

And a watch works amazingly well.  You just set up a loop or workload
that you are willing to consider "typical" that takes between 10
and 100 seconds to execute, then time it with a watch (stopwatch
not needed ;-).  Sometimes it's handy to start with a keypress and
stop with a "beep".

If your timing uncertainty is within 0.5 seconds, and the loop takes
about 30 seconds, then you've just measured the time to better than
2% accuracy--and, believe me, if you aren't talking differences of
more than 2%, there's no point in timing!  ;-)

If you have dozens of loops to time, it can get a little old, but
that's what programmers do.  ;-)  Seriously, for a few timings, it's
quite sufficient.

-michael

******** Note new website URL ********

NadaNet and AppleCrate II for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."