🚀 go-pugleaf

In article <4014@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes:
>[Whew.  This was one mean mother.  I had about given up.]
>
>I assert that floppy I/O causes noticeable delays in getting messages back 
>from the timer device.

	Could be.  Nothing says this can't happen.  The timer is speced as 
sending the message back when you ask _or later_.  System load (especially on
the timer) can affect how much later it gets back.

	When the floppy is seeking, it is doing lots of 3ms (3000us) waits.
When reading and writing, it does some 1 and 2ms waits, but not very often.
When you consider the overhead of a time request is on the order of 800us,
this is signifigant.  Also, the current timer's Microhertz unit can become
less accurate when being heavily accessed, from lots of stopping and
restarting of the hardware timer.  This should be improved in 1.4.

>When doing floppy I/O, indeed even when any of the floppy drives don't have
>a disk inserted, the SMUS player will encounter noticeable delays in playing 
>voices.  (When a disk is not inserted, the delays correspond to the clicks
>the drives make.)

	This is the proof.  The clicks are combined with the 3ms stepping
(and 15ms settle) timer waits.

	You came up with the right solution: don't use the timer device for
short, high-accuracy waits: use a free hardware timer (see posted message
or CATS about which one to use and how to allocate it.)

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Common phrase heard at Amiga Devcon '89: "It's in there!"