50g Random Turn ON

[DavidM]

(12-08-2016 05:47 AM)Joe Horn Wrote:  ...HOWEVER, if that ever did happen, then the system real-time clock would at that moment fail to be updated. Wouldn't this cause the system clock to thereafter be off by 262144 seconds? I've seen 50g clocks drift away from the correct time, of course, but never anywhere near that much. So unless my understanding of the system real-time clock update is incorrect, then I reject the above hypothesis, and stubbornly maintain that the 50g (like the 48 & 49) NEVER misses a 262144-second auto-turn-on unless some other system interrupt occurs. Proof that I'm wrong would delight me of course, since I enjoy playing with HP calculator bugs as much as playing with HP calculator features.

I hereby reject your rejection. It appears we are both stubborn. I'd much rather delight you than frustrate you, though.

If we were talking about the pre-ARM systems, I would totally agree with you. But we're not. I will offer one possible reason that the clock wouldn't have a problem -- actually, I already have. But before I do that, consider the following:

You already know that alarms don't always trigger properly on these systems. Your observation about the clock not being updated properly should apply to that scenario, too, shouldn't it? If you are rejecting the concept of a 262144-second TIMER2 expiration problem based on the fact that the clock still runs, then it seems to me that you should also reject the concept of alarm problems on the same basis. I've had alarm issues that clearly had no impact on the system clock, and I'm guessing you have as well. I actually saw a 1+ minute delay in an alarm recently when testing my logging facility for this thread's issue -- with no corresponding lag in the system clock. So whatever is causing that problem hasn't caused the system clock to stop updating.

While I disagree that the TIMER2 interrupt not triggering would absolutely stop the clock on an ARM-based calc (see below), I also don't think that's the only possible explanation for these problems. It's perfectly reasonable to consider that the interrupt is still triggering, but something in the service routine could be failing in such a way that "things" are left in a corrupted state. Those "things" may not generate a hard crash, but clearly enough is wrong that, at a minimum, alarms don't always execute properly. I see that same concept as a possibility for anything that depends on the TIMER2 interrupt servicing. I'm also open to the possibility that I'm totally wrong in assuming a link between the TIMER2 interrupt processing and alarm issues. But I've yet to see a reason not to.

One possible reason that these issues aren't causing the system clock to skip a few beats (or have cardiac arrest) is what I mentioned in the last paragraph of my previous post. In the post-ARM world, the system time is no longer computed as TheNextEvent - TIMER2. It is simply retrieved from the Saturnator with a single opcode (GETTIME). Don't take my word for it -- you can see it yourself by looking at the code for TICKS, (SysRPL) CLKTICKS/SysTime, and (ASM) GetTime++/GetTimChk. So the ARM-based systems are now dependent on the Saturnator for getting the system time, which I suspect maintains the current time independent of anything that happens in the Saturn environment (excluding direct adjustment, of course).

I could also be totally wrong about all of this. I'm open to that possibility. But please don't dismiss the whole concept based simply on the clock still keeping time.