HP 41 key assignment file and x memory

[Geoff Quickfall]

Hello,

now that I have all the xroms available (almost) on the Cl I would like the capabiltiy, similar to the 71B of saving a keyfile to x-memory. This is due to the fact that some XROM take over the CL and configure the key assignments throwing your personal assignments in the trash. Using SK and RK on PPC allow suspension and reactivation of your personal key assignment but store the assignment strings in the main register memory where they can be corrupted by other program usage. I would like to store the key assignments in x-memory where xroms do not have access to them. That way they are available at any time to recall and reactivate.

Using SK and RK on the PPC seem like a good start. SK (suspend keys) uses two storage registers of your choice to store the key assignments. They can be reactivated by RK (reactivate keys).

The two NNN numbers that SK uses are stored in a user defined register set. For example 0.00 in x; followed by xeq SK; stores the key assignments in R00 and R01.

So you would think it would be an easy thing to create a keyfile for xmemory along the lines of:

10

"KEY"

CRFLAS

LBL "KEYI"

XEQ "SK"

0

"KEY"

SEEKPTA

CLA

ARCL 00

INSREC

CLA

ARCL 01

INSREC

END

LBL "KEYR"

0

"KEY"

SEEKPTA

CLA

GETREC

ASTO 00

CLA

GETREC

ASTO 01

CLA

XEQ "RK"

END

the first three lines create the KEY text file to store the R00 and R01 NNN for recall by SK.

"KEYI" only needs to be run once to store the R00 and R01 contents in the x memory location 00 and 01.

"KEYR" should recall the NNN to their respective storage registers for use with RK at any time.

Instead I get nothing but ABS assigned to all keys as opposed to the original keys.

So you have an idea of what I want, surely an XROM has this routine or function built in somewhere. Again the idea is to create a TEXT or DATA file in xmemory which will allow me to reinstall the key assignments that is safe from main memory REG manipulation. The failing of RK and SK is that they rely on the main REGs which may be altered by any number of routines called upon by an XROM whereas the X-memory is safe from that manipulation.

Any ideas.

also ran the the above programs treating the R00and R01 registers as data, that is I created a DATA file named KEY in x-memory. But that did not work either!

Cheers, Geoff

Edited: 14 Aug 2011, 7:11 p.m.

[Raymond Del Tondo]

Hello,

the CCD module features functions related to saving/restoring user keys.

Unfortunately I couldn't include them into my CCD OS/X due to space constraints;-)

HTH

Raymond

Edited: 14 Aug 2011, 7:35 p.m.

[Geoff Quickfall]

Thanks Raymond,

well i have access to all your CCD roms (currently using osx version) but may have to switch to the full CCD again. Considering they are all built into the CL, not a problem. I can call the CCD and plug it in with a routine, save the keys and uplug if the port is required. A routine will do this in less then a second.

Then when i am finished with the current key state, another routine will plug CCD, restore assignments and unplug CCD, again in less then a second.

Thanks for directing back to the CCD, I knew the existed somewhere. Now to find the manual!

Cheers, GEoff

[M. Joury]

Hi Geoff,

Maybe I misunderstood what you were saying but...

Quote:

---

SK (suspend keys) uses two storage registers of your choice to store the key assignments.

---

I am not 100% sure on this and I don't have a manual handy but I seem to remember that SK/RK only saved and restored the bit-fields denoting that a key was assigned. They do not actually store the key assignments themselves. I believe that it is impossible to store all possible key assignments in two registers--remember that each register can hold 2 key assignments.

What is going on with SK is that it stores the bit-fields denoting that currently reassigned keys and then clears those fields so that the calculator thinks that nothing is assigned. The actual assignments are still in memory. RK restores those bit-fields and thereby reactivates the assignments--the actual assignments are already in memory.

As noted, this is all from memory and it has been a long time since I have messed with any of this so I could very well be mistaken...

Cheers,

Marwan

[Geoff Quickfall]

your memory is correct Marwan!

that is one of the problems with SK and RK. Now CCD actually creates a KEY file in x-memory with the use of SAVEK and GETK.

It appears, however that they only save calculator function keys and not global routine labels.

So the search is still on: " a way to create a key x-memory file which includes the entire key assignment state: both calc-functions and global labels."

The treat with the CL is that you carry around in your pocket the entire created ROM library with few exceptions. Some of these ROMs take over the keyboard and overwrite your key assignments without allowing you to return to your assignments unless you:

CLKEYS and then reassign your keys.

With SAVEK and GETK at least the 6 calculator functions I have assigned come back. Still leaves 12 Global routine labels to reassign.

Further, there is an ability on the 41CL to restore a calculator state from the flash memory. But I am trying to circumvent the need to do that by just recalling a key assignment state.

Cheers, Geoff

[M. Joury]

I am holding my breath and waiting for the next production run of the CL. I have my name in for one.

I also remember the SAVEK and GETK routines. I guess the reason that they don't save the global program assignments is that those are associated with and stored as part of the program labels.

Here is one approach that you could use although not very elegant. Create a program that is just composed of global labels and XEQ calls to your regular programs. Make the key assigmnets to the global labels in this new program. You can then save this one program to Extended memory and the key assignments should (IIRC) get saved with it. Then when you need to restore your assignments just restore the program from extended memory. I just tried it. Key assignments get saved as part of the file and will be restored when the program is read back into memory.

Cheers,

-Marwan

[Geoff Quickfall]

WHAT AN IDIOT I am!!!!!

Global labels in a program and in conjunction with SAVEK and GETK. I actually used to do that! This is what happens when you put a calcualator away for years. You forget.

Thanks Marwan.

once you have a CL you will put everything away (except the 34S!!)

Geoff

[M. Joury]

Glad I could be of some help :-).

I got through my last 3 years of college with my old 41 and I used to know the darn thing inside and out. These days I sometimes have to go back to the manual for stuff that I once knew backwards and forwards. Must be old age setting in and messing with my memory <g>. I actually had to test my idea to make sure that I was remembering right--I was pretty sure that worked with the card reader but was not 100% sure it worked with extended memory.

Cheers,

Marwan

EDIT:

Does the order in which you do it matter? I think it might--GETK before you read back the program?

Edited: 14 Aug 2011, 10:44 p.m.

[Geoff Quickfall]

the 41CX was my tool during my Masters program. It ran 4 pieces of my lab and was my plotter, data cruncher and printer.

I too new synthetics inside and out but yep, it is a case of:

0, STO C

;-)

i will check on the order tonight. I just got word I am off to London tomorrow and have to get Wlodek's CL up to snuff for him.

Cheers, Geoff

[M. Joury]

Happy Flying!

Cheers,

-Marwan

[Garth Wilson]

Why not just write programs full of PASN instructions? They won't actually read your key assignments, but you can have a program written to make all the assignments for each USER keyboard you want, and since you probably assigned the keys by hand according to how you wanted it, you can put the same thing in the program. Keys that don't get re-assigned can keep their old assignments. The programs can be kept in extended memory if desired so they're not usually resident in main memory. A CX with no modules at all can do this.

Edited: 14 Aug 2011, 11:11 p.m.

[M. Joury]

That would work as well. I actually thought of this but for some reason that I can not define gravitated to the other solution. This method is actually more memory efficient since, as you noted, it does not have to reside in main memory. You could read it, run it, and program it to delete itself when done. Nice and clean. You could also code the GETK call into it so everything is done in one place.

Cheers,

-Marwan

Edited: 14 Aug 2011, 11:48 p.m.

[Geoff Quickfall]

Well I resorted to brute force:

LBL "KEYG"

"WA"

-11

PASN

"WC"

-12

PASN

"ST"

-13

PASN

.

.

.

"LO"

-84

PASN

"KEYF"

GETK

"BK"

GETP

END

So here is the calc and the reason for the key assignment program. The CL is loaded with:

CCD PLUS

PPC 1981

EXT-IL

PRINTER 3B

YFNS-1E

CLUTILS 1H

At any time I can plug and unplug any other ROM of choice. Some of these ROMs like the blood glucose ROM assigns functions to the keyboard removing my custom keyboard. To return my keyboard I must remove a program "BK" (full up) and bring "KEYG" to main memory.

XEQ "KEYG"

on the CL immediately loads the custom keyboard, erases itself and calls "BK" back to main, all in a split second. I also have in FLASH another 41CL image, called IGCP. This is a full suite of main memory programs and x-memory data bases that I wrote in 1984 fo my Masters in Palynology. I dug up the cards (I am currently collating data for another article), loaded the routines including assignments. I then using a routine which copies the entire suite of programs into the CL and thence to FLASH. These calculator 'states' contain the key assignments as well as the entire x-memory, flags and main memory including any data in storage registers. Once in FLASH they are protected from Memory Lost or power failures.

Now I just swap the FLASH and have a IGCP or aviate calculator at my whim. Many calculator states can be copied to the FLASH allowing you to have many custom calculators in your pocket!

Ran the CL in the cockpit to Hong Kong from Vancouver (for a total of 6 hours both ways). Not a single ESD event, usually occured on the standard 41 at least once due to the dry cockpit air.

Cheers, Geoff

[M. Joury]

Cool! I can't wait. I should start reading the manual now.

Cheers,

-Marwan