[Long] 48/49 communications, ROM, printers
Message #6 Posted by James M. Prange on 9 Mar 2004, 5:12 a.m.,
in response to message #1 by Antoine M. " Kermit " Couëtte ( France )
Regarding the 49G revision 1.19-6 ROM, I gather that HP (management)
decided that revision 1.18 was "good enough", and that no more time and
money should be "wasted" on it, but the developers wanted to do more, so
continued with unsupported revisions on their own time, hence the "beta"
designation and refusal of official "HP Support" to deal with the
unsupported releases. I can't help wondering whether that had something
to do with closing down ACO. But in any case, I think that 1.19-6 has
very worthwhile improvements over the "supported" ROM. For any problems
with 1.19-6, ask at comp.sys.hp48 or, if it seems to be a genuine bug or
for enhancement requests, post at http://bugs.hpcalc.org/. I
understand that development for the 49G has progressed beyond 1.19-6,
but that HP has prevented the release of any newer revisions on
"intellectual property" grounds. Maybe someday....
As for the "Xmodem 1K-HPCRC protocol", I don't know that it's used
except for downloading a ROM, but perhaps a search at
http://groups.google.com/advanced_group_search?group=comp.sys.hp48 might
reveal more information.
As Raul recommmended, except for use with the 48SX/S, use the Conn4x
application now, and use the latest revision (Version 2.2 Build 2348 for
Conn4x and, for the 49g+, USB driver revision 1.2, and ROM revision 1.23
Build 31, at my last check). These have some very nice enhancements and
important bug fixes over the ones that came on the CD-ROM with my 49g+,
and I'm now happier with Conn4x than with any other communications
package that I've tried. Also note that any new files seem to show up a
few days earlier on HP's "Business Support" pages than on their
"Customer Care" pages. For the 48G series, install the XSrvr library
that comes with Conn4x; it makes things much easier. But as the
instructions say, install the library in port 0 or 1. I found out
experimentally that if installed in port 2 (and presumably higher), it
hangs the calculator when I try using Conn4x, requiring a "paperclip
reset" to force a warmstart, and leaving an unacknowledged alarm
warning, flag changes, and last command lines and stack saves disabled
(although not a TTRM, and the home directory seems to be uncorrupted). I
recommend that you "don't try this at home".
Conn4x uses the Xmodem protocol, which isn't built-in to the 48SX/S, so
doesn't work with them. I don't know of an Xmodem application for the
48SX/S, but there might be. Otherwise, use the Kermit protocol.
Conn4x does have a "text" transfer option with various translation
options for decompiled objects, similar to an HP calculator Kermit protocol
"ASCII" transfer, and compatible with the Kermit "ASCII" transfer
files, except that for the characters "NUL" (character 0, the "null
character"), """ (character 34, the double quotation mark), and "\"
(character 92), the translations differ; see the Conn4x help file. Conn4x adds the option of translating control codes 0-9, 11-31, and 127 to the "\nnn" codes (independently of the other translation options), the LF (character 10) to CR LF (characters 13 10) pair translation can be disabled independently, and where the Kermit translations always left a CR LF pair untranslated for outgoing transfers, so a tranfer back to the calculator (with any non-zero translation option) changed it to just LF, Conn4x (with LF translations enabled) translates CR LF to CR CR LF, so it's CR LF again when transferred back to the calculator (as long as your text editor hasn't made it's own "End Of Line" translations to it based on the extra CR, which can be avoided by leaving the translate control codes option enabled).
Conn4x also has a "Calculator Commands" window, so you can run the calculator from the PC, similar to the Kermit Remote Host commands. And an "Edit as text" option that uses your PC's text editor (NotePad by default, but you can set it to use your preferred editor) and a file in the PC's %TEMP% directory, sending the changes to the calculator only if you actually save the file on the PC. "Edit as text" may be preferable to the calculator's command line editor in some situations.
Note that the 49 series, unlike the 48 series, decompiles "NUL", """, and "\"
characters to "\00", "\"", and "\\"; an improvement for use on a 49
only, but a 48 series doesn't "understand" that new rules should apply
for compiling these sequences, so they cause problems for 49 series to
48 series transfers. Going the other way isn't quite so bad because
either calculator compiles a literal "NUL" unchanged and the 49 series
understands the counted string form that the 48 series uses when a """
is embedded in a string; the only problem (with these characters) for a
48 to 49 transfer is that a 49 compiles (unless it's within a counted
string) a "\" (not immediately followed by "00", """, or another "\") to
""; that is, it simply discards it. Note that with ROMs prior to 1.19-6,
the 49G incorrectly compiles "\00" to "00" instead of "NUL".
Also note that "binary" transfers between a 48 series and a 49 series
are rejected, and for good reason; they could very well cause a crash or
memory loss if you fooled the calculator into storing an incompatible
compiled object. Well, not completely rejected, but the entire incoming data stream (including the binary transfer header) is stored as a character string object, instead of extracting the compiled object and storing it as such.
A work-around for the problem of transferring an object an that contains
these characters between a 49 and a 48 is as follows. If the object
isn't already a character string (the string with these characters could
be an element of a list or program), first, to assure full precision of
real numbers and user binary integers, do STD and 64 STWS, and to avoid
any angular components being compiled using a different angular unit
(Degrees, Radians, or Gradians), execute RECT. Then do \->STR to
decompile the object to it's string form (this could, except for the
RECT command, be done with a single SysRPL command instead), and store
it as a named variable (a local variable is better, if you care to
automate the process with a program). Be sure that the fraction mark (.
or ,) is the same on both calculators. Now, set both calculators for
binary transfers, and make the transfer, using either Kermit or Xmodem,
and for that matter, either directly or by using a PC as a go-between.
The object arrives with a non-compatible binary transfer header, so the
calculator doesn't attempt to store it as the compiled object; it just
stores the entire data stream as a character string, with the original compiled character string embedded within it. Recall the string
to the stack. It starts with the 8-character binary transfer header,
followed by a 5-nibble character string prologue, followed by a 5-nibble
size field (13 characters so far), followed by the characters in the
original string. Extract everything after the first 13 characters by
doing 14 OVER SIZE SUB to get the original string, then, if the object
wasn't originally a string, do STR\-> to compile the string to the
original object, and then store it in the variable of your choice.
Other problems are that integer valued type 0 "real" numbers from a 48
may be compiled as type 28 "exact integers" on a 49 because they lack
the decimal point used on 49 series real numbers; just set the 49 to
approximate mode to avoid this. Of course, the 48 doesn't have exact
integers, so if it gets one from a 49, it's compiled as a real and, if
more than 12 digits, rounded to 12 significant digits. When doing an
"ASCII" or "text" transfer of a PC file to a 49, have the 49 in exact
mode to avoid changing exact integers to real numbers. Other new object
types on the 49, such as type 29 "symbolic" vectors/matrices, will
result in a syntax error on the 48. The 49's new command names will be
compiled as global names on the 48, and if a global name from the 48
happens to match a new command name on the 49, then it will be compiled
accordingly. I suppose that a transfer with a name that matches a
command would be rejected, but in any case, a name compiled to a
different object type within a composite (list, program, or algebraic)
will cause "unexpected behaviour".
The IR communication between 48 series models is indeed slow; only 2400
bits per second is built-in, although I understand that it can be
"tweaked" higher by adding some applications. And IR does take more
power than "via wire" communications too. Note that IR communications are half-duplex (to avoid reflections being treated as incoming data), so XON/XOFF flow control (useful for raw "serial I/O" communication, but not needed for Kermit or Xmodem) isn't available. But you can hook up wired
connections between 48 series, and between a 48 and the 49G, at 9600
bps. Between two 49Gs, you can also use that oddball 15360 bps speed. Note that on the 49G, XON/XOFF flow control doesn't work, although it's intentional removal is undocumented.
For small transfers, IR is ok, but for larger transfers, I do it via
wire. Of course, the 49G lacks IR, so transfers or printing via IR isn't an option with it.
The 49g+ lacks RS-232 style I/O, so a wire connection works only to a
USB host with the 49g+ USB driver installed. The 49g+ IR is IrDA instead
of "Serial IR", so it doesn't work with the 48 series. I don't have an
IrDA to RS-232 adapter, but I've read that they work just fine. But for
anything except connecting to a PC or other device that can supply power
from a non-data line, be sure to get one that can accept external power
from a battery or AC adapter, and one that doesn't require a device
driver (see http://www.actisys.com/instantir.html for the only example that I'm aware of). I don't know what kind of range you can expect with the 49g+ for
IrDA communications.
The 49g+ does print via IR in the "Red-Eye" protocol required by the
82240A/B (and, I think, some other) HP printers, but the range is
drastically reduced to 2 or 3 inches. If you care to spend some money,
I've read that the Martel printers that accept the "HP IR" protocol work
with the 49g+ as well as the 48 series, although I'd guess with the same
reduced range; see http://www.martelinstruments.com/cased.html.
Regards,
James
Edited: 9 Mar 2004, 8:02 a.m. after one or more responses were posted
|
Go back to the main exhibit hall