HP-41CL: Suggested module format update

[hth]

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.

[MeindertKuipers]

Good plan. Are there details about the implementation? Would be nice to add that format to my MLDL2000 software to support import and export

[Ángel Martin]

(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...)

[hth]

(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.

[hth]

(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.

[Monte Dalrymple]

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.

[Christoph Giesselink]

(10-07-2019 05:16 PM)Monte Dalrymple Wrote:  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.

Is this is still from interest?

If so, it would be possible to add such a feature, "MOD2" using the .rom format inside MOD, to V41. In this particular case the upper 6 bits will be cleared at loading. In the case of ROM this doesn't matter, but as RAM (overwriteable QROM) these 6 bits get lost when writing back.

[MeindertKuipers]

(12-16-2021 06:03 PM)Christoph Giesselink Wrote:  

(10-07-2019 05:16 PM)Monte Dalrymple Wrote:  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.

Is this is still from interest?

If so, it would be possible to add such a feature, "MOD2" using the .rom format inside MOD, to V41. In this particular case the upper 6 bits will be cleared at loading. In the case of ROM this doesn't matter, but as RAM (overwriteable QROM) these 6 bits get lost when writing back.

I would agree to have this as an 'official' additional format, if only for completeness and the ability to have some metadata that describes the content of the MOD file. My current implementation of the ROM Handler does have some limited support for .ROM files with the upper bits used.

[Monte Dalrymple]

(12-16-2021 06:03 PM)Christoph Giesselink Wrote:  

(10-07-2019 05:16 PM)Monte Dalrymple Wrote:  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.

Is this is still from interest?

If so, it would be possible to add such a feature, "MOD2" using the .rom format inside MOD, to V41. In this particular case the upper 6 bits will be cleared at loading. In the case of ROM this doesn't matter, but as RAM (overwriteable QROM) these 6 bits get lost when writing back.

Yes, still of interest.

[Christoph Giesselink]

A new release of V41 is not planned at the moment, so a public beta version of V41 R9Hb1 supporting the MOD2 format is available at

https://hp.giesselink.com/beta/V41R9Hb1-xmasbin.zip

Caution: Don't start the V41.exe file outside it's installation directory. The environment is missing and so the MOD files are not found which may then removed from the current LOD file!

I tested this feature by converting NUT-CX.mod and HEPAX.MOD to the MOD2 format. NUT-CX.mod contain only read-only modules, whereas HEPAX.MOD contains writable QROM modules which are updated when the session is closed.

[Massimo Gnerucci]

Thanks for the Xmas present!

[MeindertKuipers]

I have not tested the V41 beta, I just looked at the ModEdit and played with it a bit, I really like it, much cleaner than my implementation!. Just a few questions:

- a MOD file with multiple ROMs must have all the same MOD types (MOD1 or MOD2) ? No mix?
- what is the maximum number of ROMs in a MOD file? I use this format for MLDL2000 backups, and there can be (in theory) more than 100 ROMS in one MOD file. I now receive a load error when opening such a backup file. Would be good to know your maximum. A MOD file with 12 ROMS works.
- I misuse the MOD1 format for a baclup of the Settigs Registers of the MLDL2000. This also results in a load error in your ModEdit.

As a suggestion, would be nice to have an indication of the 41CL CRC of the image.

(12-20-2021 06:42 PM)Christoph Giesselink Wrote:  A new release of V41 is not planned at the moment, so a public beta version of V41 R9Hb1 supporting the MOD2 format is available at

https://hp.giesselink.com/beta/V41R9Hb1-xmasbin.zip

Caution: Don't start the V41.exe file outside it's installation directory. The environment is missing and so the MOD files are not found which may then removed from the current LOD file!

I tested this feature by converting NUT-CX.mod and HEPAX.MOD to the MOD2 format. NUT-CX.mod contain only read-only modules, whereas HEPAX.MOD contains writable QROM modules which are updated when the session is closed.

[Christoph Giesselink]

(12-23-2021 02:29 PM)MeindertKuipers Wrote:  I have not tested the V41 beta, I just looked at the ModEdit and played with it a bit, I really like it, much cleaner than my implementation!. Just a few questions:

- a MOD file with multiple ROMs must have all the same MOD types (MOD1 or MOD2) ? No mix?
- what is the maximum number of ROMs in a MOD file? I use this format for MLDL2000 backups, and there can be (in theory) more than 100 ROMS in one MOD file. I now receive a load error when opening such a backup file. Would be good to know your maximum. A MOD file with 12 ROMS works.
- I misuse the MOD1 format for a baclup of the Settigs Registers of the MLDL2000. This also results in a load error in your ModEdit.

As a suggestion, would be nice to have an indication of the 41CL CRC of the image.

(12-20-2021 06:42 PM)Christoph Giesselink Wrote:  A new release of V41 is not planned at the moment, so a public beta version of V41 R9Hb1 supporting the MOD2 format is available at

https://hp.giesselink.com/beta/V41R9Hb1-xmasbin.zip

Caution: Don't start the V41.exe file outside it's installation directory. The environment is missing and so the MOD files are not found which may then removed from the current LOD file!

I tested this feature by converting NUT-CX.mod and HEPAX.MOD to the MOD2 format. NUT-CX.mod contain only read-only modules, whereas HEPAX.MOD contains writable QROM modules which are updated when the session is closed.

Quote:- a MOD file with multiple ROMs must have all the same MOD types (MOD1 or MOD2) ? No mix?

The FileFormat with the MOD type is part of the ModuleFileHeader existing only once in a MOD file. So no mix!

Quote:- what is the maximum number of ROMs in a MOD file? I use this format for MLDL2000 backups, and there can be (in theory) more than 100 ROMS in one MOD file. I now receive a load error when opening such a backup file. Would be good to know your maximum. A MOD file with 12 ROMS works.

The possible no. of pages is normally limited by NumPages in the Header. It's a byte, so the maximum for pages is 255. But ModEdit is a so called dialog based application, where the class members and so the file content are created on the stack. Maybe there's a stack overflow on too many ROM pages.

Quote:- I misuse the MOD1 format for a baclup of the Settigs Registers of the MLDL2000. This also results in a load error in your ModEdit.

Many structure members have for example a byte container, but only limited values like 1 to 4 maybe allowed. To reduce errors on these "free number" fields I mostly use pre defiend combo boxes to limitate the settings.

Maybe you mail one of these MOD files making trouble as example for analysing to me. It should make no difference if the module pages containing true ROM data or fake data filled with anything else for analysing.

Quote:As a suggestion, would be nice to have an indication of the 41CL CRC of the image.

I don't know anything about the 41CL, and so nothing about the 41CL specific CRC. A description and an example file would be welcome.