Could someone educate me on options for HEPAX RAM size?

[hpgene]

Interesting! Evidently the work needed to convert a HEPAX RAM page to a standalone ROM module is less than I thought.

Gene: Please do not try what I suggest without a backup of your machine. I think it worked fine, but if you have the only copy of a program in RAM don't try it without a backup.

Curious what people find.

[Dave Britten]

Interesting! Evidently the work needed to convert a HEPAX RAM page to a standalone ROM module is less than I thought.

Gene: Please do not try what I suggest without a backup of your machine. I think it worked fine, but if you have the only copy of a program in RAM don't try it without a backup.

Curious what people find.

It's worked when I've done it once or twice. Now, what happens if you were to plug in a DIFFERENT module that uses RAM pages, I couldn't say.

[whuyse]

Mmmh the HEPAX_8H does not load in i41CX on my phone (no other module loaded btw - not even LIB#4)
I'll have to wait for the DM41X to arrive then
Werner

[rprosperi]

The contents of HEPRAM, just like any other upper RAM pages, do indeed remain intact when you remove the HEPAX module; this is described in the docs.If you plug in another module which allocates RAM pages, they will still have their prior contents, but AFAIK, modules doing so do initialize the RAM pages they use, typically with some form of proprietary file system.

But you can also EXPORT the Upper RAM ([shift] [SETUP] [2] [7]) to a file in the FAT, which can then be copied to PC, and the most recent version of Meindert's M2KM program will let you extract individual pages, which you could then copy into a new .mod file framework, effectively giving you an easy/poor mans method of authoring FOCAL modules. This has been tested and verified.

In theory this should also work to save a page of MCODE (allocated by HEPAX and then copied/edited as needed) however I don't believe this has been verified to date.

[Ángel Martin]

The contents of HEPRAM, just like any other upper RAM pages, do indeed remain intact when you remove the HEPAX module; this is described in the docs.If you plug in another module which allocates RAM pages, they will still have their prior contents, but AFAIK, modules doing so do initialize the RAM pages they use, typically with some form of proprietary file system.

So here's where this approach may cause problems: if you were to swap the HEPAX_4H and the HEPAX_8H modules the memory arrangement would be different for each one, and the HEPAX initialization process won't detect that (since it was designed to work on modules that carry their own memory, as opposed to sharing a common memory pool). So the HEPAX FileSystem is configured when the first HEPAX module is plugged in. If this happens to be the "8H" version then four pages are allocated to the HEPAX FileSystem. If you then unplug the "8H"version and plug the "4H" Module the initialization process does not see that change and leaves the pointers in HEPRAM unchanged, signaling a four page congiguration - which clashes with the "4H" Module instructions to allocate only 2 pages to it from the RAM pool.

Not a very common occurrence, you'd say, and you're right - especially considering that the HEPAX_8H module did not exist prior to yesterday... but here's another case: using multiple copies of the HEPAX_4H module on V41 allows you to have different sets of HEPRAM - one per copy -, so it is like having multiple units of physical HEPAX Modules. However on the 41X all of them share the same RAM resource, so they all will "show" the same contents.

But you can also EXPORT the Upper RAM ([shift] [SETUP] [2] [7]) to a file in the FAT, which can then be copied to PC, and the most recent version of Meindert's M2KM program will let you extract individual pages, which you could then copy into a new .mod file framework, effectively giving you an easy/poor mans method of authoring FOCAL modules. This has been tested and verified.

Indeed this is what SM came up with to address this scenario, effectively your HEPAX RAM content resides in "RAM" files instead of being part of the actual MOD file. Of course this imposes a restriction on the user, that of properly matching RAM and MOD files so their configuration settings are valid to access that content. So you'd better name those files with descriptive enough names!


PS. On the CL the HEPAX RAM pages are handled individually as standard ROM images, so you can use one HEPAX ROM to "manage" as many sets of HEPRAM pages as you can fit in the I/O bus. Better but more complicated to manage, specially because the FileSystem initialization process is disabled and the use needs to do it manually using dedicated functions available in the PowerCL Module. So it's a power user dream, of course

[MeinKuipers]

The contents of HEPRAM, just like any other upper RAM pages, do indeed remain intact when you remove the HEPAX module; this is described in the docs.If you plug in another module which allocates RAM pages, they will still have their prior contents, but AFAIK, modules doing so do initialize the RAM pages they use, typically with some form of proprietary file system.

But you can also EXPORT the Upper RAM ([shift] [SETUP] [2] [7]) to a file in the FAT, which can then be copied to PC, and the most recent version of Meindert's M2KM program will let you extract individual pages, which you could then copy into a new .mod file framework, effectively giving you an easy/poor mans method of authoring FOCAL modules. This has been tested and verified.

In theory this should also work to save a page of MCODE (allocated by HEPAX and then copied/edited as needed) however I don't believe this has been verified to date.

This is probably the easiest way to convert a single HEPRAM page into a standalone ROM with your own favourite collection of Focal programs. I am finishing the disassembler for HEPRAM pages (takes time, the devil is in the details) which gives insight in what is inside a HEPRAM module.

[Dave Britten]

This is probably the easiest way to convert a single HEPRAM page into a standalone ROM with your own favourite collection of Focal programs. I am finishing the disassembler for HEPRAM pages (takes time, the devil is in the details) which gives insight in what is inside a HEPRAM module.

Since you're here, where can I go to grab the newest version of M2KM? I've been meaning to tinker with converting RAM pages to ROMs.

[MeinKuipers]

This is probably the easiest way to convert a single HEPRAM page into a standalone ROM with your own favourite collection of Focal programs. I am finishing the disassembler for HEPRAM pages (takes time, the devil is in the details) which gives insight in what is inside a HEPRAM module.

Since you're here, where can I go to grab the newest version of M2KM? I've been meaning to tinker with converting RAM pages to ROMs.

Try this version, it it still much beta but should work with most features:
https://www.dropbox.com/sh/43e8wf0rt4e9 ... Fdf5a?dl=0

It is a version of M2kM without any code for interfacing with the MLDL2000, so no need to install any drivers. Documentation is *very* outdated

[Boub65]

Hello,
I am really new to Hepax, and trying to "ride" the (big) learning curve.

I have a "curiosity" question for the knowledgeable people here by a "neebie" :
how did Hepax manage to run programs in it's own memory, where HP41 failed to do so in it's extended memory (EM)? Is EM different? If so why did nobody write a "little" ROM (Let's call it EMPAX) just to add the Hepax ability to run programs in EM (memory that is readily available in HP41CX) ?
A kind of "HEPAX for the poor"! Was it because EM is very limited in size? So not worth the effort?

On DM41X, if we have this EMPAX rom allowing us to run programs in EM, then could there be a way of just increasing the EM memory with extra "4K banks"? Of course we would loose the backward compatibility with HP41, but who cares... it would greatly improve usability and simplicity of DM41X... Only EM instructions, only EM documentations, no weird memory Map, etc...

My point is that (the great) HEPAX was build like this because there was a hardware constraint a that time... in DM41X, there is no more Hardware constraints, can't the great DM41X community rethink from scratch some modules?

Other question for HEPAX and DM41X... If there was a way for DM41X to load directly RAW files from FAT to HEPAX, It would greatly simplify the usage...
because PC>Fat>Main Memory>Hepax RAM>CLP main memory is a quite heavy process! And each time you want to change something in your program, you have to do it the other way also...

Thanks,
Boubker.

[Dave Britten]

Hello,
I am really new to Hepax, and trying to "ride" the (big) learning curve.

I have a "curiosity" question for the knowledgeable people here by a "neebie" :
how did Hepax manage to run programs in it's own memory, where HP41 failed to do so in it's extended memory (EM)? Is EM different? If so why did nobody write a "little" ROM (Let's call it EMPAX) just to add the Hepax ability to run programs in EM (memory that is readily available in HP41CX) ?
A kind of "HEPAX for the poor"! Was it because EM is very limited in size? So not worth the effort?

HEPAX RAM appears to be located in the ROM address space, and structured in a way that looks just like ROM. (So 10-bit word size, if I'm not mistaken.) The X-MEM lives in a part of the address space that's meant for RAM, and has typical 8-bit words. In other words, the HEPAX RAM apparently looks like a normal module ROM as far as the 41 OS is concerned, whereas the calculator doesn't know what to do with X-MEM without the accompanying X-FUNC ROM.

I read an article somewhere - probably PPC Journal - that it's possible to get the 41 to execute programs directly from X-MEM via some synthetic tricks, though it required some care to do this. For one, you had to manually "compile" all the jumps in the program so that the offsets were stored in the jump instructions prior to saving the program in X-MEM. When the HEPAX ROM saves a program to its RAM, it compiles all the jumps for you, as evidenced by "COMPILING" appearing on the display briefly.

Try this version, it it still much beta but should work with most features:
https://www.dropbox.com/sh/43e8wf0rt4e9 ... Fdf5a?dl=0

It is a version of M2kM without any code for interfacing with the MLDL2000, so no need to install any drivers. Documentation is *very* outdated

Great, thanks! I'll play around with it a bit.