Making the faulty HP-50g alarm function predictable and useful

[Johnny Shek]

Long story short. Create the STARTOFF variable with a simple program « OFF » in the HOME directory. Create appointment or control alarms as usual and confine their number to 2. The calculator will wake up with a delay of 1 minute at most for each alarm. In nearly all cases, the delay is exactly 1 minute.

ROM version: 2.15
Number of test cases: 24

[Johnny Shek]

UPDATE:

In previous tests, I created more than 20 entries in the system alarm list. Only the top 2 to 3 alarms could wake up the calculator with 1 minute delay. Other alarms had unknown amounts of delay as they woke up only after I turned it on. Apparently, too many entries caused it to behave erratically.

I am working on tests with incremental number of entries starting from 3 to try to touch the limit of the calculator. An initial test showed that 3 entries made by any permutation of appointment and control alarms worked perfectly.

Stay tuned!

[Johnny Shek]

UPDATE:

Having finished a test of 19 entries with half of them being appointment alarms and another half being control alarms, the calculator did not show any erroneous behaviour. Increasing from 3 to 19 entries for the tests, those 187 alarms had a delay of 1 minute. Some users reported that an alarm came due without any delay when the calculator was still on. It was also found that an alarm came due exactly at the instant when I turned it on within the 1 minute delay.

I am in search of the maximum number of entries that the calculator can hold. For the moment, 19 entries should suffice for any purpose.

Stay tuned!

[Johnny Shek]

UPDATE:

In a test of 25 entries, the 15th and 16th ones failed to execute properly. They executed when I turned on the calculator. I stopped the test and deleted all entries. Normally, I created entries with 1 hour alarm time apart. In this test, I mistakenly entered an alarm with time 10:20 instead of 10:00. The alarm time just above it was 09:00 and the alarm time just below it was 11:00.

Unfortunately, I could not replicate the same problem after conducting another test with correct entries. Later, I conducted a test with 12 entries with 2 hours apart and no problem was found. Besides, another similar test with 24 entries was passed. I will stop here. It appears that the maximum number of entries the calculator can hold is 24. I will begin to examine the behaviour of alarms with a repeat interval. All previous tests ignored the repeat interval.

Stay tuned!

[Johnny Shek]

UPDATE:

After conducting a test of 6 entries each having a repeat interval of 1 day, it was found that the 6th entry with an alarm time of 10:59 failed to execute properly. In the light of this irregularity and the irregularity found earlier in the test of 25 entries, it appears that an alarm with non-integer time will not wake up the calculator properly. Early tests only took integer alarm times, e.g. 1:00:00, 2:00:00, 3:00:00...... Over 360 entries have executed with a delay of 1 minute without any exception. Although my tests had flaws and failed to discover the irregularity, their results might provide a clue to arrive at the ultimate solution.

Before finding the STARTOFF variable as a starting point, many tests were conducted. It was found that an alarm that would come due within 59 minutes from its creation time always had a delay of 1 minute. If an alarm took more than 59 minutes to come due, only 2 durations of delay, 1 minute and 1 hour and 1 minute, were observed. Based on the tests and findings above, a control alarm can be set using just the hour part of the desired alarm that has a non-integer time. The control alarm also has an action to ‘carry’ the desired alarm for its subsequent execution. Here are some examples:

Control alarm set for 10:00:00 with the following action to carry an appointment alarm set for 10:59:

« DATE { 10.59 « DELALARM ACK OFF » } + STOALARM DATE { 10.59 “GOOD MORNING!” } + STOALARM 3. DROPN OFF »

Control alarm set for 5:00:00 with the following action to carry another control alarm set for 5:30:

« DATE { 5.3 « DELALARM DATE TIME 2. →LIST OFF » } + STOALARM DROP2 OFF »

The 6th entry in the above-mentioned test was replaced by a control alarm that carried the desired alarm and then the test was repeated. It did execute properly! 2 full cycles of another similar test with 6 desired alarms each having a non-integer alarm time were completed successfully. I have no idea how scalable this method is but further tests will be conducted. The above-mentioned test with 25 entries containing a desired alarm set for 10:20 will be repeated using this method. This test will also be modified with 25 desired alarms each having a non-integer alarm time and a repeat interval of 1 day.

Stay tuned!

[Johnny Shek]

UPDATE:

24 entries were my estimated maximum number of entries allowed by the calculator. However, this ‘limit’ was surpassed by 25 entries for an old test using the new method and a new 2-cycle test of all 25 entries each having a non-integer alarm time and a repeat interval of 1 day.

A further attempt of 30 entries suffered a setback! Based on the previous 25 entries, I added 2 entries on the top and 3 entries on the bottom. In the earliest 1.5 cycles, everything seemed to work fine before I started to revise a few times the action of each control alarm that carried an appointment alarm. It was found that 3 entries failed to wake up. This was also the first time an alarm with integer hour did not execute properly. In both cases, there was a desired alarm that would come due at hh:59. Plus 1 minute delay, it did come due at hh+1:00. It in turn triggered indirectly control alarms that would come due at hh+1:00. Unexpectedly, they could not execute! After performing a factory reset by pressing ON-F1-F6-NO, I re-created nearly the same set of those 30 entries from scratch except a corrected digit in the minute part of the desired alarm of the last entry. 2 of the 3 entries worked again but not all. I suspected that some memory problems might have occurred.

I had to go back to 25 entries where those 3 entries had once worked. After performing another factory reset, I created them one by one each having a revised action yet the same alarm time from scratch. 3 cycles were completed successfully. It appears that 30 entries would be too many for the calculator. I will begin at 29 entries and decrease the number one by one until I find the maximum number of entries without causing any irregularity.

Apparently, the use of a control alarm to carry a desired alarm seems to make the faulty alarm feature predictable and useful. My focus will turn to the test of boundary scenarios.

It is time to summarise some information at this stage.

Make sure the ROM version is 2.15. The STARTOFF variable that stores a program « OFF » should be ready before using the following actions. No matter what the alarm is, it will come due with 1 minute delay. One of the exceptions is that other alarms trigger it at its entered alarm time. Practically, it is very rare for 2 alarms to be set so close that an alarm will trigger another. However, it should be avoided. See the example in the 2nd paragraph.

For a desired alarm having an integer alarm time or having an alarm time within 59 minutes from its creation time, set it as usual. If the desired alarm has a non-integer time, always create a control alarm with an integer time that is the hour part of the desired alarm and use it to carry the desired alarm. To make the actions look more consistent, I replaced the more hard-coded yet shorter hh.mm with a code segment “TIME IP .mm +” and probably a + sign.

Here are some examples without a repeat interval.

Control alarm set for 10:00:00 with the following action to carry an appointment alarm set for 10:20:

« DELALARM DATE TIME IP .2 + { “M2” } + + STOALARM DROP OFF »

Control alarm set for 6:00:00 with the following action to carry another control alarm set for 6:50:

« DELALARM DATE TIME IP .5 + { « DATE TIME 2. →LIST SWAP DROP OFF » } + + STOALARM DROP OFF »

In the previous reply, 2 actions were shown each having a repeat interval of 1 day. Now their less hard-coded versions are ready to accept an integer repeat interval in hours, days or weeks.

Control alarm set for 10:00:00 with the following action to carry an appointment alarm set for 10:59:

« DATE TIME IP .59 + 2. →LIST DUP { « DELALARM ACK OFF » } + STOALARM SWAP { “GOOD MORNING!” } + STOALARM 3. DROPN OFF »

Control alarm set for 5:00:00 with the following action to carry another control alarm set for 5:30:

« DATE TIME IP .3 + { « DELALARM DATE TIME 2. →LIST OFF » } + + STOALARM DROP2 OFF »

There will be cases that the repeat interval is in minutes, seconds or any unit in non-integer values. As it is not straightforward to handle such cases, programs should be developed. If you feel that the above actions are too tedious to enter, programs will also be developed to simplify entry. They will be posted here later.

Stay tuned!

[Johnny Shek]

UPDATE:

One thing suddenly strikes my mind. In the summary I made in the last reply, I forgot to mention how an alarm could be set for less than an hour from the current time. This is exactly the idea of using a control alarm to carry a desired alarm to make sure that it comes due with 1 minute delay if it is set for less than or equal to 59 minutes from its creation time. Suppose I want to set an alarm for 12:26 at 12:01 now. According to the ‘59 minute rule’, set the alarm as usual and it will come due at 12:27. The above reply has been updated accordingly.

I am working on boundary tests. In my first attempt to stretch the ’59 minute rule’ to its limit by extending it from 59 minutes 1 second to 59 minutes 59 seconds, I encountered various kinds of unacceptable behaviour. It is better for me to leave the discussion to the next reply.

29 entries were created from scratch based on the alarm data of the first 29 entries of the above 30 entries. After performing a factory reset, the test was conducted. 3 cycles were run without any problem! 29 entries might be the maximum number of entries allowed by the calculator. No more stress tests will be conducted.

Stay tuned!

[SammysHP]

Instead of empirically finding rules how to set alarm so that it works in some mysterious way, I'd be more interested in actual reverse engineering or technical analysis of the alarm handling. Is there a layer that uses the watchdog and an interrupt to wake up? Is it implemented directly in the ROM?

[Johnny Shek]

(08-31-2024 11:14 AM)SammysHP Wrote:  Instead of empirically finding rules how to set alarm so that it works in some mysterious way, I'd be more interested in actual reverse engineering or technical analysis of the alarm handling. Is there a layer that uses the watchdog and an interrupt to wake up? Is it implemented directly in the ROM?

Thank you very much for your reply.

This has been a long-standing issue since probably the earliest ROM version of the HP-49g+. Some users posted the issue to user groups or forums, which caught the attention of some HP’s ‘internal guys’. They told Kinpo to fix it. According to the conversations and my understanding, this issue is related to a synchronisation problem between the Saturn emulation layer and the ARM CPU. It has nothing to do with the Saturn code and so the HP-49g has no such issue. Unfortunately, this issue still exists in the latest ROM version of the HP-50g. It seems that the fix would not be simple.

https://groups.google.com/g/comp.sys.hp48/c/Pn7xRbcM5Ow

I had not used the alarm feature since the era of the HP-48SX until recently. In June, I started to look into the issue and designed a lot of programs as well as tests to identify certain patterns to enable me to find a workaround. Hopefully, some users find my information helpful if they still want to use the alarm feature under ROM version 2.15.

[cdmackay]

thanks very much, for the detailed notes, Johnny.