TOFF Maximum for 50g firmware 2.15

[DavidM]

I was playing around with my 50g today and decided to change my TOFF setting to avoid the customary powerdown that occurs at 5 minutes. I thought I'd just set it to the max allowed value, so I did a bit of googling and saw several references to that being (2^31)-1 (#7FFFFFFF).

I changed the value, did a warm-start, and was surprised when the 50g turned itself off after 5 minutes. At first I thought I must have forgotten to warmstart, so I did that again, but then had the same results.

After a bit of trial-and-error, I discovered that my 50g (ROM 2.15) has a maximum effective TOFF value of #6FFFFFFF instead of #7FFFFFFF. Any amount greater than #6FFFFFFF results in a default 5 minute period being used instead of the supplied value. It's really of no great consequence to me, but I was a bit surprised when I saw that the previously reported figure didn't seem to work as expected.

I did try this with Emu48 using a 50g 2.15 image and had the same results, so I'm inclined to think that it's simply a result of changes made in one of the various firmware updates.

Whether the max is 72.8 hrs (#7FFFFFFF) or 63.7 hrs (#6FFFFFFF) makes no difference to me; but I thought others may need to be aware that using the previously-reported maximum figure may not have the intended results on an updated system.

- David

[John H Meyers]

On 5/28/2012 1:01 PM, DavidM wrote:

> I discovered that my 50g (ROM 2.15) has a maximum effective TOFF value
> of #6FFFFFFF instead of #7FFFFFFF.

The following thread (Sept 2000) discusses original bugs and fixes relating to TOFF:

<https://groups.google.com/group/comp.sys.hp48/browse_thread/thread/3b3aad4a78b81280/>

At some point in that thread, Jean-Yves Avenard (principal developer) wrote:

"Unfortunately, there is a maximum for the TOFF value now: 71 hours"
<https://groups.google.com/group/comp.sys.hp48/msg/d98e1c89fdd4f40f>

And he also wrote about why an upper bound was set:

"That's what happened when you save << MEM DROP >> into TOFF, it tries to put
the next auto off like 3 billions years from now :) And as there's is a
restaurant somewhere there, the program stop for dinner and crash :)"
<https://groups.google.com/group/comp.sys.hp48/msg/728dde3645bf9fea>

"No this web site isn't broken, it's intended to look like this"
<http://avenard.com/>

The Bad Old Days:
<http://www.hpcalc.org/goodbyeaco.php>

[r->] [OFF]

[DavidM]

Hey John -

I actually saw that thread when I was googling the topic, which is why I was a little surprised at the max useable time that I ran into. #7FFFFFFF (72.8 hrs) seems like a logical max figure for a 32-bit (signed) integer, but when I tried that value my 50g defaulted to a 5min timeout instead of staying on. #6FFFFFFF appears to be the true breakpoint for a Rev. 2.15 50g, which isn't as intuitive a choice (and at 63.7 hrs. is a bit less than JYA reported in that thread). But I'm sure it was changed at least once over the course of the firmware revisions between 2000 and 2009.

No big deal either way, though. I can't imagine a situation where it would actually make a real difference. Who needs such a high number anyway? Even when running an emulator I can't see needing more than a few hours at most. Is it really that hard to press the on button? :-)

[John H Meyers]

On 5/30/2012 11:22 PM, DavidM wrote:

> I can't imagine a situation where it would actually make a real difference.
> Who needs such a high number anyway? Even when running an emulator
> I can't see needing more than a few hours at most.
> Is it really that hard to press the on button? :-)

What if we're using 2.15 for what it was updated for -- that is,
so that some sort of "data logger" could be attached,
and/or we are running on power supplied by a USB cable,
rather than batteries?

Does the HP50G still turn off on schedule?

Does the Mars mission that either NASA or some private
space launch company is controlling on the cheap,
using an HP50G instead of 30 million dollars worth
of real data logging gear, plunge into Jupiter instead?

There's a lot to ponder here, but I'm actually
typing in my sleep (having taken years to modify
my sleepwalking habit into a safer activity),
and when I wake up I will not even remember what I said
until someone else quotes it ;-)

-[ ]-

[DavidM]

> What if we're using 2.15 for what it was updated for -- that is,
> so that some sort of "data logger" could be attached,
> and/or we are running on power supplied by a USB cable,
> rather than batteries?
>
> Does the HP50G still turn off on schedule?

Uhm, not likely. Unless I'm mistaken, the timeout only kicks in when the calc is idle (probably in one of the various key-waiting loops). I assume a data-logger would require something to be executing, so the timeout wouldn't apply unless the enterprising author of the app decided to respect the TOFF value on their own.

On the other hand, perhaps you've got some really important GROB frozen on the display, or particularly special stack contents showing. Who am I to place value on what someone else wants to show indefinitely? :-)

- David

[Travis Evans]

I suppose a workaround could be storing an empty program into STARTOFF,
which would keep it on since there is no OFF command in there. Unless
that causes some sort of undesired side-effect. I haven't really
noticed any myself, compared to something like control alarms which
totally break just about anything other than the normal stack display,
even though the system makes no effort to postpone their triggering
during unsafe moments...

--
Travis