How force 50g warmstart in User RPL?

[Joe Horn]

How can a User RPL program safely force a warmstart to occur, as if ON+C had been pressed? My old brain is forgetting everything. I used the Search facility here but found nothing. Thanks in advance!

[rprosperi]

"OFF" [Enter] followed by [ON].... ;-)

[Joe Horn]

(10-23-2022 11:55 PM)rprosperi Wrote:  "OFF" [Enter] followed by [ON].... ;-)

Unfortunately, that performs a normal power-up, not an ON+C warmstart.

[DavidM]

(10-23-2022 11:41 PM)Joe Horn Wrote:  How can a User RPL program safely force a warmstart to occur, as if ON+C had been pressed?

That may depend on your definition of "safely".

So long as nothing important is pending, you could simply use the "Warmstart" entry point (<edited: the suggested method could cause problems and shouldn't be used. See Joe's response below for a safer approach.>).

Jumping to Warmstart is a one-way street, of course. Your program loses control and you would definitely not want to do that if something important were still in process. This is in essence the same thing as "On-C" being pressed, with all of the same resets occurring (including the stack being cleared and attached libraries being asked to reconfigure themselves).

Is this what you were remembering?

[Joe Horn]

(10-24-2022 12:57 AM)DavidM Wrote:  

(10-23-2022 11:41 PM)Joe Horn Wrote:  How can a User RPL program safely force a warmstart to occur, as if ON+C had been pressed?

That may depend on your definition of "safely".

As safe as pressing ON+C, which doesn't cause a Memory Lost (AKA "Coldstart").

(10-24-2022 12:57 AM)DavidM Wrote:  So long as nothing important is pending, you could simply use the "Warmstart" entry point ("#01FBDh SYSEVAL" on a 48-series or "#267E5h SYSEVAL" on a 49-series).

But the "Warmstart" entry point is a Saturn machine language entry point, not an RPL entry point. SYSEVAL expects as its argument the address of an RPL entry point. Is there a simple way for User RPL to jump to a Saturn code entry point?

#267E5h SYSEVAL on the 50g does happen to perform a warmstart, but I don't think its a safe way to do it, because it's landing on RPL gibberish and essentially crashing, resulting in a warmstart, which Murphy's Law says will cause Memory Lost only when you really, really don't want it to.

(10-24-2022 12:57 AM)DavidM Wrote:  Jumping to Warmstart is a one-way street, of course. Your program loses control and you would definitely not want to do that if something important were still in process. This is in essence the same thing as "On-C" being pressed, with all of the same resets occurring (including the stack being cleared and attached libraries being asked to reconfigure themselves).

Is this what you were remembering?

Yes, that's exactly what I want to happen. I am exploring various ways of automatically running programs AFTER a warmstart.

My current best solution is:
"CCD20C00008D5E762" H→
which creates a Code object whose body is GOVLNG 267E5=Warmstart. It works, but it feels like a total kluge. (kludge? cluge? cludge?)

[DavidM]

(10-24-2022 12:58 PM)Joe Horn Wrote:  My current best solution is:
"CCD20C00008D5E762" H→
which creates a Code object whose body is GOVLNG 267E5=Warmstart. It works, but it feels like a total kluge. (kludge? cluge? cludge?)

I actually use that same "CODEM GOVLNG =Warmstart ENDCODE" in a custom SysRPL command for a personal library, which is where I got the idea. I was under the impression that, while not a "normal" use of SYSEVAL, that it would end up accomplishing the same thing in this case by jumping straight to the routine that resets the environment. In other words, maintaining the RPL stream/return stack/etc. wouldn't matter here since it was all being reset.

That's definitely not the case, though. As you pointed out, SYSEVAL doesn't quite do what I was thinking here [PC=(A) vs. PC=A]. My quick test showed the correct action, but not for the right reason.

Personally, I don't consider your "kludge" to be a problem. I wouldn't hesitate to use that method for personal work, though it does of course imply that library 256 is attached. While I suspect you always have that available, others may not.

(10-24-2022 12:58 PM)Joe Horn Wrote:  Yes, that's exactly what I want to happen. I am exploring various ways of automatically running programs AFTER a warmstart.

I use a STARTUP object that resets my user key definitions, sets display contrast to a customized value, sets my preferred flag settings, etc. It gets executed any time a Warmstart occurs. I've sometimes thought that a program could employ something like the following to perform a "one off" action after a warmstart:

1. Rename any pre-existing STARTUP so that a new one can be created
2. Create a new STARTUP that will perform the needed one-off actions
3. The last step in the "one off" STARTUP would be to create a "cleanup" program in TEMPOB to be run immediately after the one-off completes
4. The cleanup program deletes the one-off, restores the original STARTUP, then runs it
   

The cleanup program is needed because a program can't purge itself. Since the cleanup program is in TEMPOB, it can operate independently and will disappear at the next GC.

This does require SysRPL coding, though. I'm not aware of a way to do the same with UserRPL.

[Giuseppe Donnini]

The RPL, and hence SYSEVALable, entry you are looking for is called DOAPWL (DO A PoWer Lost sequence) and lives at #21B4Eh in all ROM revisions of the HP-48 (I don’t use the HP-50G, but a quick check revealed that the corresponding entry must have been moved to #2F237h.)

Far from being a kludge, your code does exactly the same thing as DOAPWL, the only difference being that the latter is a Primitive Code Object and hence executes faster:


21B4E          =DOAPWL
21B4E 35B12             CON(5)  (*)+5
21B53 8DDBF10           GOVLNG  =Warmstart (=norecPWLseq)


(The =Warmstart entry is also called =norecPWLseq (non-recordable PoWer Lost sequence) because it doesn’t record the time nor the cause of the system halt in the warmstart log.)

The use of DOAPWL is in fact sanctioned by HP themselves, as they call it to implement the system halt inherent in the (User RPL) xRESTORE command.

[DavidM]

(10-24-2022 03:51 PM)Giuseppe Donnini Wrote:  The RPL, and hence SYSEVALable, entry you are looking for is called DOAPWL

Thanks, Giuseppe! That makes for a cleaner solution that doesn't require lib256 to be attached.

[Joe Horn]

Awesome! Thanks, Giuseppe and David!