How to use SD cards to transfer software to/from a Mac
Michael Heinz
everything you need to save HP49G+ programs as text files on an SD card,
edit them with a Mac and then load them back into the HP49G+.
To get started, BACKUP YOUR CALCULATOR - to get this program loaded you
will have to enter a SYSEVAL by hand, and if you type it wrong you may
crash your calulator!
Once you're ready, cut and paste the following text exactly as it
appears and save it to an SD card - I called it "XLAT.TXT"
DIR
\->SD
\<< SWAP OUT SWAP STO
\>>
SD\->
\<< RCL IN \>>
OUT
\<< STD 64. STWS \->STR 3. TRANSIO # 2F34Fh SYSEVAL
\>>
IN
\<< \->STR 3. TRANSIO # 2F34Dh SYSEVAL + STR\->
\>>
END
Next, put the SD card into your HP49G+ and recall the file to the stack.
Third step - for this first time, you have to type in a program by hand
to convert the text file to an HP object:
<< ->STR 3. TRANSIO # 2F34Dh SYSEVAL + STR-> >>
Note that those "->" and "<-" are arrows, and "<<" and ">>" are the
start and end program symbols. Once you've entered this and you're sure
it's right, you should have two items on the stack, a string beginning
"DIR" on level 2, and the program on level 1. Press EVAL. The text file
on the stack will be converted to a directory object. Type in a name
('XLAT') and press STO.
Presto, you now have tools for converting SD files into HP objects. The
tools are:
IN - Convert a "escaped" text string to an HP object and leave it on the
stack.
OUT - Convert the HP object on the stack to a "escaped" text string.
->SD - Stores an HP object as a text string. The object to be stored
should be on level 2 of the stack, the name of the destination text
file, including port number, should be on level 1.
SD-> - Recalls a text file from the SD card, converts it to an HP object
and leaves it on the stack. The name of the file (including port number)
should be on level 1.
Finally, you need to know what the various escape codes are. These codes
are used to translate between special HP symbols (such as start and end
program) and plain ASCII. Here's the complete table:
Complete Table of Escaped HP Ascii Characters:
\\ Backslash
\<) Angle
\x- Mean (bar-x)
\.V Inverted Triangle
\v/ Square Root
\.S Integration
\GS Sigma
\|> Solid Triangle
\pi Pi
\.d Derivative
\<= Less or Equal
\>= Greater or Equal
\= Not Equal
/\Ga Alpha
\-> Right Arrow
\<- Left Arrow
\|v Down Arrow
\|^ Up Arrow
\Gg Gamma
\Gd Delta
\Ge Epsilon
\Gn Nu
\Gh Theta
\Gl Lambda
\Gr Rho
\Gs Lower Case Sigma
\Gt Tau
\Gw Omega
\GD Delta Triangle
\PI Upper Case Pi
\[] Square Dot
\GW Upper Case Omega
\oo Infinity
You now have everything you need to write HP49G+ software on your Mac!
You can use TextEdit, jEdit, bbEdit or any other tool for editing plain
text files.
Jean-Yves Avenard
> While trapped in an all-day meeting today, I managed to track down
> everything you need to save HP49G+ programs as text files on an SD card,
> edit them with a Mac and then load them back into the HP49G+.
Aren't calculators beautiful? You can now pretend to be in a meeting and
do something fun!
Jean-Yves
Mike Mander
built-in command to compile text files...
Mike
Michael Heinz <porkchop...@NOSPAM.mac.com> wrote in message news:<porkchop_d_clown-B7...@comcast.ash.giganews.com>...
Jean-Yves Avenard
> Works like a charm - thanks! I am surprised that there isn't a
> built-in command to compile text files...
There is:
STR-> or OBJ->
Jean-Yves
James M Prange
True, but it would be nice to have built-in UserRPL options to store
decompiled and translated (with the translation options as in Conn4x)
objects on the SD card, and copy/move them to a global variable and
have them "untranslated", compiled, and stored automatically.
To be sure, we can do all of this easily enough with the help of
SysRPL commands (or the equivalent SYSEVAL sequences), but that seems
to be a bit much to expect of the average user.
Oh well, maybe in a future ROM.
--
Regards,
James
James M Prange
> While trapped in an all-day meeting today, I managed to track down
> everything you need to save HP49G+ programs as text files on an SD card,
> edit them with a Mac and then load them back into the HP49G+.
<snip>
Good, but I can foresee some possible problems.
Maybe I'm just paranoid, but the file that the 49g+ stores on the SD
card begins with an 8-character binary transfer header "HPHP49-X"
followed by the compiled object, which (assuming a character string
object) starts with the 5-nibble character string prologue, followed
by the 5-nibble character string size field, followed by the
characters in the string. What if I change the number of characters in
the string without adjusting the size field to match? What I do is
always remove those first 13 characters with my text editor, just to
make sure that the size field doesn't "confuse" the calculator.
Without a valid transfer header, the calculator just treats the file
as a character string, so the STR\-> or OBJ\-> compiles it correctly.
But maybe this isn't really necessary; I haven't actually tried it
without removing those first 13 characters.
To avoid changing "exact integers" (type 28.) to "real numbers"
(type 0.), have the calculator in "Exact" mode when using your
programs. That goes for any transfer except from a 48, in which case
the 49 series should be in "Approximate" mode to avoid changing
integer valued real numbers to exact integers.
Without an "ASCII" (text) transfer header, there are some modes used
in the file that the calculator has no way of "knowing", so it just
uses its current modes. I see that you take care of the translation
mode in your programs, but be aware of the following.
If you have an object that includes an angular component (vector or
complex number uploaded with the calculator in "polar" (cylindrical)
or spherical display mode, or if you use the \>) symbol as the
separator in one of these in the text editor), then be sure that the
calculator's angular units mode (Radians, Degrees, or Gradians) is set
to interpret it correctly.
Be sure that the fraction mark ("." or ",") mode on the calculator
agrees with what you're using in the file.
And of course, one should be aware that your programs force the
numeric display mode to STD, the wordsize to 64, and the translation
mode to 3.
--
Regards,
James
Michael Heinz
James M Prange <jmpr...@i-is.com> wrote:
> Good, but I can foresee some possible problems.
James,
You're right, of course - these routines are a first step. I've been out
of the calculator scene for a good 4-5 years and I'm still on a
re-learning curve. I haven't even touched the SysRPL aspects of the 49G+
yet.
At a minimum, what I'd like to see is a routine that can interpret the
HP text header you refered to and make changes as needed. At best, what
I'd like is something that either extends or works like the FILES menu,
so that you can select, copy and translate objects in one step.
I don't fully understand the exact/approximate issue at this point,
since I don't understand the implications of an integer being cast as a
real.
Any advice you can give on this issues would be appreciated.
Michael Heinz
Jean-Yves Avenard <m...@privacy.net> wrote:
Unfortunately, STR-> and OBJ-> don't deal with the escape sequences,
which you need for editting source code on unsupported platforms.
Urk! Time to run. I'll explain more later.
Mike Mander
>snip<
> STR-> or OBJ->
>
> Jean-Yves
Yes, I am aware of how those commands can be used. However, if you
could show me how they can compile text file escape sequences like \<<
and \oo and so on, I would love to be enlightened!
I suppose I was not clear enough and should have stated "I am
surprised there isn't a built-in UserRPL command to compile text files
that contain embedded escape sequences..."
I have a fair bit of old commented UserRPL code that was programmed on
a PC many years ago using such embedded escape sequences. Now that I
have a Mac and cannot get Conn4x to transfer files directly and have
the escape sequences translated for me, these simple programs seem to
work well (as far as I have tried them) - keeping in mind exact
integers versus reals and other such issues during the translation
stage. Now if only the comments could automatically be stripped from
the compiled code, placed on an SD card and then reinserted when the
code is decompiled for editing, I would really be happy! :-)
Mike
James M Prange
<snip>
> Maybe I'm just paranoid, but the file that the 49g+ stores on the SD
> card begins with an 8-character binary transfer header "HPHP49-X"
> followed by the compiled object, which (assuming a character string
> object) starts with the 5-nibble character string prologue, followed
> by the 5-nibble character string size field, followed by the
> characters in the string. What if I change the number of characters in
> the string without adjusting the size field to match? What I do is
> always remove those first 13 characters with my text editor, just to
> make sure that the size field doesn't "confuse" the calculator.
> Without a valid transfer header, the calculator just treats the file
> as a character string, so the STR\-> or OBJ\-> compiles it correctly.
> But maybe this isn't really necessary; I haven't actually tried it
> without removing those first 13 characters.
Ok, being that I don't have much on the 49g+ right now, I
experimented. It seems that, at least for strings, if I modify the
number of characters in the file on the SD card without changing the
header, object prologue, and size field, and put the card back into
the 49g+, then the calculator just treats the entire file as a string.
It's easy enough to just put the string on the stack and just do
14. OVER SIZE SUB to extract the relevant part and fix things up.
Personally, I'd just as lief take care of it in the text editor on the
PC.
<snip>
--
Regards,
James
Veli-Pekka Nousiainen
news:m2x7c.4291$eM....@fe03.usenetserver.com...
> I wrote:
>
> <snip>
X
> Ok, being that I don't have much on the 49g+ right now, I
> experimented. It seems that, at least for strings, if I modify the
> number of characters in the file on the SD card without changing the
> header, object prologue, and size field, and put the card back into
> the 49g+, then the calculator just treats the entire file as a string.
> It's easy enough to just put the string on the stack and just do
> 14. OVER SIZE SUB to extract the relevant part and fix things up.
> Personally, I'd just as lief take care of it in the text editor on the
> PC.
You still need the proper modes
You can search back from Google to find my short routines
that take care of the "." "," issue and naturally snip the header
line as you suggested. My post is one week back I think.
[VPN]
Michael Heinz
mma...@spymac.com (Mike Mander) wrote:
> Now if only the comments could automatically be stripped from
> the compiled code, placed on an SD card and then reinserted when the
> code is decompiled for editing, I would really be happy! :-)
>
It would be really easy to write an app, maybe even an Applescript
droplet, that would strip comments from the source code and then write
it out to the SD card. I've been toying with the idea of doing that, or
even a full HPEdit style editor if I can find time.
But still, as others have pointed out, it would be best if we could
embed the %%HP: T(x)A(y)F(z); header and have the calculator properly do
the stripping, conversion and escaping.
I took a pass through the SYSRPL entry points, but it doesn't look like
there's a routine to do all that.
Does anybody know if such an entry point exists?
Mike Mander
>snip<
> It would be really easy to write an app, maybe even an Applescript
> droplet, that would strip comments from the source code and then write
> it out to the SD card. I've been toying with the idea of doing that, or
> even a full HPEdit style editor if I can find time.
>snip<
Back in the days of owning a PC and using DOS, I had written a
programmers text editor in C and assembler that I used for developing
software in C and C++. I adapted it to use for writing HP48SX code
and wrote a filter routine that stripped all comments and excess
formatting whitespace to minimize transferred file size before doing a
Kermit RS-232 transfer to the calculator. I always hated the blocky
"@" comment characters and myself used "|" instead. Actually, it was
four programs working together - my text editor, the simple
whitespace/comment stripping program, the standard Kermit comm package
that came with HP's interface kit and a general purpose macro TSR
program that I wrote which interfaced with special "hooks" I had built
into the editor and tied the whole thing together nicely.
It was really a fast and efficient way of programming UserRPL. I
could make changes to a source file on the PC, activate a macro with a
couple of keys and in a matter of 10 seconds or so, the changes would
be on the calculator ready to test out. No SD card swapping required!
Ah, the good 'ol days...
If I just had more time, I would try and develop a simple and
efficient integrated UserRPL editor for the Mac, but I admit my Mac OS
X programming skills (cough) need work...
Then there's the issue of the (so far non-workable) USB connection to
the Mac...
Mike
Beto
I wonder if the EMU49ASC file (or something like that) that comes with
EMU48 will do the trick. It takes an ascii string and translates it to
UsrRPL.
You could give it a shot or watch it's innerworkings to see if it can be
ported to 49G+.
Regards,
--
Beto
Reply: Erase between the dot (inclusive) and the @.
Responder: Borra la frase obvia y el punto previo.
Michael Heinz
> I wonder if the EMU49ASC file (or something like that) that comes with
> EMU48 will do the trick. It takes an ascii string and translates it to
> UsrRPL.
>
I was unaware of that tool. I'll take a look!