hp49g+ : THE END OF THE QUEST !
Yoann Desir
Thanks to one of the greatest HP programmers ever, I’ve
generated a list of the supported BUSCC entries (which, as you may
already know, are direct ARM accessing commands), as provided by
applying ASM-> (of the official ROM 1.23-C VERSION: 03.54 BUILD NUMBER
0031) to all BUSCC $yx sequences, and keeping the ones giving a
mnemonic instead of the $8OByx sequence : the list includes the xy
data (please note it is reversed), and x is skipped if null.
# 0 RPL2
# 5 BEEP2
# 6 MOVEDN
# 7 MOVEUP
# 8 CRTMP
N.B. Those are obviously the MOVEDOWN, MOVEUP and CREATETEMP entries,
reprogrammed in native ARM for speed increase.
N.B. Although not documented, # 9h can generate beeps according C:B,
I’m certain of it.
# A KEYDN
# B GOSLOW
# 10 OFF
# 11 GETTIME
# 12 SETTIME
N.B. Those two latter commands allow you to use the timer, which as
you may know isn't present in IO RAM anymore.
# 13 RESETOS
# 14 AUTOTEST
# 15 NATIVE? $15
# 17 SERIAL
# 28 HST=1.5
# 29 HSCREEN
# 2A WSCREEN
# 2B MIDAPP?
# 2C BIGAPP?
N.B. "Big apple", perhaps this is the secret code name of the 49g+,
what do you think ? :-)
# 30 CONFIGD
# 31 UNCNFGD
# 32 REFRESHD
# 33 SETLNED
<FONT COLOR=white>
N.B. Try C=0.A BUSCC $33, by the way, but you can use WR's Headman too
;-)
</FONT>
# 34 SETOFFD
# 38 ?HST=1.5 GOYES there
N.B. BUSCC $83 $xy *there
# 50 REMON
# 51 REMOFF
# 56 OUTBYT
# 60 ACCESSSD
# 61 PORTTAG?
# 7F SETFLD14
# 80 B=B WP
# 81 B+B WP
# 82 B-B WP
# 83 B*B WP
# 84 B/B WP
# 85 B%B WP
# 86 B=~B WP
# 87 B=-B WP
# 88 B<B WP
# 89 B>B WP
# 8A B^B WP
# EF ARMSYS
# FF ARMSAT
"My guess is he’s after the queen" says some wise character that
you may remember (and that you will see again in may 2005).
Er, well, in fact, my guess is those two latter ARM commands, ARMSYS
and ARMSAT, can respectively SWITCH INTO NATIVE ARM (you don’t
dream !) and switch back into emulated Saturn. Detailled informations
and parameters remain to be discovered and documented, but I advise
you to learn ARM9 assembly language at once !
Very Best Regards,
Yoann.
-------------------------------
The HP-Force is with me, always
Pedro Liberato
Now we need to know how to use these commands:
# 30 CONFIGD
# 31 UNCNFGD
# 34 SETOFFD
These commands are used to display a grob in Header.
See ya
yoann...@yahoo.com (Yoann Desir) wrote in message news:<4e41df23.04021...@posting.google.com>...
Khanh-Dang
[snip]
> # EF ARMSYS
> # FF ARMSAT
>
> "My guess is he’s after the queen" says some wise character that
> you may remember (and that you will see again in may 2005).
> Er, well, in fact, my guess is those two latter ARM commands, ARMSYS
> and ARMSAT, can respectively SWITCH INTO NATIVE ARM (you don’t
> dream !) and switch back into emulated Saturn. Detailled informations
I haven't understood something : if BUSCC ARMSAT switches the OS in ARM
mode, how can you then use BUSCC ARMSAT ? I think we have to find the
subroutine designed for switching back to Saturn mode.
> and parameters remain to be discovered and documented, but I advise
> you to learn ARM9 assembly language at once !
So this is how our dear saturn ends :(
Robert Hildinger
"Yoann Desir" <yoann...@yahoo.com> wrote in message
news:4e41df23.04021...@posting.google.com...
> Er, well, in fact, my guess is those two latter ARM commands, ARMSYS
> and ARMSAT, can respectively SWITCH INTO NATIVE ARM (you don’t
> dream !) and switch back into emulated Saturn. Detailled informations
> and parameters remain to be discovered and documented, but I advise
> you to learn ARM9 assembly language at once !
--------------------------
BUSCC 0xFE - "ARMSYS"
Set the ARM PC to the 32-bit value in the first 8 nibbles of the C register.
This particular BUSCC code does not perform any kind of error checking, nor
does it save the current PC on the stack. It simply performs a 'GOTO'
command in the ARM domain to the address specified by Saturn register C
(nibbles 7 thru 0), after first clearing bit 0 and bit 1 of the address to
make sure that the address lies on a 4-byte boundary. The address is ARM
domain, not Saturn domain.
This BUSCC code is essentially unusable for the user due to the fact that
the user has no visibility into ARM domain addresses.
Register contents after command:
R0 = Saturn PC + 5
R1 = Global Base
-----------------------
BUSCC 0xFF - "ARMSAT"
Call the ARM subroutine at Saturn address specified by the A field of
register C.
This BUSCC code performs the rough equivalent of a 'GOSUB' in the ARM
domain. It first takes the contents of the A field of the C register and
converts it to the equivalent ARM domain address. It then sets the ARM PC to
that address, but leaves the link register intact and pointing to the return
address from the BUSCC execution.
This apparently is the BUSCC code that can actually be used to execute
user-provided ARM code. I believe that all a user has to do to execute a
custom ARM function is to create the function using position independent
code (and placing the ARM command BX LR at the end!), encode it as an HP
code object, get the Saturn address of the object, put it in the A field of
the C register, and then execute BUSCC FF. Let the hacking commence!
Register contents after command:
R0 = Saturn PC + 5
R1 = Global Base
-------------------------
Some interesting variable locations in the ARM domain: (all 32-bit
variables)
Saturn register A (low order 8 nibbles) = Base + 0x90C
Saturn register A (high order 8 nibbles) = Base + 0x910
Saturn register B (low order 8 nibbles) = Base + 0x914
Saturn register B (high order 8 nibbles) = Base + 0x918
Saturn register C (low order 8 nibbles) = Base + 0x91C
Saturn register C (high order 8 nibbles) = Base + 0x920
Saturn register D (low order 8 nibbles) = Base + 0x924
Saturn register D (high order 8 nibbles) = Base + 0x928
Saturn register R0 (low order 8 nibbles) = Base + 0x92C
Saturn register R0 (high order 8 nibbles) = Base + 0x930
Saturn register R1 (low order 8 nibbles) = Base + 0x934
Saturn register R1 (high order 8 nibbles) = Base + 0x938
Saturn register R2 (low order 8 nibbles) = Base + 0x93C
Saturn register R2 (high order 8 nibbles) = Base + 0x940
Saturn register R3 (low order 8 nibbles) = Base + 0x944
Saturn register R3 (high order 8 nibbles) = Base + 0x948
Saturn register R4 (low order 8 nibbles) = Base + 0x94C
Saturn register R4 (high order 8 nibbles) = Base + 0x950
Saturn register d0 = Base + 0x954
Saturn register d1 = Base + 0x958
Saturn register P = Base + 0x95C
Saturn register ST = Base + 0x968
Saturn register HST = Base + 0x96C
Saturn register CARRY = Base + 0x970
Saturn register DECIMAL_MODE = Base + 0x974 ; dec = 1, hex = 0
----------------------
The above information was obtained through analysis of disassembled ARM code
and is part of an upcoming BUSCC information sheet that I'm writing. This
information is free to dietribute, although I'd appreciate it if I were
given some credit for it. It is by no means guaranteed to be correct, so use
it at your own risk!
-Robert Hildinger
rh_public AT mindspring DOT com
Tim Wessman
>user-provided ARM code. I believe that all a user has to do to execute a
>custom ARM function is to create the function using position independent
>code (and placing the ARM command BX LR at the end!), encode it as an HP
>code object, get the Saturn address of the object, put it in the A field of
>the C register, and then execute BUSCC FF. Let the hacking commence!
I almost fell off my chair when I saw this post! So who will have the
honor of being the first to write something? I'd love to see it even
if it doesn't really do anything. . . =)
TW
Yoann Desir
> I haven't understood something : if BUSCC ARMSAT switches the OS in ARM
> mode, how can you then use BUSCC ARMSAT ? I think we have to find the
> subroutine designed for switching back to Saturn mode.
I believe that's (partially) the purpose of ARMSAT. Perhaps there's a
command you have to use inside the ARM code to tell the processor that
you're going back to Saturn code (just like in Saturn ASM, you used to
write A=DAT0 A D0+5 PC=(A) to go back to RPL), and then in saturn
code, you use ARMSAT...
> > and parameters remain to be discovered and documented, but I advise
> > you to learn ARM9 assembly language at once !
> So this is how our dear saturn ends :(
Not necessarily, if I guessed right, the 49g+ both supports ARM and
Saturn programming, so you can choose between the two assembly
languages.
Regards,
Yoann.
Yoann Desir
That command writes the serial number of the 49g+ into DAT1 on 10
bytes (ascii coded). And the SERIAL ARM command is of course used
inside the SERIAL romptr of the 256 devlib.
> # 29 HSCREEN
> # 2A WSCREEN
In addition, I can tell you that those two ARM commands respectively
give the height and the width of the screen (the real screen of the
calculator) in A:A.
For example, HSCREEN acts like LA 00050 and WSCREEN acts like LA
00083.
Perhaps those commands mean it is possible to set a larger display,
putting the adresse of a larger grob than 131x80 into the HARDBUFF ?
> # 2Bh MIDAPP?
This command seems to always unset the carry on the 49g+, at least in
normal mode.
> # 2Ch BIGAPP?
This command seems to always set the carry on the 49g+, at least in
normal mode.
In addition, a mere code containing :
CODE
81B1
ENDCODE
doesn't do anything. This prooves that 81B1 can be used as a quick
replacement of the usual sequence A=DAT0 A D0+5 PC=(A).
There's something more interesting : probing the FALSE routine, I saw
that it uses BUSCC $30.
I tried to use that command in a home-made Saturn code, and I wrote :
CODE
BUSCC $30
ENDCODE
When this code, once compiled, is evaluated, it is left on the stack
(and doesn't bug, so this means the # 3 BUSCC command is capable to go
back to RPL).
Furthermore, calling BUSCC $30 allows to keep on the stack the object
which is being evaluated (like the FALSE object for instance).
Regards,
Yoann.
Jonathan Busby
<rh_p...@mindspring.removeme.com> wrote:
>BUSCC 0xFF - "ARMSAT"
>
>Call the ARM subroutine at Saturn address specified by the A field of
>register C.
>
>This BUSCC code performs the rough equivalent of a 'GOSUB' in the ARM
>domain. It first takes the contents of the A field of the C register and
>converts it to the equivalent ARM domain address. It then sets the ARM PC to
>that address, but leaves the link register intact and pointing to the return
>address from the BUSCC execution.
>
>This apparently is the BUSCC code that can actually be used to execute
>user-provided ARM code. I believe that all a user has to do to execute a
>custom ARM function is to create the function using position independent
>code (and placing the ARM command BX LR at the end!), encode it as an HP
>code object, get the Saturn address of the object, put it in the A field of
>the C register, and then execute BUSCC FF. Let the hacking commence!
That's interesting. The BX instruction is usually associated with an
arm-thumb mode switch. This raises the question: Is the emulator
written in thumb or is the BX just there to insure that the processor
mode is restored upon a return if the user code altered it?
-------------------------------------------------------------------------------
Jonathan Busby - <j...@SNMAPOhouston.rr.com>
Remove the random permutation of "NOSPAM" from my e-mail address
before replying.
Jonathan Busby
<j...@SNMAPOhouston.rr.com> wrote:
>Is the emulator written in thumb or is the BX just there to insure that the processor
>mode is restored upon a return if the user code altered it?
I should have read more carefully. From your post : "... after first
clearing bit 0 and bit 1 of the address to make sure that the address
lies on a 4-byte boundary." So it's arm mode.
On another note, you say "I believe that all a user has to do to
execute a custom ARM function is to..." "...get the Saturn address of
the object, put it in the A field of the C register, and then execute
BUSCC FF." Wouldn't you need to insure that the Saturn address is
aligned on 4 byte boundary then? This could be accomplished by using 4
bytes of padding and moving the arm code in-place using say MOVEDOWN
before it's executed. Or, another possibility is to use a arm "loader"
at a fixed Saturn address (like a location in one of the 49's unused
reserved memory regions) that copies the arm code to a 4-byte aligned
arm address and then executes it, reminiscent of copying library
routines into TEMPOB before executing them (although that's for an
entirely different purpose).
Robert Hildinger
news:mgid301fsu1s2mu7n...@4ax.com...
> On Fri, 20 Feb 2004 21:55:52 GMT, "Robert Hildinger"
> <rh_p...@mindspring.removeme.com> wrote:
>>This apparently is the BUSCC code that can actually be used to execute
>>user-provided ARM code. I believe that all a user has to do to execute a
>>custom ARM function is to create the function using position independent
>>code (and placing the ARM command BX LR at the end!), encode it as an HP
>>code object, get the Saturn address of the object, put it in the A field
>>of
>>the C register, and then execute BUSCC FF. Let the hacking commence!
>
>
> That's interesting. The BX instruction is usually associated with an
> arm-thumb mode switch. This raises the question: Is the emulator
> written in thumb or is the BX just there to insure that the processor
> mode is restored upon a return if the user code altered it?
Woops, I made a slight mistake there. The subroutine return operation should
be 'MOV PC,LR', not 'BX LR'. There is no ARM/thumb mode switch involved, and
to answer your question, the emulator is written in ARM (99.9%), although
there does appear to be a small amount of thumb code (0.1%).
Cyrille de Brébisson
%%HP: T(3)A(R)F(.);
<<
"D9D20430F2CCD20212008FB9760808F70E00F14D29E4192195E4293195E20070A1E30080A1E
10C60A3E2920400E4
4640A1E3930500E54650A1E500E480E1090E53EA00000AC5004440E2930300E4002780E3C530
A1E3003880E100665
2E1FFFFFA186961D5E10066C3E86961C5E0F18DB8E86961D5E1006683E86961C5E0F18DB8E07
1341F00108340E000
80B60AE280B331FE9228319AAF0A7C151717FA6E55F1B0210034E922814413437FFFEFFFFAF7
31F481A60BAF23300
81BFAAF53128AC0B4406340010880BFF860D01564B421544A44580160B44AF23104A7107A6E5
6C161AF23166A7311
BA6E10B54931FF8018F2120096A6F8F2120096E6F8080310180B338FC77621361B021001448D
34150B2130"
13 CHR "" SREPL DROP 10 CHR "" SREPL DROP H-> EVAL >>
Cyrille
"Robert Hildinger" <rh_p...@mindspring.removeme.com> wrote in message
news:InvZb.8815336$Id.14...@news.easynews.com...
Arnaud Amiel
The commented source code would be great if you have it. It seems quite
useful anyway, I have to look at it better.
Thanks a lot for this and so much more.
Arnaud
Beto
What does it do? For us without the 49G+ yet...
Regards,
--
Beto
Reply: Erase between the dot (inclusive) and the @.
Responder: Borra la frase obvia y el punto previo.
Arnaud Amiel
more serious issues with my hp at the moment) and draws a Mendelbrot
structure instantly, well fast enough for me not to see it calculating.
Arnaud
Beto
Impressive! and when is CdB going to release the key to that knowledge? :)
Tim Wessman
Yes. Thank you very much. however I think he obviously enjoys
teasing us. . . please share a wee bit more. . . she can't take much
more of this captin!
TW
Robert Hildinger
"Beto" <beto_z_o....@hotmail.com> wrote in message
news:c1dnto$1gsjcn$1...@ID-95421.news.uni-berlin.de...
> Arnaud Amiel wrote:
>
> > It obviously calls the ARM but I haven't figured out where and how (I
have
> > more serious issues with my hp at the moment) and draws a Mendelbrot
> > structure instantly, well fast enough for me not to see it calculating.
>
> Impressive! and when is CdB going to release the key to that knowledge? :)
I don't know whether or not Cyrille intends to release further information,
but I've provided a preliminary guide to writing ARM subroutines in the post
entitled "Preliminary guide to writing ARM subroutines on the 49G+".
Al Borowski
> try this...
>
> %%HP: T(3)A(R)F(.);
> <<
> "D9D20430F2CCD20212008FB9760808F70E00F14D29E4192195E4293195E20070A1E30080A1E
> 10C60A3E2920400E4
> 4640A1E3930500E54650A1E500E480E1090E53EA00000AC5004440E2930300E4002780E3C530
> A1E3003880E100665
> 2E1FFFFFA186961D5E10066C3E86961C5E0F18DB8E86961D5E1006683E86961C5E0F18DB8E07
> 1341F00108340E000
> 80B60AE280B331FE9228319AAF0A7C151717FA6E55F1B0210034E922814413437FFFEFFFFAF7
> 31F481A60BAF23300
> 81BFAAF53128AC0B4406340010880BFF860D01564B421544A44580160B44AF23104A7107A6E5
> 6C161AF23166A7311
> BA6E10B54931FF8018F2120096A6F8F2120096E6F8080310180B338FC77621361B021001448D
> 34150B2130"
>
> 13 CHR "" SREPL DROP 10 CHR "" SREPL DROP H-> EVAL >>
>
> Cyrille
>
Here's whjat I know...
The east part is th user RPL. All "13 CHR "" SREPL DROP 10 CHR "" SREPL
DROP H-> EVAL >>" does is remove all newline chars from the string. The
H-> converts the hex string into a binary one. The EVAL runs this code.
NOSY translates this code into:
TURNMENUOFF
and then some assembly code (keep in mind I don't know saturn or ARM
assembly)
GOSBVL 0679V --> This is called SAVPTR
INTOFF ; looks like it disables interrupts
GOSUB 93972
RTI ; looks like a 'return from interrupt' instruction, probably
re-enables interrupts
(Lots of saturn code follows)
Anyhow, a column of my screen just failed, and rebooting doesn't fix it...
Does anyone have an ARM dissambler floating around?
Al
Lilian Pigallio
::
TURNMENUOFF
CODE
GOSBVL =SAVPTR
INTOFF
GOSUB LE0DFE
NIBHEX
0F14D29E4192195E4293195E20070A1E30080A1E10C60A3E2920400E44640A1E3930500E5465
0A1E500E480E1090E53EA00000AC5004440E2930300E4002780E3C530A1E3003880E1006652E
1FFFFFA186961D5E10066C3E86961C5E0F18DB8E86961D5E1006683E86961C5E0F18DB8E
LE0DFE C=RSTK
D0=C
D1=(5) #80100
LC(5) #E0
BUSCC
GOTO LE0CB5
P= 8
CSTEX
LC(4) #9EF1
P= 2
?XM=0
GOYES LE0DD0
A=0 W
A=A-1 W
LE0E2F DAT1=A W
D1=D1+ 16
C=C-1 B
GONC LE0E2F
D0=(5) #120
LC(5) #8229E
DAT0=C A
D0=C
LCHEX FFFFEFFF
D=C W
LC(2) #4F
R3=C.F B
LE0E67 C=0 W
LC(4) #1800
C=-C W
B=C W
LC(2) #82
A=0 S
A=A+1 S
LE0E80 RSTK=C
LC(5) #80100
BUSCC
D=-D-1 A
?ST=0 0
GOYES LE0E9E
C=DAT0 S
C=C-A S
DAT0=C S
LE0E9E A=A+A S
GONC LE0EAA
D0=D0+ 1
A=A+1 S
LE0EAA C=0 W
LC(2) #40
B=B+C W
C=RSTK
C=C-1 B
GONC LE0E80
D0=D0+ 2
C=0 W
LC(2) #66
D=D+C W
C=R3
C=C-1 B
R3=C
GONC LE0E67
LC(2) #FF
OUT=C
LE0EDC GOSBVL =CINRTN
?C=0 B
GOYES LE0EDC
LE0EE8 GOSBVL =CINRTN
?C#0 B
GOYES LE0EE8
INTON
LC(2) #10
BUSCC
LC(4) #7CF8
GOSUB LE102F
LCHEX 00120B1
DAT0=C A
GOVLNG =GETPTRLOOP
ENDCODE
;
"Cyrille de Brébisson" <cyr...@hp.com> wrote in message
news:403a1c6f$1...@usenet01.boi.hp.com...
Samuel Nyall Stearley
that have been re-written in arm asm language? I searched hpcalc for
a couple hours but didn't find them all.
-Samuel
http://www.nyall.net
Arnaud Amiel
"Samuel Nyall Stearley" <sste...@yahoo.com> wrote in message
news:551a73ee.0402...@posting.google.com...
> Can anyone recomend a good document that details all of those routines
> that have been re-written in arm asm language? I
Yoann's post at the top of this thread is the best I have seen so far.
Arnaud
Samuel Nyall Stearley
what those routines already listed do. I can find some but not all.