HP-41CL: Design request (YFNZ/YFNX)
01-02-2018, 05:27 PM (This post was last modified: 01-02-2018 05:30 PM by Ángel Martin.)
Post: #21
 Ángel Martin Senior Member Posts: 915 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-02-2018 04:54 PM)Geir Isene Wrote:  That's a possible hack.

But the design is still messy and a security risk. Why not mitigate the real issue?

I don't mean to sound flippant but... maybe because it's not an issue??

I guess I don't see it as a messy design: there are two modules with similar but not identical FATs, one *the simple one, witho no dependencies) is loaded by default on ML and other conditions, the other is more complex (it requires the YLIB) and needs manual user action. Certainly I can live with this.
01-02-2018, 05:35 PM (This post was last modified: 01-02-2018 05:38 PM by Geir Isene.)
Post: #22
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-02-2018 05:27 PM)Ángel Martin Wrote:
(01-02-2018 04:54 PM)Geir Isene Wrote:  That's a possible hack.

But the design is still messy and a security risk. Why not mitigate the real issue?

I don't mean to sound flippant but... maybe because it's not an issue??

I guess I don't see it as a messy design: there are two modules with similar but not identical FATs, one *the simple one, witho no dependencies) is loaded by default on ML and other conditions, the other is more complex (it requires the YLIB) and needs manual user action. Certainly I can live with this.

I have given a number of situations where this is an issue. It may even be fatal. If that's not enough to inspire any change, then I'm at loss.

As I've already said - giving YFNX a different XROM# (31 as the original YFNS?), then this issue is mitigated.
01-02-2018, 06:56 PM (This post was last modified: 01-02-2018 06:58 PM by Sylvain Cote.)
Post: #23
 Sylvain Cote Senior Member Posts: 847 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
Small suggestion ...

We could simply ask Monte to reorganize the FAT entries of the YFNX ROM to match as possible the ones from the YFNZ ROM.

As example, the following table contains my take of YFNX reorganized in the YFNX-UPD column: (lines with * has the same XROM for the same functions)
Code:
XR   YFNX-2C      YFNX-UPD     *   YFNZ-4F      XR --   ----------   ----------   -   ----------   --  0   ROMID        ROMID            ROMID         0  1   MMUDIS       MMUCLS           MMUCLR        1  2   MMUEN        MMUDIS       *   MMUDIS        2  3   MMU?         MMUEN        *   MMUEN         3  4   MMUCLP       MMU?         *   MMU?          4  5   MMUCLS       MMUCLP           TURBOX        5  6   PPLUG        ROMID2           TURBO2        6  7   PLUG         ROMID3           TURBO5        7  8   LOCK         ROMID4           TURBO10       8  9   UNLOCK       TURBO            TURBO20       9 10   LOCK?        PTURBO           TURBO50      10 11   EXPG         TURBO?       *   TURBO?       11 12   MVPG         YPOKE        *   YPOKE        12 13   EXCFG        YPEEK        *   YPEEK        13 14   RCLCFG       YMCLR        *   YMCLR        14 15   STOCFG       YMCPY        *   YMCPY        15 16   MAPDIS       YBPNT        *   YBPNT        16 17   MAPEN        YBPNT?       *   YBPNT?       17 18   ROMID2       YBUILD       *   YBUILD       18 19   PTURBO       PLUG             PLUG1        19 20   TURBO        PPLUG            PLUG1L       20 21   TURBO?       LOCK             PLUG1U       21 22   YPOKE        UNLOCK           PLUG2        22 23   YPEEK        LOCK?            PLUG2L       23 24   YMCLR        EXPG             PLUG2U       24 25   YMCPY        MVPG             PLUG3        25 26   IMDBF        EXCFG            PLUG3L       26 27   IMDBR        RCLCFG           PLUG3U       27 28   IMDBF?       STOCFG           PLUG4        28 29   PIMDB?       IMDBF            PLUG4L       29 30   IMDB?        IMDBR            PLUG4U       30 31   IMDBCPY      IMDBF?           UPLUG1       31 32   IMDBINS      PIMDB?           UPLUG1L      32 33   IMDBUPD      IMDBCPY          UPLUG1U      33 34   ROMID3       IMDBINS          UPLUG2       34 35   PBAUD        IMDBUPD          UPLUG2L      35 36   BAUD         YGPNT            UPLUG2U      36 37   SERINI       YGPNT?           UPLUG3       37 38   SERON        YGPNT-           UPLUG3L      38 39   YIMP         CHKXROM          UPLUG3U      39 40   YEXP         YCRC             UPLUG4       40 41   SYNDIV       SYNINI           UPLUG4L      41 42   SYNINI       SYNON            UPLUG4U      42 43   SYNON        YFERASE      *   YFERASE      43 44   YGPNT        YFWR         *   YFWR         44 45   YGPNT?       41CL             BAUD96       45 46   YGPNT-       BAUD             BAUD48       46 47   YGETLB       PBAUD            BAUD24       47 48   YGETUB       SERON            BAUD12       48 49   YPPNT        SERINI           SERINI       49 50   YPPNT?       YGETLB       *   YGETLB       50 51   YPPNT-       YGETUB       *   YGETUB       51 52   YPUTLB       YPUTLB       *   YPUTLB       52 53   YPUTUB       YPUTUB       *   YPUTUB       53 54   ROMID4       YEXP         *   YEXP         54 55   YCRC         YIMP         *   YIMP         55 56   YFERASE      IMDB?        *   IMDB?        56 57   YFWR         YPPNT            PLUGP        57 58   CHKXROM      YPPNT?           UPLUGP       58 59   YFNS?        YPPNT-           PLUGH        59 60   YBPNT        SYNDIV           UPLUGH       60 61   YBPNT?       YFNS?        *   YFNS?        61 62   YBUILD       MAPDIS       *   MAPDIS       62 63   41CL         MAPEN        *   MAPEN        63

The beauty of this reorg is that MMU?, MMUEN and MMUDIS has the same XROM ID for both ROMs and can be used to manage the MMU.
01-02-2018, 06:59 PM
Post: #24
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-02-2018 06:56 PM)Sylvain Cote Wrote:  Small suggestion ...

We could simply ask Monte to reorganize the FAT entries of the YFNX ROM to match as possible the ones from the YFNZ ROM.

As example, the following table contains my take of YFNX reorganized in the YFNX-UPD column: (lines with * has the same XROM for the same functions)
Code:
XR   YFNX-2C      YFNX-UPD     *   YFNZ-4F      XR --   ----------   ----------   -   ----------   --  0   ROMID        ROMID            ROMID         0  1   MMUDIS       MMUCLS           MMUCLR        1  2   MMUEN        MMUDIS       *   MMUDIS        2  3   MMU?         MMUEN        *   MMUEN         3  4   MMUCLP       MMU?         *   MMU?          4  5   MMUCLS       MMUCLP           TURBOX        5  6   PPLUG        ROMID2           TURBO2        6  7   PLUG         ROMID3           TURBO5        7  8   LOCK         ROMID4           TURBO10       8  9   UNLOCK       TURBO            TURBO20       9 10   LOCK?        PTURBO           TURBO50      10 11   EXPG         TURBO?       *   TURBO?       11 12   MVPG         YPOKE        *   YPOKE        12 13   EXCFG        YPEEK        *   YPEEK        13 14   RCLCFG       YMCLR        *   YMCLR        14 15   STOCFG       YMCPY        *   YMCPY        15 16   MAPDIS       YBPNT        *   YBPNT        16 17   MAPEN        YBPNT?       *   YBPNT?       17 18   ROMID2       YBUILD       *   YBUILD       18 19   PTURBO       PLUG             PLUG1        19 20   TURBO        PPLUG            PLUG1L       20 21   TURBO?       LOCK             PLUG1U       21 22   YPOKE        UNLOCK           PLUG2        22 23   YPEEK        LOCK?            PLUG2L       23 24   YMCLR        EXPG             PLUG2U       24 25   YMCPY        MVPG             PLUG3        25 26   IMDBF        EXCFG            PLUG3L       26 27   IMDBR        RCLCFG           PLUG3U       27 28   IMDBF?       STOCFG           PLUG4        28 29   PIMDB?       IMDBF            PLUG4L       29 30   IMDB?        IMDBR            PLUG4U       30 31   IMDBCPY      IMDBF?           UPLUG1       31 32   IMDBINS      PIMDB?           UPLUG1L      32 33   IMDBUPD      IMDBCPY          UPLUG1U      33 34   ROMID3       IMDBINS          UPLUG2       34 35   PBAUD        IMDBUPD          UPLUG2L      35 36   BAUD         YGPNT            UPLUG2U      36 37   SERINI       YGPNT?           UPLUG3       37 38   SERON        YGPNT-           UPLUG3L      38 39   YIMP         CHKXROM          UPLUG3U      39 40   YEXP         YCRC             UPLUG4       40 41   SYNDIV       SYNINI           UPLUG4L      41 42   SYNINI       SYNON            UPLUG4U      42 43   SYNON        YFERASE      *   YFERASE      43 44   YGPNT        YFWR         *   YFWR         44 45   YGPNT?       41CL             BAUD96       45 46   YGPNT-       BAUD             BAUD48       46 47   YGETLB       PBAUD            BAUD24       47 48   YGETUB       SERON            BAUD12       48 49   YPPNT        SERINI           SERINI       49 50   YPPNT?       YGETLB       *   YGETLB       50 51   YPPNT-       YGETUB       *   YGETUB       51 52   YPUTLB       YPUTLB       *   YPUTLB       52 53   YPUTUB       YPUTUB       *   YPUTUB       53 54   ROMID4       YEXP         *   YEXP         54 55   YCRC         YIMP         *   YIMP         55 56   YFERASE      IMDB?        *   IMDB?        56 57   YFWR         YPPNT            PLUGP        57 58   CHKXROM      YPPNT?           UPLUGP       58 59   YFNS?        YPPNT-           PLUGH        59 60   YBPNT        SYNDIV           UPLUGH       60 61   YBPNT?       YFNS?        *   YFNS?        61 62   YBUILD       MAPDIS       *   MAPDIS       62 63   41CL         MAPEN        *   MAPEN        63

The beauty of this reorg is that MMU?, MMUEN and MMUDIS has the same XROM ID for both ROMs and can be used to manage the MMU.

Bingo! All thumbs up.
01-02-2018, 07:22 PM
Post: #25
 Monte Dalrymple Member Posts: 193 Joined: Jan 2014
RE: HP-41CL: Design request (YFNZ/YFNX)
While I am not categorically opposed to reorganizing the FAT for the two modules,
I still don't understand why this is such a big deal. In my opinion, if you don't know
the configuration of your machine, you shouldn't be running programs that rely on
a certain configuration. It's simple to force the default configuration by disabling the
MMU and then programming the configuration you want. This is what the YRES
function is for.
01-02-2018, 09:22 PM (This post was last modified: 01-02-2018 09:23 PM by PeterP.)
Post: #26
 PeterP Member Posts: 64 Joined: Jul 2015
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-02-2018 07:22 PM)Monte Dalrymple Wrote:  While I am not categorically opposed to reorganizing the FAT for the two modules,
I still don't understand why this is such a big deal. In my opinion, if you don't know
the configuration of your machine, you shouldn't be running programs that rely on
a certain configuration. It's simple to force the default configuration by disabling the
MMU and then programming the configuration you want. This is what the YRES
function is for.

FWIW, I can see both sides of argument. It has not been a problem for me, but that could be due to my limited use and sophistication. Just from a programmer-perfectionist perspective, I do admit that I like he elegance of Sylvain’s idea - same functions with same spot in FAT in both modules (where possible). It seems kinda a bit more neat. Fully admit, probably more OCD than practical relevance for almost all users, but definitely befitting the amazing design and capabilities of the CL.

Cheers,

PeterP
01-02-2018, 10:00 PM
Post: #27
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-02-2018 07:22 PM)Monte Dalrymple Wrote:  While I am not categorically opposed to reorganizing the FAT for the two modules,
I still don't understand why this is such a big deal. In my opinion, if you don't know
the configuration of your machine, you shouldn't be running programs that rely on
a certain configuration. It's simple to force the default configuration by disabling the
MMU and then programming the configuration you want. This is what the YRES
function is for.

Sure - for manual recoveries.

Take a look at my automatic restore procedure and you will see the ugly hacks needed to mitigate the issue: https://github.com/isene/hp-41_CL/blob/m...restore.41

Similarily, any ROMs that rely on YFNX functions would break (and potentially do damage) if YFNZ got popped in and replaced YFNX.

Warning to Focal programmers: Do not use YFNX functions in your programs - it is deemed unsafe to do so.

The clean solution proposed by Sylvain would indeed be nice. Like he said, "The beauty of this reorg is that MMU?, MMUEN and MMUDIS has the same XROM ID for both ROMs and can be used to manage the MMU."
01-02-2018, 10:58 PM
Post: #28
 Monte Dalrymple Member Posts: 193 Joined: Jan 2014
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-02-2018 10:00 PM)Geir Isene Wrote:  Sure - for manual recoveries.

Take a look at my automatic restore procedure and you will see the ugly hacks needed to mitigate the issue: https://github.com/isene/hp-41_CL/blob/m...restore.41

Similarily, any ROMs that rely on YFNX functions would break (and potentially do damage) if YFNZ got popped in and replaced YFNX.

Warning to Focal programmers: Do not use YFNX functions in your programs - it is deemed unsafe to do so.

The clean solution proposed by Sylvain would indeed be nice. Like he said, "The beauty of this reorg is that MMU?, MMUEN and MMUDIS has the same XROM ID for both ROMs and can be used to manage the MMU."

I must be slow today. Why is YRES only useful for manual recoveries?

YRES is identical to MMUDIS, except that it resides in the Time Module FAT and is
therefor ALWAYS AVAILABLE. Executing YRES, even in a program, places the
machine in a known state, with YFNZ located in Page 7. Is this not sufficient?

Can you give an example where executing a function in YFNX is unsafe? Perhaps
my definition of unsafe is different. My definition of unsafe is where something is
done to Flash memory. If YFNX is not present, but somehow YFNZ is present, the
ONLY way that YFNZ could write to Flash is if it were located in RAM and you had
somehow programmed the MMU to point to that RAM copy of YFNZ instead of
YFNX. But this circumstance requires a fair amount of operator error, or a virus,
or a high radiation environment to arrange.
01-02-2018, 11:13 PM
Post: #29
 rprosperi Senior Member Posts: 2,552 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
Like Peter, I see both sides of this.

Also like Peter, Sylvain's proposed solution appeals to the OCD leanings I typically follow; this new mapping of the XROM IDs is elegant and appealing.

But, I really think too big a deal is being made of this "problem". YFNX has been used safely for several years, by a lot of people, without issues.

Geir - you've obviously been heavily involved in using lots of different ROMs and configurations while developing and documenting your recent CL Update via HP-IL and backup system updates (and btw, thanks for sharing these, just following their evolution from the proverbial armchair has taught me much) and I've found that's it's during these times that the lion's share of the kinds of problems you describe occur, not during use of the finished tools, day to day calculating or casual programming.

Also I think it's quite unfair to say "Warning to Focal programmers: Do not use YFNX functions in your programs - it is deemed unsafe to do so." Maybe it's reasonable to say that you've found YFNX unsafe under some very specific circumstances, but the general statement you've made can scare folks aware from using it at all. The tools you're making probably can be equally unsafe under specific circumstances, but that doesn't mean they should be categorized as unsafe for use.

Ignoring for a moment the number of hours/days of Monte's time to do this, what about the impacts of changing the YFNX XROM IDs on programs people already have written? Surely these impacts are as large or likely larger (IMHO) than those resulting from the rare cases that can occur due to the hardware issues with voltage or with loading bad flash pages you have alluded to. As an example, a program using the original YMCOPY to copy a page will now execute MVPG, moving the page. Changing what an API does after the programs have been written is always a bad idea.

And finally there's the time you're asking someone else to spend, on behalf of the community, but really to fix a problem only you've found important enough to report. I don't see (yet) clear support to justify such a change; however it is possible support may come as more users read this thread and comment. In the interim, I have to ask that if this is such a big problem, why not modify this ROM yourself (source is available), and offer it to the community as an option?

--Bob Prosperi
01-02-2018, 11:48 PM (This post was last modified: 01-03-2018 12:00 AM by Geir Isene.)
Post: #30
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
And that is a good point. I will settle with that.

May I finally ask what the ramifications from other modules would be to make an alternative YFNX with a) Sylvain's elegant FAT reorganisation, or b) simply making an alternative YFNX with XROM# 31? What could or would break?
01-03-2018, 02:50 AM
Post: #31
 mfleming Member Posts: 241 Joined: Jul 2015
RE: HP-41CL: Design request (YFNZ/YFNX)
Eh, at the risk of being chased off with rocks and sticks, I'll repeat a suggestion I made in an earlier thread. If you're entering the program by hand, why not just avoid having the function compiled to an XROM reference? Crude, but as Sylvain showed, easy to do. For example

Code:
 LBL "MMUDIS" XEQ "MMUDIS"   ; Seen as MMUEN with YFNX

Delete the label afterward and the reference to "MMUDIS" should be resolved to the correct YFNS or YFNX FAT entry when your FOCAL program is run.

~Mark
(slowly backing away with arms protectively wrapped around head)

Where's my personal jet pack?
01-03-2018, 04:43 AM (This post was last modified: 01-03-2018 04:47 AM by Sylvain Cote.)
Post: #32
 Sylvain Cote Senior Member Posts: 847 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-03-2018 02:50 AM)mfleming Wrote:  Eh, at the risk of being chased off with rocks and sticks, I'll repeat a suggestion I made in an earlier thread. If you're entering the program by hand, why not just avoid having the function compiled to an XROM reference? Crude, but as Sylvain showed, easy to do. For example

Code:
 LBL "MMUDIS" XEQ "MMUDIS"   ; Seen as MMUEN with YFNX

Delete the label afterward and the reference to "MMUDIS" should be resolved to the correct YFNS or YFNX FAT entry when your FOCAL program is run.

~Mark
(slowly backing away with arms protectively wrapped around head)

This is so funny, I suggested it in Mark thread, then forgot about it, then Mark came back with the same suggestion but for this thread. Bravo Mark!
I was not sure that it will work with a do-or-skip-condition like MMU? but it does perfectly.

Setup:
Code:
MMUDIS MMUCLR "YFNX" PLUG1L

Test program:
Code:
LBL "ISMMU?" // is MMU active CF 00 LBL "MMU?" XEQ "MMU?"   // do one BST and then delete LBL "MMU?" SF 00 END

Test program after deleting LBL "MMU?":
Code:
LBL "ISMMU?" // is MMU active CF 00 XEQ "MMU?"   // do next step if MMU is enabled or skip next step if MMU is disabled SF 00 END

Test #1: MMU disable, executing YFNZ::MMU? XROM 15,04, flag 0 should be clear
Code:
MMUDIS XEQ "ISMMU?"

Test #2: MMU enable, executing YFNX::MMU? XROM 15,03, flag 0 should be set
Code:
MMUEN XEQ "ISMMU?"

Test #3: MMU disable, executing YFNZ::MMU? XROM 15,04, flag 0 should be clear
Code:
MMUDIS XEQ "ISMMU?"
01-03-2018, 07:08 AM (This post was last modified: 01-03-2018 07:21 AM by Ángel Martin.)
Post: #33
 Ángel Martin Senior Member Posts: 915 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-02-2018 11:48 PM)Geir Isene Wrote:  May I finally ask what the ramifications from other modules would be to make an alternative YFNX with a) Sylvain's elegant FAT reorganisation, or b) simply making an alternative YFNX with XROM# 31? What could or would break?

As they include functions from YFNS/YFNX, the following modules would have to be rev'd :

PWCL PowerCL
PWRX PowerCL_Extreme
XPMM CL Expanded Memory

If the FAT is changed, every FOCAL program using Y-Fns will be suspect. Say good-bye to backwards compatibility...

and if you happen to have several CL boards, this is going to force you to update the OS sectors of the old ones? No thanks, I want my OS sector to still have YFNS as-is, not capable of damaging FLASH unless I move it to RAM - and without the YLIB dependency.

Now I seem to be running from a group of people with pitchforks and torches, but nothing comes for free!!
01-03-2018, 07:11 AM
Post: #34
 Monte Dalrymple Member Posts: 193 Joined: Jan 2014
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-02-2018 10:00 PM)Geir Isene Wrote:  Sure - for manual recoveries.

Take a look at my automatic restore procedure and you will see the ugly hacks needed to mitigate the issue: https://github.com/isene/hp-41_CL/blob/m...restore.41

Similarily, any ROMs that rely on YFNX functions would break (and potentially do damage) if YFNZ got popped in and replaced YFNX.

Warning to Focal programmers: Do not use YFNX functions in your programs - it is deemed unsafe to do so.

The clean solution proposed by Sylvain would indeed be nice. Like he said, "The beauty of this reorg is that MMU?, MMUEN and MMUDIS has the same XROM ID for both ROMs and can be used to manage the MMU."

My questions don't seem to get answered, but I'll keep trying.

I looked at the automatic restore procedure. The "hack" in lines 19-21 should be
replaced by two steps:

YRES
MMUCLR

Lines 36-37 should be replaced by:

"4LIB 4"
PPLUG

Lines 143-145 should be replaced by two steps:

YRES
MMUCLR

Why are YUIL and YUPS loaded to RAM in lines 149-154? Why do you think this is
necessary? And then lines 155-158 become:

"YUIL C"
PPLUG
"YUPS D"
PPLUG

As far as YFNX disappearing and getting replaced by YFNZ, I'd like to see a
specific example of "potentially do damage." There is a reason that YFNZ is
"stupid." It CANNOT disrupt Flash memory unless the user goes to the trouble
of copying it to RAM BEFORE doing a YFWR or YFERASE. And YPOKE cannot
operate on Flash, ever, BY DESIGN.

The reverse case, where YFNX is loaded but the user thinks that YFNZ is
active, is why the functions YFWR, YFERASE and YPOKE should NOT have
the same XROM IDs. Because the YFNX versions of those functions CAN
operate directly on Flash, and they all REQUIRE that the user not play
Russian roulette.

Sylvain's solution is okay. But placing the ROMID labels in random spots
defeats something I was trying to do. Those labels show up in CAT 2, and
make it easier to find specific function names during the catalog, because
the functions are grouped into categories. I thought it might be useful not
to have to scroll through the entire catalog, but I guess I'm the only person
who uses CAT 2 that way.
01-03-2018, 07:16 AM
Post: #35
 Ángel Martin Senior Member Posts: 915 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-02-2018 10:00 PM)Geir Isene Wrote:  Warning to Focal programmers: Do not use YFNX functions in your programs - it is deemed unsafe to do so.

That's a few notches above the realm of plausible, really not the case!
01-03-2018, 07:30 AM (This post was last modified: 01-03-2018 08:09 AM by Geir Isene.)
Post: #36
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
As I said, I'll settle with Ron's good points.

And I got my answers as to what would break.

As for questions to me; I avoid YRES as it needs on OS sector update. YUIL and YUPS are loaded into RAM to allow for update of sector 0x060. And Monte is right (of course) when it comes to safety regarding flash sectors. So far I've only lost some 8 hours of casual work and only a couple of hours of billed work (USD 400) from corrupted HEPAX RAM - so no catastrophies as such. As I use my 41CL as a daily tool also in work, I do rely on it to not lock up to the point of having to remove the batteries.
 « Next Oldest | Next Newest »

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