41CL MMU Backup
05-28-2020, 10:15 PM
Post: #1
 twoweims Member Posts: 265 Joined: Apr 2019
41CL MMU Backup
What is the proper way to backup and restore the MMU Configuration (Page 804)
to / from Flash Memory.

If I write YFWR page 804 to page 3F1 I can see that the CRC of page 3F1 is getting changed. The 41CL Manual seems to be silent on the procedure for restoring page 804. I tried MMUDIS, MMUCLR, then YMCPY with 3F1>804 in ALPHA. When I enable MMU the calculator locks up with a constant tone until I remove the batteries.

I am obviously missing some important step.
I would appreciate any advice on this and also to learn some backup strategies/best practices from fellow CL users.
05-29-2020, 04:07 PM
Post: #2
 Monte Dalrymple Member Posts: 275 Joined: Jan 2014
RE: 41CL MMU Backup
(05-28-2020 10:15 PM)twoweims Wrote:  What is the proper way to backup and restore the MMU Configuration (Page 804)
to / from Flash Memory.

If I write YFWR page 804 to page 3F1 I can see that the CRC of page 3F1 is getting changed. The 41CL Manual seems to be silent on the procedure for restoring page 804. I tried MMUDIS, MMUCLR, then YMCPY with 3F1>804 in ALPHA. When I enable MMU the calculator locks up with a constant tone until I remove the batteries.

I am obviously missing some important step.
I would appreciate any advice on this and also to learn some backup strategies/best practices from fellow CL users.

Was the Flash at 0x3f1 empty before you wrote to it? What was the configuration you had previously stored at 0x3f1? There are locations in Page 804 that are used for internal stuff by YFNX and YUPS, and you are actually executing code transiently stored in this area when doing Flash operations. But that shouldn't matter when doing YMCPY. I'll try to duplicate what you are doing in the next couple of days and let you know.
05-29-2020, 04:44 PM
Post: #3
 twoweims Member Posts: 265 Joined: Apr 2019
RE: 41CL MMU Backup
(05-29-2020 04:07 PM)Monte Dalrymple Wrote:  Was the Flash at 0x3f1 empty before you wrote to it? What was the configuration you had previously stored at 0x3f1? There are locations in Page 804 that are used for internal stuff by YFNX and YUPS, and you are actually executing code transiently stored in this area when doing Flash operations. But that shouldn't matter when doing YMCPY. I'll try to duplicate what you are doing in the next couple of days and let you know.

Hello Monte, Thank you for responding.
I am not sure that I am even following a proper procedure for backing up.
My understanding is that to back up the entire state of the calculator so that I can recover from an extended period of battery removal that I should save copies of both page 800 and 804 to flash. We can assume I have nothing in pages 801, 802, and 803 for now. Is that a correct assumption?

is
Code:
    [ALPHA] 800>3F0 [ALPHA]     [XEQ]  [ALPHA]  YFWR  [ALPHA]                 [ALPHA] 804>3F1 [ALPHA]     [XEQ]  [ALPHA]  YFWR  [ALPHA]

the proper way to perform this backup?

I did verify that Pages 3F0 and 3F1 showed YCRC value of 53D36BD2 before starting.
Afterward the YCRC values had changed, which indicated to me that I had written something to those locations.

I then removed the batteries for about 1/2 hour and have tried to figure out a procedure to restore from these backups. Is YMCPY the proper way to do it?

I am surely missing a key step in the process and appreciate your assistance.
05-29-2020, 05:49 PM
Post: #4
 Monte Dalrymple Member Posts: 275 Joined: Jan 2014
RE: 41CL MMU Backup
(05-29-2020 04:44 PM)twoweims Wrote:
(05-29-2020 04:07 PM)Monte Dalrymple Wrote:  Was the Flash at 0x3f1 empty before you wrote to it? What was the configuration you had previously stored at 0x3f1? There are locations in Page 804 that are used for internal stuff by YFNX and YUPS, and you are actually executing code transiently stored in this area when doing Flash operations. But that shouldn't matter when doing YMCPY. I'll try to duplicate what you are doing in the next couple of days and let you know.

Hello Monte, Thank you for responding.
I am not sure that I am even following a proper procedure for backing up.
My understanding is that to back up the entire state of the calculator so that I can recover from an extended period of battery removal that I should save copies of both page 800 and 804 to flash. We can assume I have nothing in pages 801, 802, and 803 for now. Is that a correct assumption?

is
Code:
    [ALPHA] 800>3F0 [ALPHA]     [XEQ]  [ALPHA]  YFWR  [ALPHA]                 [ALPHA] 804>3F1 [ALPHA]     [XEQ]  [ALPHA]  YFWR  [ALPHA]

the proper way to perform this backup?

I did verify that Pages 3F0 and 3F1 showed YCRC value of 53D36BD2 before starting.
Afterward the YCRC values had changed, which indicated to me that I had written something to those locations.

I then removed the batteries for about 1/2 hour and have tried to figure out a procedure to restore from these backups. Is YMCPY the proper way to do it?

I am surely missing a key step in the process and appreciate your assistance.

No, you are doing everything correctly.

I have just investigated this and found the problem. It is somewhat complicated, but related to what I alluded to in my first reply.

During a Flash write code must be executed out of RAM because the Flash can't interleave reads (of instructions) and writes (of data) at the same time. So the YFWR function (among others) first copies a small section of itself to RAM and then reprograms the MMU for Page 4 to point at this code. It then jumps into this code in page 4 to do the actual Flash write. Once done, the code returns to executing out of Flash in the YFWR code and restores the MMU programming to what it was before. You probably see the problem: the Flash write captures the transient MMU programming for Page 4 that was used during YFWR. When this programming is restored via YMCPY the MMU points to RAM for Page 4, and everything is messed up.

This is one of the reasons that a dedicated backup ROM might be useful. This special circumstance could be handled transparently. The backup code could also tag backups with date/time and source information, etc. But I digress...

There is a way to fix the problem in the backup in Flash, but you will lose the previous Page 4 programming for the MMU. Unlike the YPOKE function in YFNZ or YFNX, the YPOKE+ function in the 41CL Memory Functions allows you to poke directly into Flash. Or, you can YPOKE directly into the MMU registers after you do the restore, but BEFORE you enable the MMU.

If you do "804040-0000" YPOKE before you enable the MMU you will clear out the incorrect MMU programming for Page 4 and should be good to go. I just tried it and it works.

Monte
05-29-2020, 08:50 PM
Post: #5
 twoweims Member Posts: 265 Joined: Apr 2019
RE: 41CL MMU Backup
Here is my revised procedure. It still leaves me with a locked calculator after MMUEN:

Code:
Save Configuration to Flash Memory         [ALPHA] 800>3F0 [ALPHA]              Copy page 800 (Main Memory)         [XEQ]  [ALPHA]  YFWR  [ALPHA]        to page 3F0                                                           [ALPHA] 804>3F1 [ALPHA]             Copy page 804 (MMU Config)         [XEQ]  [ALPHA]  YFWR  [ALPHA]       to page 3F1                                               Restore Configuration from Flash Memory         [ALPHA] 3F1>804 [ALPHA]            Copy page 341 (MMU Config)         [XEQ]  [ALPHA]  YMCPY  [ALPHA]    back to page 804.         [ALPHA] 804040-0000 [ALPHA]                 [XEQ]  [ALPHA]  YPOKE  [ALPHA]               [ALPHA] 3F0>800 [ALPHA]               Copy page 3F0 (Main Memory)          [XEQ]  [ALPHA]  YMCPY  [ALPHA]    back to page 800.                                               [XEQ]  [ALPHA]  MMUEN  [ALPHA]        Enable the MMU
05-29-2020, 10:09 PM
Post: #6
 Monte Dalrymple Member Posts: 275 Joined: Jan 2014
RE: 41CL MMU Backup
(05-29-2020 08:50 PM)twoweims Wrote:  Here is my revised procedure. It still leaves me with a locked calculator after MMUEN:

Code:
Save Configuration to Flash Memory         [ALPHA] 800>3F0 [ALPHA]              Copy page 800 (Main Memory)         [XEQ]  [ALPHA]  YFWR  [ALPHA]        to page 3F0                                                           [ALPHA] 804>3F1 [ALPHA]             Copy page 804 (MMU Config)         [XEQ]  [ALPHA]  YFWR  [ALPHA]       to page 3F1                                               Restore Configuration from Flash Memory         [ALPHA] 3F1>804 [ALPHA]            Copy page 341 (MMU Config)         [XEQ]  [ALPHA]  YMCPY  [ALPHA]    back to page 804.         [ALPHA] 804040-0000 [ALPHA]                 [XEQ]  [ALPHA]  YPOKE  [ALPHA]               [ALPHA] 3F0>800 [ALPHA]               Copy page 3F0 (Main Memory)          [XEQ]  [ALPHA]  YMCPY  [ALPHA]    back to page 800.                                               [XEQ]  [ALPHA]  MMUEN  [ALPHA]        Enable the MMU

Hmm... I think that should work. What happens if you do the MMUEN immediately after the YPOKE? Does it still lock up? That will help isolate the problem.
05-30-2020, 01:05 AM (This post was last modified: 05-30-2020 01:49 AM by twoweims.)
Post: #7
 twoweims Member Posts: 265 Joined: Apr 2019
RE: 41CL MMU Backup
Still the same.
Would I have to somehow plug in a new copy of 4LIB after copying 341>804 and before enabling the MMU?

Here is what I had plugged in before starting the whole process if it helps:
[attachment=8521]

Attached File(s) Thumbnail(s)

05-30-2020, 05:22 AM (This post was last modified: 05-30-2020 06:17 AM by Ángel Martin.)
Post: #8
 Ángel Martin Senior Member Posts: 1,262 Joined: Dec 2013
RE: 41CL MMU Backup
I hope I'm not confusing things, but If I understand the concept YFWR (1) temporarily remaps page #4 to 0x804, then (2) it runs the transient code, then (3) does the flash writing and then re-maps page #4 to its previous setting.

But this means than when using YFWR on 0x804 itself the information written to flash is under the conditions of step (2), so it says "page #4 is mapped to 0x804". Therefore restoring that block with YMCPY to 804 is going to preempt the actual page#4 mapping (in your case to the Library#4).

An interesting problem... maybe you can try to do a manual re-mapping to Library#4 after YFWR but you cannot perform any Library#4 dependent action until that is done, which it's unlikely unless the MMU is entirely disable of course.

"804>1F1"
YFWR - saves MMU settings with INCORRECT page#4

Then to restore things:

MMUDIS - disables MMU, so plain YFNZ is active
"1F1>804"
YMCPY - this step breaks the current Library#4 mapping
"804040-8120"
YPOKE - to restore that mapping
MMUEN - enables all mappings, so YFNX is active

I guess this means I should probably modify the YRALL routine in the PWRX module to include the fix, it was written with a previous version of YFWR (the one still included in YFNZ) that did not alter page#4 mapping in the saved flash block.
05-30-2020, 08:27 AM
Post: #9
 grsbanks Senior Member Posts: 1,219 Joined: Jan 2017
RE: 41CL MMU Backup
Would another solution not be to copy YFNX into a RAM page and point the MMU to it there rather than in flash?

That way, YMCPY doesn't need to be copied to page 4 in the first place because it's already running from RAM rather than ROM.

There are only 10 types of people in this world. Those who understand binary and those who don't.
05-30-2020, 02:32 PM
Post: #10
 twoweims Member Posts: 265 Joined: Apr 2019
RE: 41CL MMU Backup
(05-30-2020 05:22 AM)Ángel Martin Wrote:  I hope I'm not confusing things, but If I understand the concept YFWR (1) temporarily remaps page #4 to 0x804, then (2) it runs the transient code, then (3) does the flash writing and then re-maps page #4 to its previous setting.

But this means than when using YFWR on 0x804 itself the information written to flash is under the conditions of step (2), so it says "page #4 is mapped to 0x804". Therefore restoring that block with YMCPY to 804 is going to preempt the actual page#4 mapping (in your case to the Library#4).

An interesting problem... maybe you can try to do a manual re-mapping to Library#4 after YFWR but you cannot perform any Library#4 dependent action until that is done, which it's unlikely unless the MMU is entirely disable of course.

"804>1F1"
YFWR - saves MMU settings with INCORRECT page#4

Then to restore things:

MMUDIS - disables MMU, so plain YFNZ is active
"1F1>804"
YMCPY - this step breaks the current Library#4 mapping
"804040-8120"
YPOKE - to restore that mapping
MMUEN - enables all mappings, so YFNX is active

I guess this means I should probably modify the YRALL routine in the PWRX module to include the fix, it was written with a previous version of YFWR (the one still included in YFNZ) that did not alter page#4 mapping in the saved flash block.

Ángel,
In the PowerCL Extreme manual, in the YWALL section, it says "Early CL beta user Geoff Quickfall prepared a few FOCAL programs to commit the calculator contents to FLASH, so that even without the batteries it’ll be preserved for a restore at any later time."

Watching Geoff's presentation from the 2011 HHC is what prompted me to start looking into this. Are his FOCAL programs available somewhere so I could study them to try to better understand this process?

Also, in your YWALL program listing in the PowerCL Manual, the comment next to YSERASE says "erase BLOCK" but YFERASE in the 41CL manual says that it erases an entire sector. Won't the second call to YFERASE erase the whole sector, wiping out the copy of 800 that was just put into 1FE?

I hope my questions are not too stupid. I am new to the 41CL and have been away from using my HP-41 in general for about 20 years. You can blame the Corona Virus for this. Staying at home prompted me to buy a second CL Board so now I am free to "play" without screwing up my daily use CL.
05-30-2020, 03:45 PM (This post was last modified: 05-30-2020 05:33 PM by Ángel Martin.)
Post: #11
 Ángel Martin Senior Member Posts: 1,262 Joined: Dec 2013
RE: 41CL MMU Backup
(05-30-2020 02:32 PM)twoweims Wrote:
(05-30-2020 05:22 AM)Ángel Martin Wrote:  I guess this means I should probably modify the YRALL routine in the PWRX module to include the fix, it was written with a previous version of YFWR (the one still included in YFNZ) that did not alter page#4 mapping in the saved flash block.

Also, in your YWALL program listing in the PowerCL Manual, the comment next to YSERASE says "erase BLOCK" but YFERASE in the 41CL manual says that it erases an entire sector. Won't the second call to YFERASE erase the whole sector, wiping out the copy of 800 that was just put into 1FE?

This is tricky. Depending on the CL board version YFERASE will delete the complete TOP sector (32K ) or only the selected block (4k).

- YWALL in the original PowerCL assumed the complete TOP sector was deleted so only one YFERASE call was done, but
- YWALL in the PWRX module assumes the top sector erasing is granular (i.e. by blocks), so there are two YFERASE calls for the 1EF and 1FF blocks.

I don't remember how to tell which version your board is, we need Monte to remind us how to tell.

BTW tinkling a bit further into this I think it's better to avoid the problem from happening rather than fixing it afterwards (prevention rather than cure). All we need is to call YFWR in YFNZ instead of YFWR in YFNX to avoid the problem, so here's the updated listing o YWALL (note steps 13 and 15 used to switch between the two YFN's versions))

Code:
01 LBL "YWALL" 02 "1FE000" 03 AVIEW 04 YFERASE   05 "800>1FE" 06 AVIEW  07 YFWR 08 FC? 01 09 GTO 02 10 "1FF000" 12 YFERASE 12 "804>1FF" 13 MMUDIS 14 YFWR 15 MMUEN 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

ARRGGHHHH now I remember why this won't work either: the YFWR functioni from YFNZ must be executed from RAM to begin with! - full circle to the same place....

So never mind, I guess we're back to having to remap the library#4 after YFWR (in the YFNX) has terminated....
05-30-2020, 03:52 PM (This post was last modified: 05-30-2020 04:07 PM by Ángel Martin.)
Post: #12
 Ángel Martin Senior Member Posts: 1,262 Joined: Dec 2013
RE: 41CL MMU Backup
(05-30-2020 08:27 AM)grsbanks Wrote:  Would another solution not be to copy YFNX into a RAM page and point the MMU to it there rather than in flash?

That way, YMCPY doesn't need to be copied to page 4 in the first place because it's already running from RAM rather than ROM.

The transient code snippet is copied by YFWR to a RAM page, not to flash.
Then the MMU is changed to map Page#4 to that RAM page, and the MCODE execution is sent to page#4
The MCODE runs there, including a final remapping of page#4 to the original flash/RAM block.

And herein lies the issue: if you're copying 804 to 1FE that requires YFWR , which modifies the 804 content on the fly during the copying. Sure it undoes that modification but not before the modified one was copied to 1FE.

The question is which other RAM page could be used to copy the transient code and map it to Page# - specifically how to guarantee it's always available for this purpose.

801, 802 and 803 come to mind but they're also used by the CL Xpanded backups, the the Y-Registers functions and the Y-Matrix extensions of the SandMatrix...

805 is already reserved for the IMDB location in RAM

and above those you get into the standard RAM, which is user-dependent.
05-30-2020, 06:47 PM
Post: #13
 Monte Dalrymple Member Posts: 275 Joined: Jan 2014
RE: 41CL MMU Backup
There is a chicken-and-egg problem no matter what you do:

Any code writing to Flash MUST be executed out of RAM, because Flash memory does not support simultaneous reading and writing. Flash writes require a SEQUENCE of write transactions on the bus, which requires that the CPU fetch a bunch of instructions to create the sequence. This sequence cannot be interleaved with instruction fetches, so the code doing the write MUST be resident in RAM.

In YFNZ, the way to make the code resident in RAM is to copy the entire image to a RAM page and then reprogram the MMU to use that page. Saving page 804, which contains the MMU registers, is going to capture this MMU reprogramming. So when this capture is restored YFNZ better be resident in RAM, in the same page as before, when you enable the MMU or you will be screwed. Or, you have to manually change the MMU back to point at the Flash version of YFNZ BEFORE you enable the MMU.

In YFNX, the code automatically copies a very small section (128 bytes) of code to RAM, reprograms the MMU to point Page 4 at this code, and then executes that code to do the Flash write. Once done, the MMU is reprogrammed back to what it was and the user is none the wiser. But the same problem still exists: this time it's the Page 4 MMU programming that is screwed up on the restore.
So in this case you have to manually change the MMU for Page 4, either to something innocuous (0000) or to point at Library-4 (8120).

In either case, only ONE location needs to be repaired, and everything else should be fine.

There IS a way to avoid these problems that I just thought of: Copy the entire page 804 to another page of RAM and THEN backup THAT copy. If you do this BEFORE you start the RAM version of YFNZ everything is fine. And everything is fine when using YFNX because you are again backing up a snapshot of Page 804 rather than the actual Page 804.

As far as determining what kind of Flash device you have, if you are running the latest version of YFNX, simply run "41CL" for a report on the size and organization of the Flash device on the board.
05-30-2020, 08:26 PM
Post: #14
 twoweims Member Posts: 265 Joined: Apr 2019
RE: 41CL MMU Backup
What are the 104 Pages of RAM from page 818 to 87F used for?
05-30-2020, 10:07 PM
Post: #15
 Monte Dalrymple Member Posts: 275 Joined: Jan 2014
RE: 41CL MMU Backup
(05-30-2020 08:26 PM)twoweims Wrote:  What are the 104 Pages of RAM from page 818 to 87F used for?

Whatever you want to use them for.
05-30-2020, 10:36 PM
Post: #16
 rprosperi Senior Member Posts: 5,069 Joined: Dec 2013
RE: 41CL MMU Backup
(05-30-2020 06:47 PM)Monte Dalrymple Wrote:  As far as determining what kind of Flash device you have, if you are running the latest version of YFNX, simply run "41CL" for a report on the size and organization of the Flash device on the board.

And if you don't it displays "41CL Monte" and plays a short tune, which I probably should recognize, but don't...

Need to do some CL updates... but think I'll wait for this process to play out first...

--Bob Prosperi
05-30-2020, 11:58 PM (This post was last modified: 05-31-2020 01:33 AM by Monte Dalrymple.)
Post: #17
 Monte Dalrymple Member Posts: 275 Joined: Jan 2014
RE: 41CL MMU Backup
(05-30-2020 10:36 PM)rprosperi Wrote:
(05-30-2020 06:47 PM)Monte Dalrymple Wrote:  As far as determining what kind of Flash device you have, if you are running the latest version of YFNX, simply run "41CL" for a report on the size and organization of the Flash device on the board.

And if you don't it displays "41CL Monte" and plays a short tune, which I probably should recognize, but don't...

Need to do some CL updates... but think I'll wait for this process to play out first...

Think 2001... I admit it was a feeble attempt.
It's still there in the latest version, but it's hidden. I've left it as an exercise for the user to find out how to activate it.
05-31-2020, 03:00 AM
Post: #18
 rprosperi Senior Member Posts: 5,069 Joined: Dec 2013
RE: 41CL MMU Backup
(05-30-2020 11:58 PM)Monte Dalrymple Wrote:
(05-30-2020 10:36 PM)rprosperi Wrote:  And if you don't it displays "41CL Monte" and plays a short tune, which I probably should recognize, but don't...

Need to do some CL updates... but think I'll wait for this process to play out first...

Think 2001... I admit it was a feeble attempt.
It's still there in the latest version, but it's hidden. I've left it as an exercise for the user to find out how to activate it.

"Also Sprach Zarathustra" on an HP-41!?! Bold Monte, Bold!

So I did recognize it, but could not place it, no doubt due to the limited tonal fidelity available from BEEP. After updating I'll search for it. Easter Eggs demand attention and respect.

--Bob Prosperi
05-31-2020, 06:09 AM (This post was last modified: 05-31-2020 06:50 AM by Ángel Martin.)
Post: #19
 Ángel Martin Senior Member Posts: 1,262 Joined: Dec 2013
RE: 41CL MMU Backup
(05-30-2020 03:45 PM)Ángel Martin Wrote:  So never mind, I guess we're back to having to remap the library#4 after YFWR (in the YFNX) has terminated....

Ok but it's not too difficult to get it fixed after the fact - just adding three instructions to YRALL remapping Library#4 to page#4 does the trick. I chose PPLUG because it requires shorter text in ALPHA: ("4LIB", 4, PPLUG 7 bytes instead of "804040-8120" YPOKE 12 bytes)

YWALL
can be optimized using a subroutine, to the final form shown below - also checking on the low battery condition before doing any flash writings:

Code:
1    LBL "YWALL" 2    "1FE" 3    XEQ 00 4    "1FF" 5    FS? 01 6    XEQ 00 7    GTO 92 8    LBL 00 9    ASTO T 10    >"000" 11    AVIEW 12    FC? 49 13    YFERASE 14    "800>" 15    ARCL T 16    AVIEW 17    FC? 49 18    YFWR 19    RTN 20    LBL "YRALL" 21    "1FE>800" 22    AVIEW 23    YMCPY 24    "1FF>804" 25    AVIEW 26    FS? 01 27    YMCPY 28    "4LIB" 29    4 30    PPLUG 31    LBL 02 32    "DONE" 33    END

The role of user flag 01 is to choose if only the 801 block (cF1 clear) or also the MMU registers (F1 set) will be backed up.
In the POWER Extreme module this is managed by the string in ALPHA as explained in the manual:

"OK" means only the 800 block
"OKALL" means both 800 and 804 blocks
05-31-2020, 06:55 AM
Post: #20
 Ángel Martin Senior Member Posts: 1,262 Joined: Dec 2013
RE: 41CL MMU Backup
(05-30-2020 11:58 PM)Monte Dalrymple Wrote:  Think 2001... I admit it was a feeble attempt.
It's still there in the latest version, but it's hidden. I've left it as an exercise for the user to find out how to activate it.

I must have the older versions, only the tune comes up under 41CL...
BTW always missed the stumping drumming in that tune ;-)
 « Next Oldest | Next Newest »