HP-41C IL Module Question

[Craig Bladow]

Something that I have always found odd is the WRTS/WRTA functions, which as part of their operation save the contents of the ALPHA register, but necessarily need the file name in the ALPHA register, which somewhat reduces the intended benefit of these functions in my mind.

The 41's card reader has similar functions but the 'filename' was provided by good old pen and pencil, thus preserving the contents of the ALPHA register.

This could have been solved if WRTS, for example, worked like GTO NAME, where WRTS FILENAME saved the status including the contents of the ALPHA register.

So am I correct that expansion module functions can't take a following alpha string?

[Sylvain Cote]

(01-12-2021 06:39 PM)Craig Bladow Wrote:  Something that I have always found odd is the WRTS/WRTA functions, which as part of their operation save the contents of the ALPHA register, but necessarily need the file name in the ALPHA register, which somewhat reduces the intended benefit of these functions in my mind.

I agree that ALPHA is lost, but when you look at all the other HP-IL file functions, ALPHA is used uniformly for "filename" or one of the variant like "progname,filename" or "oldname,newname".
Personally, I prefer consistency.

(01-12-2021 06:39 PM)Craig Bladow Wrote:  So am I correct that expansion module functions can't take a following alpha string?

Sorry, I do not understand the question and which module you are talking about. XFM ?

edit: typo

[Craig Bladow]

(01-12-2021 06:54 PM)Sylvain Cote Wrote:  

(01-12-2021 06:39 PM)Craig Bladow Wrote:  So am I correct that expansion module functions can't take a following alpha string?

Sorry, I do not understand the question and which module you are talking about. XFM ?

The specific module is the HP-82160A HP-IL module for the HP-41C. I'm wondering if it is generally possible for functions residing in a plug-in module to take an alpha string as an argument following a command.

[Sylvain Cote]

(01-12-2021 08:12 PM)Craig Bladow Wrote:  

(01-12-2021 06:54 PM)Sylvain Cote Wrote:  Sorry, I do not understand the question and which module you are talking about. XFM ?

The specific module is the HP-82160A HP-IL module for the HP-41C. I'm wondering if it is generally possible for functions residing in a plug-in module to take an alpha string as an argument following a command.

Sorry, I am still not quite sure I understand your question, probably the language barrier here.

The ALPHA data is located in the status chip located at addressed 0 to 15, more specifically in registers M, N, O and P[nibbles:5..0].
In a FOCAL program or sub-routine, ALPHA can be accessed through:

• 41C/CV/CX functions: ARCL/ASTO/ASHF/AVIEW/APPEND/CLA/AON/AOFF
• 41CX/XFM functions: ALENG/ANUM/AROT/ATOX/POSA/XTOA
• any modules that offers ALPHA access functions like: Extended I/O, HP-IL Dev, ALPHA ROM, PANAME, etc
  

In an MCODE function, the assembly program first select the chip, then select the register then load/save the register (whole or part) to/from the CPU.
Since the status registers and the storage registers are global, they are accessible from any FOCAL program or from any MCODE function.

[Dave Britten]

(01-12-2021 08:12 PM)Craig Bladow Wrote:  

(01-12-2021 06:54 PM)Sylvain Cote Wrote:  Sorry, I do not understand the question and which module you are talking about. XFM ?

The specific module is the HP-82160A HP-IL module for the HP-41C. I'm wondering if it is generally possible for functions residing in a plug-in module to take an alpha string as an argument following a command.

You mean a parameterized function like CLP, where you XEQ CLP and then give it the program name? I recall someone (probably Angel) mentioning that XROM calls to module functions generally can't be parameterized, or at least not easily. If the module is removed, the calculator has no way of telling if any of the bytes following the XROM instruction should be treated as parameters or if they're subsequent instructions.

And I don't think there are many built-in functions that take a name as an argument which can be entered into a program, or at least I can't think of any besides LBL, GTO, and XEQ (and STO and RCL on the 42S). This is why you have functions like PASN for when you need to include them in a program.

[Sylvain Cote]

It took some time but with Dave example I finally understood your question, sorry about that.
Dave is right, to my knowledge XROM cannot be parameterized.
The only way I can think would be through polling point like CCD or ZENROM did and even then, their behavior extensions were not programmable.
The best ones to answer that would be Ángel Martin, Håkan Thörngren or other MCODE guru here.

[Ángel Martin]

I believe WRTA stands for Write ALL, not ALPHA - so it's still true that ALPHA's contents is partially (or totally) lost with the name of the Disk File but it's not as bad as if it were only Write ALPHA...

As to using prompting functions in plug-in modules, that's a restriction of the OS in the case of programmable functions (non-programmable ones don't have that limitation, see for example NEWM _ _ _). There are ways to go around that limitation but all involve some degree of trickery that HP never wanted to resort to, and I don't blame them - imagine the customer support nightmare when non power users used them incorrectly.

[Craig Bladow]

(01-13-2021 01:30 AM)Dave Britten Wrote:  

(01-12-2021 08:12 PM)Craig Bladow Wrote:  The specific module is the HP-82160A HP-IL module for the HP-41C. I'm wondering if it is generally possible for functions residing in a plug-in module to take an alpha string as an argument following a command.

You mean a parameterized function like CLP, where you XEQ CLP and then give it the program name? I recall someone (probably Angel) mentioning that XROM calls to module functions generally can't be parameterized, or at least not easily. If the module is removed, the calculator has no way of telling if any of the bytes following the XROM instruction should be treated as parameters or if they're subsequent instructions.

And I don't think there are many built-in functions that take a name as an argument which can be entered into a program, or at least I can't think of any besides LBL, GTO, and XEQ (and STO and RCL on the 42S). This is why you have functions like PASN for when you need to include them in a program.

Yes, this is what I meant. Thanks for stating my question more clearly.

[Craig Bladow]

(01-13-2021 08:08 AM)Ángel Martin Wrote:  I believe WRTA stands for Write ALL, not ALPHA - so it's still true that ALPHA's contents is partially (or totally) lost with the name of the Disk File but it's not as bad as if it were only Write ALPHA...

As to using prompting functions in plug-in modules, that's a restriction of the OS in the case of programmable functions (non-programmable ones don't have that limitation, see for example NEWM _ _ _). There are ways to go around that limitation but all involve some degree of trickery that HP never wanted to resort to, and I don't blame them - imagine the customer support nightmare when non power users used them incorrectly.

Yes, WRTA is Write All, including the ALPHA register. And Write Alpha only would be a much worse case.