Post Reply 
41CL MMU Backup
05-31-2020, 06:22 PM
Post: #21
RE: 41CL MMU Backup
(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.
Visit this user's website Find all posts by this user
Quote this message in a reply
05-31-2020, 06:30 PM
Post: #22
RE: 41CL MMU Backup
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.
Visit this user's website Find all posts by this user
Quote this message in a reply
05-31-2020, 06:51 PM
Post: #23
RE: 41CL MMU Backup
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.

--Bob Prosperi
Find all posts by this user
Quote this message in a reply
05-31-2020, 07:44 PM
Post: #24
RE: 41CL MMU Backup
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.
Visit this user's website Find all posts by this user
Quote this message in a reply
05-31-2020, 08:09 PM
Post: #25
RE: 41CL MMU Backup
(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!

--Bob Prosperi
Find all posts by this user
Quote this message in a reply
06-01-2020, 09:24 PM
Post: #26
RE: 41CL MMU Backup
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?
Visit this user's website Find all posts by this user
Quote this message in a reply
06-01-2020, 10:48 PM
Post: #27
RE: 41CL MMU Backup
(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.)
Visit this user's website Find all posts by this user
Quote this message in a reply
06-01-2020, 11:48 PM
Post: #28
RE: 41CL MMU Backup
(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
Visit this user's website Find all posts by this user
Quote this message in a reply
06-02-2020, 01:42 AM
Post: #29
RE: 41CL MMU Backup
(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.
Visit this user's website Find all posts by this user
Quote this message in a reply
06-04-2020, 07:14 PM (This post was last modified: 06-04-2020 08:08 PM by grsbanks.)
Post: #30
RE: 41CL MMU Backup
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.

There are only 10 types of people in this world. Those who understand binary and those who don't.
Find all posts by this user
Quote this message in a reply
06-04-2020, 08:50 PM
Post: #31
RE: 41CL MMU Backup
(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.
Visit this user's website Find all posts by this user
Quote this message in a reply
08-07-2021, 02:07 AM
Post: #32
RE: 41CL MMU Backup
(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.
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 2 Guest(s)