Re: HP 50g?
Message #5 Posted by James M. Prange (Michigan) on 10 Aug 2006, 9:02 a.m.,
in response to message #4 by Howard Owen
Quote:
One other drawback is that coding non-trivial User RPL
programs on the calculator itself is difficult. Even with the 49G+
and 50g, where you have a fair amount of screen real estate, the
calculator reformats your code to its own idea of what the
indentation should be.
True, the RPL calculators compile the source code to an object,
and then decompile the object for display or editing, thus losing
any user-preferred formatting and comments.
A work-around is to write the source code within a character
string, thus preserving it exactly as written. Then when you want
to compile the source code, use the STR\-> (or OBJ\->) command on
a copy of it.
A problem with using STR\-> is that it may be difficult to
determine just where the problem is when you get an "Invalid
Syntax" error. In this case, edit a copy of the string in the
command line, editing out the " delimiters, and then press ENTER;
this should be more helpful.
Of course, for lengthy programs, the larger screen and QWERTY
keyboard of a PC is a big advantage. Transferring a program to the
calculator is reasonably fast, even with the 48 series. If you get
an "Invalid Syntax" error, insert
C$ $
on its own line after the header to make the rest of the file a
string, and proceed as above.
Quote:
I find I have to use something like HPUserEdit in order to be
productive, which means I need a Windows PC. That's a problem for
me since I strongly prefer Linux. But if I do deign to boot
Windows, the process of coding with HPUserEdit is quite nice. The
code can be tested on a cooperating copy of emu48, and the
integration is very, very sweet.
Well, suit yourself, but I find it much easier to just use a text
editor, using translation mode 3 for the transfers. I happen to
prefer TSE, but any text editor, even MS Notepad, suffices. Surely
any Linux user would be familiar with some text editor? For that
matter, any "word processor" should work too, as long as the
source file is saved as "plain text". If you do this, then you'll
soon learn the translation sequences for non-ASCII characters that
you use frequently.
If you need a reminder of the translation sequences, the following
User-RPL program for the 49 series builds a handy string with the
decimal value, "binary" value, the character, and the translation
sequence for characters 128-255. Note that the "binary" value is
mode (BIN, OCT, DEC, or HEX) dependent, and whether a character or
its translation sequence appears in the last column depends on the
translation mode stored as the last element of IOPAR (I recommend
translation mode 3), when the program is run. How any character
appears depends on the current font when the string is viewed. To
view the string, press TOOL and then VIEW, or put it into the
command line editor with CursorDown or LeftShift CursorDown. Be
patient; this takes about 16.5 seconds to run on a 49G, or 6.2
seconds on a 49g+, but once you've run it, you can simply store
the string for later use. A SysRPL version of this is available in
my "ASCII on SD" package.
%%HP: T(3)A(D)F(.);
@ For 49G and 49g+ (and, I guess, 48gII and 50g) only.
@ Checksum: # A162h
@ Size: 116.5
@ Download in exact mode.
\<< @ Begin program.
"" @ Start with empty string.
128 255 @ Relevant character values.
FOR n @ Start loop.
"\010" @ LineFeed string.
n @ Loop index value.
" " @ Space string.
OVER @ Copy of loop index value.
R\->B @ Convert to "binary" integer.
OVER @ Copy of space string.
+ @ Append space to binary string.
PICK3 @ Copy of index value.
CHR @ Convert to character string.
PICK3 @ Copy of space string.
OVER @ Copy of character string.
# 2F34Eh SYSEVAL @ KVIS for 49G and 49g+ (converts
@ character to translation sequence).
+ + + + + + + @ Concatenate strings.
NEXT @ Loop end.
"\010" + @ Append LineFeed.
\>> @ End program.
Here's a version for the 48 series. Note that the entry point for
KVIS is different, and it uses 3 PICK instead of PICK3. Use
CursorDown to view the string. It takes about 23.5 seconds on a
48SX, or 14.8 seconds on a 48GX.
%%HP: T(3)A(D)F(.);
@ For 48SX/S/GX/G/G+ only.
@ The usual dire warnings to be careful with SYSEVAL apply.
@ Checksum: # 58A5h
@ Size: 128.5
\<< @ Begin program.
"" @ Start with empty string.
128 255 @ Relevant character values.
FOR n @ Start loop.
"\010" @ LineFeed string.
n @ Loop index value.
" " @ Space string.
OVER @ Copy of loop index value.
R\->B @ Convert to "binary" integer.
OVER @ Copy of space string.
+ @ Append space to binary string.
3 PICK @ Copy of index value.
CHR @ Convert to character string.
3 PICK @ Copy of space string.
OVER @ Copy of character string.
# 2FEDDh SYSEVAL @ KVIS for 49G and 49g+ (converts
@ character to translation sequence).
+ + + + + + + @ Concatenate strings.
NEXT @ Loop end.
"\010" + @ Append LineFeed.
\>> @ End program.
Of course, in modes 1-3, a LineFeed not immediately preceded by a
CarriageReturn is translated to a CarriageReturn LineFeed pair on
transfers from the calculator, and a CarriageReturn LineFeed pair
is translated to a LineFeed on transfers to the calculator. In
modes 2 and 3, the translation sequence \010 can be used for
LineFeed, and \013 for CarriageReturn. Also, in modes 2 and 3, the
translation sequence for \ itself is \\ (or \092). In mode 2, you
can also use the translation sequence \nnn for characters 0-159,
and in mode 3, you can use \nnn for characters 0-255, where nnn
represents the 3-digit decimal value of the character.
Regards,
James
|
Go back to the main exhibit hall