Path: utzoo!attcan!uunet!husc6!purdue!gatech!udel!mmdf
From: CRONEJP%UREGINA1.BITNET@cornellc.ccs.cornell.edu (Jonathan Crone)
Newsgroups: comp.sys.amiga
Subject: (none)
Message-ID: <3043@louie.udel.EDU>
Date: 17 Jun 88 18:55:40 GMT
Sender: mmdf@udel.EDU
Lines: 30



>CRONEJP@UREGINA1.BITNET writes:
>>I'm posting this because many people may find this of use in
>>their hunt for that silly bugger in a turban who keeps throwing
>>wierd numbers out at us.
>>
>>I normally run as a system configuration, the following..
>>a 650k VD0:, Handshake V1.60b, Taskx , RSLClock1.3, Dmouse 1.06, and
>                                        ^^^^^^^^^^^
>>Gomf 2.2.   (on an A1000, 2 drive, 2 meg Micron power supplied memory)
>>
>Quite a while back (shortly after RSLClock1.3 came out), there was a rash
>of people complaining about random guru's, corrupted disks, etc...
>after much testing, several people reported that the random guru's and/or
>corrupted disks stopped happening after removing RSLClock1.3 from their
>startup-sequence. Since I was also having similar problems, I removed
>RSLClock1.3, and my ami got cured of its sickness, too. The problem
>apparently arose only if you had other programs that used timer.device,
>such as PopCLI (now mostly replaced by dmouse) or almost ANY terminal
>program: the timer.device (aka Delay(0)) bug got triggered frequently.
>
>You may have also noticed that RSLClock1.3 is something of a CPU cycle
>hog -- (it's been a while, but...) about 15-20% of the cpu cycles were
>going to support that "little" clock (according to "pm" anyway).

ACtually the problem with RSL Clock was that the twit who wrote it
had the program set itself up with a prioiryt of 20.
as soon as i set it to run at priority -1 it ran  perfectly...
its a nice clock .