HP41-CL - Module behaves differently than on 41CX

[PeterP]

Question to the gurus of the 41-CL:

I have a module - COGO41 - which behaves nicely when plugged into port 3 after a "MEMORY LOST" on a HP-41CX, showing up as 'COGO41A3', 'COGO41B3', 'COGO41C3', 'COGO41D3' in Cat 2. It uses XROM nr 4, 5, 6, 7. (verified)

When I try to do the same on my HP-41CL however, the calculator hangs. (ML, Port 3). I tried moving the YFNX to page 8, in case the module is trying some stuff from port 6 and/or 7. Same problem. Which is weird, since there is no XROM conflict.
I then tried to create a pristine 41CX:

• Memory Lost
• MMUDIS
• MMUCLR
• MMUEN
  

This removes access to the YFNZ/YFNX of course but should give me a plain old 41CX. However, upon plugging in the COGO41, the calculator hangs again.

Now I'm stumped and can't think of what else to try.

Question: How is this possible? Any suggestions on what else to try?

[PeterP]

(12-29-2017 11:05 PM)Geir Isene Wrote:  Peter; Thank you for your probing and opening new 41CL threads.

I have a question on a tangent here; How would one recover from not having YFNZ/X installed (as in your above example). My solution has been to remove the batteries for a couple of minutes. Is there another, better way tht doesn't lose the clock?

A simple Memory Lost works as well (at least on my V5 boards). Brings you back to MMUDISabled, YFNZ in page 7 (I think).

Yes, exploring the 41CL as well as all the new modules from Angel, Sylvain, and you has been my Christmas present and joy.

[PeterP]

Quote:Hmm. I didn't think of that.

Now here's another tip; If you have a NOV module, you can load it with the NOVCHAP rom and use SAVEN to save your RAM to the NOV HEPAX. Whenever you get a MEMORY LOST, just pop the NOV back in and do a GETN to restore RAM. Very handy.

Oh, how neat! I tried to look at the manual by clicking on the link on your site but it seems you e removed it from the Dropbox. Would you mind pointing me to the right link?

[rprosperi]

(12-29-2017 10:28 PM)PeterP Wrote:  Question: How is this possible? Any suggestions on what else to try?

Is it possible the COGO ROM pre-dates the 41CX? The CX uses Page 5 differently than the C/CV, to support the TIME module and bank 2 of the CX functions, and perhaps if this ROM was pre-CX, it is not compatible? Just a guess.

[rprosperi]

(12-29-2017 11:56 PM)Geir Isene Wrote:  NOVCHAP rom manual: https://isene.files.wordpress.com/2017/12/novchap.pdf

@Geir - can you post a link to the NOVCHAP .rom or .mod file? I've somehow never seen this before, even when exploring the NoVRAM module extensively several years ago.

Thanks, and absolutely no rush.

[hth]

(12-29-2017 10:28 PM)PeterP Wrote:  I then tried to create a pristine 41CX:

• Memory Lost
• MMUDIS
• MMUCLR
• MMUEN
  

This removes access to the YFNZ/YFNX of course but should give me a plain old 41CX. However, upon plugging in the COGO41, the calculator hangs again.

Now I'm stumped and can't think of what else to try.

Question: How is this possible? Any suggestions on what else to try?

It is possible if it uses page 7. Move the YFN* module away from page 7 before you enable the MMU.

Håkan

[rprosperi]

(12-30-2017 12:33 AM)Geir Isene Wrote:  You'll find it at TOS ?
I can also supply a fresh link here tomorrow.

Got it, should have looked there first.

No need for a link, it's available here.

[PeterP]

(12-30-2017 12:44 AM)hth Wrote:  

(12-29-2017 10:28 PM)PeterP Wrote:  I then tried to create a pristine 41CX:

• Memory Lost
• MMUDIS
• MMUCLR
• MMUEN
  

This removes access to the YFNZ/YFNX of course but should give me a plain old 41CX. However, upon plugging in the COGO41, the calculator hangs again.

Now I'm stumped and can't think of what else to try.

Question: How is this possible? Any suggestions on what else to try?

It is possible if it uses page 7. Move the YFN* module away from page 7 before you enable the MMU.

Håkan

Yes, I tried that. The above sequence actually creates a CX without any YFNZ/X, so only pages 1,2,3,5 are used. Still hangs.

With regards to it predating the CX - it works in a standard CX just fine, which would seem to invalidate that hypothesis also.

Theoretically the above procedure should create a 41CL which is identical to a standard CX. However, the COGO41 works on a standard CX, but not a CL prepared in this manner. So there is for certain some difference. Question is - what difference? And why does said difference make the module hang? Could there be an opcode used in the COGO41 for the 16k EPROM(?) hardware it runs on which is (mis)interpreted by the 41CL? If so, which op-codes does the 41CL use (so that I could search on my normal CX using the hepax module in the listing of the COGO41, which btw looks to be mostly FOCAL code. The plot thickens...

[Sylvain Cote]

(12-29-2017 10:28 PM)PeterP Wrote:  I have a module - COGO41 - which behaves nicely when plugged into port 3 after a "MEMORY LOST" on a HP-41CX, showing up as 'COGO41A3', 'COGO41B3', 'COGO41C3', 'COGO41D3' in Cat 2.
It uses XROM nr 4, 5, 6, 7. (verified)

Peter,
Can you send me your 4 ROM images so I can try it out.
Sylvain

[rprosperi]

(12-29-2017 10:28 PM)PeterP Wrote:  I have a module - COGO41 - which behaves nicely when plugged into port 3 after a "MEMORY LOST" on a HP-41CX, showing up as 'COGO41A3', 'COGO41B3', 'COGO41C3', 'COGO41D3' in Cat 2. It uses XROM nr 4, 5, 6, 7. (verified)

Some other thoughts:

You specifically mention that it works when plugged into Port-3.

a. Does it also work in other Ports?

b. Is the 3 also seen in the CAT 2 Module names a result of being in Port-3 or just a coincidence?

c. Is it possible one or more of the .ROM image files (or single .MOD file) are damaged?

4. When you say it works in a real 41CX, do you have the original module, or do you have them loaded in a NoVRAM module? If real module is available, maybe try creating new images?

[PeterP]

(12-30-2017 02:15 AM)Sylvain Cote Wrote:  

(12-29-2017 10:28 PM)PeterP Wrote:  I have a module - COGO41 - which behaves nicely when plugged into port 3 after a "MEMORY LOST" on a HP-41CX, showing up as 'COGO41A3', 'COGO41B3', 'COGO41C3', 'COGO41D3' in Cat 2.
It uses XROM nr 4, 5, 6, 7. (verified)

Peter,
Can you send me your 4 ROM images so I can try it out.
Sylvain

I need to device another method for getting them off the module, which requires the PIL box - which needs to be upgraded - for which I need to get to it (its in the UK), after which I need to make a VM with Windows work on my machine. I also need a HP-IL module, which is in a box en route to Luxembourg. So it might be a while until this Yak is shaved... I even have the full manual of the thing...

[PeterP]

Quote:Some other thoughts:

You specifically mention that it works when plugged into Port-3.

a. Does it also work in other Ports?

Yes, it also works in Port 1 and 2.

Quote:b. Is the 3 also seen in the CAT 2 Module names a result of being in Port-3 or just a coincidence?

This seems to be a coincidence, as CAT 2 shows the same names when it is plugged into port 1 or 2.

Quote:c. Is it possible one or more of the .ROM image files (or single .MOD file) are damaged?

It is the actual module, so it could be damaged. But why would it work in a real CX and not in a CL?

Quote:4. When you say it works in a real 41CX, do you have the original module, or do you have them loaded in a NoVRAM module? If real module is available, maybe try creating new images?

It is the real module that I am testing, not images. So, the real, physical module plugged into a real, physical 41 CX works (from port 1, 2, and 3). However, when I plug the real, physical module into a real, physical 41 CL, it does not work, independent of the page that YFNX or YFNZ is plugged in (7, 8, none).

I might try copying it via NoVram and Geir's module or some other way over to the 41CL page by page to see if there is a particular page causing the havoc. Or if the havoc disappears when it is in the NoVram, which would provide further indication that there is some op-code trickery going on, potentially as a way to prevent copying the module. I need to dig out the NoV manuals to see how I can copy something onto the NoV when plugged into the calculator that stays even when the NoV is unplugged, I thought that this was not possible. May I never cease to learn new things!

And all the neat tools packaged into the PWRX and the OSX3 require Lib4 (as well as YFNX), yet I dont have access to a windows machine to burn my Nov64 with it (here comes the Yak again...).

[Ángel Martin]

(12-30-2017 05:25 AM)PeterP Wrote:  It is the real module that I am testing, not images. So, the real, physical module plugged into a real, physical 41 CX works (from port 1, 2, and 3). However, when I plug the real, physical module into a real, physical 41 CL, it does not work, independent of the page that YFNX or YFNZ is plugged in (7, 8, none).

Wow, that's a puzzling scenario if it's as you describe it. By "it does not work" do you also include CAT-2 doesn't see its FAT? How about PGCAT, and ROMLST - do they catch it?

I believe the COGO has 4 pages, which may be arranged as two banks on each one of the two pages it occupies, (because it takes a complete port, right?).

Edited: nope, I just re-read the previous posts and it's simpler than that: four pages but not bank-switched as per your description of XROM numbers. So this puppy takes up two full ports, likely to be the one it's plugged in and the adjacent one. So far nothing out of ordinary and shouldn't be a problem for the CL...

If that's correct, I'd suggest you extract them 4 using CPYBNK in the XPMM (as you have already done for other modules) and upload the 4 ROM images to the PC.

This would be the best way to tell what's going on in there... I have to say you're coming up with *very* unusual challenges ;-)

Edited: Specifically we must look in the polling points for those pages. It may be a problem of the CL not allowing some EPROM configuration to occur, which is triggered by the CALC_ON event. Why do I suspect this? Because it is exactly what happens with the ZEPROMs - as confirmed by my own ZEPROM-based 41Z : the CALC_ON event is *not* performed (and the complex stack is not created).

ÁM