CW%APG.PH.UCL.AC.UK@pucc.PRINCETON.EDU (04/04/91)
Hello Happy Hackers,
It turns out that the prefixed machine code at #3685h is yet
another useful routine for doing completely undocumented and
useless things with, that seems to give us me (us?) so much
pleasure. The recently coined phrase 'calculator geek' was,
I thought, very apt. I had the same feelings reading the 'HP
announce new calculator' wind-up and fell for it hook line and
sinker, until I read the last line. My only excuse was that it
was April 2nd in England when I read it. Anyway to 3685h (you
will need to refer to my last bit on 371Dh to understand some of
this)
Put a 3x3 array on the stack
1: [ [ 9 8 3 ]
[ 4 11 6]
[ 7 0 3 ] ]
The elements of the array will have the following
indexes
1: [ [ (1) (2) (3) ]
[ (4) (5) (6) ]
[ (7) (8) (9) ] ]
By this I mean
1 GET2 -> 1: 9
5 GET2 -> 1: 11
8 GET2 -> 1: 0
{ Where (for those who weren't paying attention) GET2 is the
following program
\<<
R\->B
#5A03h SYSEVAL @Binary to System Binary
SWAP
#371Dh SYSEVAL @Extract N'th object from array
DROP @Get rid of external
\>>
}
Anyway the routine at 3685h is all about calculating those indices.
As usual for very low level routines it works in system binaries, and
here's how to get 'em
#5A03h SYSEVAL converts a binary on the stack to a system binary
# SYSEVAL converts a real on the stack to a system binary
Say you want to get the number 11 from the array above but can't
work out the index of it but know its position (2,2) then if you
put the array on level 1 of the stack and the position in the array
as a list of system binaries on level 2, like so-
2: { <2h> <2h> }
1: [ [ 9 8 3 ]
[ 4 11 6]
[ 7 0 3 ] ]
then type #3685h SYSEVAL you get
2: <5h>
1: External
Where <5h> is the index and the External is 'true' (i'll explain
how to get a false later...). So now you know the index of the
number 11. WOW! ;-)
This may seem a very long way of going about things since 2D
arrays are very well catered for already inside the rom of the
HP48sx. But what about a 3D array? Lets create one. First we
must know what it looks like in memory
8E920 Array header
E9000 Length of rest of array (inc these 5)
33920 Header for reals (a real array)
30000 This bit tells us it is a 3D array!
20000
20000
20000 These last three tell us it is a 2x2x2
array (i.e. 8 numbers)
0000000000000010 first number (index 1)
0000000000000020 second number (index 2)
0000000000000030
0000000000000040
0000000000000050
0000000000000060 and so on....
0000000000000070
0000000000000080
So type
"8E920E900033920300002000020000200000000000000000001000000000000000
020000000000000000300000000000000004000000000000000050000000000000
000600000000000000007000000000000000080E464" ASC->
AND WHAT DO YOU GET? A 2D ARRAY ON THE STACK!!!
Note also that the numbers are not quite right. This is because
the display routines in the 48 do not know how to cope with a 3D
array. You can tell its not really a 2d array since if you try SIZE you
get
2: <2h> <- Is this the third dimension?
1: { 2 2 }
and if you try 4 GET2 you get 4, which is indeed the fourth
number in the array and 8 GET2 gives you 8, also correctly.
Try this, put the array in level 1 of the stack and { <2h> <2h> <2h> }
on level 2. (I shall write ARR for the array)
2: { <2h> <2h> <2h> }
1: ARR
then #3685h SYSEVAL produces
2: <8h>
1: External
Where <8h> is indeed the index of the number in position in (2,2,2),
and could be used by 371Dh to extract the number stored at that
position. I hope this is at least a little bit clear to somebody
out there!??
The routine at 3685h does quite a bit of error checking: If
you do not specify enough coordinates or your coordinates are out of
the bounds of the array then you just get an External ('false')
returned to level 1 of the stack (very useful indeed).
Also note that as with 371Dh this code works with arrays of any
type of variables. So these two routines 3685h and 371Dh used
together could help the manipulation of n-dimensional array
of any type.......
I'll leave you with that thought,
Conrad
cloos@acsu.buffalo.edu (James H. Cloos) (04/05/91)
In article <36F537C380002DD9@gacvx2.gac.edu> CW%APG.PH.UCL.AC.UK@pucc.PRINCETON.EDU writes: > #5A03h SYSEVAL converts a binary on the stack to a system binary > # SYSEVAL converts a real on the stack to a system binary > #18CEAh does the real->system_binary > 2: <2h> <- Is this the third dimension? > 1: { 2 2 } Yes, that is the first dimention. Obviously the routine that returns the dimentions of an array (returning system_binaries) is smart enough to handle n-dimentional arrays; unfortunately, all that is checked is if 1 value was returned or if more than 1 value was returned, in the latter case, either the routine "list-> drop sb->r swap sb->real swap 2 >list", in some form, or "sb->r swap sb->r swap 2 >list", in some form, is executed. (I dan't know offhand whether the values are returned as a list or a meta-object.) That is why the extra sys_bin is left on the stack. (NB: this is all from my explorations, and is really a theory--a bit better than just a hypothesis, I should think--don't take this as authoritative.) -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@ACSU.Buffalo.EDU Snail: PersonalZipCode: 14048-0772, USA cloos@ub.UUCP Quote: <>