#RSLclock 1.32
7 messages in this thread
Roy,
I'm another one who seems to be having "lock-up" problems that are very
similar to Jim's. They started a little after installing RSLClock into my
system. I thought I could give you a little more information to work with as a
lock-up occurred only today and the circumstances are still pretty fresh in my
mind.
My system contains; 512K A1000, 3.5" DF0:, 5.25" DF1: which is the SYS: device
and contains C:,LIBS:, and a SYSTEM directory (Path added). That's about it.
My lockups have only occurred from the CLI (rarely use Workbench) and
occur upon disk removal/insertion, have no idea which. After inserting the disk
the red light on/offed as usual but the console was dead, this includes the
mouse pointer. A three-fingered salute DOES result in the normal warm-boot, at
least it did today. The only programs run since cold-boot were Temacs (viewed
text files only, no writes or popclis) and the system commands, Dir, List,
Copy, and Rename, etc.
I no longer keep the free disk space report enabled after I found out
it was causing the requestors although I occasionally bring it down. It was NOT
enabled at the time of the freeze.
My command file for the clock is;
Run RSLClock132 LONG HIGHLIGHT 0 COLORS 2,1
I hope some of this can be of help to you. If you need to know anything
else, just yell. Take it as a compliment that people bother to "complain". Most
PD stuff I just yank at the first sign of problems, not this one! BTW, is the
clock freeware or do I owe you?
-Jeff
P.S. I also have had times where the disk light stayed on, but not recently so
I can't remember the exact circumstances.
Hi Jeff, Thanks for the information. There exists a split second at the
59th second when the device is checked to be occupied with a disk and then
polled. If the disk is yanked during that short interval when RSLCLock
thinks there's a disk and there isn't all hell can break loose! This would
require that the disk polling be enabled though and I really can't
think{why it would happen otherwise! Highlight has been taken out the the
latest version. I just recieved my copy of Aztec 3.40a, and was going to
see what "magic" could be done, but Murphy has struck and of all the
programs to be corrupted by a hrdware malfunction on my Compiler disk????
You guessed it the Compiler itself! Oh well, I'll have to call Manx
tomorrow morning. I will try to simulate this problem and see if I can
lock up my machine. I have yet to do this though. I am hoping that 1.34+
simply doesn't have this problem, and that is why I can't reproduce it!
BTW RSLClock is FreeWare, although the author will except any complements
offered graciously! -RSL-
Roy,
Consider yourself complimented! I'm sorry I can't be of much more help, but
I'm pretty ignorant where the Ami OS is concerned. I can only emphasize the
random nature of the thing. I've gone days without any problems then wham!
Freeze city without doing anything extraordinary.
Is it possible for the system to continue polling after the disk
free space option being de-selected? While I didn't have the option
displayed at the time of the freeze I did have it up a few (unknown amount)
minutes previous to the last occurence. Up until a few days prior to that I
had the clock boot-up with the option selected, this was the only occurence
after I changed that. The only other thing that I did than run standard
Enhancer 1.2 C: commands was use Temacs to view a file. Maybe they (Temacs
and RSLClock) don't like each other? I hope some of this is helpful rather
than red herrings.
Good luck on your quest. Random problems are notorious for being far
harder to find than the eventual cause would suggest (Is THAT all it was?). I
also hope your hardware problem wasn't too serious, AND that Manx is responsive
to your problem. (Of course! What did you expect to get munged? A README file?
Never! Not in this universe.) Let me know what turns up.
-Jeff
P.S. How come no highlight option? Looks good to me.
Theoretically, once de-selected, the disk device should not be polled under
any circumstance, but I will check through the source! The "hardware"
problem was purely with Manx' disk, and they report that they will be
shipping me another copy today! As far as the highlight feature, I thought
it was nice too, but unfortunately it used a series of nine linked
IntuiTexts that visibly slowed down the program to a crawl and maq {de it
necessary to lower it's priority 0 or -1. With the highlight feature
removed, RSLClock hums at as fast a speed as it ever had, and I have
included a feature to rev up its priority back up to 20 so that the clock
never stops ticking! -RSL-
Hehe…
The version running at -1 is really kind of neat… rather than showing "real
time", it actually shows "time at which CPU was last available". I've run very
CPU intensive programs like huge sorts and the clock freezes entirely for
minutes at a time, updating only during disk writes, when the CPU has some
breathing space.
I'm glad that you're enjoying it! In Ver. 1.34+ RSLClock runs faster and a
toggle exists to "rev" up the priority back to 20 for those who don't like to
see "time stop". I've modified Ver 1.35 to use the trackdisk.device instead of
making higher level AmigaDOS calls. This will allow for more disk updates,
**No Info** only coming up when the disk in question is out, not to mention
(hopefully) no more disk lock ups during the 59th second!
When I get my "fixed" version 0f Aztec 3.40 I will try for a keyboard handler
intercepter. Any suggestions of coded functions for about 10 keys (i.e.
blackout, shuffling screesn etc). Please don't get too exotic, I don't want
the source to double!
-RSL-
Roy,
Hmm, well, I can't think of anything I'd like to have added, but one change
would be nice (and Cheath has already done this): it would be nice to have the
screen just dim rather than go black completely. This would allow you to still
watch the progress of a program from across the room, for example.
Other than that, hmm… let you know if I think of anything. OH, say, I
know… this is a wierd one! With the full width switch set, it'd be nice if
the gadgets on RSLClock were transparent; in other words, it would be nice if
you could _not_ click the clock off, or to front or back. Reason: this would
allow you to click _through_ the clock bar to flip screens and whatnot without
first moving the clock out of the way.
Hehe… you asked!
Rick