Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!amiga!cbmvax!jesup From: jesup@cbmvax.UUCP (Randell Jesup) Newsgroups: comp.sys.amiga.tech Subject: Re: Floppy I/O causes delays getting timer.device messages Message-ID: <7305@cbmvax.UUCP> Date: 13 Jul 89 20:49:57 GMT References: <4014@sugar.hackercorp.com> Reply-To: jesup@cbmvax.UUCP (Randell Jesup) Organization: Commodore Technology, West Chester, PA Lines: 33 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!"