41CL Maximum registers for DATA/PROGS storage

[Podalirius]

Hi, I use a hp 50g with the HP-41X emulator by Hrast Programmer.
This emulator give me over 3000 registers: I use SIZE 900.
More of this I have installed the W&W RAMBOX emulation, that store
programs and permits to execute them from rambox page.
I don't understand from 41CL manuals if exits a possibility to store
programs in a page and execute from this page and if in 41CL
the rambox use hp 41 standard ports or pages.
Thank you very much!!!

[Sylvain Cote]

(07-19-2018 06:02 PM)Podalirius Wrote:  This emulator give me over 3000 registers: I use SIZE 900.

This is an extension specific to HP-41X emulator and thus not compatible with any 41C+Quad, CV, CX or CL.
The CL reimplement the Nut CPU and run the standard 41 OS code, so the maximum SIZE possible is 319.

(07-19-2018 06:02 PM)Podalirius Wrote:  More of this I have installed the W&W RAMBOX emulation, that store programs and permits to execute them from rambox page.
I don't understand from 41CL manuals if exits a possibility to store programs in a page and execute from this page and if in 41CL the rambox use hp 41 standard ports or pages.

Using the W&W RAMBOX in a 41CL is pretty straightforward, here is the step-by-step how-to.

Code:

command                     description

Setup MMU (this example cleanup the MMU to avoid any conflict)

Code:

MMUDIS                      disable MMU  
MMUCLR                      clear MMU configuration
"YFNX"                      41CL Extreme Functions ROM module name (XROM 15)
PLUG1L                      map module to page 8
"RM32"                      W&W RAMbox-32 ROM module name (XROM 31)
PLUG1U                      map module to page 9
"113>820"                   initialize RAM block (since we will be using XROM 27 for our module simulation, we need to choose a ROM with the same XROM ID to avoid any conflict)
YMCPY                       copy the EILP (XROM 27) module from Flash (0x113) to RAM (0x820) [for v2 board use address 0x016 instead of 0x113]
"820-RAM"                   4K RAM block at address 0x820 (XROM 27 will be used for this simulated module)
PLUG2L                      map RAM block to page 10
MMUEN                       enable MMU

Code:

CAT 2                       should display "-RAMBOX 32" then "-EXT IL+"

Setup simulated W&W RAMBox RAM at page 10

Code:

27                          module simulation XROM ID
10                          module simulation page address
"-WW RB PG10"               module simulation name (any name of 8 characters or more will do here)
INITPG                      module simulation initialization
FRBYT?                      module simulation free RAM space, should return 4044 words
CAT 2                       should display "-RAMBOX 32" then "-WW RB PG10"

Move the "MY-PROG" program from main memory to module simulation memory (replace "MY-PROG" for your own program name)

Code:

"MY-PROG"                   name of the program
LDPGM                       copy the program from main memory to module simulation memory
FRBYT?                      module simulation free RAM space, should return less than 4044 words
CAT 2                       press R/S when "-WW RB PG10" is displayed, then press ENTER, you should see "MY-PROG" displayed
CLP "MY-PROG"               clear the program from main memory
XEQ "MY-PROG"               execute the program from the module simulated memory

In this example I have only mapped 1 RAM page, but you can map more as needed into available pages like you would do with the physical W&W RAMBox unit.

Sylvain

edit 1: added "MY-PROG" section
edit 2: added a temporary module as a place holder prevent the 41CL to hang, thanks Patrik

[Sylvain Cote]

(07-20-2018 12:52 AM)Sylvain Cote Wrote:  

(07-19-2018 06:02 PM)Podalirius Wrote:  This emulator give me over 3000 registers: I use SIZE 900.

This is an extension specific to HP-41X emulator and thus not compatible with any 41C+Quad, CV, CX or CL.
The CL reimplement the Nut CPU and run the standard 41 OS code, so the maximum SIZE possible is 319.

I knew Àngel had created a 41CL specific module that was bypassing this limit, but I had to find it before posting the answer.
The is module called CL XPMEM (manual) and allow you to have up to 1024 expanded data registers.

[Podalirius]

Hi, Thank you very much for help!
I readed Cl XPMEM manual: seems that the commands for use of the additional 1024 registers are more byte consuming.
Again Thank you so much!!

[CY-CL]

[/quote]
Using the W&W RAMBOX in a 41CL is pretty straightforward, here is the step-by-step how-to.

Code:

command                     description

Setup MMU (this example cleanup the MMU to avoid any conflict)

Code:

MMUDIS                      disable MMU  
MMUCLR                      clear MMU configuration
"YFNX"                      41CL Extreme Functions ROM module name (XROM 15)
PLUG1L                      map module to page 8
"RM32"                      W&W RAMbox-32 ROM module name (XROM 31)
PLUG1U                      map module to page 9
"820-RAM"                   4K RAM block at address 820000 (XROM 27 will be used for this simulated module)
PLUG2L                      map RAM block to page 10
MMUEN                       enable MMU

Hi Sylvain

With this setup after MMUEN the CL hangs!

Regards,
Patrik

[CY-CL]

The problem is, the RAM-820 has no content. When you copy a WW Container to the RAM Page 820, your setup works! Then you can change the name by INITPG, how you described it in your 2nd step “Setup simulated W&W RAMBox RAM at page 10”.

Thanks
Patrik

[Sylvain Cote]

(07-20-2018 07:25 AM)CY-CL Wrote:  With this setup after MMUEN the CL hangs!

(07-20-2018 07:36 AM)CY-CL Wrote:  The problem is, the RAM-820 has no content. When you copy a WW Container to the RAM Page 820, your setup works! Then you can change the name by INITPG, how you described it in your 2nd step “Setup simulated W&W RAMBox RAM at page 10”.

Hello Patrik,

You are right, I forgot to clear up the RAM page before activating it, sorry about that.
Unfortunately there is no RAM clear in the YFNZ module and YMCLR from YFNX will initialize it with FFF which is not good for us, I will need to do more searching for the real solution.
In the mean time I will modify the instructions to copy a module into the targeted RAM area as a place holder, that will allow us to activate the MMU and not crashing, then the INITPG will reformat it correctly.

Sylvain

[CY-CL]

Thanks Sylvain

Your information about the RAMBOX was very helpfully for me, I was not aware that I can set an XROM number for a PRGM-STORE with INITPG.

I have now an easy setup after a complete MEMORY LOST. I connect over the PIL Box to an IL-Drive and load an Autorun/Program.

After 2 minutes my CL is configured as OSX3 with WARP, RAMBOX etc… and all RAM Pages are filled up with the PRGM-STORE’s.

I made some tests to store a RAM Page on a Flash Sector, but when I copy the Flash Sector back to a RAM Page, something goes wrong. The content is complete damaged and useless.

Backup:

"1FE000"
YFERASE
YFWR "830>1FE"

Restore:

"1FE>830"
YMCPY

Any idea what goes wrong? I use "YFNX"

Thanks
Patrik

[Sylvain Cote]

Patrik,

(07-20-2018 11:39 AM)CY-CL Wrote:  Your information about the RAMBOX was very helpfully for me, I was not aware that I can set an XROM number for a PRGM-STORE with INITPG.
I have now an easy setup after a complete MEMORY LOST. I connect over the PIL Box to an IL-Drive and load an Autorun/Program.
After 2 minutes my CL is configured as OSX3 with WARP, RAMBOX etc… and all RAM Pages are filled up with the PRGM-STORE’s.

Great!

(07-20-2018 11:39 AM)CY-CL Wrote:  I made some tests to store a RAM Page on a Flash Sector, but when I copy the Flash Sector back to a RAM Page, something goes wrong. The content is complete damaged and useless.

Flash does not work like RAM, I am at the office right now and cannot give you the exact procedure but here is the pseudo code that you need to do.

1. copy Flash sector (64K) into 8 continuous RAM pages (ex.: 0x810..0x817)
2. update RAM pages (4K) that need to be updated (ex.: within 0x810..0x817)
3. erase Flash sector (64K)
4. copy back the 8 continuous RAM pages (ex.: 0x810..0x817) into the newly erased Flash sector (64K)
   

Sylvain

[Sylvain Cote]

Patrik,
Have you looked at the HePaX module ?
Even though the RAMBox was a great piece of hardware in its time and can be emulated today on the 41CL, the introduction of the HePaX module basically obsoleted it.
The HePaX module is more powerful, more flexible than the RAMBox and is emulated on the 41CL.
Regards,
Sylvain

[CY-CL]

Quote:Flash does not work like RAM, I am at the office right now and cannot give you the exact procedure but here is the pseudo code that you need to do.

It is not urgent, when you can provide me later an example, how exactly copy Flash to RAM, it would be great.

[CY-CL]

(07-20-2018 12:49 PM)Sylvain Cote Wrote:  Patrik,
Have you looked at the HePaX module ?
Even though the RAMBox was a great piece of hardware in its time and can be emulated today on the 41CL, the introduction of the HePaX module basically obsoleted it.
The HePaX module is more powerful, more flexible than the RAMBox and is emulated on the 41CL.
Regards,
Sylvain

I played one year ago a little bit with HEPAX, unfortunately I lost the focus. I have read in several posts here in the forum, most people use HEPAX.

In the CL manual is a good example how to setup HEPAX. I will try it in the next days. Many thanks for your impulse.

Regards,
Patrik

[Sylvain Cote]

(07-20-2018 01:26 PM)CY-CL Wrote:  

Quote:Flash does not work like RAM, I am at the office right now and cannot give you the exact procedure but here is the pseudo code that you need to do.

It is not urgent, when you can provide me later an example, how exactly copy Flash to RAM, it would be great.

There are several ways to do it.

The easiest way is to use the 41CL Update Function module (YUPS), but unfortunately it has the same XROM ID (31) as the RAMBox ROM.
A way to solve this, is to map the YUPS ROM at the same page as the RM32 ROM.
I will assume the following ...

• MMU is enabled
• YFNX is mapped somewhere
• RM32 is mapped at page 9
• WW Container is mapped somewhere
• WW Container is at RAM address 830 (based on your previous message)
• you want to save the WW Container to Flash address 1FE (based on your previous message)
  

Note: if you have a v5 board, I would suggest to use one of the unused top Flash sector (ex: 3F0 or 3F8)

The update procedure ...

Code:

command                     description

Code:

"YUPS 9"                    deactivate RAMBox ROM and activate 41CL Update Function ROM
PPLUG                       activate mapping
"1F8"                       1FE is part of Flash sector 1F8..1FF, so we need to specify the start address 1F8
P8BFR                       copy flash sector (1F8..1FF) to RAM buffer (810..817)
"830>816"                   copy content of RAM 830 to RAM 816 who will be copied to 1FE later on
PGCPY                       do RAM to RAM page copy
"1F8"                       flash sector start address to erase
P8ERASE                     erase flash sector

Code:

"1F8"                       destination flash sector start address
P8UPD                       copy RAM buffer (810..817) to flash sector (1F8..1FF)
"RM32 9"                    deactivate 41CL Update Function ROM and activate RAMBox ROM
PPLUG                       activate mapping

Regards,

Sylvain

[CY-CL]

Many thanks Sylvain

I understand now, how to copy the RAM correctly to a Flash sector.

How is to setup the restore to a RAM page. Can I copy the Flash start address direct to the RAM page, or to the RAM buffer?

Yesterday, I once again configured HEPAX RAM. This RAM is complete different to the “Pages” in a Rambox, like a HDRIVE on a Mass Storage. Thanks again for your input.

Kind regards,
Patrik

[Sylvain Cote]

Patrik,

(07-21-2018 08:26 AM)CY-CL Wrote:  I understand now, how to copy the RAM correctly to a Flash sector.

Perfect!

(07-21-2018 08:26 AM)CY-CL Wrote:  How is to setup the restore to a RAM page. Can I copy the Flash start address direct to the RAM page, or to the RAM buffer?

This one is the easiest

I will assume the following ...

• MMU is enabled
• YFNX is mapped somewhere
• RM32 is mapped at page 9
• WW Container will be mapped to page 10
• active WW Container will be at RAM address 830 (based on your previous message)
• saved WW Container is at Flash address 1FE (based on your previous message)
  

The update procedure ...

Code:

command                     description

Code:

"EMPT A"                    remove whatever is at page 10 (assumed WW Container)
PPLUG                       unmap page 10
"1FE>830"                   saved WW Container address in Flash and destination WW Container address in RAM
YMCPY                       copy WW Container from Flash to RAM
"-830 A"                    WW Container address in RAM and where to mapped it
PPLUG                       do the mapping

(07-21-2018 08:26 AM)CY-CL Wrote:  Yesterday, I once again configured HEPAX RAM. This RAM is complete different to the “Pages” in a Rambox, like a HDRIVE on a Mass Storage.

Yep! Have fun ...

(07-21-2018 08:26 AM)CY-CL Wrote:  Thanks again for your input.

My pleasure.

Best regards,

Sylvain

[CY-CL]

Hello Sylvain

Anything runs very well. I have now written a Flash Backup and Restore program from my RAMBOX containers.

Thanks again for you’re very helpfully inputs.

Kind regards,
Patrik

[Sylvain Cote]

Hello Patrik,

(07-22-2018 11:02 AM)CY-CL Wrote:  Anything runs very well. I have now written a Flash Backup and Restore program from my RAMBOX containers.

This is great!

Make sure the restore program is not running from the RAMBOX container being restored, because it could create some serious misbehaviour.
If that's the case, I would suggest to do the following procedure:

1. copy the restore program from the mapped container to the main RAM using the COPY function
2. run the restore program from main RAM
3. delete the restore program from main RAM
   

Best regards,

Sylvain

[CY-CL]

Thanks Sylvain

In my restore program I implemented an easy security feature. In the first program steps I unplug all RAMBOX containers. If I run the program from the container, it will be interrupted automatically.

Best regards,
Patrik

[Ángel Martin]

(07-20-2018 06:22 AM)Podalirius Wrote:  I readed Cl XPMEM manual: seems that the commands for use of the additional 1024 registers are more byte consuming.

Looks like this thread is more about the RAMBOX but just for completion sake - yes, using the Expanded register functions (YSTO, YRCL, etc...) has a more demanding byte consumption. However you have more standard memory for your program code - since no standard DATA registers are needed.

[Gene]

...and since a very likely use of the Y-registers is by way of indirect addressing, the byte usage probably will not be as high as the savings in regular data registers would use.

Tough to do a determinant of a 20x20 matrix any other way. :-)