HP-41CL: Design request (YFNZ/YFNX)
12-27-2015, 10:31 PM
Post: #1
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
HP-41CL: Design request (YFNZ/YFNX)
The more I perfect my CL setup, the more I come to realize that the current discrepancies in the FAT tables of the YFNZ and YFNX creates quite a mess.

There are situations where I want to disable the MMU to revert from the YFNX to the YFNZ - like when updating the CL flash sectors. FOCAL programs that are designed to run with the YFNZ can wreck havoc when run with the YFNX and vice versa. It becomes a liability to have certain programs available - especially assigned to keys.

Can we please have the same XROM numbers for the identical functions between the YFNZ and the YFNX? This should be easy enough - to reorganize the FAT tables of the YFNX.
12-27-2015, 11:10 PM (This post was last modified: 12-27-2015 11:10 PM by Monte Dalrymple.)
Post: #2
 Monte Dalrymple Member Posts: 193 Joined: Jan 2014
RE: HP-41CL: Design request (YFNZ/YFNX)
(12-27-2015 10:31 PM)Geir Isene Wrote:  The more I perfect my CL setup, the more I come to realize that the current discrepancies in the FAT tables of the YFNZ and YFNX creates quite a mess.

There are situations where I want to disable the MMU to revert from the YFNX to the YFNZ - like when updating the CL flash sectors. FOCAL programs that are designed to run with the YFNZ can wreck havoc when run with the YFNX and vice versa. It becomes a liability to have certain programs available - especially assigned to keys.

Can we please have the same XROM numbers for the identical functions between the YFNZ and the YFNX? This should be easy enough - to reorganize the FAT tables of the YFNX.

Hmm... what is the advantage of reverting from YFNX to YFNZ when updating Flash sectors?

This is more than just a simple FAT change, because it impacts PWRX, for example. I originally tried to keep functions aligned, but threw that idea out the window when only about 20 of the 64 functions have the same name or equivalent functionality.
12-27-2015, 11:23 PM
Post: #3
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(12-27-2015 11:10 PM)Monte Dalrymple Wrote:  Hmm... what is the advantage of reverting from YFNX to YFNZ when updating Flash sectors?

Well - when doing MMUDIS, the YFNZ automatically comes into play, and then the (un)fun starts. My Y2RAM program follows the flash-update procedure and does just this:

Code:
     001*LBL "Y2RAM"     002 MMUDIS     003 MMUDIS (need to do this to secure the YFNZ/YFNX situation)     004 MMUCLR     005 TURBO50     006  SERINI     007  BAUD48     008 "007>805"     009 YMCPY     010 "805-RAM"     011 PLUG1L     012 MMUEN     013 "167>806"     014 YMCPY     015 "806-RAM"     016 PLUG1U     017 TONE 7     018 TONE 9     019 END
12-27-2015, 11:35 PM
Post: #4
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
Could the soultion to my problem be to update Flash RAM page 0x007 by overwriting YFNZ with YFNX?
12-28-2015, 12:06 AM
Post: #5
 Monte Dalrymple Member Posts: 193 Joined: Jan 2014
RE: HP-41CL: Design request (YFNZ/YFNX)
(12-27-2015 11:35 PM)Geir Isene Wrote:  Could the soultion to my problem be to update Flash RAM page 0x007 by overwriting YFNZ with YFNX?

I suppose you could do that, but I guess I don't understand why you even need your Y2RAM routine. There are only two reasons you ever need YFNF in RAM: you're updating the sector that contains YFNF, or you want to patch it so that you can modify the OS sector. Neither of these happen often enough to need a routine.

At the same time, why do you want to use a RAM copy of YFNZ? If your copy of YFNX is current you should be using that to do the Flash operations, and it also does not need to be in RAM to work, unless you need to patch it to work on the OS sector.

Those first steps in the update document are to get you to the point where YFNX and YFNF are available. Once you have them you don't need to futz around with copying code to RAM unless you are updating the OS sector. And that should be a VERY rare occurance.
12-28-2015, 12:10 AM (This post was last modified: 12-28-2015 12:10 AM by Geir Isene.)
Post: #6
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(12-28-2015 12:06 AM)Monte Dalrymple Wrote:
(12-27-2015 11:35 PM)Geir Isene Wrote:  Could the soultion to my problem be to update Flash RAM page 0x007 by overwriting YFNZ with YFNX?

I suppose you could do that, but I guess I don't understand why you even need your Y2RAM routine. There are only two reasons you ever need YFNF in RAM: you're updating the sector that contains YFNF, or you want to patch it so that you can modify the OS sector. Neither of these happen often enough to need a routine.

At the same time, why do you want to use a RAM copy of YFNZ? If your copy of YFNX is current you should be using that to do the Flash operations, and it also does not need to be in RAM to work, unless you need to patch it to work on the OS sector.

Those first steps in the update document are to get you to the point where YFNX and YFNF are available. Once you have them you don't need to futz around with copying code to RAM unless you are updating the OS sector. And that should be a VERY rare occurance.

Ah, OK. Got that.

Then I guess it only leaves my problem of the MMU going "offline" every now and then
12-28-2015, 02:25 AM
Post: #7
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
And - the problem does apply to situations where power is lost for a little while - like sometimes when you're not quick enough in changing batteries.
12-29-2015, 12:33 PM
Post: #8
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(12-28-2015 12:06 AM)Monte Dalrymple Wrote:  At the same time, why do you want to use a RAM copy of YFNZ? If your copy of YFNX is current you should be using that to do the Flash operations, and it also does not need to be in RAM to work, unless you need to patch it to work on the OS sector.

I realized why I habitually did the copy of YFNZ to RAM - it's because of the YWALL fuction of the Power CL (and earlier sibling modules) - it clearly recommends doing so. I am not sure why, though.
12-29-2015, 06:49 PM
Post: #9
 Ángel Martin Senior Member Posts: 915 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(12-29-2015 12:33 PM)Geir Isene Wrote:  I realized why I habitually did the copy of YFNZ to RAM - it's because of the YWALL fuction of the Power CL (and earlier sibling modules) - it clearly recommends doing so. I am not sure why, though.

Because it predated the advent of the YFNX function set and wasn't updated afterwards. Not sure it's worth the time to revisit the idea, specially given that depending on the CL board revisions the last flash sector has different behaviors: whole vs. individual block erasing rules differ...
12-29-2015, 06:52 PM (This post was last modified: 12-29-2015 06:52 PM by Geir Isene.)
Post: #10
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(12-29-2015 06:49 PM)Ángel Martin Wrote:
(12-29-2015 12:33 PM)Geir Isene Wrote:  I realized why I habitually did the copy of YFNZ to RAM - it's because of the YWALL fuction of the Power CL (and earlier sibling modules) - it clearly recommends doing so. I am not sure why, though.

Because it predated the advent of the YFNX function set and wasn't updated afterwards. Not sure it's worth the time to revisit the idea, specially given that depending on the CL board revisions the last flash sector has different behaviors: whole vs. individual block erasing rules differ...

So, I can do away with the YWALL and just do the same with the YFERASE and YFWR of the 800 and 804?

Also; What are the 801-803 for?
12-29-2015, 09:21 PM
Post: #11
 Monte Dalrymple Member Posts: 193 Joined: Jan 2014
RE: HP-41CL: Design request (YFNZ/YFNX)
(12-29-2015 06:52 PM)Geir Isene Wrote:  So, I can do away with the YWALL and just do the same with the YFERASE and YFWR of the 800 and 804?

Also; What are the 801-803 for?

Yes, I would do the writes to Flash directly.

801-803 are Alternate Memory (as shown on p. 17 of the Memory Reference.) Using this Alternate Memory is explained on p. 21 of the 41CL Memory Functions manual. These pages are a region of RAM where you can store alternate copies of the regular 41C memory, much the same way that the alternate MMU registers allow alternate configurations.
01-01-2018, 04:26 PM
Post: #12
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
Revisiting this old thread and reiterating my request.

My ISENE.ROM has the routine XMFILE? relying on two routines from YFNZ (namely YFNS? and YPEEK), but when this routine is run with YFNX plugged instead, those two functions are something entirely different. And even if I did an update to my module to make it instead compatible with YFNX, it would break if YFNZ was plugged instead (like with a MEMORY LOST or some lock-up). I would love to have a YFNX module that would at least have the same XROM numbers for the same functions as the YFNZ. Or else MY FOCAL programs using any functions from either YFNZ Or YFNX would randomly break or in the worst case wreck my CL.
01-01-2018, 07:21 PM
Post: #13
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
Or - at the very least - could the YFNX get a YFNX? function to check if YFNX specifically is plugged?
01-02-2018, 06:03 AM
Post: #14
 Monte Dalrymple Member Posts: 193 Joined: Jan 2014
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-01-2018 07:21 PM)Geir Isene Wrote:  Or - at the very least - could the YFNX get a YFNX? function to check if YFNX specifically is plugged?

The FAT for both YFNZ and YFNX is full. Plus, I doubt that there is space in the
ROM for a redefined function.

I can write a function that will query the address space looking for the presence
of either YFNX or YFNZ and report which one it finds. You could then include this
function in your ROM and use the result to control which XROM number you call.
Would that work? If so, how would you like the result signaled? A different value
in X or something like that?
01-02-2018, 07:40 AM (This post was last modified: 01-02-2018 07:53 AM by Ángel Martin.)
Post: #15
 Ángel Martin Senior Member Posts: 915 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-02-2018 06:03 AM)Monte Dalrymple Wrote:
(01-01-2018 07:21 PM)Geir Isene Wrote:  Or - at the very least - could the YFNX get a YFNX? function to check if YFNX specifically is plugged?

The FAT for both YFNZ and YFNX is full. Plus, I doubt that there is space in the
ROM for a redefined function.

I can write a function that will query the address space looking for the presence
of either YFNX or YFNZ and report which one it finds. You could then include this
function in your ROM and use the result to control which XROM number you call.
Would that work? If so, how would you like the result signaled? A different value in X or something like that?

Sorry but I personally think there's not a real issue with he YFNS / YFNX dichotomy. A simple trick may be to assign MMUEN - from the YFNS - to a key. This mutates into MMU? *after* executing it when the YFNX does replace YFNS.
• If YFNS is active, this key changes to YFNX
• If YFNX is active, this key just says "YES"

In other words, a perfectly compatible arrangement that respects all reasons to keep both sets and provides the easy way to get them switched.

Problem solved, yes?

Edited: In case you're not happy about this, there's already a sub-function in the PWRX module that interrogates for the presence of the YFNX module. The sub-function is aptly named ?YFNX, and it looks for the address of MMUEN to be the corresponding to the YFNX FAT. If not true, the "NO YFNX" message is shown and execution halted.
01-02-2018, 03:24 PM
Post: #16
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-02-2018 07:40 AM)Ángel Martin Wrote:  Sorry but I personally think there's not a real issue with he YFNS / YFNX dichotomy. A simple trick may be to assign MMUEN - from the YFNS - to a key. This mutates into MMU? *after* executing it when the YFNX does replace YFNS.
• If YFNS is active, this key changes to YFNX
• If YFNX is active, this key just says "YES"

In other words, a perfectly compatible arrangement that respects all reasons to keep both sets and provides the easy way to get them switched.

Problem solved, yes?

Edited: In case you're not happy about this, there's already a sub-function in the PWRX module that interrogates for the presence of the YFNX module. The sub-function is aptly named ?YFNX, and it looks for the address of MMUEN to be the corresponding to the YFNX FAT. If not true, the "NO YFNX" message is shown and execution halted.

Sorry, but none of these solutions are good enough.

The design decision to have XROM numbers point to different function in YFNX and YFNZ makes any FOCAL program using YFNX functions a real risk. It may wreck the CL. The YFNX module should come with a risk disclaimer that the user should never create FOCAL programs incorporating YFNX functions - as these may be interpreted as something totally different should you be so unlucky that the YFNZ pops into the MMU and you run your FOCAL program.

It would be far better to have the YFNX have a different XROM numer all together. That would avoid this problem.

Having FOCAL programs rely on PWRX as an additional dependency is just adding to the mess as that module would also go offline if the calc cleared the MMU and YFNZ popped into place.

And the scenario of the YFNX being replaced by YFNZ is not that unlikely. It happens with MEMORY LOST and it happens if you have bad contacts in your CL and the voltage drops. And it happens for other random reasons when one is experimenting and the calc locks up (XROM conflicts, loading bad flash pages, etc.)

These are not concerns for those who do not program in FOCAL. It is a concern for FOCAL programmers using YFNX functionality in FOCAL Programs.

Please consider a fix for this.
01-02-2018, 03:56 PM
Post: #17
 rprosperi Senior Member Posts: 2,551 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-02-2018 03:24 PM)Geir Isene Wrote:  ...
And the scenario of the YFNX being replaced by YFNZ is not that unlikely. It happens with MEMORY LOST and it happens if you have bad contacts in your CL and the voltage drops. And it happens for other random reasons when one is experimenting and the calc locks up (XROM conflicts, loading bad flash pages, etc.)

These are not concerns for those who do not program in FOCAL. It is a concern for FOCAL programmers using YFNX functionality in FOCAL Programs.

If you experience a MEMORY LOST (from any cause) then there are no FOCAL programs left intact, so running the wrong XROM functions can't happen until you restore your programs and configuration. Maybe I'm missing something, but this seems like a concern over a near-impossible scenario, no?

--Bob Prosperi
01-02-2018, 04:21 PM (This post was last modified: 01-02-2018 04:26 PM by Ángel Martin.)
Post: #18
 Ángel Martin Senior Member Posts: 915 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-02-2018 03:24 PM)Geir Isene Wrote:  It would be far better to have the YFNX have a different XROM numer all together. That would avoid this problem.

These are not concerns for those who do not program in FOCAL. It is a concern for FOCAL programmers using YFNX functionality in FOCAL Programs.

And how about including in your FOCAL program the instructions to plug the expected version of YFNS?

Here's the code for ?FNX, feel free to use it in your own modules:

Code:
0D8     "X" 04E     "N" 046     "F" 059     "Y" 03F     "?" 130     LDI S&X     3C2     CON:        "MMUEN " fcn. Id# 001     ?NC XQ      Get ROM address to A[3:0] 020     ->0800      [GTRMAD] 04B     JNC +09     [NOYFNS] 130     LDI S&X     0AC     CON:        "MMUEN" fcn. Address 366     ?A#C S&X    does it match? 02F     JC  +05     no, show error 04E     C=0 ALL     clean slate 01C     PT= 3     0A2     A<>C @PT    YFNP pg# to C(3) 3E0     RTN     020     XQ>GO       no return… 321     ?NC XQ      Show "NO_"  msg 10C     ->43C8      [NOMSG4] 019     "Y"     006     "F"         "NO YFNX" 00E     "N"     218     "X"     1F1     ?NC GO      LeftJ, Show and Halt 0FE     ->3F7C      [APEREX]
01-02-2018, 04:52 PM
Post: #19
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-02-2018 03:56 PM)rprosperi Wrote:
(01-02-2018 03:24 PM)Geir Isene Wrote:  ...
And the scenario of the YFNX being replaced by YFNZ is not that unlikely. It happens with MEMORY LOST and it happens if you have bad contacts in your CL and the voltage drops. And it happens for other random reasons when one is experimenting and the calc locks up (XROM conflicts, loading bad flash pages, etc.)

These are not concerns for those who do not program in FOCAL. It is a concern for FOCAL programmers using YFNX functionality in FOCAL Programs.

If you experience a MEMORY LOST (from any cause) then there are no FOCAL programs left intact, so running the wrong XROM functions can't happen until you restore your programs and configuration. Maybe I'm missing something, but this seems like a concern over a near-impossible scenario, no?

True with a MEMORY LOST (except as I do when I restore memory from a NoVRam and forget to do the plugging of YFNX) - but with hardware issues with voltage or with loading bad flash pages or with certain XROM conflicts, it does indeed occur.
01-02-2018, 04:54 PM
Post: #20
 Geir Isene Senior Member Posts: 567 Joined: Dec 2013
RE: HP-41CL: Design request (YFNZ/YFNX)
(01-02-2018 04:21 PM)Ángel Martin Wrote:
(01-02-2018 03:24 PM)Geir Isene Wrote:  It would be far better to have the YFNX have a different XROM numer all together. That would avoid this problem.

These are not concerns for those who do not program in FOCAL. It is a concern for FOCAL programmers using YFNX functionality in FOCAL Programs.

And how about including in your FOCAL program the instructions to plug the expected version of YFNS?

Here's the code for ?FNX, feel free to use it in your own modules:

Code:
0D8     "X" 04E     "N" 046     "F" 059     "Y" 03F     "?" 130     LDI S&X     3C2     CON:        "MMUEN " fcn. Id# 001     ?NC XQ      Get ROM address to A[3:0] 020     ->0800      [GTRMAD] 04B     JNC +09     [NOYFNS] 130     LDI S&X     0AC     CON:        "MMUEN" fcn. Address 366     ?A#C S&X    does it match? 02F     JC  +05     no, show error 04E     C=0 ALL     clean slate 01C     PT= 3     0A2     A<>C @PT    YFNP pg# to C(3) 3E0     RTN     020     XQ>GO       no return… 321     ?NC XQ      Show "NO_"  msg 10C     ->43C8      [NOMSG4] 019     "Y"     006     "F"         "NO YFNX" 00E     "N"     218     "X"     1F1     ?NC GO      LeftJ, Show and Halt 0FE     ->3F7C      [APEREX]

That's a possible hack.

But the design is still messy and a security risk. Why not mitigate the real issue?
 « Next Oldest | Next Newest »

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