Post Reply 
HP-41CL: Suggested module format update
10-01-2019, 02:25 AM
Post: #1
HP-41CL: Suggested module format update
This is for anyone making tools for the HP-41.

As you probably know there are two common ways to deal with HP-41 plug-in page images, module files (.mod extension) and ROM files (.rom extension).

Normal HP-41 page data uses 10-bit words, but for the 41CL we have 16-bit words. The upper bits are used for speed annotations, making timing loops run at the normal speed regardless of any turbo mode. Modules that contain such timing annotations cannot be represented by the module format and is lost.

I propose that there should be a variant of the module format that does not pack the data, but instead stores it as 16-bit data internally (like in the .rom format).

To implement this I have updated my own tools to have a MOD2 variant (the current one is MOD1). The only other difference is that it stores page data unpacked in the same way as .rom files.

I talked to Warren about this and he agrees that this is a solution to the problem. I suggest that anyone making tools to consider it.

Comments are welcome.
Find all posts by this user
Quote this message in a reply
10-06-2019, 10:25 AM
Post: #2
RE: HP-41CL: Suggested module format update
Good plan. Are there details about the implementation? Would be nice to add that format to my MLDL2000 software to support import and export

Regards, Meindert
Find all posts by this user
Quote this message in a reply
10-07-2019, 05:21 AM
Post: #3
RE: HP-41CL: Suggested module format update
(10-06-2019 10:25 AM)MeindertKuipers Wrote:  Good plan. Are there details about the implementation? Would be nice to add that format to my MLDL2000 software to support import and export

Not to discourage from the idea but what usage would the high-bits have on the MLDL2k?
On the CL the mark No-Turbo condition, but nothing more (I believe...)
Find all posts by this user
Quote this message in a reply
10-07-2019, 04:14 PM
Post: #4
RE: HP-41CL: Suggested module format update
(10-06-2019 10:25 AM)MeindertKuipers Wrote:  Good plan. Are there details about the implementation? Would be nice to add that format to my MLDL2000 software to support import and export

I have added support in my tools, but as they are written in Haskell it does not carry over to the C implementation.
Find all posts by this user
Quote this message in a reply
10-07-2019, 04:18 PM
Post: #5
RE: HP-41CL: Suggested module format update
(10-07-2019 05:21 AM)Ángel Martin Wrote:  
(10-06-2019 10:25 AM)MeindertKuipers Wrote:  Good plan. Are there details about the implementation? Would be nice to add that format to my MLDL2000 software to support import and export

Not to discourage from the idea but what usage would the high-bits have on the MLDL2k?
On the CL the mark No-Turbo condition, but nothing more (I believe...)

I think that the ability to load such files and strip the speed bits is a benefit. It would mean that a module that defines speed bits for the HP-41CL, need not to be delivered as both MOD1 and MOD2 files. Only producing a MOD2 file in that case would suffice.

As it is now, I produce both MOD1 and MOD2 files, then I extract the .rom files from the MOD2 and zip them (losing module metadata). A more general support and acceptance for a MOD2 format would be helpful IMO.
Find all posts by this user
Quote this message in a reply
10-07-2019, 05:16 PM
Post: #6
RE: HP-41CL: Suggested module format update
This is certainly an extreme use case, but when I am debugging code using V41 it is a royal pain to have to go all the way back to the source when doing a quick hack. This is because it is impossible to use a hex editor to do a quick hack on the code in a .mod file like it is on a .rom file. It's usually because I got the polarity wrong for the carry on a jump and I just need to flip the case. So I would love an uncompressed format for .mod files, especially if it were supported by V41.
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)