#RSLClock1.31
11 messages in this thread
Roy,
There appears to be a flaky with RSLClock 1.3x. The symptom is very "jerky"
output to the screen; when using a terminal package the characters come in
"packets" of several characters. I shoved the priority of my terminal way up
with no significant change. I later talked to Bri in CO and he's seen the same
problem. He said he tried running the clock at priority 0, same problem. He
also said it occurred in 1.3. I have not seen it in 1.2, so something you
changed between 1.2 and 1.3 is apparently the culprit.
Running PM with and without the clock shows a significant difference… a
straight line without, and consistent deep dips with. These dips seem to come
three or four per second, about the rate of the data "packets" to the screen.
If I recall correctly, 1.2 only dipped once per second, and wasn't as obvious
about it.
I'd appreciate it if you could take a look at this and see if you can track
down the problem. I love the full width screen, but this problem is roughly as
irritating as the split screen effect.
Thanks for putting up with the hassles!
Rick
Rick, Look at message 50834. It is a response to me from Lon Leader after I
had complained of the same problem. He says that by changing the priority of
RSLClock1.3 from 20 to 4 the problem is solved. I did that but still had some
jerkiness so I changed the priority to 0 and voila! No more problems. (The
mentioned message describes how to change the programs priority with FileZap.)
Khalid.
Khalid,
Brian told me in CO last night that he had run the clock's priority all the way
down to zero, with still no change. Ah well, I will take a look at the message
you indicated and try it at any rate. Thanks for the pointer!
(RSLClock is just another example of what this forum is all about: the members
pulling _together_ for a common goal: the best d*mn computing environment
available for the price. We're getting there. Slowly, but we're getting
there.)
Oh well, back to the drawing board! I'll have to take a good and long look at
the source and see what I'm doing differently|~?~?~?~? every second that I did
not do in 1.2. I really didn't notice the deterioration in system performance!
-RSL-
Roy,
Were you running 1.2 at a priority of 20 also? I've bypassed the problem for
now by patching the program for a priority of -1; even a priority of 0 caused
contention.
It's working smoothly enough now that I'm thrilled with it. I wouldn't sweat
the time thing; it's just that it looks crowded: the time now, for example, is
Time:11:28:52, which is hard to read at a glance. Just ignore me… I'm into
aesthetics… comes from too much graphic arts training. 8)
Fullwidth works fine, it just isn't in the doc file, which you already know.
Thanks again for a super program!
Nybbles
Your welcome. My best guess is that in breaking up the window's character
string so that alternate parts could be highlighted I simply am using too many
CPU cycles. All the other versions also ran with a task priority of 20 without
problems. I have uploaded yet another version 1.32 so that patching is
unnecessary. I also added your aesthetic suggestion and fixed the d docs to
include FULLWIDTH arguments. Any more good ideas for 1.33?????
-RSL-
Hehe… 1.33… let me think about it. 8)
What did you do to 1.32 to avoid patching… did you just run the priority
down? (And if so, how far?) If so, I think I'll wait for all the great
enhancements coming in 1.33… my file is already patched, and I can live
without the left shifted "Time:" label.
Out of curiosity, did you notice the problem at all on your system? About half
the people I've talked to have, the others don't know what I'm talking about.
Was the high priority (20) to insure you could get another CLI when you wanted
it? Doesn't seem to be a need for such a high setting otherwise.
OH… you want a suggestions for 1.33? How about an alarm function? (Well, you
asked! 8) Then, of course, when you get everything just the way you want it,
you can rewrite it in assembly language so it will only take 42 bytes. 😉
Nybbles!
I reset the priority down to -1. It was original set to 20 to insure the
seconds counter not becoming "sluggish", besides it seemed to run well, except
by 1.3! As far as noticing the slowdown, it wasn't that obvious to me. It
seems to be a matter of how much updating of the screen can be downgraded
before you say "What the…" My threshold seemed to be less sensitive than
others!
-RSLP.S. I'm waiting for a REAL
masochistic mood (not to mention Aztec 3.4) before attempting to translate it
into assembly!
Roy is your modem comming 'unglued?' 73s, bill
No, I just wanted to try an experiment and see if I would generate the same
noise if I reset my terminal program back to 7 bit – space. I did, and now
STRONGLY believe that that was the problem!
-RSL-
Roy:
I just thought of two utilities that would be very handy. The first
would be a utility that would dismount DF2: (the 5.25 drive). That one should
not be too bad to create. The other would be to create a memory squeeze
program. I suspect that it could be a real bear! Let me know what you think.
73s,
bill