^ma5 75^pl-62 0 0
^sk2^paPlease note, in all LEX files I sent you, I have used scratch LEX ID numbers.
These numbers are consistant with my own personal numbering scheme but may need to be changed 
for use by other people.
Unfortunately I am opening Pandoras box by bringing up this subject.
It will have to be addressed eventually though so the soooner the better.
^sk1^paPlease refer to IDS V1, Chap 18, Resource Allocation, page 18-5.
Note that only LEX IDs 5C-5E, three total, have been allocated as scratch.
All others are reserved.
As an example, the HPIL analyzer I wrote I intend to market in a 'deluxe' form.
HP has assigned me LEX ID #s, Tokens, Message #s, and Buffer ID for the application.
The version you recieved however uses scratch numbers, NOT the ones assigned me by HP.
To avoid conflicts, LEX IDs, Tokens, etc, need to be unique.
As we, the user community, write HP71 enhancements, we will need to address these issues.
Perhaps the simplest procedure is for each user to maintain a personal numbering scheme, using 
IDs 5C-5E, and change all files going into their machine to reflect this.
The drawback is only the work required to make those changes.
A bigger problem arises when using files which are already assembled.
Short of 'POKING' the file mercilessly, there is no easy way to change an assembled file.
In short, we the user community, are faced with the exact same problem HP has, resource 
management.
Files distributed by HP and those who have gone through the procedures with HP for resources 
will have absolutely no problem whatsoever.
The problem only arises with files we write and swap personally or through CHHU or PPC.
At this stage of the 71s life it is not a problem, we just need to keep it from becoming one.
^sk1^paCompared to the HP1000 based Saturn Assembler, the FORTH/Assembler ROM is 'stupid'.
It will however do quite a bit more than the owners manual discloses.
For example, in a LEX file, the MAIN Table is in ascending numerical order by Token number 
and the TEXT Table is alphabetical by Keyword.
The FORTH/Assembler normally associates one-for-one MAIN and TEXT Table entries.
This requires assigning Token numbers to the Keywords in alphabetical order.
If the Token assignments do not ascend numerically/alphabetically, then the ENTRY pseudo-op 
gets the assignments thoroughly confused!!!!!
The remedy is not to use the ENTRY pseudo-op, instead replace it with a CON(3), REL(5) pair.
The following examples show it both ways:
^sk1This is the usual way:
^sk1^co
       ENTRY  start1  the label for keyword 1
       CHAR   #D      a fully programmable statement

       ENTRY  start2  the label for keyword 2
       CHAR   #F      a function

       KEY    'ASTATE' the keyword for the statement
       TOKEN  1        lets assign token 1 to the statement

       KEY    'FUN'    the keyword for our function
       TOKEN  2        lets give the function token 2

       ENDTXT          ends the TEXT Table
^ad
^sk2^paIn the preceeding example, everything was alright because the TEXT Table had 
ascending token numbers and was alphabetical.
Consider what would have occured had keyword 'ASTATE' been token 2 and 'FUN' been token 1.
The TEXT Table would still have to be arranged alphabetically by keyword, the problem is that 
the pseudo-op 'ENTRY' would assign the wrong Keyword to the wrong execution code.
The resulting file would trash the 71 if executed!!!!!!!!!!
^sk1^paFolowing is the solution to this dilemma:
^sk1^co
       CON(3) (TxEn02)-(TxTbSt)
       REL(5) start2
       CHAR   #F

       CON(3) (TxEn01)-(TxTbSt)
       REL(5) start1
       CHAR   #D

       KEY    'ASTATE'
       TOKEN  2

       KEY    'FUN'
       TOKEN  1

       ENDTXT
^sk1^paIn the above example, notice the use of two 'restricted' labels;  'TxEnxx', where xx is 
the xx'th entry in the TEXT Table and 'TxTbSt', which is the start of the TEXT Table.
Of the four pseudo-ops needed for a Keyword entry, only 'TOKEN' is needed as-is.
The 'TOKEN' pseudo-op is needed by the assembler to construct the file header properly.
The CHAR pseudo-op may be replaced by a CON(1), KEY by a CON(1) NIBASC pair, and ENDTXT by 
NIBHEX.
^sk1^paThe Hewlett-Packard 71B Handheld Computer is the logical successor to the 41c.
It's small yet incredably powerful.
I believe the Swiss cheese approach taken by HP ('Open', does that mean 'full of holes' ?) will 
return 'margins' (i.e. they'll keep it on the market for a few years because they'll eventually 
sell enough).
^sk1^paIn closing I would like to say that I think the HP71 handheld is the finest I've ever 
used.
My only real (and serious) complaint is that, for an 'open' machine, HP still keeps a lot to 
themselves.
^sk2^ceJohn R Baker
^sk0 142 Johns Court
^sk0Charles Town, WV 25414