Threaded Mode | Linear Mode

twoweims · 05-28-2020, 10:15 PM

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.

Monte Dalrymple · 05-29-2020, 04:07 PM

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

twoweims · 05-29-2020, 04:44 PM

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

Monte Dalrymple · 05-29-2020, 05:49 PM

(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

twoweims · 05-29-2020, 08:50 PM

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

Monte Dalrymple · 05-29-2020, 10:09 PM

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

twoweims · (This post was last modified: 05-30-2020 01:49 AM by twoweims.)

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]

Ángel Martin · (This post was last modified: 05-30-2020 06:17 AM by Ángel Martin.)

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.

grsbanks · 05-30-2020, 08:27 AM

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.

twoweims · 05-30-2020, 02:32 PM

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

Ángel Martin · (This post was last modified: 05-30-2020 05:33 PM by Ángel Martin.)

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

Ángel Martin · (This post was last modified: 05-30-2020 04:07 PM by Ángel Martin.)

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

Monte Dalrymple · 05-30-2020, 06:47 PM

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.

twoweims · 05-30-2020, 08:26 PM

What are the 104 Pages of RAM from page 818 to 87F used for?

Monte Dalrymple · 05-30-2020, 10:07 PM

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

**rprosperi** · 05-30-2020, 10:36 PM

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

Monte Dalrymple · (This post was last modified: 05-31-2020 01:33 AM by Monte Dalrymple.)

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

**rprosperi** · 05-31-2020, 03:00 AM

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

Ángel Martin · (This post was last modified: 05-31-2020 06:50 AM by Ángel Martin.)

(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

Ángel Martin · 05-31-2020, 06:55 AM

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