Post Reply 
41CL CLXPMEM - YSTO, YRCL and YX<> index problem
08-28-2018, 06:07 PM
Post: #1
41CL CLXPMEM - YSTO, YRCL and YX<> index problem
Hi, I am studying the CLXPMEM module.
In a test on my nsimII emulator (soon I will receive my 41CL board)
with the command YSTO, value 500, I think that the vale of the X register
is stored in the register number 500, But with YRCL 500 I do not obtain any value.
With YSTO 500 and YRCL 500 no errors is displayed.
But if I use the command YX<> 500 the value of X register is swapped with
the register number 500, as I can expect to obtain.
I chose the value 500 because is in the range of MAIN memory addresses
(192-511, Hex 0CD-1FF). Where I am wrong?
Thank you so much for every help!!!
Find all posts by this user
Quote this message in a reply
08-28-2018, 06:53 PM
Post: #2
RE: 41CL CLXPMEM - YSTO, YRCL and YX<> index problem
(08-28-2018 06:07 PM)Podalirius Wrote:  Hi, I am studying the CLXPMEM module.
In a test on my nsimII emulator (soon I will receive my 41CL board)
with the command YSTO, value 500, I think that the vale of the X register
is stored in the register number 500, But with YRCL 500 I do not obtain any value.
With YSTO 500 and YRCL 500 no errors is displayed.
But if I use the command YX<> 500 the value of X register is swapped with
the register number 500, as I can expect to obtain.
I chose the value 500 because is in the range of MAIN memory addresses
(192-511, Hex 0CD-1FF). Where I am wrong?
Thank you so much for every help!!!

I believe this module will only work with CL boards, as they have memory installed at different addresses than used in a normal 41 (or emulator). e.g. the first block (out of 3) of "Y" registers is located at address 0x801.

But I am not at all familiar with the nsimII emulator, so the above answer is possibly not correct, but would have to wait for Monte or Angel to confirm or clarify this.

--Bob Prosperi
Find all posts by this user
Quote this message in a reply
08-29-2018, 04:57 AM (This post was last modified: 08-29-2018 05:28 AM by Ángel Martin.)
Post: #3
RE: 41CL CLXPMEM - YSTO, YRCL and YX<> index problem
(08-28-2018 06:07 PM)Podalirius Wrote:  I chose the value 500 because is in the range of MAIN memory addresses
(192-511, Hex 0CD-1FF). Where I am wrong?

the argument 500 refers to the 500th. register within the CL-Expanded memory area, i.e. it's got nothing to do with main RAM addresses. In other words, it's an INDEX, not an address.

Without the CL board these functions are therefore meaningless, because that memory area does not exist.

For instance, using them on a standard HP-41 they properly return NONEXISTENT, as there's a memory existence check embedded into their MCODE.

Using them on emulators may yield confusing results if the emulator does not handle memory addresses properly (i.e. exactly like the original machine). For instance, V41 misinterprets the addresses over 3FF by simply wrapping the "XS" digit back to "0", so it always defaults to the 000-3FF range. If there's Extended memory that *may* match some of the emulated registers, giving you the impression that it is working - but it's really storing the values in unexpected areas.

Maybe this is also what happens with your emulator, so make sure the RAM SELECT instruction doesn't override values above 3FF in your implementation .

BTW the latest version of the CLXPMEM module , rev "2D" includes a CL-Board presence check; I added that precisely to avoid the ambiguous response of V41 that I use extensively. You get the "NO CL" error msg and the operation is not performed. If you don't see that error msg you're not using the latest revision...

Cheers,
ÁM
Find all posts by this user
Quote this message in a reply
08-29-2018, 07:10 AM
Post: #4
RE: 41CL CLXPMEM - YSTO, YRCL and YX<> index problem
(08-29-2018 04:57 AM)Ángel Martin Wrote:  
(08-28-2018 06:07 PM)Podalirius Wrote:  I chose the value 500 because is in the range of MAIN memory addresses
(192-511, Hex 0CD-1FF). Where I am wrong?

the argument 500 refers to the 500th. register within the CL-Expanded memory area, i.e. it's got nothing to do with main RAM addresses. In other words, it's an INDEX, not an address.

Without the CL board these functions are therefore meaningless, because that memory area does not exist.

For instance, using them on a standard HP-41 they properly return NONEXISTENT, as there's a memory existence check embedded into their MCODE.

Using them on emulators may yield confusing results if the emulator does not handle memory addresses properly (i.e. exactly like the original machine). For instance, V41 misinterprets the addresses over 3FF by simply wrapping the "XS" digit back to "0", so it always defaults to the 000-3FF range. If there's Extended memory that *may* match some of the emulated registers, giving you the impression that it is working - but it's really storing the values in unexpected areas.

Maybe this is also what happens with your emulator, so make sure the RAM SELECT instruction doesn't override values above 3FF in your implementation .

BTW the latest version of the CLXPMEM module , rev "2D" includes a CL-Board presence check; I added that precisely to avoid the ambiguous response of V41 that I use extensively. You get the "NO CL" error msg and the operation is not performed. If you don't see that error msg you're not using the latest revision...

Cheers,
ÁM

Hi, Thank you very much!
I use the nsimII emulator that support (in beta version) the 41CL V3.
I have upgraded this emulator with the last rom_file_180706.zip
I have installed in nsimII 41CL emulation, LIB#4, OSX3, YFNX, PWRX and XPMM,
thanks to all the helps obtained in this Forum, without any problem.
I think that real 41CL is so much better that emulator, but the emulator is actually
the only system I have to study and make experience, and also to test
before to make changes to the real 41CL (I am witing the receive of my 41CL board).
to avoid 41CL damaging.
I think that addressing of many pages is missing in a 41CL V3,
but the instruction YX<> seems to vork well, and the YSTO and YRCL do not
return any error. Without any other help, I think that only I can test this with the real 41CL.
Again, Thank you so much!!!
Find all posts by this user
Quote this message in a reply
08-31-2018, 07:49 PM (This post was last modified: 08-31-2018 08:19 PM by cgh.)
Post: #5
RE: 41CL CLXPMEM - YSTO, YRCL and YX<> index problem
Hello,

Normally, nsimII handles the 4 RAM pages (0x800, 0x801, 0x802 and 0x803) and RAMSLCT (DADD=C) loads the address to 0x804000 as described in the newt.pdf (see DADDR=C page 76).
I never really look for CLXPMEM, as I own an old 41CL.

So, I have tried.
After installing the YFNX, 4LIB and XPPM:
1234
YSTO 500
CLX
YRCL 500 -> returns 1234 to X. Is this the expected behavior ?

Christophe
Find all posts by this user
Quote this message in a reply
09-01-2018, 06:31 AM
Post: #6
RE: 41CL CLXPMEM - YSTO, YRCL and YX<> index problem
(08-31-2018 07:49 PM)cgh Wrote:  After installing the YFNX, 4LIB and XPPM:
1234
YSTO 500
CLX
YRCL 500 -> returns 1234 to X. Is this the expected behavior ?

Of course.
Find all posts by this user
Quote this message in a reply
09-03-2018, 03:49 PM (This post was last modified: 09-03-2018 03:54 PM by Podalirius.)
Post: #7
RE: 41CL CLXPMEM - YSTO, YRCL and YX<> index problem
(08-31-2018 07:49 PM)cgh Wrote:  Hello,

Normally, nsimII handles the 4 RAM pages (0x800, 0x801, 0x802 and 0x803) and RAMSLCT (DADD=C) loads the address to 0x804000 as described in the newt.pdf (see DADDR=C page 76).
I never really look for CLXPMEM, as I own an old 41CL.

So, I have tried.
After installing the YFNX, 4LIB and XPPM:
1234
YSTO 500
CLX
YRCL 500 -> returns 1234 to X. Is this the expected behavior ?

Christophe

Hi, Thank you so much for your help supporting nsimII.
In my case:
1234
YSTO 500
CLX
YRCL 500 -> returns nothings, the X register is already at value 0.
I think that some mistakes occurred when I upgraded the nsimII to the latest
41CL rom file.
When I have a bit of time, I update nsimII again.
Again I thank you very much.
Find all posts by this user
Quote this message in a reply
Post Reply 




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