Post Reply 
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
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.
Find all posts by this user
Quote this message in a reply
01-02-2018, 05:35 PM (This post was last modified: 01-02-2018 05:38 PM by Geir Isene.)
Post: #22
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.
Find all posts by this user
Quote this message in a reply
01-02-2018, 06:56 PM (This post was last modified: 01-02-2018 06:58 PM by Sylvain Cote.)
Post: #23
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.
Find all posts by this user
Quote this message in a reply
01-02-2018, 06:59 PM
Post: #24
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.
Find all posts by this user
Quote this message in a reply
01-02-2018, 07:22 PM
Post: #25
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.
Visit this user's website Find all posts by this user
Quote this message in a reply
01-02-2018, 09:22 PM (This post was last modified: 01-02-2018 09:23 PM by PeterP.)
Post: #26
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
Find all posts by this user
Quote this message in a reply
01-02-2018, 10:00 PM
Post: #27
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."
Find all posts by this user
Quote this message in a reply
01-02-2018, 10:58 PM
Post: #28
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.
Visit this user's website Find all posts by this user
Quote this message in a reply
01-02-2018, 11:13 PM
Post: #29
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
Find all posts by this user
Quote this message in a reply
01-02-2018, 11:48 PM (This post was last modified: 01-03-2018 12:00 AM by Geir Isene.)
Post: #30
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?
Find all posts by this user
Quote this message in a reply
01-03-2018, 02:50 AM
Post: #31
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)

"Don't assume quotations pulled from the Internet are genuine."
-- George Washington
Find all posts by this user
Quote this message in a reply
01-03-2018, 04:43 AM (This post was last modified: 01-03-2018 04:47 AM by Sylvain Cote.)
Post: #32
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?"
Find all posts by this user
Quote this message in a reply
01-03-2018, 07:08 AM (This post was last modified: 01-03-2018 07:21 AM by Ángel Martin.)
Post: #33
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!!
Find all posts by this user
Quote this message in a reply
01-03-2018, 07:11 AM
Post: #34
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.
Visit this user's website Find all posts by this user
Quote this message in a reply
01-03-2018, 07:16 AM
Post: #35
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!
Find all posts by this user
Quote this message in a reply
01-03-2018, 07:30 AM (This post was last modified: 01-03-2018 08:09 AM by Geir Isene.)
Post: #36
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.
Find all posts by this user
Quote this message in a reply
Post Reply 




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