HP Forums

Full Version: YFNX does not work on my 41CL
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
If I plug in the extreme functions module with "YFNX" PLUG1L, MMUEN, a CAT 2 causes the calculator to freeze. The only thing plugged in otherwise is a time module. YFNP can be plugged in without any problems.
I am running with an old image database that came with it (from years ago) as I never managed to update the module database.
Are you trying a new version of YFNX ?
What version of YFNX, YLIB & YFNP are you using or trying to ?
YFNX uses YLIB and they must be synchronized in order to work.
(09-17-2019 05:25 PM)Sylvain Cote Wrote: [ -> ]Are you trying a new version of YFNX ?
What version of YFNX, YLIB & YFNP are you using or trying to ?
YFNX uses YLIB and they must be synchronized in order to work.

I am trying with the YFNX that came preinstalled. I have not changed anything in the image database ever. It is an early V4 board ordered September 2013.

YFNP is version 1C. I do not know the version of YFNX as the calculator freezes when I plug it in.
I should add that what I really want to do is to use PPLUG to map in an alternative OS in RAM. If such functionality is in YFNZ or YFNP, then I am fine with it. At least MAPEN is available for enabling mapping of the OS, but I cannot see that I can set up the OS mapping with those modules after looking in the manual.
I am currently at work (GMT-4h), I will look into it tonight.
Some further input on this. I can actually plug in YFNX, provided the MLDL2000 is not attached. It turns out that if I plug in any YFN* module and enable the MMU the calculator will freeze (when the MLDL2000 is attached).

I have two modules in the MLDL2000 located in port address A and B. I assume PLUG1L would put the YFNZ/P/X in page address 8. I want to move it away from page 7 (the default) as I need to use the HP-IL module to download OS images. The reason to use the MLDL2000 is that it holds a module with an MCODE function to download 16-bit page images over HP-IL to the 41CL RAM.

MLDL2000 straps indicate that it is enabled, strapped for SR from SRAM. I have carefully checked MKDL2000 Manager software that only page A and B are enabled and it looks good in CAT 2 on both a halfnut and the 41CL (with no MMU enabled).
Yet some more input, I believe it is my own fault and I have an idea how to deal with that later tonight.
(09-17-2019 05:18 PM)hth Wrote: [ -> ]If I plug in the extreme functions module with "YFNX" PLUG1L, MMUEN, a CAT 2 causes the calculator to freeze. The only thing plugged in otherwise is a time module. YFNP can be plugged in without any problems.
I am running with an old image database that came with it (from years ago) as I never managed to update the module database.

That is a very old version of YFNX and YLIB. There were bugs, and not every feature in the manual was implemented at that time. I would recommend updating both of them before doing anything else.
(09-18-2019 04:50 AM)Monte Dalrymple Wrote: [ -> ]That is a very old version of YFNX and YLIB. There were bugs, and not every feature in the manual was implemented at that time. I would recommend updating both of them before doing anything else.

I am not sure about the easiest and best way of doing that update. Checking the new update functions module and doing it manually (example 5) I can figure out how to replace the images (YFNX and YLIB), but what about FLDB? It is a 4K ROM with the CRCs, if I update it many of my stored modules will not match the CRC in the FLDB. If I do not update it, then the CRC will be wrong for only YFNX and YLIB.

As YFNX does not work anyway, is the easiest and best way to just ignore the FLDB and only update YFNX and YLIB? It cannot get much worse as the version I have now does not work.

I have no serial port and doing a complete update seems way over my head at the moment.
(09-18-2019 04:31 PM)hth Wrote: [ -> ]
(09-18-2019 04:50 AM)Monte Dalrymple Wrote: [ -> ]That is a very old version of YFNX and YLIB. There were bugs, and not every feature in the manual was implemented at that time. I would recommend updating both of them before doing anything else.

I am not sure about the easiest and best way of doing that update. Checking the new update functions module and doing it manually (example 5) I can figure out how to replace the images (YFNX and YLIB), but what about FLDB? It is a 4K ROM with the CRCs, if I update it many of my stored modules will not match the CRC in the FLDB. If I do not update it, then the CRC will be wrong for only YFNX and YLIB.

As YFNX does not work anyway, is the easiest and best way to just ignore the FLDB and only update YFNX and YLIB? It cannot get much worse as the version I have now does not work.

I have no serial port and doing a complete update seems way over my head at the moment.

I would not worry about the FLDB at the moment. It is only really used when doing an accelerated update (with the CPONLY option.) Since you don't have the serial port you can't use this feature anyway. If in the future you do an update that relies on the FLDB, what will happen is that YFNX and YLIB will be marked as stale because of the stale FLDB entry, and will updated even though they don't need to be. This will not be a problem except for the extra 2-3 minutes it will add to the update time.
OK, I tried to update the 008 sector. I downloaded the Update module to the MLDL, set up the 008 sector in RAM, picked new YFNX and YLIB over HP-IL and went ahead with P8UPD.

Pressing R/S and it indicates that it starts erasing sectors 008 and hangs there for a while. Eventually the display goes blank and if I try to get in control pressing keys the display comes on with characters that I have never seen before, like it is only showing the upper half of the segments for a weird low characters random view. I thought the HP-41 had a character set for the LCD and could not display characters like this, LOL.

I tried it twice with the same result (different but similar weird displays).

Anyway, I cannot seem to get it to work, any idea what is up?
(09-18-2019 05:57 PM)hth Wrote: [ -> ]OK, I tried to update the 008 sector. I downloaded the Update module to the MLDL, set up the 008 sector in RAM, picked new YFNX and YLIB over HP-IL and went ahead with P8UPD.

Pressing R/S and it indicates that it starts erasing sectors 008 and hangs there for a while. Eventually the display goes blank and if I try to get in control pressing keys the display comes on with characters that I have never seen before, like it is only showing the upper half of the segments for a weird low characters random view. I thought the HP-41 had a character set for the LCD and could not display characters like this, LOL.

I tried it twice with the same result (different but similar weird displays).

Anyway, I cannot seem to get it to work, any idea what is up?

The erase probably succeeded. Unless you've removed the batteries the sector image should still be good in RAM. YUPS may not like being run out of the MLDL. To be safe, copy YUPS to a page in RAM and then PLUG in that page. Power off and remove the MLDL. Run PGCRC on each page in the sector buffer and compare with the values shown in mem_ref.pdf to make sure that the images there are good. Then run P8UPD on sector 008. If you want to verify that the images are correct in Flash, run PGCRC on the updated pages. Then you should be good to go. Make sure that your batteries are not weak. The functions check the battery level before starting, but not during the operations themselves.
Moving the update module to 41CL RAM did the trick, I now have a working YFNX!
Sorry for not stepping in as promised, I have been very sick in the last 24h and now I have to ready myself for an early morning flight to Reno.
(09-18-2019 08:10 PM)hth Wrote: [ -> ]Moving the update module to 41CL RAM did the trick, I now have a working YFNX!

Excellent! Let me know how the OS substitution goes.

I can't help wondering if there is something about the MLDL that doesn't agree with the 41CL?
My guess is that the update module switch on turbo and that does not work with the MLDL memory.

The OS substitution went fine. One unexpected behaviour was the SHIFT-ON (CLOCK) dropped back to the flash OS. I also found a couple of issues related to the OS itself which I need to look into.
(09-19-2019 02:11 AM)hth Wrote: [ -> ]My guess is that the update module switch on turbo and that does not work with the MLDL memory.

The OS substitution went fine. One unexpected behaviour was the SHIFT-ON (CLOCK) dropped back to the flash OS. I also found a couple of issues related to the OS itself which I need to look into.

Ahh... I didn't think of that. SHIFT-ON does a POWOFF after updating the display, which disables the MAPEN. Then I don't think it goes through the CALC-ON polling point when the time chip wakes up the CPU. The CPU does start executing at 0x0000, so it does the call to Page 4, which makes Page 4 a better MAPEN enable choice.
Yes, page 4 is better if one wants to keep MAPEN enabled. I may make a temporary module for that purpose later. At the moment I am happy that I can test on real hardware before I flash it.
Reference URL's