MCODE question - where to savely store an address

[PeterP]

Hi,

Where to safely store a 3-digit absolute address?

I'd like to build a little constant library of physical and financial constants. One would initialize it by running CONINT which would store the constants (say 10 constants) in 10 consecutive registers, starting with a user given register. Later, I want to be able to access each constant via X: constant number, XEQ 'GETCONST' which would place the constant in X.

For this to work I need to somehow store the address of the first constant in memory so that GETCONST knows where to look for it.

One idea is to store it in the MLDL RAM via WROM. This can be done port-independently and would work for pretty much all existing devices that can function as Q-ROM. However, such a library could never be burned on an EPROM. This bugs me but the question here is -should it?

The other option I came up with is the first three digits of the pointer register in the XF/M module. They are not used (they are normally 000), so that is good. I'm happy to assume that this means the user has a CX or a X/function module, as most/all do. Only problem is, that I need to restrict the usage of the X/F memory to have less than 16 files in its memory. (the 2nd and 3rd byte carry a counter of active workfile for the XF/M module, if that is greater than 15 it needs 2 digits which then overrides the the last of my three digits with a 0, which is the default of the operating system) Which bugs me, but should it? How many files do you have on average in your X-Memory? but 15 files are not a lot for a full 600 regs of x-memory...

So the question to the community is, which solution do you think is preferable - storing it in the MLDL-RAM via WROM, which means it can not be burned to an EPROM or storing it in the XF/M pointer register, which means one can not have more than 15 files in the XF/M Or, is there a third location where one could store an absolute address.

Thanks for your kind help!

Cheers

Peter
(PS: A third option, would be to create a buffer. But that involves a whole can of worms for a simple application I really was hoping to avoid. I have not read a good description on how to create a buffer and maintain it anywhere so far, but I believe that it would mean I have to write a routine which is triggered via the polling points of my module as the OS deletes all buffers when it starts. And then I have to search for my buffer etc, etc... iiieeeee, nasty...

Edited: 20 Aug 2008, 12:37 a.m.

[Håkan Thörngren]

If you just want to return a constant, why not just let the MCODE routine take its argument from X, then build the constant in CPU register C and write it to X.

Do not forget to move old X to L and consider how to change stack lift status.

[Meindert Kuipers]

I would agree with this. If these are constants, why not simply put them in mcode?
Otherwise, the DFSYSTEM rom has functions which are much better than XFUNCTIONS. HEPAX could also be an alternative for storing data in some kind of file system, but the results could not be burned in EPROM.

Meindert

[PeterP]

This would work but I wanted to have the ability to add new constants (Sandbox has a few good constants as part of its functions) which would have to be placed in user registers or X-Memory.

Meindert, what is the DFSystem?

Thanks for the tip on the Zenrom manual, I'll check it out how to do a buffer.

Cheers

Peter

[Eric Smith]

For constants, they should just be stored directly in ROM. Usually that would just be done as a series of LC instructions, though higher storage density can be obtained through the use of the CXISA instruction.

If a ROM needs to store variable data somewhere other than in user registers, that's done using buffers, which reside following the key assignment registers (which start at 0x0C0). That's where the Time Module (and equivalent 41CX time functions) store alarms, and the HP-IL Development ROM stores its buffer.

The first register of a buffer contains the buffer ID (one nibble) and the buffer length in registers. Make sure the length isn't zero, or the 41 will crash hard. Also make sure that no registers in the buffer contain all zeros. The buffer ID has to be unique to the particular plug-in ROM, and the ROM has to respond to a poll to mark the buffer as in use at every warm start, or the mainframe ROM will delete it.

The best published description I've seen on this is the ZenROM manual, pages 37-39.

Edited: 20 Aug 2008, 8:56 a.m.