I was toying lately with some ROMPTR functions, and discovered that some of them behave differently depending on HP48 or HP49.
Namely GETLINK_ (but i guess that GETHASH_, GETCONFIG_ or similar will behave the same).
When using this SysRPL call with a library stored into a covered port, on a HP48, the content of link table is present into stack 1 while on HP49, we merely get an extended pointer.
So, i wish i could do something with this extended pointer, and especially get the content of the pointed table into stack 1, like an HP48, but, i can merely detect this object type for now. Looking into "HP49G Entry Reference", i found no SysRPL entry to deal with extended pointer.
everything starting from Lib6 is in covered memory in the 49G.
> Namely GETLINK_ (but i guess that GETHASH_, GETCONFIG_ or similar will > behave the same).
From Lib6 on upwards. Covered memory access is mostly undocumented, I found out a lot the hard way while developing the Language Packs.
> So, i wish i could do something with this extended pointer, > and especially get the content of the pointed table into stack 1, like > an HP48, > but, i can merely detect this object type for now. > Looking into "HP49G Entry Reference", i found no SysRPL entry to deal > with extended pointer.
?ACCPTR> (I have the description somewhere in my sources but also search this newsgroup:-) TOSSRP deals with covered memory and gives some hints if you look into the code of it.
56.13 Extended pointer Prologue: 02BAA Epilogue: none Size: 15 nibbles Type: 27 In memory: Prologue (02BAA) 5 nibbles Object’s address 5 nibbles Program’s address 5 nibbles As you will learn in the next part, some areas of memory are covered by others, but sometimes we need to point something that is covered. This is the object the HP uses internally for that purpose. There are routines in ROM, which we’ll discuss later, that are used to “uncover” the part we want to use. In this case, the object is what we want access to, and the program is the ROM routine that will be associated with the object’s address, and will unconfigure and reconfigure memory modules as needed.
> Any idea ?
What do you want to know exactly ? ACPTRs are used for accessing covered memory. They need a little bit more memory than FLASHPTRs and are a little bit slower BUT the advantage is that you can replace them as opossed to FLASHPTRs. I use them to move the messages of the Language Packs into covered memory so that the lib can be stored in a Port>0.
The drawback is that it is extremly hard to program as debug4x is not designed to handle covered ports and Bill Graves explained to me once that it is almost impossible to implent and that he can not do it. It takse a lot of time and patience.
If you have specific questions contact me directly and I'll try to answer your questions if I can.
Also search this newsgroup for the infamous STO bug which was discovered while creating the language packs. Since it exits since the very first ROM and has not been fixed so far it will probably stay in the ROM forever...
It seems that ?ACCPTR> is doing exactly what i'm looking for. This entry exists for both HP48 & HP49 systems, but is completely undocumented. So your advise is really welcomed.
I'm also surprised that such entry exist for HP48; as i though "Extended Ptr" object type were only available for HP49.
Anyway, it solves my issues, as the extended pointer is translated into the content pointed by the pointer. And if the object type is not an extended pointer, it does nothing, which is excellent, as i don't need to test object type myself.
My current objective is simply to toy with Library object structure, which is pretty complex. I'm currently developing a "library checker" program which would simply try to tell which libraries can be compressed and which one cannot.
One of the (many) reasons why compression is not possible is when several library entries points into the same object. Comparing object size with distance between 2 offset into link table should be enough for this task. That's why i need to access the link table.
But then, i'm just beginning my travel into Library structure...
> This was introduced with the 48GX (and not on the 48SX) as the covered > memory was needed for the 48GX.
Good point ! I tried the code on an HP48SX (rev E), and it produced a warm reset.
As i always try to have a code which remains valid for both S/G series, i guess in this circumstance, i merely need a conditional assembly method to exclude ?ACCPTR> from the HP48 target.
Looking into RPLCOMP, i found nothing but within SASM there are some conditional assembly instructions, for example IFDEF, which seem to be what i need, should i know how to make it work...
From SASM help file :
label IFDEF symbol Assemble code only if symbol is defined now. label IFNDEF symbol Assemble code only if symbol is not defined now.
> label IFDEF symbol Assemble code only if symbol is defined now. > label IFNDEF symbol Assemble code only if symbol is not defined now.
Look into the sources of HPlanétarium which is using this to create different software depending on the target machine. It will be much more use for you than I trying to explain it to you because you are French ;-)
I too use it but my explanation for me I wrote once back about conditional assembly is in German ;-)
If you can not figure out I will provide you with help but HPlanétarium sources contain exactly what you need. Also there is a build-in Conditional Compilation in debug4x:
From the help file of debug4x:
Conditional Compilation
The flags: HP49Proj and HP48Proj can be tested by code such as:
#IF HP49Proj ( compille if a HP49 project ) #ELSE ( compile if a HP48 project ) #ENDIF
In RPL, the conditional directives are #IF, #IFNOT, #ELSE, #ENDIF.
See the RPLCOMP Manual for details.
In Saturn, the conditional directives are #IF, #IFDEF, #IFNDEF, #ELSE, #ENDIF.
Thanks again Andreas, as always, your help is very valuable.
Yes, i read some explanation from Khan Dang Nguyen, who's using MASD conditional compilation. They work pretty well, but are a bit less "verbose", because using Flag Numbers (instead of names)
I was unaware of the Debug4x ready-to-use Flags, and indeed, they solve *exactly* my need. And they are pretty clean too.
|
