Threaded Mode | Linear Mode

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