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

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

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

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

• 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).
  

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

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

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

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

(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

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

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

(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

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

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

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