50g Random Turn ON

[DavidM]

I decided that it was a reasonable time to check the 49g+ and 50g I had set aside and left alone for the last 5-6 days to see what their status was. Both calculators had logged a single power-up event occurring, and both events were at times which seemed to coincide with what would be expected for TIMER2 expiring (262144 seconds). I can't be 100% sure, as I didn't note the exact time I turned them off when I started this test. I'll make sure to do that for future ones, or more likely, I'll have the calculators log it appropriately on their own.

(12-07-2016 06:42 AM)Joe Horn Wrote:  But STARTOFF *is* executed every 262144 seconds (if no other interrupts occur in the meantime). The power-up that Wickes is talking about DOES engage the System Outer Loop, and it does turn on the display.

As is usually the case with you, Joe, I'll take you at your word on this one. My own limited testing certainly agrees with what you're saying. This does imply several possibilities, though, given that others are experiencing less-than-predictable results. Some that come to mind:
- Some other interrupt/alarm is occurring on their systems that preempts (and resets) the 262144 second timer reset, and if so, is also not activating or bypassing STARTOFF when it occurs.
- People are using the calculator more often than they think, thereby circumventing the 3 day event.
- Some other software-related issue is occurring in their STARTOFF programs (or elsewhere) that makes it seem like the programs aren't running consistently (ie. beep not activated, etc.).
- An inherent issue in the platform is making the TIMER2 interrupt processing inconsistent.

My own personal experience makes me lean more toward the last item, in that I've already had verified issues with alarms not running consistently. Since the triggering of alarms is very similar to the "timer reset", it makes sense to me that it is a good possibility.

(12-07-2016 06:42 AM)Joe Horn Wrote:  

(12-06-2016 09:23 PM)DavidM Wrote:  - One hour after the last keypress was popped from the key buffer

Never heard of that last one.

That one came from multiple posts on comp.sys.hp48 that I believe were all initially sourced from comments by Dan Kirkland. This one is fairly specific on the topic, but there are other references as well.

(12-07-2016 06:42 AM)Joe Horn Wrote:  It's not a problem. It's a feature. And it's totally predictable: exactly every 262144 seconds, if no other interrupts have occurred.

I feel there's enough anecdotal evidence to question if it is as predictable as it should be, so we will have to agree to disagree on this one.

(12-07-2016 06:42 AM)Joe Horn Wrote:  If your STARTOFF is executed "much more irregular" than every 262144 seconds, then (a) something else is causing interrupts to occur, or (b) there is something in your STARTOFF program that is causing it to exit before the backup is performed, or (c) you have discovered an interesting new bug that involves executing a backup during the execution of STARTOFF.

Or perhaps it's (d): the TIMER2 interrupt doesn't always happen when it should. Sometimes perfect, sometimes late, sometimes not at all, or at least not until some user activity occurs.

In the pre-ARM RPL systems, the system clock was defined as "SysTime = Next_Event - TIMER2", which is why that 3-day NextEvent/TIMER2 reset was needed in the first place. Post-ARM, though, an ARM-specific op-code is used instead: GETTIME (80B11). While I haven't traced through the TIMER2 service routine (and doubt I'd understand it even if I did), I am assuming that it is also different on the ARM systems as a result. Clearly there is still a 2^31 tick timer event, but how those events actually trigger in the ARM environment has to be different -- there's no longer a hardware-driven way to get exactly 8192 decrements to TIMER2 per second. I've never seen any detailed information about the inner workings of timekeeping on the ARM systems, but I know that there are a number of quirks (sub-second adjustments, jittery system time, and alarm problems all come to mind here). It just doesn't seem that far-fetched to think that those differences could result in some of the problems people are experiencing with TIMER2 and STARTOFF consistency.