41: What's the significance of the alpha mark (ᵀ) prefix on catalog 2 entries?

[Dave Britten]

I've noticed some inconsistency between - and even within - modules as to whether or not the catalog 2 entries have the alpha mark (ᵀ) in front of the name.

The conversion section of the Advantage module doesn't have them, and the matrix section generally doesn't, except for some entries like MEDIT, CMEDIT, MP, MATRX, and MTR. For the math portion of the module, most of the entries have the mark, except for the first three and last one: SOLVE, INTEG, SILOOP, and AIP. The handful of labels in the TVM portion all have the alpha mark.

The Math/Stat module has it on all the entries.

Is it supposed to indicate something about the entry it's attached to?

[Joe Horn]

I *think* the alpha marked entries are user-code programs which can be listed and copied into RAM. The entries without alpha marks are neither listable nor copyable, because they are in lower-level "m-code".

EDIT: From page 395 in Vol II of the 41CX manual, regarding Catalog 2: "An operation in ROM in an applications or extension module or in a peripheral is provided either as a program or as a function. A program can be copied into user memory, then listed and altered, etc. A function, on the other hand, cannot be viewed — only used. When you list out catalog 2, the computer differentiates the two with the "raised T" in front of programs."

[Dave Britten]

(01-19-2020 03:19 PM)Joe Horn Wrote:  I *think* that the alpha marked entries are user-code programs which can be listed and copied into RAM. The entries without alpha marks are neither listable nor copyable, because they are in lower-level "m-code".

I think you're probably right. I know the base conversions in Advantage are all m-code, and TVM is not, so that's consistent with the catalog 2 entries. Then GTO "CSUM" gives NONEXISTENT, whereas GTO "MEDIT" takes me to the user program in ROM, so again, that's consistent.

[Joe Horn]

Yes, that's right. It turns out that it's even mentioned in the 41 manual (see my edit above).

[Dave Britten]

(01-19-2020 03:39 PM)Joe Horn Wrote:  Yes, that's right. It turns out that it's even mentioned in the 41 manual (see my edit above).

Ah ha! Thanks for the reference. It's always rough to try finding the one sentence you need from a stack of manuals.

[rprosperi]

You can easily copy FOCAL programs in ROM (in a module) to user RAM by simply using the COPY command. Go to the end of RAM (i.e. [GTO] [.] [.]), put the FOCAL program name in Alpha ([Alpha] [T] [V] [M] [Alpha]) then XEQ "COPY". You can then modify this copy of the program, save it to extended memory etc.

This lets you use FOCAL programs from the module even with the module not installed. But also note that many FOCAL programs in modules also depend on MCODE routines in the same ROM, so check this before you need to use it.

[hth]

(01-19-2020 03:52 PM)rprosperi Wrote:  You can easily copy FOCAL programs in ROM (in a module) to user RAM by simply using the COPY command. Go to the end of RAM (i.e. [GTO] [.] [.]), put the FOCAL program name in Alpha ([Alpha] [T] [V] [M] [Alpha]) then XEQ "COPY". You can then modify this copy of the program, save it to extended memory etc.

Just to be picky. You do not need (and probably do not want) to press GTO .. before doing COPY. The reason is that COPY converts the permanent .END. to an ordinary END and then appends the copied program. Thus, if you have a normal END after the last program (created by pressing GTO ..), you will get double ENDs.

Also COPY does not take it argument from Alpha, you are expected to press XEQ "COPY" [Alpha] name [Alpha].

This is all because COPY is part of the mainframe (HP-41 original firmware) and it does not contain any code to take a name from Alpha. Such routines were introduced in the Extended Functions module and the HP-IL module.

Apart from this particular case, it is (as mentioned) a good idea to use GTO .. to ensure that a program is not replaced when reading from some mass storage. There are usually two routines and the usual read-a-program from mass storage will replace the last program, which is protected by the GTO .. that creates an invisible/empty last program (if such does not already exist).

COPY is just different from the rest.

[Ángel Martin]

(01-23-2020 08:09 AM)hth Wrote:  Also COPY does not take it argument from Alpha, you are expected to press XEQ "COPY" [Alpha] name [Alpha].
COPY is just different from the rest.

100% agreement - boy have I often wondered why force the user to press the first ALPHA if *only* ALPHA entry is allowed....

[hth]

(01-23-2020 03:55 PM)Ángel Martin Wrote:  

(01-23-2020 08:09 AM)hth Wrote:  Also COPY does not take it argument from Alpha, you are expected to press XEQ "COPY" [Alpha] name [Alpha].
COPY is just different from the rest.

100% agreement - boy have I often wondered why force the user to press the first ALPHA if *only* ALPHA entry is allowed....

I think this is related to did not have time, not enough ROM space and being consistent. They had to stop somewhere. An instruction like XEQ accepts both numeric and Alpha input. On the other hand ASN, COPY, CLP take only alpha, sometimes empty input is allowed. In some way it makes it more consistent (you always press Alpha to mark start and end of text input) and probably easier to implement.

But I agree, I always found it annoying. However, when I have recently created ASN' which is like ASN but also with numeric input, suddenly it turned into a good thing.

[rprosperi]

(01-23-2020 08:09 AM)hth Wrote:  ... COPY does not take it argument from Alpha, you are expected to press XEQ "COPY" [Alpha] name [Alpha].

This is all because COPY is part of the mainframe (HP-41 original firmware) and it does not contain any code to take a name from Alpha. Such routines were introduced in the Extended Functions module and the HP-IL module.

Thanks for the correction! I never noticed that Functions taking arguments from existing Alpha register all came in or after the XFM, and that all mainframe functions did this the 'old' way. Like many such behavioral things, it makes sense, once you see the pattern.

[Dave Britten]

(01-23-2020 10:01 PM)rprosperi Wrote:  

(01-23-2020 08:09 AM)hth Wrote:  ... COPY does not take it argument from Alpha, you are expected to press XEQ "COPY" [Alpha] name [Alpha].

This is all because COPY is part of the mainframe (HP-41 original firmware) and it does not contain any code to take a name from Alpha. Such routines were introduced in the Extended Functions module and the HP-IL module.

Thanks for the correction! I never noticed that Functions taking arguments from existing Alpha register all came in or after the XFM, and that all mainframe functions did this the 'old' way. Like many such behavioral things, it makes sense, once you see the pattern.

I wonder why the switch. It's not like a function couldn't take an indirect argument the way XEQ IND does if you needed a non-hard-coded argument. Was it to get around the 6-character register limit maybe? But for that matter, I wonder why the 41 doesn't support IND A.

[Thomas Okken]

(01-23-2020 10:10 PM)Dave Britten Wrote:  I wonder why the switch. It's not like a function couldn't take an indirect argument the way XEQ IND does if you needed a non-hard-coded argument. Was it to get around the 6-character register limit maybe? But for that matter, I wonder why the 41 doesn't support IND A.

Supporting ALPHA arguments for arbitrary programmable functions was a bit difficult on the 41 because the opcode space was pretty much used up, and XROM functions don't support arguments at all. Squeezing that in would have required some rather drastic measures in the command interpreter.

They did eventually make those changes, on a machine that had more RAM and especially ROM so that functionality could be put to good use. I'm referring, of course, to the 42S.

[Dave Britten]

(01-23-2020 11:00 PM)Thomas Okken Wrote:  

(01-23-2020 10:10 PM)Dave Britten Wrote:  I wonder why the switch. It's not like a function couldn't take an indirect argument the way XEQ IND does if you needed a non-hard-coded argument. Was it to get around the 6-character register limit maybe? But for that matter, I wonder why the 41 doesn't support IND A.

Supporting ALPHA arguments for arbitrary programmable functions was a bit difficult on the 41 because the opcode space was pretty much used up, and XROM functions don't support arguments at all. Squeezing that in would have required some rather drastic measures in the command interpreter.

They did eventually make those changes, on a machine that had more RAM and especially ROM so that functionality could be put to good use. I'm referring, of course, to the 42S.

That would certainly explain it, then (emphasis mine). It's just a shame the 42S didn't have any ROM expansion capabilities to take advantage of it!

[hth]

(01-23-2020 10:10 PM)Dave Britten Wrote:  

(01-23-2020 10:01 PM)rprosperi Wrote:  Thanks for the correction! I never noticed that Functions taking arguments from existing Alpha register all came in or after the XFM, and that all mainframe functions did this the 'old' way. Like many such behavioral things, it makes sense, once you see the pattern.

I wonder why the switch. It's not like a function couldn't take an indirect argument the way XEQ IND does if you needed a non-hard-coded argument. Was it to get around the 6-character register limit maybe? But for that matter, I wonder why the 41 doesn't support IND A.

The original ROMs had severely underdeveloped programmable alpha functionality. This was rectified with the Extended Functions module.

The switch from prompting for the alpha name to using the alpha register was most likely caused by the file systems. Early on there were the card reader and the Wand, both which relied on physical media that the user picked manually. With the Extended functions and the HP-IL mass storage, there was multiple files and they were selected by name. In order to do this it was natural to use the alpha register. It also allowed for specifying a program by name and save it under a different name.

[hth]

(01-23-2020 11:03 PM)Dave Britten Wrote:  

(01-23-2020 11:00 PM)Thomas Okken Wrote:  Supporting ALPHA arguments for arbitrary programmable functions was a bit difficult on the 41 because the opcode space was pretty much used up, and XROM functions don't support arguments at all. Squeezing that in would have required some rather drastic measures in the command interpreter.

They did eventually make those changes, on a machine that had more RAM and especially ROM so that functionality could be put to good use. I'm referring, of course, to the 42S.

That would certainly explain it, then (emphasis mine). It's just a shame the 42S didn't have any ROM expansion capabilities to take advantage of it!

XROMs do support arguments on the HP-41. This was used by the PRP function in the printer to select a program to print. In fact, the command interpreter on the HP-41 is quite capable of handling arguments for XROMs, but it saw limited use. Probably due to this, the command interpreter also had a couple of bugs related to XROMs that I have fixed in the IFG ROM variant for the 41CL.

The main problem with supporting arguments with XROMs on the HP-41 is that they cannot be stored into programs. This is because the user can unplug a module and then there is no way to know whether it would use any argument, making it impossible to properly display a program. There are a couple of ways around this to make this somewhat possible. One is the semi-merged feature I use in the Ladybug module, being generalized in a coming OS extension module that I am currently working on.