rmariani@watmum.waterloo.edu (Rico Mariani) (05/08/88)
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
neil@amiga.UUCP (Neil Katin) (05/11/88)
In article <4319@watcgl.waterloo.edu> rmariani@watmum.waterloo.edu (Rico Mariani) writes: >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 The bug is definitely in the timer device, and it has been fixed. It will make it to the outside world in the next release (1.4). In a way, I'm kind of embarassed about it: its my bug from way back. In brief, the timer goes out of its way to be race free, but I missed the case of the timer going off before I stopped it but after I had turned off interrupts. This meant the interrupt was held for the next request (which turns out to sometimes be a trackdisk 3 ms STEP request). Apologies to all of you with trashed disks. Neil Katin "You can't idiot proof anything; some idiots are just too clever"