[comp.sys.handhelds] More units

sburke@jarthur.Claremont.EDU (Scott Burke) (02/13/91)

Hi.

I must have missed the earlier unit posting, so I must briefly rehash a small
units problem/question/curiosity:

# FA53h SYSEVAL 2 GET gives 1_m, on which BYTES returns #     0d  2.5
1_m UBASE             gives 1_m, on which BYTES returns # 59779d 12.5
1_m                   gives 1_m, on which BYTES returns # 54012d 16

This is interesting.  Please (;-), all I want to do is check if a quantity
that I UBASE (which may or may not be really ugly) is in fact equal to 1_m,
because I want to know _what_ units the quantity had.

The suggestion by James Cloos was to do 1_m UBASE <ugly> UBASE SAME, but 
here's the caveat:  There are several possible units, and it is _slow_ to
build the list { 1_m 1_... ... }, so that I can do a <list> object POS to
find out if I have an acceptable unit.

The first line of attack was to simply store the acceptable units as strings
in a list like { "'1_m'" ... } and so far I am standing by that as the best
solution.  I tried the obvious ploy:  Build the dumb list first, on the 48
stack, using UBASE.  This gives a list of the correct things.

But AHA when that list is inserted in a program with |STK key in the editor,
and then that source code is uploaded in ASCII to the Mac and then down-
loaded in ASCII to the calculator, guess what?  It changed, and 1_m \=/ 1_m
again, just like before.

I don't mind using the string approach (it may be smaller, too!), but is 
there another idea out there?  When I saw the SYSEVAL posted, I thought that
it would return a list of the UBASE versions of the units, but it doesn't.

Scott.
sburke@jarthur.claremont.edu

cloos@acsu.buffalo.edu (James H. Cloos) (02/14/91)

In article <10800@jarthur.Claremont.EDU> sburke@jarthur.Claremont.EDU (Scott Burke) writes:
>Hi.
>
>I must have missed the earlier unit posting, so I must briefly rehash a small
>units problem/question/curiosity:
>
># FA53h SYSEVAL 2 GET gives 1_m, on which BYTES returns #     0d  2.5
>1_m UBASE             gives 1_m, on which BYTES returns # 59779d 12.5
>1_m                   gives 1_m, on which BYTES returns # 54012d 16
>
>This is interesting.  Please (;-), all I want to do is check if a quantity
>that I UBASE (which may or may not be really ugly) is in fact equal to 1_m,
>because I want to know _what_ units the quantity had.

This piqued my curiosity.

The first 1_m above comes out as @FA84 on the stack.  Ie., when you do the
#FA53h SYSEVAL, you get @FA53h on the stack, 2 GETing from there puts the
address of the second element, rather than that element, on the stack.
BYTES sees a ROM object & returns #0 2.5.  In the second case, you get a
UNIT OBJECT on the stack that would look like UNIT %1 String_m u_ ;
where UNIT ==> data.a x'2ada; %1 ==> data.a x'2a2c9; String_m ==> 
data.a x'fa8e; u_ ==> data.a x'10b86; and `;' ==> data.a x'312b (to use
star code for each).  Notice that the string points to a ROM address rather
than being of the form $ "m" (data.a x'2a2c data.a x'7 ascii `m').

I would point out that in a program, the first possibility can be ignored;
it will not happen in ordinary unit manipulations.  (Really, how many
people use #FA53h SYSEVAL 2 GET to enter 1_m on the stack?)

Lastly, here are the addresses of the UBASED units for the 8 base units:
1_kg	#FA58
1_m	#FA84
1_A	#FAA4
1_s	#FAC4
1_K	#FAE4
1_cd	#FB04
1_mol	#FB26
1_?	#FB4A

These are for version A, but are most likely the same for B thru E as well.

(I got these by doing #FA53 SYSEVAL LIST\-> \-> n \<< 1 n START n ROLL
\->HX S\->B NEXT \>>.)  (\->HX is Rick's HEX\-> and S\->B looks like: 
\<< DUP TYPE 2 IF == THEN DUP SIZE 5 + R\->B B\->S 1 5 SUB SWAP + "E4A20"
SWAP + HX\-> ELSE 514 DOERR END \>>
and B\->S looks like:
\<< DUP TYPE 10 OF == THEN \->HX 11 OVER SIZE SUB ELSE 514 DOERR END \>>
and HX\-> is Rick's \->HEX.  (Think of HX format as being just like ASC
format, but w/o the \n's or the crc, and HEX as being the normal format.))

Enjoy!!!

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