[50g] Assign VIEW to a key

[DavidM]

(07-23-2018 04:29 PM)SammysHP Wrote:  

Code:

:: PTR 275C6 PTR 06E97 :: PTR 79E9A PTR 2B8AA ; FPTR 2 0 ;

...and what the various addresses mean?
...
What would be a good start for understanding and learning SysRPL programming? You can find many tools for low-level development on the HP 50g, each with some kind of manual, but most of them just explain what it does, but not why or how you use it. I usually work with high-level languages like C or C++, Java etc. and even some low-level languages like smali or AVR assembler. I have the feeling that nothing of that can be compared with SysRPL or ASM on HP calculators (reference, toolchain, usability in general).

Re-reading your request, it feels like a bit more explanation is in order.

Yes, the above SysRPL program is executed upon pressing the VIEW menu item when the TOOL menu is shown. You could theoretically assign that code segment to a key and execute it, but it wasn't designed to be activated that way and as was already mentioned, there's a better way to do it.

As you probably already realize, SysRPL routines (sometimes referred to as "secondaries") are generally encapsulated between the :: and ; tokens (their formal names are DOCOL and SEMI).

Yes, installing extable will help you somewhat by showing names for certain entries instead of their PTR addresses. But be aware that not all routines in ROM have formal names. In this case, only a couple of the ones identified above do:

PTR 275C6: TakeOver
PTR 06E97: ' (usually pronounced "tick")

The others are references to ROM routines that aren't named, and are only accessible by the PTR reference. Non-named ROM routines are more likely to be inconsistent from one ROM version to the next, and it's best not to call them directly unless your code has already verified that it's OK to do so. Knowing when that's OK is not an easy concept to describe, so most sources you find will simply say "don't do it".

That first pointer in the ticked secondary (79E9A) appears to be the heart of the command. The details aren't meaningful at a high level, but it essentially checks some things, performs a DUP, then calls a named ROM command named ViewObject. That's where the main functionality of that menu item takes place.

The second one appears to perform some specialized functions based on the last nibble of the address of the current item in stack level 1, but I'm too lazy to keep tracing the code to see why. Why? Because there's already a much easier solution (the previously-mentioned SCROLL command), and because that code is likely to create problems if you attempt to call a routine like that out of context. Assigning the above code segment to a user key qualifies as "calling it out of context". It may work, it may not. It may work sometimes, but not others. And by "not working", I mean things like "crashing the calculator and losing data in the process". Is it worth it?

Finally, FPTR 2 0 is a specialized command that makes the preceding secondary run its objects in such a way that the appropriate memory bank is switched in before the secondary runs, and then switched back out when it finishes. Not unlike other environments that have a limited address space, this is required in order to have access to far more code than will fit in the relatively paltry addressable space that the Saturn environment affords.

It's nice to see others that are still interested in SysRPL/Saturn coding! I hope the above does more to pique your interest than to dissuade you.