Saving the state of HP41 CL to PC

[PeterP]

Hi, I am wondering if there is a good way to save the state of the HP-41CL to PC.

I've got a nice set-up with YFNX, POWERCL_EXT, XPMM, AMC/OSX, Lib#4, Hepax + 4k RAM, plus a couple programs and key assignments. I've used the Expanded Memory functions from Angel and Monte to store the CL configuration into section 2, as well as the MM & XM into block 2.

As long as I have only "minor" hang ups, I can always regain my state by doing a "memory Lost", disable MMU, loading YFNX, enable MMU, RCLCFG 2, YBK-MM 2, YBK-XM 2. It still takes a number of keystrokes though.

However, even worse, if my calc hangs up and I need to take out the batteries, it seems save to do a XEQ "MMUDIS", XEQ "MMUCLR" after getting to "Memory Lost".

At this point it is my understanding that both the CL configuration as well as the MM & XM area is deleted and can not be recovered via RCLCFG and YBK-??. Please do correct me if this is not true.

Is there an easy way to save the state of the calculator (MM, XM, Loaded modules) to the PC and then load again from PC? Ideally this can be done with the YFNZ only.

Thanks for everyone's help!

[Monte Dalrymple]

(12-27-2017 11:30 PM)PeterP Wrote:  Hi, I am wondering if there is a good way to save the state of the HP-41CL to PC.

I've got a nice set-up with YFNX, POWERCL_EXT, XPMM, AMC/OSX, Lib#4, Hepax + 4k RAM, plus a couple programs and key assignments. I've used the Expanded Memory functions from Angel and Monte to store the CL configuration into section 2, as well as the MM & XM into block 2.

As long as I have only "minor" hang ups, I can always regain my state by doing a "memory Lost", disable MMU, loading YFNX, enable MMU, RCLCFG 2, YBK-MM 2, YBK-XM 2. It still takes a number of keystrokes though.

However, even worse, if my calc hangs up and I need to take out the batteries, it seems save to do a XEQ "MMUDIS", XEQ "MMUCLR" after getting to "Memory Lost".

At this point it is my understanding that both the CL configuration as well as the MM & XM area is deleted and can not be recovered via RCLCFG and YBK-??. Please do correct me if this is not true.

Is there an easy way to save the state of the calculator (MM, XM, Loaded modules) to the PC and then load again from PC? Ideally this can be done with the YFNZ only.

Thanks for everyone's help!

If you look at the later sections of the mem_ref.pdf: http://systemyde.com/pdf/mem_ref.pdf you'll see that all of the calculator state
is stored in the lower pages of RAM.

Page 0x800 is the main calc configuration: registers, program memory, X-memory
Pages 0x801-0x803 are the alternate configurations.
Page 804 is the MMU

So, the user-visible 41C state is all in one RAM page, at 0x800, so that's what
you need to save. YEXP works with RAM.

Monte

[hth]

If you feel like using HP-IL, you can use the CLILUP module and save it up to a drive.

To save page 800, put the filename in Alpha register, 800 in X and then XEQ WRROM16.

Håkan

[PeterP]

(12-28-2017 12:13 AM)Monte Dalrymple Wrote:  

(12-27-2017 11:30 PM)PeterP Wrote:  Hi, I am wondering if there is a good way to save the state of the HP-41CL to PC.

I've got a nice set-up with YFNX, POWERCL_EXT, XPMM, AMC/OSX, Lib#4, Hepax + 4k RAM, plus a couple programs and key assignments. I've used the Expanded Memory functions from Angel and Monte to store the CL configuration into section 2, as well as the MM & XM into block 2.

As long as I have only "minor" hang ups, I can always regain my state by doing a "memory Lost", disable MMU, loading YFNX, enable MMU, RCLCFG 2, YBK-MM 2, YBK-XM 2. It still takes a number of keystrokes though.

However, even worse, if my calc hangs up and I need to take out the batteries, it seems save to do a XEQ "MMUDIS", XEQ "MMUCLR" after getting to "Memory Lost".

At this point it is my understanding that both the CL configuration as well as the MM & XM area is deleted and can not be recovered via RCLCFG and YBK-??. Please do correct me if this is not true.

Is there an easy way to save the state of the calculator (MM, XM, Loaded modules) to the PC and then load again from PC? Ideally this can be done with the YFNZ only.

Thanks for everyone's help!

If you look at the later sections of the mem_ref.pdf: http://systemyde.com/pdf/mem_ref.pdf you'll see that all of the calculator state
is stored in the lower pages of RAM.

Page 0x800 is the main calc configuration: registers, program memory, X-memory
Pages 0x801-0x803 are the alternate configurations.
Page 804 is the MMU

So, the user-visible 41C state is all in one RAM page, at 0x800, so that's what
you need to save. YEXP works with RAM.

Monte

Thanks Monte! This is super helpful. [deletedTwo] Four quick questions:

1. Which events/functions clear the RAM page at 0x800?
2. Do I need to save the page 804 as well or does page 800 include all the modules loaded correctly when saved?
3. The XPMM module from Angel provides the functions "YWALL" / "YRALL" to store everything into Flash 0x1FE and 0x1FF. While certainly not as easy to use as it requires Lib#4 and OSX and XPMM, I wanted to know if there are any other risks/objections to using this function?
4. If these functions are not objectionable, would it be possible to add them to the YFNZ module so that one always has the ability to restore to a nice state from a ML condition and batteries out?
   

Thank you for your kind help!

[PeterP]

(12-28-2017 03:23 AM)hth Wrote:  If you feel like using HP-IL, you can use the CLILUP module and save it up to a drive.

To save page 800, put the filename in Alpha register, 800 in X and then XEQ WRROM16.

Håkan

Dear Håkan, super helpful!

I'm currently using page 7 but this could be a cool solution. Keep the configuration on my RAM-Drive and when in need, plug in the HP-IL and restore. I'll be next studying the CLILUP manual to see how to best restore the page again. Of course, an advanced version would be to have the 41CL connected to the PC via PIL box as well as the serial cable :-)

Thanks again (and thanks for writing the module!)

[hth]

There is no manual for that CLILUP module yet... hmmm some day, it was a quick thing I made for Geir.

To restore, filename in Alpha, 800 in X, XEQ RDROM16.

Those RDROM16 and WRROM16 routines are fairly easy to use. The issue is to connect the HP-IL module without getting bus conflicts and to get the CLILUP module into the memory map. Well, it is always good with alternatives...

Håkan

[PeterP]

(12-28-2017 04:06 AM)hth Wrote:  There is no manual for that CLILUP module yet... hmmm some day, it was a quick thing I made for Geir.

To restore, filename in Alpha, 800 in X, XEQ RDROM16.

Those RDROM16 and WRROM16 routines are fairly easy to use. The issue is to connect the HP-IL module without getting bus conflicts and to get the CLILUP module into the memory map. Well, it is always good with alternatives...

Håkan

There is a manual - you just provided it! Thank you. Indeed, its always good to have options.

[rprosperi]

(12-28-2017 03:23 AM)hth Wrote:  If you feel like using HP-IL, you can use the CLILUP module and save it up to a drive.

To save page 800, put the filename in Alpha register, 800 in X and then XEQ WRROM16.

Håkan

Håkan - I have located the CLILUP ROM image in the git pkg. that Geir listed, but could not find any docs for it. Have you published docs for the commands in this ROM, and if so, could you share it?

Also, can your CLILUP ROM image be included in the CL ROM library?

Thanks and Happy New Year!

[hth]

(12-28-2017 04:08 AM)PeterP Wrote:  

(12-28-2017 04:06 AM)hth Wrote:  There is no manual for that CLILUP module yet... hmmm some day, it was a quick thing I made for Geir.

To restore, filename in Alpha, 800 in X, XEQ RDROM16.

Those RDROM16 and WRROM16 routines are fairly easy to use. The issue is to connect the HP-IL module without getting bus conflicts and to get the CLILUP module into the memory map. Well, it is always good with alternatives...

Håkan

There is a manual - you just provided it! Thank you. Indeed, its always good to have options.

After having a look at it, it seems the instruction above will not work. The reason is that RDROM16 prevents you from loading to page 800 as it is deemed dangerous. Instead you need to load it to another RAM page (807 or above), then move it into 800.

Håkan

[hth]

(12-28-2017 04:14 AM)rprosperi Wrote:  Håkan - I have located the CLILUP ROM image in the git pkg. that Geir listed, but could not find any docs for it. Have you published docs for the commands in this ROM, and if so, could you share it?

Also, can your CLILUP ROM image be included in the CL ROM library?

Thanks and Happy New Year!

I have now put the source code on github. There is a README file which gives some background and instructions on how to use the module. You will find it at https://github.com/hth313/CLILUP

Anyone who knows how to get it into the CL ROM library have my blessings to do so.

Håkan

[Ángel Martin]

(12-28-2017 03:46 AM)PeterP Wrote:  Thanks Monte! This is super helpful. [deletedTwo] Four quick questions:

1. Which events/functions clear the RAM page at 0x800?
2. Do I need to save the page 804 as well or does page 800 include all the modules loaded correctly when saved?
3. The XPMM module from Angel provides the functions "YWALL" / "YRALL" to store everything into Flash 0x1FE and 0x1FF. While certainly not as easy to use as it requires Lib#4 and OSX and XPMM, I wanted to know if there are any other risks/objections to using this function?
4. If these functions are not objectionable, would it be possible to add them to the YFNZ module so that one always has the ability to restore to a nice state from a ML condition and batteries out?
   

Thank you for your kind help!

YWALL and YRALL are also in the PowerCL_Extreme, and except the Library#4, they don't have any additional dependency but the YFNX itself. They are short FOCAL programs BTW, see the listing below:

Code:

1    LBL "YWALL"
2    "1FE000"
3    AVIEW
4    FC? 49
5    YFERASE
6    "800>1FE"
7    AVIEW
8    YFWR
9    FC? 01
10    GTO 02
11    "1FF000"
12    FC? 49
13    YFERASE
14    "804>1FF"
15    YFWR
16    GTO 02
17    LBL "YRALL"
18    "1FE>800"
19    AVIEW
20    YMCPY
21    "1FF>804"
22    AVIEW
23    FS? 01
24    YMCPY
25    LBL 02
26    "DONE"
27    END

They use FLASH blocks at 0x1FE and 0x1FF for a back-up of the bottom RAM pages 0x800 and 0x804 respectively. As far as I know those locations are still available in the "official" CL flash map.

The main restriction is that they assume the top flash sector (from 0x1F8 to 0x1FF) is eraseable by 4k blocks, and not as a complete sector like all others. I understand this has had some variations in the different versions of the CL boards, so you'll need to make sure this is the case in yours. The functions assume versions V3 or V4 by default.

The FLASH? function in the YUPS module tells you which type of CL board you have as to that behavior, see the CL Update Functions manual, pages 15 & 16.

User Flag 01 is used to control whether to include block 804 in the backup: FI Set includes it, F1 Clear excludes it. This is where the MMU "meta-data" and other CL-configuration details are included, I always include it.

As always, make sure your batteries are fresh before you write to flash!

Cheers,
ÁM

[mfleming]

(12-28-2017 06:44 AM)hth Wrote:  I have now put the source code on github. There is a README file which gives some background and instructions on how to use the module. You will find it at https://github.com/hth313/CLILUP

Hello Håkan,
Thanks for the very useful set of utility functions! I was curious about the files in the repository, a mix of FOCAL and MCODE that are compiled, assembled and linked to produce a MOD file. A search on some keywords seems to point to a toolset you authored, NutStudio. I can only find defunct links to code.google.com for the sources. Any chance of making that available again, or pointing out where it can be found?

Thanks,
~Mark

[PeterP]

Angel, sorry to bother you but I'd love to get some user advice if at all possible. I have a V5 board, loading Lib4 into page 4, YFNX into page 7, and PWRX into page 8. I then perform this sequence:

Quote:Enter in programs, make assignments, save to XM
Enter "OKALL" into Alpha
SF 1
XEQ "YWALL"

The first thing I notice here is that the display does not show 1FF but only 800>1FE. So I must be doing something wrong as it seems to only save the MM state of the machine. Any tips?

Second, when I want to retrieve the state, I do

Quote:Enter "OKALL" into Alpha
SF 1
XEQ "YRALL"

Again, the program only shows '1FE' but not '1FF' which at this point is expected. However all I get is a "Memory Lost" with no content in my memory.

Please tell me what I am doing wroing.

[rprosperi]

(12-29-2017 02:33 AM)PeterP Wrote:  Angel, sorry to bother you but I'd love to get some user advice if at all possible. I have a V5 board, loading Lib4 into page 4, YFNX into page 7, and PWRX into page 8. I then perform this sequence:

Quote:Enter in programs, make assignments, save to XM
Enter "OKALL" into Alpha
SF 1
XEQ "YWALL"

The first thing I notice here is that the display does not show 1FF but only 800>1FE. So I must be doing something wrong as it seems to only save the MM state of the machine. Any tips?

Second, when I want to retrieve the state, I do

Quote:Enter "OKALL" into Alpha
SF 1
XEQ "YRALL"

Again, the program only shows '1FE' but not '1FF' which at this point is expected. However all I get is a "Memory Lost" with no content in my memory.

Please tell me what I am doing wroing.

@PeterP - Check the manual on pp. 55-56. While it says that it requires a V3/V4 board, I'm not sure if V5 is compatible as well (it did not exist when the manual was released).

1FE is the Flash Page that RAM page 800 is written-to, likewise with RAM page 804 written to 1FF. The FOCAL code on p. 56 shows this.

[Ángel Martin]

The PWRX has a simplified version of the code listed in the manual, pls. refer to the previous posting in this thread. The display is showing the right information: from RAM block > to Flash Block for the YWALL case, and from Flash block > to RAM block in YRALL case.

With F01 set the 804 RAM block should also be included, which you're reporting it's not the case. That's definitely fishy.

I don't know if on V5 boards the "1F8" sector is erased by individual blocks or as a whole. As I mentioned in the previous post, the program assumes the sector is erasable by blocks, and that's why the code has two YFERASE instructions - one for the 1FE block and another for the 1FF block.

If on V5 boards the 1F8 sector erases as a whole then two things will happen:
1. the contents of blocks 1F8 to 1FD will be lost.
2. the second YFERASE will also wipe out the previous writing of RAM 800 to flash 1FE.

Hope this clarifies...

[PeterP]

(12-29-2017 10:07 AM)Geir Isene Wrote:  Peter,

Here's how I do it:

Regularily backup pages 0x800 [RAM] (to 0x1FE) and 0x804 [MMU] (to 0x1FF) to flash.

Then, semi-regularly backup those flash pages to PC via HP-IL using the CLILUP module.

See my full backup/restore system here: https://github.com/isene/hp-41_CL

And of course the HP-IL update system here: https://github.com/isene/hp-41cl_update

Thanks @Geir for this link, I'll enter the program later today and will report back. Appreciate you sharing it!

Waiting for @Monte to tell us about the V5 board behavior regarding sector 1F8 as per @Angel's comment. I was naively assuming upward compatibility (what works on V3 works on V5) which shows my ignorance when it comes to hardware. He probably also put it in the manual and I just cant find it / understand it...

[Sylvain Cote]

(12-29-2017 06:11 PM)PeterP Wrote:  Waiting for @Monte to tell us about the V5 board behavior regarding sector 1F8 as per @Angel's comment.
I was naively assuming upward compatibility (what works on V3 works on V5) which shows my ignorance when it comes to hardware. He probably also put it in the manual and I just cant find it / understand it...

After verification, 0x1FE & 0x1FF are still available for v3, v4 & v5.

Use the FLASH? function from the YUPS module to find what type of board you have.
Look at page 16 of the clupdate.pdf manual for board description.

If you have a v3/v4 board type 0x2257 or a v5 board, you need to do the following
1) copy Flash:0x1F8..0x1FF sector to RAM:0x810..0x817
2) copy RAM:0x800 to RAM:0x816
3) copy RAM:0x804 to RAM:0x817
4) erase the Flash:0x1F8..0x1FF sector
5) copy RAM:0x810..0x817 to Flash:0x1F8..0x1FF

If you have a v3/v4 board type 0x2256 then its simpler, you need to do the following
1) erase the Flash:0x1FE sector
2) copy RAM:0x800 to Flash:0x1FE
3) erase the Flash:0x1FF sector
4) copy RAM:0x804 to Flash:0x1FF

Best regards,

Sylvain

PS: I have not forgotten to reply to your last email, just missing time.

[PeterP]

(12-29-2017 09:55 PM)Geir Isene Wrote:  

(12-29-2017 06:11 PM)PeterP Wrote:  Thanks @Geir for this link, I'll enter the program later today and will report back. Appreciate you sharing it!

Waiting for @Monte to tell us about the V5 board behavior regarding sector 1F8 as per @Angel's comment. I was naively assuming upward compatibility (what works on V3 works on V5) which shows my ignorance when it comes to hardware. He probably also put it in the manual and I just cant find it / understand it...

I just did some last minute updates to my BACKUP/RESTORE system.

Great, thank you! Should come in handy as I try to figure out this COGO41 module...

[Monte Dalrymple]

(12-28-2017 03:46 AM)PeterP Wrote:  [*]Which events/functions clear the RAM page at 0x800?
[*]Do I need to save the page 804 as well or does page 800 include all the modules loaded correctly when saved?
[*]The XPMM module from Angel provides the functions "YWALL" / "YRALL" to store everything into Flash 0x1FE and 0x1FF. While certainly not as easy to use as it requires Lib#4 and OSX and XPMM, I wanted to know if there are any other risks/objections to using this function?
[*]If these functions are not objectionable, would it be possible to add them to the YFNZ module so that one always has the ability to restore to a nice state from a ML condition and batteries out?
[/list]

Thank you for your kind help!

I think that MEMORY LOST clears some 41C register information, but I've never
traced that sequence.

Saving page 804 will preserve the MMU programming.

Not all Flash devices have the segmented top block that make the YWALL easy to
use. If the top block is not segmented you'll end up erasing the entire block (pages
1F8 through 1FF). In addition, depending on the sequence, you may end up
inadvertently erasing 1FE when you attempt to write 1FF.

There is no room in YFNZ.

[Monte Dalrymple]

(12-29-2017 06:11 PM)PeterP Wrote:  Waiting for @Monte to tell us about the V5 board behavior regarding sector 1F8 as per @Angel's comment. I was naively assuming upward compatibility (what works on V3 works on V5) which shows my ignorance when it comes to hardware. He probably also put it in the manual and I just cant find it / understand it...

The memory organization is explained in the Update Functions Manual. But
the top block is different with different Flash sizes. Plus, not all Flash devices
segment the top block. My original intent was to only use bottom-block
segmented devices, because that is where the OS resides, and would make
updating the OS a little more safe. But availability issues forced me to use
whatever was available when I had a batch fabricated. So some batches
had the bottom block segmented and some had the top block segmented.

So, to answer your question, on a V5 board the 1F8 segment is just another
block of Flash. I think that the best solution to this backup issue would be
to allow the functions specify which Flash pages to use, rather than picking
a specific page.