1,024 additional Registers on the CL

[Ángel Martin]

If you haven't heard about the 41CL in the last couple of years you must have been on a Mars expedition, but even if you know all about it already this may be of interest. Building upon the 'Expanded Memory' concept, the new version of the CL Expanded Mem module now includes functions to access the RAM block located at 0x801 on an individual register basis.

Basically the XSTO _ _ _, XRCL _ _ _ and XX<> _ _ _ trio will let you store, recall and exchange data between the X register and any of the 1,024 extended registers on the upper RAM block. The functions prompt for an index between 0 and 1,023 - or use the next program line in a running program. Somehow similar to (but simpler than) the PEEKR and POKER functions, which work on absolute address within the "native" memory range.

This functionality is compatible with the memory back-up features of the module, which you can continue to use on the 802 and 803 RAM blocks.

No more data registers shortage, not if you use the CL. That's what I call a sizeable improvement ;-)

PS. Another new function (CLXRG) clears the entire block.

[Gene]

What a great addition!

20x20 determinant using Sandmatrix is now possible. :-)

[d b]

Angel;

And to a surveyor with the Surveyors Co Op, Super ROM, or Dzign on his cl; this will give him over 500 more x, y points in storage for the small work of writing an "is the point number bigger than 299?, do if true...." into it.

Did Monte know that or did you surprise him too?

[Monte Dalrymple]

(08-06-2016 07:30 PM)Den Belillo (Martinez Ca.) Wrote:  Did Monte know that or did you surprise him too?

I designed the CL with this in mind from the outset. But I'm not enough of a programmer to have done the software. I leave those kinds of things to 'Angel.

[Ángel Martin]

Well, this is really not a new development - it was there from the beginning, all along from the word go: it's in the hardware design!

And to take advantage of those registers the programs will need to be re-written; the new functions are not the same as the native STO/RCL... for instance there's no IND or STK addressing, hope you bear that in mind!

So unfortunately 20x20 determinants are not quite yet a done deal, and ditto for the surveyor's software - sorry!

[d b]

(08-06-2016 09:13 PM)Ángel Martin Wrote:  Well, this is really not a new development - it was there from the beginning, all along from the word go: it's in the hardware design!

And to take advantage of those registers the programs will need to be re-written; the new functions are not the same as the native STO/RCL... for instance there's no IND or STK addressing, hope you bear that in mind!

So unfortunately 20x20 determinants are not quite yet a done deal, and ditto for the surveyor's software - sorry!

Angel;

I believe this is much more useful than you humbly describe it.

In the surveying software example, the addressing would all be done by routines in good old program memory as it is now. The decision to use regular extended or the upper block for data storage would be simplified by using sequential point numbers for each coordinate pair as it almost always is in calculators. #1 to 299 automatically go into extended, the higher point numbers for the next more-than 500 (or 340 or 255) would be routed into that upper 1024 sized space. It should be as do-able as any other coordinate pair (or x,y,z - or x,y,z, with descriptor) storage-retrieval scheme.

As my favorite math teacher said a couple of times; "I leave proof of this to others".

[Paul Dale]

(08-06-2016 11:26 PM)Den Belillo (Martinez Ca.) Wrote:  It should be as do-able as any other coordinate pair (or x,y,z - or x,y,z, with descriptor) storage-retrieval scheme.

Without indirect addressing it will be rather tricky


Pauli

[Ángel Martin]

(08-07-2016 12:00 AM)Paul Dale Wrote:  

(08-06-2016 11:26 PM)Den Belillo (Martinez Ca.) Wrote:  It should be as do-able as any other coordinate pair (or x,y,z - or x,y,z, with descriptor) storage-retrieval scheme.

Without indirect addressing it will be rather tricky
Pauli

ok, let's take the gauntlet and implement the INDirect addressing then, which will need to use a different implementation scheme than the native does: X-addresses go from 4FF up to 7FF, thus using the "80" mask won't work without mods. I could still use that mask and check for "08x" in S&X, but i suspect it'll be easier using an "800" mask and simply check for the XS digit.... yeah, that should work and be relatively approachable. Satay tuned!

[Paul Dale]

Might it be easier to implement new commands that access these registers indirectly instead?

XISTO, XIRCL, XI<> or shorter would be XIST, XIRC and XI<>


Pauli

[Ángel Martin]

(08-07-2016 06:58 AM)Paul Dale Wrote:  Might it be easier to implement new commands that access these registers indirectly instead?

XISTO, XIRCL, XI<> or shorter would be XIST, XIRC and XI<>

Naah, if we're going to do it we might get it done with all the glory details..

So it's done (been a *very* long day!) - not only the IND feature but also the eight (4 for XSTO and 4 for XRCL) arithmetic functions (which also have IND of course).

In RUN mode simply use the SHIFT key and +,-,*,/ keys.
You can move from XSTO to XRCL (or XXM<>) by pressing the STO/RCL/SST keys.
Pressing the EEX key adds the thousands digit, for registers 1,000 to 1,023.


Rewriting standard programs to use the expanded registers is now very easy:

1. - enter the function in the program, ignoring the prompt.
2. - enter the index as next line after the extended-reg function.
3. - add 1,024 to the index value for indirect registers.

Next is to make step#2 above automated, so the prompt will be entered as the next line for you.

Get ready!

[Ángel Martin]

Mission accomplished... all working as intended.

the only limitation is Stack arguments for the Indirect case (since obviously the direct case is the same as for the native functions) - and perhaps a XVIEW _ _ _, but there's no more room available for more code.

Incidentally, the choice of 1,024 registers is arbitrary. The same code would support 2,048 registers, as now there's only an artificial limit placed there so that blocks 802 and 803 can be used as back-up.

Were we going to only have the 803 block for back-ups then the register range could double up to be 2,048 instead.

What's your preference?

[Gene]

So, the previous prompting for MMSTO which was for a 1, 2, or 3 and mapped to 801, 802, and 803 has now changed to ?

Does the 1 now point to 802 and the 2 to 803 ? and 3 will be disabled ?


If so, I'd like to suggest this: Have 1 point to 803 and 2 to 802. That way, one could back up to two locations if desired OR have up to 2048 memory locations if possible. Anyway to have that selectable? Can location 802 be either a backup location OR chosen for more registers ?

[Ángel Martin]

(08-08-2016 03:53 PM)Gene Wrote:  So, the previous prompting for MMSTO which was for a 1, 2, or 3 and mapped to 801, 802, and 803 has now changed to ?

Does the 1 now point to 802 and the 2 to 803 ? and 3 will be disabled ?

So far nothing has been changed, you have the choice to use the same three blocks for backups with no individual registers, or use the first one for individual registers access and 802/803 for back ups.

(08-08-2016 03:53 PM)Gene Wrote:  If so, I'd like to suggest this: Have 1 point to 803 and 2 to 802. That way, one could back up to two locations if desired OR have up to 2048 memory locations if possible. Anyway to have that selectable? Can location 802 be either a backup location OR chosen for more registers ?

Not sure I'm comfortable with that arrangement, I think it's a bit counter-intuitive - but maybe this is a developer view and not a user's?

Actually coming to think about it, your proposal is good in that "1" pointing as 803 will always be available; "2" pointing at 802 (like it does now) is the second possible block, and "3" pointing at 801 is the last possible choice for backup and the first one to use the extended registers...

But will anybody need more than 1,023 extended registers, really?

[Gene]

Perhaps not, but by building it into the design, flexibility is maintained. After all, that's the name of the game.

Great work. Can't wait to try it out.

[Sylvain Cote]

Hello Angel,
I just came from the Mars expedition
IMHO this is as great an addition to the 41CL as the X-Function/Memory or the HePaX was to the original 41 back then.
I have been reading this thread since the beginning, but I am not sure I have been quite following your exchange with Gene about the 801/802/803 selection.
Could you give a simple FOCAL usage example with the region selection in it please.
Best regards,
Sylvain

[Gene]

The CL Expanded memory rom can make a complete backup of the entire HP 41 memory (main and extended) and allows three separate backups. The function to copy the current memory to one of these regions prompts for a 1, 2, or 3. These presently point to the ram block in the 41CL of 801, 802 or 803 (1,2,3).

The way Angel has set up the expanded register access in the same rom takes ram block 801 away and you would now have only two backup locations - 802 or 803.

I had suggested he change the backup function prompt so that if you typed 1 it would backup to page 803 rather than 801. It would allow someone to have ONE backup of full memory in 803 and if they wanted 2048 registers by using 801 and 802.

Or they could have two backups in 803 and 802 and 1024 registers in 801...if the backup function copied FIRST to 803 and then 802 rather than 801, then 802, then 803.

I think that's correct?

[Ángel Martin]

(08-08-2016 06:25 PM)Gene Wrote:  The CL Expanded memory rom can make a complete backup of the entire HP 41 memory (main and extended) and allows three separate backups. The function to copy the current memory to one of these regions prompts for a 1, 2, or 3. These presently point to the ram block in the 41CL of 801, 802 or 803 (1,2,3).

The way Angel has set up the expanded register access in the same rom takes ram block 801 away and you would now have only two backup locations - 802 or 803.

I had suggested he change the backup function prompt so that if you typed 1 it would backup to page 803 rather than 801. It would allow someone to have ONE backup of full memory in 803 and if they wanted 2048 registers by using 801 and 802.

Or they could have two backups in 803 and 802 and 1024 registers in 801...if the backup function copied FIRST to 803 and then 802 rather than 801, then 802, then 803.

I think that's correct?

Yes, very much so - the only nuance is that the backup locations are independent from one another, so (even with the current version of the CLXMEM module) you can have ONE single back up in 803 (index#3), or in 802 (index #2); or in both if so fancied - so no need to have the RAM blocks sequentially filled up (used).

and BTW there are several functions that do the backup, both MCODE and FOCAL too. They're described in the CLXMEM manual, posted at: http://systemyde.com/pdf/CL_Expanded_Mem...lities.pdf (BTW that posted version is old and the front page graphics show wrong addresses. You can search for CLXMEM at TOS for an updated version until Monte has this one refreshed).

On the new setup: I'm slowly doing the testing - which requires a CL for obvious reasons, and therefore it isn't that easy to debug (no break points, traces, etc. - how I miss V41 facilities!). Found a couple of flies in the ointment; one is already fixed but now I'm dealing with the routine that reads the argument from the subsequent program line. The original only goes up to 99, so I'm trying to increase its range up to 1,024 at least....

[Ángel Martin]

After some reasonable testing (which uncovered a few more glitches!) I think it's ready for BETA TESTING. It's amazing how much we take for granted things like register storage and recall... you really learn to appreciate it when you need to write it for an extended register range!

Beta testers are welcome - only condition is you must have a CL machine. On other systems (and on V41) you can play with the U/I but the execution won't proceed: a "NO CL" error message is all you'll get.

Everything should work in RUN mode: the limit is 1,023. Registers beyond 999 require you press the EEX key. Indirect addresses are from 0 to 1023 as well (i.e. every register can be used as indirect).

In a running program it's all automated, no special remarks.

The only CAVEAT is during program entry: the automated feature that writes the index# as a second program line won't work for registers over 99. This includes all the INDIRECT addresses, because the way IND works is by adding 1,024 to the register number. For instance, XRCL IND 5 = XRCL 1,029.

In this case you'll need to edit the second line by hand after the function has written the "place holder". When the program runs it'll subtract 1,024 from the index number, read its contents, and use that as the indirect index...

Easier to use it than to explain it!


Send me a PM with your email address to receive the ROM image.
Pls. report incidences if and when you run into glitches.

PS. Gene, I know you're interested so your copy is going already.

[Sylvain Cote]

Hello Gene & Angel,

Sorry for the delay in my reply.

Thank you very much Gene for explaining the CL Expanded Memory functions of the CL-XMEM module.
The module has been a permanent fix on my CL for the past year and the backup/restore functions are very handy.

I understood that the new functions (XSTO/XRCL/X<>) were mapped to page 801.
As I was reading, I got the impression that the functions were modified to support the other pages (802 & 803) as well.
My question was about how this page select was to be entered or selected.
After re-reading the thread I realized that I had mis-read it on the first time, sorry for the noise.

Sylvain

[Gene]

Never a problem.

Questions which generate answers here form a very useful trail of material which, when indexed by search engines, provide answers for people for years to come.

Very handy and I use that feature for HP questions all the time.