[comp.sys.handhelds] Directory structure unearthed

cloos@acsu.buffalo.edu (James H. Cloos) (11/14/90)

Hello all.  I've finally determined precisely *how* sub-dir's are
stored in the 48sx and 28s's.  Below, I will use the code _DIR for the
header.  In the 48sx, the value of this is <#02A96h>; on the 28s, it
is <#02AB8h>(from Eric Toonen's obj.doc; don't blame me if its incorrect).
(I do take responsibility for the 48sx value, though).

The format is:

_DIR <#7ffh> (link_to_1st_object) (end_link) (nth_object) (link_to_nth_object)
(n-1th_object) (link_to_n-1th_object) ... (1st_object)

1st object is the one that is on the left-most menu key == the last
object STO'ed, assuming ORDER hasn't been used.

All links are 5 nybbles long.

A link_to_ith_object field is also the length of the ith_object, in
nybbles.

An object has the form:
(len_of_name) (the_name) (len_of_name) (data_STO'ed_in_name)

The (end_link) field is <#00000h>.

Notice that the object are stored in reverse order, which means that
when searching the directory tree, the hp sees a dir via the _DIR
header, then uses the pointers to find each of the id's w/in that dir
by 1st jumping to the "1st" one, which is at the end of the mem
structure; it then sequentially looks at the pointer just before the
"current" name and jumps back that many nybbles to find the "next" id.
When a pointer of 0 is found, it knows that it is at the end of the
directory. 

2 Examples:

(remove the spaces and then ASC\-> these...)

1)	DIR END
is:	"69A20 FF7 00000 B6E5" == _DIR,7FF,00000,kcrc

2)	DIR A SIN B COS END
is:	"69A20 FF7 02000 00000 10 24 10 29E20 200 250 11000
	 10 41 10 29E20 200 150 1D89"
which is:  _DIR,7ff,lnk_to_A,1_char_id,'B',1_char_name,
		RomPtr,002,052,lnk_to_B,1_char_name,
		'A',1_char_name,RomPtr,002,051,kcrc

(A RomPtr = ROM pointer = XLIB, so we see that SIN is library 2, cmd 52h.)

--
I hope that this is understandable.  I'm currently at work putting
together a rpl compiler, and have been concentrating just now on
getting the bison grammer together.  I still have to figure out how to
do a library, backup object, & unit object.  (At least now that it can
do a directory, usrlib can be used to convert that into a library.)
Anyway, given my primary project, I've not a lot of time to get this
posting done properly.  Perhaps someone who understands what I'm
saying can take the time to explain it for any who don't.  Oh, yes,
the "kcrc" means kermit crc, which as I pointed out earlier is the
algorithm for the BYTES crc; it is the one used for kermit transfers
when checksum type is set to 3.  I included it above only so that the
strings could be put thru ASC\->, these are not there in memory.

-JimC
--
James H. Cloos, Jr.		Phone:  +1 716 673-1250
cloos@ACSU.Buffalo.EDU		Snail:  PersonalZipCode:  14048-0772, USA
cloos@ub.UUCP			Quote:  <below:  ;^)>

THIS INFORMATION COMES WITHOUT ANY FORM OF WARRENTY, NOT EVEN IMPLIED ONES.

akcs.dnickel@hpcvbbs.UUCP (Derek Scott Nickel) (12/02/90)

Jim,

In reguards to that 3 nibble field near the start of a directory.  You
stated that it was 7FF.  I've played around with the ATTACH command and
have discovered this:  

For the HOME directory:  this field is the count of the Library objects
that are attached to the HOME directory, including the two standard
libraries 2 and 1792.

For subdirectories:  this field is 7FF if no library has been attached to
the subdirectory.  Otherwise 
Otherwise it is the library number of the attached library.

I hope this additional info is of use...

        Derek S. Nickel

lien@plains.NoDak.edu (Craig Lien) (12/03/90)

In article <2758b6f2:1124.1comp.sys.handhelds;1@hpcvbbs.UUCP> akcs.dnickel@hpcvbbs.UUCP (Derek Scott Nickel) writes:
>Jim,
>
>In reguards to that 3 nibble field near the start of a directory.  You
>stated that it was 7FF.  I've played around with the ATTACH command and
>have discovered this:  
>
>For the HOME directory:  this field is the count of the Library objects
>that are attached to the HOME directory, including the two standard
>libraries 2 and 1792.
>

Lately I've been doing menu commands on every Library number that I know of.
When I saw the above posting I did menu 2 I didn't expect anything
spectacular.  However menu 1792 is quite unique.  What I get on a REV E. is 

IF THEN ELSE END -> WHILE
REPEAT DO UNTIL START FOR NEXT
STEP IFERR HALT XLIB -> >>
<< >> ' ' END END
THEN CASE THEN DIR PROMPT XLIB
XLIB XLIB XLIB XLIB XLIB XLIB
the above menu contiues for as long as I can tell.

Will the XLIBs ever stop?  I realize that numbers in computers are finite
and it will stop when the menu number rolls over.

I hope someone follows up on this.

[7 lines deleted]
>        Derek S. Nickel

Craig
-- 

           We've come a long way since the world was flat.
                       lien@plains.nodak.edu 

TNAN0@CCVAX.IASTATE.EDU (12/03/90)

Hello everyone...  Has anyone tried this?

Type:
{'''' <ENTER>  (Important: NO CLOSING BRACE!)
You will get back an apparently empty list...  But NOW try:
1 GET <ENTER>
Big deal, right?  An empty stack... ok... well then, try
DEPTH
Hmmm...  There's something there?  Try
123 SWAP
Weird, huh???  You can DUP it and play with it all you want...  It is a type
8 object (program)...  I just found it so I haven't screwed around with the
scanner to figure out what exactly it is...  Is it a NULL program?  I can't
really think of any use for it (not yet anyway)...  

People keep asking about the possibility of speeding up the 48sx...
The "Gurus" of this discussion brush it off as impossible immediately...
They say, "nope... can't be done... processor is already at full speed"
Well, although this is true, might not there be other avenues to explore?
In particular, is it possible to disable the alarm and/or clock system???
Are these hardwired into ROM, or is there a way to avoid this time-consuming
task?  (Or is it not time consuming at all?  Perhaps there is a dedicated
alarm interrupt generator?  Whatever the case, I'm sure it is apparent to
anyone that the HP-28S kicks the pants off of the 48sx when the 28S is in
FAST mode...  Therefore, I can only assume that there is more overhead being
performed on the 48sx...  My 28s and 48sx just about tie (in NORMAL speed on
the 28s) when I run this (rather ridulously simple) 'benchmark':

\<< 1 1000 FOR A NEXT \>>

So, my point is:  Has anyone explored every possible avenue of speeding the
48sx up?  It is sad that such a wonderful machine should have such annoying
delays...  By the way, is there anyone else out there who feels that the
Equation Writer is a useless waste of address space???  It so incredibly slow.
I can't imagine anyone actually keying an equation in during an exam and
waiting for it to digest the information.  (However, I must admit that I
do use it to enter integrals and summations as I keep forgetting the RPN
format... :<)

XLIB is a reserved word...  Is there a way one can enter an XLIB name if one
knows its number???  ie., XLIB 1792 2088 or whatever?

One more thing, if you wish to exclude the \<< and \>> from your programs and
your programs are contained inside a large loop (ie., \<< DO ... END \>>),
then an easy way to perform this task is to use { DO ... END } and then use
1 GET...  This will return the raw DO loop to the stack (without any
delimeters)... To edit it again, simply put it in a list using 1 \->LIST.

I have more to say, but it's very late here and I'm very tired...  Good night
all...

---Xeno
(Gary Snethen)

tnan0@isuvax
tnan0@ccvax.iastate.edu

P.S.  My high scores on Syzygy are: 244 with border and 579 without...

cloos@acsu.buffalo.edu (James H. Cloos) (12/04/90)

NET:  I haven't had any luck replying to akcs accounts, so must followup:

Derek,

Thanks for the info.  I'd not looked at HOMEDIR as I lost the SYSEVAL
to RCL the current DIR.  Also, I didn't have any lib's ever attatched
to any dir's other than HOMEDIR.  Also, some of my insight came from
an article by Eric Toonen wrt to the 28s, where there were no lib's to
attach to sub-dirs.

-JimC
--
James H. Cloos, Jr.		Phone:  +1 716 673-1250
cloos@ACSU.Buffalo.EDU		Snail:  PersonalZipCode:  14048-0772, USA
cloos@ub.UUCP			Quote:  <>

cloos@acsu.buffalo.edu (James H. Cloos) (12/04/90)

Wrt what you get when you parse:
{''''
it is indeed an empty program (w/in a list, of course).  Try doing a
LIST\-> on the list you get, then a \->ASC; you'll get the string:
"D9D20B21305485" where 5485 is the crc, D9D20 is the :: (COLON) and
B2130 is the ; (SEMI).

As for how to enter an XLIB, you need to do a "29E20lllnnn" and HEXIFY
it (or use my soon to be posted HX\->ASC or HX\->) on it.  lll above
is the library number for the XLIB, in hex and reversed; nnn is the
command number of the XLIB, in hex & w/ the digits reversed.

Enjoy.

-JimC
--
James H. Cloos, Jr.		Phone:  +1 716 673-1250
cloos@ACSU.Buffalo.EDU		Snail:  PersonalZipCode:  14048-0772, USA
cloos@ub.UUCP			Quote:  <>

bill@videovax.tv.tek.com (William K. McFadden) (12/04/90)

In article <6993@plains.NoDak.edu> lien@plains.NoDak.edu (Craig Lien) writes:
->Lately I've been doing menu commands on every Library number that I know of.
->When I saw the above posting I did menu 2 I didn't expect anything
->spectacular.  However menu 1792 is quite unique.  What I get on a REV E. is 
->
->IF THEN ELSE END -> WHILE
->REPEAT DO UNTIL START FOR NEXT
->STEP IFERR HALT XLIB -> >>
-><< >> ' ' END END
->THEN CASE THEN DIR PROMPT XLIB
->XLIB XLIB XLIB XLIB XLIB XLIB
->the above menu contiues for as long as I can tell.
->
->Will the XLIBs ever stop?  I realize that numbers in computers are finite
->and it will stop when the menu number rolls over.

I tried it.  I noticed that pressing each of the menu keys put the
corresponding name in the command line.  The 16th item (the XLIB
on the third menu page) resulted in XLIB 1792 15.  After a little
more experimentation, I found that all the menu items were numbered,
starting with zero.  Hence, the 30th item (the XLIB on the fifth
menu page) gave XLIB 1792 29.

Next, I tried 1792 MENU and pressed PREV, which got me to the end
of the XLIB list.  Pressing the last non-blank menu button revealed
XLIB 1792 2088.  So there are 2089 items in this "menu."

Evaluating any of them gave uninteresting results, e.g., the same
as if I had typed them on the command line.
-- 
Bill McFadden    Tektronix, Inc.  P.O. Box 500  MS 58-639  Beaverton, OR  97077
bill@videovax.tv.tek.com,     {hplabs,uw-beaver,decvax}!tektronix!videovax!bill
Phone: (503) 627-6920       "The biggest difference between developing a missle
component and a toy is the 'cost constraint.'" -- John Anderson, Engineer, TI

umapd51@cc.ic.ac.uk (W.A.C. Mier-Jedrzejowicz) (12/04/90)

Either menu 1792 is a fascinating new discovery or some of us have
missed a previous post on this topic ;-)
Execute 1792 MENU and then press orange NXT (i.e. PREV). Now press the
rightmost menu key with XLIB on it and you will get XLIB 1792 2089
(at least you will on HP48 versions A, C and D). So, in answer to the
question - you would have to press the NXT key a total of 348 times to
get through all that. Oh, and the A, C and D versions show the same menu
as was described for version E.
One is led to wonder if all the XLIBs are HP48 commands which ended up
unnamed and therefore not available to ordinary RPL programming, but
available via SYSEVAL or direct entry of the corresponding address. This
deserves study!!!
(Or a hint from Bill ;-) )
Wlodek Mier-Jedrzejowicz

akcs.dnickel@hpcvbbs.UUCP (Derek Scott Nickel) (12/05/90)

Craig,

Quite odd!  A quick check shows that they go up to XLIB 1792 2089 (on a
REV B machine).  (do 1792 MENU [right-shift] [PREV] and press the last
displayed key.)

        Derek S. Nickel

akcs.dnickel@hpcvbbs.UUCP (Derek Scott Nickel) (12/05/90)

That { '''' stuff is indeed a 'null' program:
02D9D ! Program
0312B ! End Marker

        Derek S. Nickel

frechett@boulder.Colorado.EDU (-=Runaway Daemon=-) (12/05/90)

In article <6993@plains.NoDak.edu> lien@plains.NoDak.edu (Craig Lien) writes:
>XLIB XLIB XLIB XLIB XLIB XLIB
>the above menu contiues for as long as I can tell.
Did go far enough.. I realized that after going and going ......
That there was a better way to check.
Do a 1792 MENU and then hit PREV.     Poof.  The last XLIB is 
XLIB 1792 2089
>
>Will the XLIBs ever stop?  I realize that numbers in computers are finite
yep.
>and it will stop when the menu number rolls over.
>I hope someone follows up on this.
>Craig
That should do it.  I have no idea what they do though.

	ian
--
-=Runaway Daemon=-

cloos@acsu.buffalo.edu (James H. Cloos) (12/05/90)

In article <1990Dec4.035402.27461@cc.ic.ac.uk> umapd51@cc.ic.ac.uk (W.A.C. Mier-Jedrzejowicz) writes:
|
|Either menu 1792 is a fascinating new discovery or some of us have
|missed a previous post on this topic ;-)
|Execute 1792 MENU and then press orange NXT (i.e. PREV). Now press the
|rightmost menu key with XLIB on it and you will get XLIB 1792 2089
|(at least you will on HP48 versions A, C and D). So, in answer to the
|question - you would have to press the NXT key a total of 348 times to
|get through all that. Oh, and the A, C and D versions show the same menu
|as was described for version E.
|One is led to wonder if all the XLIBs are HP48 commands which ended up
|unnamed and therefore not available to ordinary RPL programming, but
|available via SYSEVAL or direct entry of the corresponding address. This
|deserves study!!!
|(Or a hint from Bill ;-) )
|Wlodek Mier-Jedrzejowicz

This is even more interesting when you note that at address #22E12h
there is a hex string that is the link table for the lib 700h
commands.  There are only 29 entries in it.  It would seem that the
routines that build the menus for libraries are missing the end of one
of the tables (hash, I suppose) for lib 700h.  I've not yet coerced
the subroutines of xMENU to give me lib 2's menu, though.  That would
be interesting, I should think.

-JimC
--
James H. Cloos, Jr.		Phone:  +1 716 673-1250
cloos@ACSU.Buffalo.EDU		Snail:  PersonalZipCode:  14048-0772, USA
cloos@ub.UUCP			Quote:  <>

akcs.dnickel@hpcvbbs.UUCP (Derek Scott Nickel) (12/06/90)

Jim,

You're welcome.  I belive the only way to send mail to an akcs user is if
you are also an akcs user.  Since akcs is my only access to
comp.sys.handhelds, I can't give you any other net address...

        Derek S. NIckel