HP49-50G: help for "frozen" screen

[Gil]

Suppose that, instead of using the built-in ROOT command, I write a program P with the MSLV command to solve the equation 2x=10 (I know it's stupid, it's just a simple example/case):

« '2*X-10' 1 —>ARRY 'X' 1 —>ARRY 3 1 —>ARRY MSLV»
'P' STO

I launch the program and get [5], the expected result in brackets, in stack level 1.

Looking at the top of the calculator, however, we see that that part of the screen was frozen,
ie the line "RAD XYZ HEX C X"
and the other line "{HOME... }" have disappeared.

After launching the program P, I press ENTER or any other key, and the lines RAD XYZ HEX C X & {HOME...} appear again (normal screen).

My question: what instruction/which commands should I add at the end of the program P to get back the lines RAD XYZ HEX C X& {HOME... } automatically after execution of the program P?

A bad solution would be to add, inside the program P, after the MSLV-command, the instruction CONT, that seems to do the job (with lines RAD XYZ HEX C X& {HOME... } automatically added back after reading the CONT command in program P) ?

Bad idea because, if I create now a second program P2, which should square the result found with P
« P 1 GET SQ »,
the execution of the instruction CONT in program P will terminate the process, without executing 1 GET SQ.

I tried to "play" with the instruction DISP, FREEZE & WAIT, but with no success.

Thanks for your help.

[DavidM]

(02-01-2024 10:52 AM)Gil Wrote:  I tried to "play" with the instruction DISP, FREEZE & WAIT, but with no success.

After experimenting with this for a bit, the closest User RPL solution I could come up with was to trigger an error inside of a protected block to keep it from HALTing the program:

Code:

IFERR 0 DOERR THEN END

The above code would need to be placed after the MSLV step.

There's a more concise alternative that has been tested on a 50g 2.15 ROM:

Code:

#2EE6Dh SYSEVAL

Edit: the above address was updated to use a "safer" entry point

The above directly calls the internal routine that specifically clears the "OK" status of the entire display, which in turn causes the O/S to redraw the entire display at the next opportunity.

While I haven't tried that on all known firmware variants, it definitely works for a v2.15 50g.

Hopefully someone else may know of a more straightforward way to do this.

[Gil]

Nicely thought and found.

Thanks for your quick answer and solution.

Playing with your condition, it seems that
IFERR 1 DOERR THEN END
works.

But also IFERR DOERR THEN END

Regards

[DavidM]

(02-01-2024 03:40 PM)Gil Wrote:  Nicely thought and found.

Thanks for your quick answer and solution.

Playing with your condition, it seems that
IFERR 1 DOERR THEN END
works.

But also IFERR DOERR THEN END

Regards

Any number or string should work, but numbers in the 0 - 9 range will take up less room. An empty string works as well.

I like 0 more than 1, only because 1 is a real error ("Insufficient Memory"), and if you subsequently use ERRN or ERRM, you will see what appears to be a legitimate error number or message.

The same applies to DOERR by itself, because it tries to use whatever is already in SL1 as its argument. If you happened to have a number or string in SL1 when calling DOERR, then that stack object will be "eaten" by DOERR, which is not likely what you want to happen. In other cases, ERRN and ERRM will then represent the error code #202h for "Bad Argument Type". That could be very misleading depending on how you troubleshoot.

[Gil]

Thanks for the explanation.

Then, I will be using your first "0" suggestion.

Regards,
Gil