HP-41CY re-initialization ROM

[Jurgen Keller]

I've written a module to re-initialize a corrupted HP-41CY. It seems to work fine in all situations I've tested. However, there is a problem: there is a part that I do not fully understand.

First, let me recap my approach and considerations (where RB2INI is my initialization module):

• Create a CLONIX module with RB2INI in page 8 (to mask a potentially corrupted RAMBOX2 OS) and OS/A in page E and OS/B in page F.
• Use the I/O service polling vector in RB2INI to take over control and run the initialization process.
• The bank switching op-codes (ENROM1/2/3) only work if the currently executed code is in the RAMBOX2 RAM.
  

My understanding of the bank switching instructions in RAMBOX2:

• ENROM1: Reset all pages to bank #1
• ENROM2: Enable odd pages of bank #2
• ENROM3: Enable even pages of bank #2
  

Re-initialization is straight-forward if we assume that the active RAMBOX2 bank is #1:

• Copy RB2INI to page A (in RAM).
• Transfer control to RB2INI in page A.
• Clear pages 9 and B to F.
• Copy OS/A from page E to 8.
• Enable odd pages of bank #2.
• Copy RB2INI to page 9 (in bank #2).
• Transfer control to RB2INI in page 9.
• Enable even pages of bank #2.
• Clear pages A to F.
• Copy OS/B from page F to 8.
• Power off.
  

However, if bank #2 is active I don't see a controlled way to initialize bank #1 because we would need to use the ENROM1 instruction to initialize a page in bank #1 but these pages are all potentially corrupted. Therefore, after ENROM1, we would execute some garbage instructions!

Because I had no other idea (even after many experiments) I tried to force a switch to bank #1 anyway. Suprisingly, it kind of works. When I run the initialization process on a HP-41CY with active bank #2, the process is somehow restarted after the ENROM1 instruction (i.e., the I/O service interrupt gets called again). Maybe the garbage in bank #1 was not bad enough, although I tried hard to create nasty situations. Only once I run into a problem where the calculator hanged. But even then, after turning it off and on again, RB2INI ran again and completed successfully.

The source code of RB2INI is available online. I think what I have right now is good enough for my needs. Anyway, I don't like if I do not fully understand the details. So any comments are highly appreciated.

Maybe the RAMBOX2 MMU can be controlled somehow and there is another possibility to activate bank #1? Or maybe there is another instruction than WROM to write to the whole RAMBOX2 RAM? I don't know ...

[Jurgen Keller]

While doing further test runs I think I should also delete the polling vectors FF8, FF9 and FFA (or even more?) in all RAM pages of the active bank. I guess I should install a handler for FF9. I'll give it a try.

[CY-CL]

Hello Jürgen

Congratulation to your great job. Hope you will publish the code as .rom to burn it into a Clonix Module?

Thanks
Patrik

[Jurgen Keller]

(10-27-2019 04:16 PM)CY-CL Wrote:  Hope you will publish the code as .rom to burn it into a Clonix Module?

Sure I will, however, without any warranty. Still looking for more test cases (i.e., corrupted 41CYs) :-)

[HP-Collection]

Congratulations from my side, too. A great job for collectors and enthusiasts. Recovering a CY / Rambox was always a hard job until now.

[Jurgen Keller]

I made an illustration of the problem. Maybe that helps to understand what I'm currently trying to avoid:



This picture inspired me and here is a sketch of the potential solution:



This looks adventurous to say the least! As you can see I propose to set the ENROM1 instruction at a page boundary and mask the next page with a ROM. Remember that ENROM1 only works when executed in RAM. Not sure if the HP-41 hardware allows for such page crossing MCODE. I'll give it a try anyway :-)

[Jurgen Keller]

It looks like I'm doing a monologue ;-) Anyway I just wanted to report that the trick mentioned in my previous post seems to work fine. The current setup is like that:

• The main procedure is a take-over ROM at page #4.
• At page C there is a helper ROM to do the controlled switch to bank #1 (see second picture above).
• Pages E and F contain the 41CY OS (OS/A and OS/B).
  

What is currently missing it the cleanup after initialization is done which is straightforward.

[hth]

(11-03-2019 02:32 PM)Jurgen Keller Wrote:  It looks like I'm doing a monologue ;-)

Because I am so totally lost by all this.

Why does it not have a fail-safe mechanism to re-install its OS/control image (which is in RAM?) How did they even program it from the factory? And if the software is broken and without such fail-safe mechanism, how is it even possible to repair the software?

I guess I am mentally blocked from following your endeavours as I just cannot get it into my mind that this should be a problem in the first place...

I am probably missing something here.

[PeterP]

(10-27-2019 03:00 PM)Jurgen Keller Wrote:  While doing further test runs I think I should also delete the polling vectors FF8, FF9 and FFA (or even more?) in all RAM pages of the active bank. I guess I should install a handler for FF9. I'll give it a try.

Wonderful stuff Juergen! It was the last piece of code I was thinking of writing one day as I felt it is missing in the Open Source, and you have done it now! This means CYs and Ramboxes from both W&W and Eramco can now be recovered.

I love the location of the InitRom in page 4!

One thing I wonder (and that has kept me from writing it out) is how to avoid garbage in the polling points of the pages E & F (in your case) where you have the OS. I always thought that if I put the InitRom in page 4 (I was thinking page 6, but it doesnt really matter I think) and the OS into pages E&F that I would not easily be able to clear the polling points there in case they got corrupted. So my thought was that I have to have the OS in the InitRom also and copy it from there to page 8 & 9, using that the difference between OS/A and OS/B is very small (just a couple of bytes) so one would copy OS/A twice and then overwrite the correct spots to make it OS/B.

Would love to hear your thoughts, I'm probably missing a whole bunch here as you clearly state it works already neatly and is recovering CYs (of which you - similarly amazingly - have it seems a never ending supply!

Great work and I love to see this happening!

Cheers

PeterP

[Jurgen Keller]

(11-03-2019 05:59 PM)hth Wrote:  

(11-03-2019 02:32 PM)Jurgen Keller Wrote:  It looks like I'm doing a monologue ;-)

Because I am so totally lost by all this.

Why does it not have a fail-safe mechanism to re-install its OS/control image (which is in RAM?) How did they even program it from the factory? And if the software is broken and without such fail-safe mechanism, how is it even possible to repair the software?

I guess I am mentally blocked from following your endeavours as I just cannot get it into my mind that this should be a problem in the first place...

I am probably missing something here.

W&W did for sure have such a fail-safe mechanism. Unfortunately, I didn't found any information about it. There is also a valued member of this forum who has developed such a re-initialization module in the past. However, he decided to not disclose that module for personal reasons and I fully respect his decision. Nevertheless, for personal curiosity, to get into MCODE-ing and to be able to restore my 41CY when needed, I wanted to solve the mystery.

The whole re-initialization process is not very complicated once you understand how the ENROMx instructions work in the 41CY. There is only one situation which caused me headaches:

• Assume that the 41CY "died" while bank #2 was active.
• Please note that after a ENROMx instruction is executed the next instruction is taken from the bank to which you switched to.
• It is possible to only enable odd or even pages of bank #2 but the pages of bank #1 can only be enabled together (ENROM1).
• Therefore you would end up with a situation as shown in my first picture: after the ENROM1 instruction the CPU would execute garbage which potentially crashes the calculator.
  

Not sure if that sheds some more light on it ...

After many partially working attempts the current version of my re-initialization module seems to work fine now. Hopefully, I can publish it soon.

[Jurgen Keller]

(11-03-2019 06:19 PM)PeterP Wrote:  

(10-27-2019 03:00 PM)Jurgen Keller Wrote:  While doing further test runs I think I should also delete the polling vectors FF8, FF9 and FFA (or even more?) in all RAM pages of the active bank. I guess I should install a handler for FF9. I'll give it a try.

Wonderful stuff Juergen! It was the last piece of code I was thinking of writing one day as I felt it is missing in the Open Source, and you have done it now! This means CYs and Ramboxes from both W&W and Eramco can now be recovered.

I love the location of the InitRom in page 4!

One thing I wonder (and that has kept me from writing it out) is how to avoid garbage in the polling points of the pages E & F (in your case) where you have the OS. I always thought that if I put the InitRom in page 4 (I was thinking page 6, but it doesnt really matter I think) and the OS into pages E&F that I would not easily be able to clear the polling points there in case they got corrupted. So my thought was that I have to have the OS in the InitRom also and copy it from there to page 8 & 9, using that the difference between OS/A and OS/B is very small (just a couple of bytes) so one would copy OS/A twice and then overwrite the correct spots to make it OS/B.

Would love to hear your thoughts, I'm probably missing a whole bunch here as you clearly state it works already neatly and is recovering CYs (of which you - similarly amazingly - have it seems a never ending supply!

Great work and I love to see this happening!

Cheers

PeterP

Great to hear from you, Peter!

Well, in my understanding, the polling vectors are not a problem anymore. The take-over ROM runs before the polling vectors (like I/O service) are called:



The previous version of my module used the I/O service (xFF8) to take over control, and there I added some code to clear the polling points (copying some code from your RSU init module). But as I have moved on to the page #4 approach this is not needed anymore and the code got simpler.

However, beware. I'm not an HP-41 OS expert at all so my understanding might be completely wrong. I still have a 41CY that's totally screwed up. I will use this one for final testing. If tests are passed I will publish the code here.

[hth]

(11-03-2019 06:29 PM)Jurgen Keller Wrote:  W&W did for sure have such a fail-safe mechanism. Unfortunately, I didn't found any information about it. There is also a valued member of this forum who has developed such a re-initialization module in the past. However, he decided to not disclose that module for personal reasons and I fully respect his decision. Nevertheless, for personal curiosity, to get into MCODE-ing and to be able to restore my 41CY when needed, I wanted to solve the mystery.

The whole re-initialization process is not very complicated once you understand how the ENROMx instructions work in the 41CY. There is only one situation which caused me headaches:

• Assume that the 41CY "died" while bank #2 was active.
• Please note that after a ENROMx instruction is executed the next instruction is taken from the bank to which you switched to.
• It is possible to only enable odd or even pages of bank #2 but the pages of bank #1 can only be enabled together (ENROM1).
• Therefore you would end up with a situation as shown in my first picture: after the ENROM1 instruction the CPU would execute garbage which potentially crashes the calculator.
  

Not sure if that sheds some more light on it ...

After many partially working attempts the current version of my re-initialization module seems to work fine now. Hopefully, I can publish it soon.

So basically you can just use a page 4 ROM to write an ENROM1 instruction at the last address of the corrupted page which is also stuck in some secondary bank. Then call that address, bank 1 is switched in and execution falls into the next page where you have another ROM of your own, which could be just RTN (or NOP and RTN to make it safer) to pass control back again to page 4. Is that a correct understanding?

[Jurgen Keller]

(11-03-2019 08:32 PM)hth Wrote:  

(11-03-2019 06:29 PM)Jurgen Keller Wrote:  W&W did for sure have such a fail-safe mechanism. Unfortunately, I didn't found any information about it. There is also a valued member of this forum who has developed such a re-initialization module in the past. However, he decided to not disclose that module for personal reasons and I fully respect his decision. Nevertheless, for personal curiosity, to get into MCODE-ing and to be able to restore my 41CY when needed, I wanted to solve the mystery.

The whole re-initialization process is not very complicated once you understand how the ENROMx instructions work in the 41CY. There is only one situation which caused me headaches:

• Assume that the 41CY "died" while bank #2 was active.
• Please note that after a ENROMx instruction is executed the next instruction is taken from the bank to which you switched to.
• It is possible to only enable odd or even pages of bank #2 but the pages of bank #1 can only be enabled together (ENROM1).
• Therefore you would end up with a situation as shown in my first picture: after the ENROM1 instruction the CPU would execute garbage which potentially crashes the calculator.
  

Not sure if that sheds some more light on it ...

After many partially working attempts the current version of my re-initialization module seems to work fine now. Hopefully, I can publish it soon.

So basically you can just use a page 4 ROM to write an ENROM1 instruction at the last address of the corrupted page which is also stuck in some secondary bank. Then call that address, bank 1 is switched in and execution falls into the next page where you have another ROM of your own, which could be just RTN (or NOP and RTN to make it safer) to pass control back again to page 4. Is that a correct understanding?

Yes, that's the trick I use to switch to bank #1 in a safe manner. I was not sure if code running across page boundaries is somehow prohibited by the HP-41 hardware. However, it seems to run fine.

BTW, I've got some insider information that W&W used a MBK ProfiSET to initialize HP-41CYs.

[PeterP]

Juergen, that makes total sense for the kick-off of the initialization. My concern was with the pages where you store the OS. My understanding is that you use a CLONIX which has the init module on page 4 and the OS/A on page E and the OS/B on page F.

Assuming this is the case, here is the problem case I was thinking of: Assume you have messed up pages - including junk in polling points - 8, 9, E, F. You can clear of course pages 8 & 9 as they are not masked by a plug-in module (which takes precedence). But how are you clearing the polling points in pages E & F, as they are masked by the CLONIX, aren't they?

Not sure if this question makes sense.

Cheers,

PeterP

[Jurgen Keller]

(11-04-2019 03:48 PM)PeterP Wrote:  Juergen, that makes total sense for the kick-off of the initialization. My concern was with the pages where you store the OS. My understanding is that you use a CLONIX which has the init module on page 4 and the OS/A on page E and the OS/B on page F.

Assuming this is the case, here is the problem case I was thinking of: Assume you have messed up pages - including junk in polling points - 8, 9, E, F. You can clear of course pages 8 & 9 as they are not masked by a plug-in module (which takes precedence). But how are you clearing the polling points in pages E & F, as they are masked by the CLONIX, aren't they?

Not sure if this question makes sense.

Cheers,

PeterP

You can still write to RAM pages using WROM, even if they are masked by ROM images in the CLONIX. However, jumps to such addresses will end up in ROM code. This is described by Winfried Maschke in this post. I don't exactly understand it (electronics stuff), but I confirmed that it works like that. Does this answer your question?

[Diego Diaz]

Hi Jurgen, all,

I would say that your "monologue" feeling comes mostly from the fact that there are very, very few CYs out there; and not because your M-coding efforts are not appreciated. They are! :-)

I don't have a CY myself, however, a well known contributor here sent me his CY for repair... IICR one memory chip and a logic IC were damaged (as weird as it may sound.)

Once the HW was fixed, reinstalling the W&W OS was not trivial. I made a heavily modified Clonix-D, running HEPAX at and odd page (preventing auto allocation) and use the CRF (Crash Recovery Function) stolen from the NoV-64 code, to prevent polling crashes.

A lot of fun (for a real geek :-) but certainly doing all that with a simple Clonix and M-code at page #4 is a serious programming achievement.

Congrats from Spain.

Diego.

[Jurgen Keller]

(11-04-2019 09:35 PM)Diego Diaz Wrote:  Hi Jurgen, all,

I would say that your "monologue" feeling comes mostly from the fact that there are very, very few CYs out there; and not because your M-coding efforts are not appreciated. They are! :-)

I don't have a CY myself, however, a well known contributor here sent me his CY for repair... IICR one memory chip and a logic IC were damaged (as weird as it may sound.)

Once the HW was fixed, reinstalling the W&W OS was not trivial. I made a heavily modified Clonix-D, running HEPAX at and odd page (preventing auto allocation) and use the CRF (Crash Recovery Function) stolen from the NoV-64 code, to prevent polling crashes.

A lot of fun (for a real geek :-) but certainly doing all that with a simple Clonix and M-code at page #4 is a serious programming achievement.

Congrats from Spain.

Diego.

Agreed, the 41CY community is probably quite small and there are many other interesting topics about HP calculators. Sometimes, talking to yourself or writing down your thoughts helps even if you don't get a reply. And in the end, there were some interesting inputs and encouraging words. Highly appreciated!

Your quote "Do not suppose, check it twice" perfectly applies to this project. I programmed the CLONIX module (love it) over and over again to check assumptions and verifying each step. And sometimes I was at that point:
Real coders ... love their machine

Now I started to write some documentation ... boring ;-)

[HP-Collection]

Hope you'll find a german co-author..... could be a perfect symbiose.

[PeterP]

(11-04-2019 08:02 PM)Jurgen Keller Wrote:  

(11-04-2019 03:48 PM)PeterP Wrote:  Juergen, that makes total sense for the kick-off of the initialization. My concern was with the pages where you store the OS. My understanding is that you use a CLONIX which has the init module on page 4 and the OS/A on page E and the OS/B on page F.

Assuming this is the case, here is the problem case I was thinking of: Assume you have messed up pages - including junk in polling points - 8, 9, E, F. You can clear of course pages 8 & 9 as they are not masked by a plug-in module (which takes precedence). But how are you clearing the polling points in pages E & F, as they are masked by the CLONIX, aren't they?

Not sure if this question makes sense.

Cheers,

PeterP

You can still write to RAM pages using WROM, even if they are masked by ROM images in the CLONIX. However, jumps to such addresses will end up in ROM code. This is described by Winfried Maschke in this post. I don't exactly understand it (electronics stuff), but I confirmed that it works like that. Does this answer your question?

It sure does!!! thank you!

PeterP

[PeterP]

(11-05-2019 08:26 PM)Jurgen Keller Wrote:  

(11-04-2019 09:35 PM)Diego Diaz Wrote:  Hi Jurgen, all,

I would say that your "monologue" feeling comes mostly from the fact that there are very, very few CYs out there; and not because your M-coding efforts are not appreciated. They are! :-)

I don't have a CY myself, however, a well known contributor here sent me his CY for repair... IICR one memory chip and a logic IC were damaged (as weird as it may sound.)

Once the HW was fixed, reinstalling the W&W OS was not trivial. I made a heavily modified Clonix-D, running HEPAX at and odd page (preventing auto allocation) and use the CRF (Crash Recovery Function) stolen from the NoV-64 code, to prevent polling crashes.

A lot of fun (for a real geek :-) but certainly doing all that with a simple Clonix and M-code at page #4 is a serious programming achievement.

Congrats from Spain.

Diego.

Agreed, the 41CY community is probably quite small and there are many other interesting topics about HP calculators. Sometimes, talking to yourself or writing down your thoughts helps even if you don't get a reply. And in the end, there were some interesting inputs and encouraging words. Highly appreciated!

Your quote "Do not suppose, check it twice" perfectly applies to this project. I programmed the CLONIX module (love it) over and over again to check assumptions and verifying each step. And sometimes I was at that point:
Real coders ... love their machine

Now I started to write some documentation ... boring ;-)

Speaking of Clonix - what programming environment are you using here? (I am talking about the physical programmer and the computer and OS you are using). Having switched to MacOS 8 years ago, I have been a bit at a loss what programmer and software to use...

Cheers

PeterP