HP Forums

Full Version: 41CL MMU Backup
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
(05-31-2020 06:55 AM)Ángel Martin Wrote: [ -> ]
(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 ;-)

YLIB-5A was in the 02/01/2020 release. That version changed the 41CL function to report the size/organization of Flash instead of the message and tune. It reports this information directly instead of the ID string that YUPS reports. Makes it so you don't have to look up what the ID string means. I have multiple machines and don't always remember which is which and got tired of pulling out the YUPS manual.
That you Monte and Ángel.

I think I have all of the bugs worked out of my backup strategy for now.
I am able to backup my MMU configuration and restore everything successfully.
Since it seems to be tricky, or at least not obvious, please consider sharing the programs (or steps, if manual) you use to do the 41CL Backup and Restore, including board and module types and version info (since this seems to matter). This will help the folks that find this thread in the future, looking for the same information you couldn't find.
I am in the process of putting together a procedure, I will share it once I have done some more testing just to be sure. What I am doing is very similar to Ángel's YWALL but I want something that I can run without relying on YFNX being loaded and before the MMU is enabled.
(05-31-2020 07:44 PM)twoweims Wrote: [ -> ]I am in the process of putting together a procedure, I will share it once I have done some more testing just to be sure. What I am doing is very similar to Ángel's YWALL but I want something that I can run without relying on YFNX being loaded and before the MMU is enabled.

Nice! Fewer module dependencies typically means it's useful to more people that don't want to learn a new module's behavior and idiosyncrasies.

Thanks!
Are the "not visible OS" areas in Page 800 (Register 200, 2F0-300, and 3F0-3FF) used for? Are they completely unused or is the Nut processor using them for something that is just not visible to the 41 OS?
(06-01-2020 09:24 PM)twoweims Wrote: [ -> ]Are the "not visible OS" areas in Page 800 (Register 200, 2F0-300, and 3F0-3FF) used for? Are they completely unused or is the Nut processor using them for something that is just not visible to the 41 OS?

As in the original HP41, these locations are not readable. The bus stays 3-state for these addresses.

The RAM corresponding to those register addresses is accessible using the NEWT WCMD however (I think, not sure I ever tried it.)
(06-01-2020 10:48 PM)Monte Dalrymple Wrote: [ -> ]
(06-01-2020 09:24 PM)twoweims Wrote: [ -> ]Are the "not visible OS" areas in Page 800 (Register 200, 2F0-300, and 3F0-3FF) used for? Are they completely unused or is the Nut processor using them for something that is just not visible to the 41 OS?

As in the original HP41, these locations are not readable. The bus stays 3-state for these addresses.

The RAM corresponding to those register addresses is accessible using the NEWT WCMD however (I think, not sure I ever tried it.)

I was able to YPOKE a value into 800800 then YMCPY 800>801 then YPOKE a new value into 801800 then YMCPY 801>800 then YPEEK the changed value from 800800.
So it looks like YPEEK/YPOKE and YMCPY can read and write from this location! Smile
(06-01-2020 11:48 PM)twoweims Wrote: [ -> ]
(06-01-2020 10:48 PM)Monte Dalrymple Wrote: [ -> ]As in the original HP41, these locations are not readable. The bus stays 3-state for these addresses.

The RAM corresponding to those register addresses is accessible using the NEWT WCMD however (I think, not sure I ever tried it.)

I was able to YPOKE a value into 800800 then YMCPY 800>801 then YPOKE a new value into 801800 then YMCPY 801>800 then YPEEK the changed value from 800800.
So it looks like YPEEK/YPOKE and YMCPY can read and write from this location! Smile

That confirms what I expected. All of these functions use the WCMD instruction.
Here's an idea that could save some time when updating a 41CL.

When the updater sees that the YCRC of a modified page should be 0x53D36BD2, instead of transferring a page of 0xff can it not simply fill the target page with that value? Or better still, simply skip writing that page after erasing the sector because it'll already be full of 0xff.
(06-04-2020 07:14 PM)grsbanks Wrote: [ -> ]Here's an idea that could save some time when updating a 41CL.

When the updater sees that the YCRC of a modified page should be 0x53D36BD2, instead of transferring a page of 0xff can it not simply fill the target page with that value? Or better still, simply skip writing that page after erasing the sector because it'll already be full of 0xff.

I have wanted to do that since the very beginning, but there is no room in the ROM.
(05-31-2020 03:00 AM)rprosperi Wrote: [ -> ]
(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.

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

So, Bob, did you ever find it? Hint: It takes five keystrokes, and then execute 41CL.
Pages: 1 2
Reference URL's