Path: utzoo!utgpu!water!watmath!watcgl!watmum!rmariani
From: rmariani@watmum.waterloo.edu (Rico Mariani)
Newsgroups: comp.sys.amiga
Subject: The Delay(0) problem is really in the timer.device
Message-ID: <4319@watcgl.waterloo.edu>
Date: 8 May 88 07:58:44 GMT
References: <409@ritcv.UUCP> <2193@antique.UUCP> <2093@munnari.oz> <2347@louie.udel.EDU> <5877@well.UUCP> <3741@cbmvax.UUCP>
Sender: daemon@watcgl.waterloo.edu
Reply-To: rmariani@watmum.waterloo.edu (Rico Mariani)
Organization: U. of Waterloo, Ontario
Lines: 21

In article <3741@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes:
>In article <5877@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>>	Unfortunately, Delay() is part of the DOS domain, and DOS is immune
>>to the SetFunction() call, since DOS breaks the rules for library vectors.
>
>Two things:
>
>1) as I've mentioned before, the bug is probably in the timer.device...
>   Delay just makes a timer request and waits on it...nothing fancy at all.

The problem is definately in the timer.device.  Warrior Cycles doesn't
use Delay() for its timing at all and was bitten by a Delay(0) type bug
when zero delays were requested from the timer.device directly.  There
is definately something rotten in timer.device but it is very subtle. 
It didn't manifest itself at all on my system with a hard drive
installed, I had to run from floppies *only* to get timer.device to crap
out (which I never did before releasing the code, much to my displeasure). 

I don't envy the person who has to find this bug...

	-Rico