#RSLClock 1.3
20 messages in this thread
Hi,
I just noticed something strange when I run RSLClock 1.3. When the
program is active and I try to move the mouse smoothly, the mouse tends to jump
a bit every half a second. The same happens when I try to drag the workbench
screen down; it jumps a few times a second. This stops as soon as I kill the
program. I tried it with RSLClock 1.2, but the problem did not show with the
older version.
Do you have any idea why this might occur, and if it was solved in
version 1.31?
Khalid Aldoseri, 75166,2531.
I don't know what to tell you about that strange effect. I tried to
simulate it and with all possible features enabled I did not see an appreciable
slow down in pointer positioning. Any program that always runs, though in the
background, can slow up the pointer. Perhaps you were running other programs
too and the additional strain caused by RSLClock was just too much for the OS
to keep up with without the tell tale signs that you noticed. If this had been
noticeable I would have set it at a lower task priority than the one that I
chosed.
Try running RSLClock 1.31 alone and tell me if you find the effect disag
disagreeable!
-RSL-
I am not at my Amiga at the moment, so I will experiment with the
pointer problem later. But, when I noticed the problem, RSLClock1.3 was the
ONLY program running besides Workbench. I don't know if expansion memory has
anything to do with it, but I have a 2 meg expansion card connected. I will
try to disconnect it and see if that has any effect.
Later,
Khalid.
It may be memory expansion. I still am only using 512K, and have no way
of testing that possibility. I'm interested if this is the cause, and if the
type of expansion memory makes a different. I wonder if anyone else out here
has noticed a perceptible slow down using RSLClock 1.3?
-RSL-
Roy,
See my msg to Khalid regarding my problems with rslclock1.2 and
expansion ram (Techni-Soft 2MB).
Bill Christens-Barry
I've read ALL the messages! MEA CULPA! I have recompiled RSLClock with a task
priority of -1 (instead of the previous 20). This is a temporary "quick fix"
that will solve the problem temporarily and not make it neccessary to patch
1.31! I will try to see if the added features can be optimized, and if they
can not, I will eliminate the worst offenders! I have also included in 1.32 a
slight adjustment of tTime: placement as suggested by Richard Rae (just to give
him an excuse to re-download). I hope that everyone isn't growing tired of the
revisions, (but then again, don't you wish commercial producers cared as much)!
I HOPE this version works better!
BTW, I went back to using 7 bits/space as parity in my previous messages
earlier this night just to see if it was the line noise or my parity setting.
Happy Hacking (but please not with MY program)!
-RSL-
Roy:
I can't speak for everyone else (but probably most of them). Yes, I do
wish commercial developers could hammer out corrections/changes as efficiently
as you do (and in fairness to commercial people, it might still be a labor of
love but it has to have a reasonable unit cost). I would hate to even consider
how much RSLCLOCK would have to sell for to make a profit. I can only thank
God that there are still people who wish to produce something of quality for
its own sake and the sake of others!
Thank You Roy and I look forward to your next project,
whenever and whatever it wil be.
73s,
bill
Your welcome! I originally wanted my next project to be a low cost system
clock using the BSR X-10 controller heavily discounted by DAK, but
unfortunately I believe that my controller is partially inoperative, so it has
been put on semi-permanent hold. I have received numerous suggestions and
wouldn't mind hearing of any short utility type projects that people have not
yet seen, but would like (no promises of course) Please, no one suggest a
terminal program ;->
-RSL-
Roy:
Roger on the terminal program. I'll try and think of something. Hate
to see you idle <he he>. 73s,
bill
Khalid, I didn't see your earlier msgs, but I've found I have some boot
problems
with rslclock1.2 when my 2MB expansion ram is powered on. Seems to give
"software failure" error msg and go guru on me when the startup-sequence hits
the run rslclock1.2 command. This doesn't always happen, 'tho. A long warmup
of the expansion ram (Techni-Soft) seems to help. Hope this is relevant. I'm
going to get rslclock1.31 and see how that does.
Bill Christens-Barry
Thanks Bill, but I have the Comspec RAM and never had a problem with it. I was
using RSLClock1.2 without any problem, and now I've changed to 1.3 and having
the problem with its taking too much priority.
Khalid.
Hello again, I just tried everything I could think of, to the point of
removing every expansion on the Amiga and running it with the original 1.2
kickstart and workbench disks. Same problem: the pointer still jumps and the
screen does not drag smoothly. This does NOT happen with RSLClock1.2, only
with 1.3.
Khalid.
Khalid, the problem with RSLClock 1.3 has been noted on another network.
Someone there was having problems with it causing 'hiccups' in Deluxe Music
Construction Set. Myself, I found that it was causing interruptions to the
stepping of my disk drives, noticable when they were doing a long seek.
The answer is that apparently the priority is set too high (at 20), and it
was suggested that 04 would be adequate and preferable. Using FileZap, find
record 16, and at C0 you will see 48780014. Change the 14 to 04. This might
do the trick for you, it did for me.
It's a great utility, wouldn't be without it.
-=[ Lon ]=-
Thanks very much, Lon.
Khalid.
Khalid,
The numbers Lon gave you are for 1.3. For 1.31, everything has moved. The
patch now appears to be in record 17 at 70. As before, the string is 48780014.
FYI, changing the priority to 0 did not cure the problem for me, although it
did help a little bit. I ran PROCS and it shows everything in my system
running at 0 (with the exception of POPCLI at 20), so there was still
contention. I cured the problem in my system by setting the priority to -1
(487800FF). The only negative effect I've seen from this is a pregnant pause
in the seconds at times when heavy activity is going on elsewhere.
Please note there are NO GUARANTEES as to this being the correct patch, but
PROCS did reflect the expected clock priority, so it seems to be alright.
Thanks again for the pointer to Lon's message!
Nybbles!
Rick, I think 0 worked for me because RSLClock is the only program I keep
resident, and rarely run another program unless I really need it. I know I've
got a lot of memory (2.5 megs) but I still can't get over the old fear of
running out of it. (I rarely have less than 1 meg free these days.)
Thanks for the info about 1.31. I just downloaded it and will set its priority
to -1. I will also test lower priorities and see if that doesn't affect its
operation too much. I don't really mind if it skips a second now and then.
Will keep in touch.
Khalid.
Hi Lon,
I have just uploaded a revised version of RSLClock (Ver 1.32) that has its
task priority reset to -1. This is intended as a "quick fix" pending further
re-writes to cure the problem, and also making it unnecessary to patch my
program. Out of curiousity, what other Service has there been talk about
RSLClock? (I'm sure other services can be mentioned on CES without lightning
bolts falling from t the sky ;->
-RSL-
Interesting!?!?!? What have you enabled on 1.3? Have you tried 1.31? I really
don't know what may be causing it. I will try running 1.31 under al possible
conditions and see what happens. Is the slow down significant in your opinion,
or just annoying?
-RSL-
Roy, I've just changed RSLClock1.3's priority to 0 by FileZapping it. No more
jumpy pointers or screens. Only when I runs several heavy-duty programs that
the effect starts again. But, by then, if the system runs, who cares.
Khalid.
Sorry for any inconvenience, 1.32 has its priority set to -1!
-RSL-