Version 5.2004: Command O~S added to Ioman+. remCR, addCR now merged in the command ~CR.
Version 4.2004: Ioman+ got a third page; see below. First option in the IOP and PrP menu is now I~W (toggle Infrared/Wire).
Version 3.2003: Access to MODE during parameter setting for flag control etc.
Version 2.2003: Repeater keys in the parameter setting environments faster. Parity parameters can also be negative. Ioman+ for HP49g+ added.
FIRST version 1.2003 (January 2003).
Page 1 - Transfer
Page 1 of the Ioman command menu is shown in the screen. The
first four commands do what they say, but Send,
XSend, and XRecv first open an input
list,
as
in the screen capture for the case of XSend, for entering
global or port names. Recv doesn't take any arguments;
it just waits for a Kermit file transfer (1 or more named
files) to arrive. Press VAR to put the names of the files to be
sent with Xmodem, say, in front of the blinking cursor and then
press ENTER to start the transfer. This is clearly more
convenient than producing the list in advance. If the names are
already on the stack, you can press the HIST key to open a
stack browser and ECHO the names to the list from the stack.
Note that if you have Filer6 installed, you can use its Q key
(Quote) to put quoted names on the stack before using the Ioman
commands. This list input procedure can be aborted any time by
pressing CANCEL. When sending one or several files with Send,
simply set the Kermit server mode on the receiving calculator
or other Kermit device. Alternatively, you could use Recv or
the RECN command on the other 49g+, or another system's
equivalent commands. However, if using XSend, option XRecv on
the receiving device only works if run with a list of file
names, not necessarily the ones used by the sender. Send, XSend
and XRecv turn off the calculator after ending the task. This
saves the batteries and makes CLOSEIO dispensable. Clearly,
these four commands are particularly helpful for the transfer
between two calculators using IrDA (= Infrared Data Association
protocol). For transfer from and to a PC via USB (= Universal
Serial Bus), it's better use the connectivity kit Conn4x with
the calculator in Xmodem Server mode; see the Conn4x Help.
OVW? toggles flag -36 and flashes the messages "RCV
overwrites" and "RCV renames". Hence, you need not visit the
flag browser for this option.
Most interesting is option IOP. It creates the reserved variable IOPAR in HOME if not
yet present and sets a message box
with the current values in it. IOP has its own menu as shown in the
screen below at left for choosing Infrared/Wire
(flag -33), ASCII/binary (flag -35), and all admissible values
of the parameters from IOPAR. These are
cycled through in place with the corresponding menu options in
the range of valid arguments. There is an option Reset, invoked
by pressing 
(backspace), which resets the IOPAR values to the most useful
defaults. Reset selects translation mode 3 instead
of 1, so all characters 128-255 are translated when sending in
Kermit "ASCII" mode. In contrast to the RESET option from the
Transfer dialog in APPS, Reset doesn't change any flags.
It's a better idea to have the reserved variable STARTUP force
system flags to your preferred state. STARTUP may well be
useful during normal usage, not only in warmstarts. It's a good
idea to assign STARTUP to a key and to run it just before
using I/O. Note that for a connection to Conn4x, flag -33 must
be clear, done by setting I~W in IOP to WIRE. And for
screen captures, flag -34 must be set, done by setting
I~W in PrP to WIRE, see below. Conn4x doesn't care about flag -35
though, using it's own Binary/Text setting instead, and ignores
the Kermit translation mode parameter in IOPAR, using it's own
settings instead.
Inside the IOP environment, you can visit APPS and its items like I/O functions, or MODE for setting additional flags, say. If no error occurred, you'll nicely return to IOP. The +/- key changes the sign of the parity value. Use parity if some other system requires it, but it's not a very effective error detection system for communications, adds overhead (slower transfer), and with any parity setting except 0, you can transfer only the 7-bit pure ASCII characters 0-127 when using XMIT or SRECV, or printing "via wire". Also, USB and IrDA , as well as Kermit and Xmodem, use their own (much better) error correction methods, and parity is always "none" in Xmodem Server mode. Note that ASCII/binary, checksum, and translation mode affect only Kermit transfers, not Xmodem transfers. Transfer via wire/IR, translation mode, and parity also affect printing "via wire". Some object types, such as libraries, graphics objects, fonts, and minifonts, are always transferred in binary mode. Baud rate choice in IOP may not cause any difference in the actual speed with the 49g+. Besides CANCEL and ENTER, only NXT, APPS, MODE and +/- are active hardkeys in IOP. The IOP box is left with CANCEL or ENTER; the last setting is valid in either case.
 |
 |
|
their menus for selecting admissible parameter values. |
|
Page 2 - Printing
Menu page 2 of Ioman looks as
follows: |PrVar|
|PrSTK| |PrLCD| |SSP?|
|LF?| |PrP|
PrVar| starts printing after one or several names have
been put into the waiting list and ENTER pressed, much like the
transfer commands above. The name of the variable is printed,
then starting on the next line, the variable's content,
formatted similar to what it would be in the command line
editor, and then the paper is advanced one line before printing
the next variable, which makes it easy to notice where the end
of a variable is. PrVar turns the calculator off when finished.
PrSTK opens a choose box for printing the stack, with
the items PR1, PRST, and PRSTC, with the middle item
pre-selected. PR1 is a command for printing stack level
1 only, in multi-line format, without the stack level tag, and
a string is printed without the "" delimiters. PRST
prints all objects on the stack in multi-line format, tagged
with the level number, and with "" delimiters enclosing
strings. PRSTC is similar, but prints the objects in
single-line format. The third menu key, PrLCD, executes
the PRLCD command, which prints the entire display as a
graphic object. It's also available by the [ON]_hold_[CursorUp]
key combination from anywhere except from special system tests
screens. SSP? toggles Single/Double spaced printing
(flag -37) and flashes the result in the header. LF?
toggles the adding of linefeeds (flag -38) and indicates this
in the header. When "No linefeeds" is chosen, existing LF (=
Line Feed, character 10) characters in strings are left
unchanged (see Lend below), the normal print formatting isn't
done, no line wrapping (see Llen below) is done, no line
termination string is added at the end of printing, and print
delay (see below) adds a pause only after a LF within a string.
Finally, PrP creates a menu (right-hand screen) for
toggling Print Infrared/Wire, the four parameters in the
reserved variable PRTPAR, an option to visit IOP (see above),
and a Reset.
The PrP menu is more difficult to explain. As soon as PrP is pressed, the default PRTPAR is created in the HOME directory if not yet present. I~W toggles flag -34 for choosing printing by "Infrared" or "Wire". The first is for printing to the HP 82240A, 82240B, or compatible printers, the second is indeed for printing by wire if "Transfer by wire" is selected, but by IrDA if "Transfer by IR" is selected. When printing by "wire" the special formatting of some objects such as matrices for the 82240A/B printers is lost, and the character translations (except LF) are applied as in Kermit ASCII transfers. Dlay controls the delay after printing each line (after the first 200 hundred bytes). The HP 82240A/B printers have only a 200 hundred byte buffer, a maximum print speed of about 1 line per second, and no way to tell a calculator when the printer is ready to accept more data, so delays are added to avoid overrunning the buffer. The print delay selected by Ioman can have values of 0, .1, .2, …, 6.9, cycled through with Dlay if it's held down longer. Choose a value that allows your printer to keep up with the data being sent without overrunning its buffer, but not waiting long for the next line, just a slight delay at the end of the line. The "best value" varies with the printer's battery condition. If the printer prints out a black box with a white slash through it, a buffer overrun has occurred.
Remap looks for a global variable named 'Remap' on the path, with a string in it. If not found on the path, Remap simply displays its own name to remind you that it is not defined. Definition is not mandatory though. If not found, the system chooses the empty string, which suffices for the 82240B for most purposes. The string replaces the remapping string in PRTPAR. The remapping is applied only when printing by IR. The 1st character in the string replaces character 128, the 2nd replaces character 129, and so on through the 128th replacing character 255. The intended purpose is for remapping the 48/49 series character set to match (where possible) the older 82240A printer. The OLDPRT command supplies a string for this, but it perhaps leaves a bit to be desired for some characters. Also, it might be better to choose an 82240A character that isn't in the calculator's character set as a replacement for calculator characters missing from the 82240A character set.
Llen and Lend apply only when printing by wire. Llen tells us to employ + or - for changing the printout's line length (default is 80 characters). Holding down + or - repeats, similar to Dlay. Print lines are wrapped (assuming Add linefeeds) to this length, but note that this is inconsistent; for example, with the PRST and PRSTC, the stack level tag ("1: ", for example) is not counted for wrapping, so some lines may exceed what you set. Lines are normally wrapped at spaces separating "words", but a space within a character string isn't treated as a separator to be optionally replaced by a Line Feed. If the first "word" on a line is longer than the length value, then it will be split. Lend toggles the default line termination string (a 2-character string containing CR (= Carriage Return, character 13) and LF (= Line Feed, character 10) with your own line termination string. This must be a string in the global variable Lend on the path. This string will replace any LF character, whether added by wrapping or pre-existing in a string. Most printers are set up to use the pair CRLF to print the current line and start a new line, but some use just CR for this, so a string containing the single character CR would be appropriate. There may be printers that need just LF for this. You can use any string for Lend; for example, the string "End of the line!". You could use it to add text at the end of each line or the beginning of each line after the first. If the name Lend is not found, the name itself is displayed to remind you that it may be defined; definition is not mandatory though.
For choosing transfer parameters (some of which affect
printing), press IOP from the PrP menu. The I/O parameter for
Transfer via wire/IR, and when printing by "wire", for baud,
parity, and translation mode apply. After visiting IOP, you
return safely to PrP with ENTER or CANCEL. For choosing the
right flags for serial port connection or other information,
you may visit APPS and MODE from PrP, with a safe return to
PrP. Reset, invoked by pressing as indicated in the last screen-shot,
sets the 4 parameters in PRTPAR to the most useful default.
PrP's Reset sets the print delay to 1.8 (appropriate for an
82240A/B printer) instead of the default PRTPAR's 0. Like the
Reset in IOP, the one doesn't change any flags; use MODE FLAGS
to check flags -33 through -39. It may be useful to have a
STARTUP variable force these flags before printing.
At any rate, remember that I~R both in IOP (toggles flag -33) and in PrP
(toggles flag -34) must show WIRE for communication with
Conn4x. The first is responsible for file transfer, the second
for screen-shot upload. We could have included these settings in
the Reset options of IOP and PrP, but we did not because some
users may communicate more often with other devices than a
Windows based PC.
In Transfer via IR mode with the port open, the 49g+ frequently sends out a signal that, if detected by an 82240A/B printer, is treated as a series of bytes with uncorrectable errors, so the next time the printer receives a character 4 or 10, it prints them as black boxes. So when using these printers, it's best to leave the port closed which should also save on batteries. A turn-off of the 49g+ suffices.
The parameters for I/O speed, parity, receive pacing, transmit pacing, Kermit checksum method, and translation mode are stored in the reserved variable IOPAR in the HOME directory, and the parameters for print delay, remapping string, line length, and line termination string are stored in the reserved variable PRTPAR in the HOME directory. For more details, see the reserved variables IOPAR and PRTPAR, the system flags mentioned above, and the various I/O and printing commands in the HP 48G Series Advanced User's Reference Manual. For those of you interested in some secrets about the ASCII control characters (characters 0 - 31), some of which play a basic role also in the commands of page 3 listed below, the Ioman package contains the file CtrlChrs.hp (a self-decompressing binary), which lists the names and their original meaning of all 32 control characters. You may load this file either to the 49g+ or to its SD-card and have this useful information always available.
Printing from APPS: By pressing APPS, choosing "I/O functions…", and then "Print…", you get to an input form for printing any object. By pressing CHOOSE, you're taken to a filer, and pressing CHECK with a variable highlighted selects the object in the variable for printing. To print the objects, press OK or ENTER to get back to the input form, and then PRINT to begin printing the objects. But note that this is different from the PRVAR command: The variable names aren't printed, and after the last line of one object, the next object is printed on the very next line. If you press EDIT instead of CHOOSE, a command line is opened. From this command line, you have access to much of the calculator's normal functionality, with access to the menus, or by pressing HIST, to the stack browser (to ECHO items from the stack, for example), but not to APPS. Pressing ENTER executes the command line, but putting the result into the input form field instead of on the stack.
Page 3 - Extras
| visCC | Visualize Control Characters (characters 0 - 31) in stack object: The object, if not already a string, is converted into a string. An often invisible control character with number n is replaced by the small text fragment #nx (no space between # and n) with n being the value of the character in the current number base (HEX, DEC, OCT, or BIN), and x the trailing h, d, o, or b indicating the base. Only Line Feed (= LF, character 10) is not affected by visCC, in order to respect possible linebreaks of the input. Note that visCC eliminates styled text parts or any font changing inside a text. On the 49(+), these are controlled by character 19. Thus, after running a styled text with visCC, you'll see a #19d at various places. And you'll see, by the way, how stylings or font changings are internally realized. |
|
~CR |
You can download a text file (no matter with or without a
HP header) with Conn4x in binary mode by just
ignoring its warning, even this document, Ioman.htm. Then you will probably see
black squares at the end of lines. Each
black square is a Carriage Return (= CR, character 13).
~CR just removes them. Text editors most often use a
CRLF pair as the line terminator when saving a
file, and Conn4x normally changes the CRLF
pair to a LF when downloading a text file. But
forcing Conn4x to download a text in binary mode prevents this change. ~CR just replaces
each CRLF pair in
a string with LF. In the same way you may
download commented source files of programs with Conn4x
in binary mode in order to keep the comments, which would
be lost if downloaded in text mode.
For this immediately compiles the file,
discarding, by the way, all comments. Note that if the
file has a valid transfer header, Conn4x uses the header
to determine how to treat the file, but this can be avoided by adding anything, a
space character or blank line for example, before the
header. ~CR also does the opposite. That is, it replaces all LF characters with CRLF pairs. Some text editors treat CRLF pairs as line terminator strings when loading a file, but treat a LF by itself as a literal character, displaying it as a black box or some strange looking symbol. Conn4x is usually set up to translate all LF characters to CRLF pairs when uploading a file in text mode, but also decompiles an object to its source code string form. Suppose that you want to upload an object in its compiled form (binary transfer), but do want any LF characters translated? Here ~CR does the translation. You see toggling ~CR also if pressing CrTT below and then toggle on the resulting string with ~CR. In older MAC computers, linebreak in text files is realized by CR only. It is easy to write in UsrRPL a corresponding toggler ~LF, using the powerful command SREPL from the menu set with RS. For example: %%HP: T(3); \<< \->STR "\013" "\010" PICK3 OVER IF POS THEN SWAP END SREPL DROP \>> You can copy and paste the above to a file and download it with Conn4x in Text mode. (Set up Conn4x to Translate Codes 128-255.) This program decompiles any object to a string before toggling LF with CR. To change between CRLF pairs and "bare" Carriage Returns, use ~CR before or after ~LF. Note that if a string has both CR and LF in it, toggling twice won't return the original; a program to do that would be larger and slower. |
|
O~S |
Toggle a HP user object with its string representation.3.14 is toggled with "3.14", 123 with "123" (in exact mode), 'Name' with "Name", SIN with "SIN", O~S with "O~S" and similar for other rompointers. A a user program is toggled with its string representation. One may say, O~S toggles decompilation and recompilation at the user level. If you download an ASCII source file from a PC with Conn4x in binary mode, it arrives unchanged on the calculator and you still see all comments if there were any. O~S just compiles it no matter whether the black squares are still present. These need not be removed before with ~CR. Note that O~S may error, e.g. on "1+". It also does not decompile SysRPL objects to their correct source. Use Sys~ from OT49 instead. |
| CrTT | Create the Translation Table, a table of the characters 128 through 255 together with their transcriptions in pure ASCII when writing them on a PC for ASCII transfer. Important: These transcriptions are only displayed in Translation mode 3, the default in IOP as set with the Reset option from the PrP menu. |
Recommendation: For quick access to Ioman, assign << 306 Menu >> to the dispensable rightshift-hold COPY (31.31), which gets a nice functionality now. If you process the program before assigning it with the command →TO? from Keyman, the Ioman menu can also be set in edit mode and its commands can readily be printed inside a program or a command line.
Note for advanced users: If setting APPS (customized
with Appsman) from inside IOP or PrP for invoking some tools
which handle menus, proceed as in the following example. The
list below adds the item "I/O setup menu" to APPS. It launches
the I/O menu 104 and suspends. You may browse through various
transfer menus. Return to IOP or PrP with CONT (left-shift
ON).
{
#
61C
(Number of message "I/0 setup menu")
MenuDef@
PushVStack&Clear
(recall list of menu names of IOP or PrP and save stack in the
Virtual Stack)
104 UNCOERCE InitMenu% xHALT (set menu 104 and
suspend)
PopVStack InitMenu
DispStatus }
(restore the former stack, reset to IOP or PrP menu and update
the Header)
Credits: Thanks to William Graves, Otto Praxl and Stefano Priore for discussion.
Wolfgang Rautenberg - raut@math.fu-berlin.de
James M. Prange - jmprange@i-is.com
Appendix
Notes on character sets
ASCII (= American National Standard Code for Information Interchange) is a strictly 7-bit code with 33 "control characters", codes 0-31 and 127 decimal, and 95 "graphic" or "printable" characters, codes 32-126. Many so-called "extended ASCII" character sets that use 8 bit characters (those in the range 128-255) as well are in use, some proprietary, some "standard". Also the HP 4x calculators have a 8 bit character set, i.e., each character is coded by 1 byte or what amounts to the same, by 2 hexa nibbles.
ECMA 94 (= European Computer Manufacturers Association standard 94) is a standard that defines graphic characters 32-126 to be the same as ASCII characters, and defines an additional 96 graphic characters for codes 160-255. It does not define codes 0-31, 127, or 128-159, as these are defined as control characters in other standards. But many proprietary character sets (including that used in these calculators) use codes 128-159 as graphic characters, as these are seldom actually used as control characters. The 48 and 49 series use a modified "ECMA 94 Latin No. 1" character set. It.seems to be idecal with the ISO 8859-1 character set.
Notes on the 49g+'s I/O capabilities and comparison with previous calculators' I/O capabilities
The 48 series' and 49G's "serial" port is of the RS-232 variety, though not quite up to the "Recommended Standard" (the "RS" in "RS-232"). With an RS-232 port, the communication is of the "peer-to-peer" kind; almost any RS-232 device can communicate with almost any other RS-232 device. To be sure, you may have to set them to matching parameters such as speed, number of data bits, parity, and number of stop bits, but that's usually easy enough. The 49g+'s "wire" port is very different; it's a USB (Universal Serial Bus) device port. USB communications are of the "client-server" kind; a USB "device" (client) can communicate with a USB "host" (server) only, and a USB host can communicate with a USB device only. Furthermore, the device has to identify itself to the host, and the host has to know (normally by means of a software "device driver") how to communicate with it.
USB has it's advantages (most notably for the 49g+, it's much faster than the serial port on previous calculators), but it also means that you can't use the 49g+'s USB port to communicate with any other USB device, such as another 49g+ or a USB printer, and whatever USB host you want it to communicate with must have the special device driver installed. To be sure, a printer with a USB host port and a device driver (either in software or firmware) for the 49g+ could be designed and marketed, but that would seem to be extremely unlikely. To communicate with another USB device, the communication has to be indirect, with a USB host (with the special device drivers installed) such as a PC or Mac "desktop" or "laptop" computer, or perhaps even a "handheld" sized computer, with two USB ports, acting as a "go-between" to relay data (or at least one USB port, using the host to store the data). HP provides a 49g+ USB driver and an Xmodem-based communication application (Conn4x) for current versions of MS Windows (see the hp.com web site, and use the latest version), but as of this writing, not for any other operating system. (Although a Mac application should be coming "real soon now".)
The 49g+ also has an IrDA port (IrDA = Infrared Device Association; see http://www.irda.org/). IrDA is a communications protocol in itself, detecting "who's out there", negotiating "who's the boss", which speed to use, which capabilities they have in common, how to "packetize" data and ensure that it's been received correctly, and so on. For file transfers, you'll also need a file transfer protocol, so the other IrDA device knows what to do with the data. Two 49g+es can communicate with each other, but must be very close and aligned (rather like two 48 series, due to the 48's low sensitivity IR input), and a 49g+ can communicate with an IrDA capable printer, though again the 49g+'s IrDA port must be very close to and aligned with the printer's IrDA port. Presumably, a 49g+ should be able to communicate with other IrDA devices, but exactly which IrDA capabilities the 49g+ has built-in is not well (if at all) documented. Even "low power" IrDA devices are, according to IrDA standards, supposed to be able to communicate at a range of 0.2 meter (about 8 inches) minimum; the 49g+ seems to be out of compliance with this. Note that the 49g+'s IrDA can not communicate with the 48 series' "SIR" (= Serial IR) used between 48 series calculators, so a 49g+ cannot directly communicate with a 48. IrDA is faster (and more robust) than the 48 series' SIR.
Basic serial communication commands such as XMIT, SRECV, and associated commands are built-in on all 48 and 49 series calculators.
Parity setting of none (0), odd (1), even (2), mark (3), or space (4) are available. A negative value for parity generates the parity bit when transmitting and ignores it when receiving, and only the 7 low-order bits are treated as data. In Xmodem Server mode, parity is always "none".
The 48 series has built-in speeds of 1200, 2400, 4800, and 9600 bps (= bits per second). The 49G has an additional speed of 15360 bps; it's non-standard, but allows a 60% speed increase between two 49G calculators.
The RS-232 type communication is full-duplex, and receive and transmit pacing (XON/XOFF software flow control) are separately available on the 48 series, but don't work on the 49G. Using transmit pacing when printing by wire disables the print delay (even on the 49G). This doesn't apply to the 49g+, as USB and IrDA have their own flow control methods.
The 48 series has an SIR (Serial IR) communication method intended for communications between two 48 series calculators. This is similar to the RS-232 type serial by wire; a fairly simple adapter can be used to convert from one to the other. But note that as built-in, SIR uses a fixed speed of 2400 bps. This is half-duplex only, to avoid reflected IR signals being incorrectly treated as incoming signals, so XON/XOFF flow control doesn't apply to SIR.
A rather basic Kermit File Transfer Protocol, including a Kermit Server, is also built-in on all 48 and 49 series calculators; it can communicate with any almost any other system with a standard Kermit protocol capable of "binary" file transfers. (see http://www.columbia.edu/kermit/). An exception would be using parity and any of characters 128-255 (without using the "ASCII" translation) with a Kermit that doesn't agree to use the optional eighth-bit prefixing. The Kermit protocol, before sending, changes any character whose 7 low-order bits represent an ASCII control character to "printable" character sequences. If parity is used, any character with the 8th bit set is changed to an ASCII (7-bit) character sequence by an "eighth bit prefixing" procedure so that using the 8th bit for parity doesn't affect it. These are transparently changed back to the original characters when a Kermit program receives them. The only control characters Kermit uses are a "start of packet" character (usually character 1, but negotiable), and sometimes a "packet terminator" character (usually character 13, also negotiable). All signals (even acknowledge and not-acknowledge), except the optional packet terminator character, are in a packet with a 1, 2, or 3 character checksum. A Kermit (as implemented on these calculators) packet can hold up to 91 data characters (after prefixing), or 1 or 2 less if a 2 or 3 character checksum is used. This all makes Kermit very robust, particularly when systems between the Kermit programs might misinterpret control characters or change (or be affected by) the 8th bit, but does add a lot of "overhead", and isn't really needed for relatively noise-free, very fast, direct communications between two devices that can handle all 256 characters.
As implemented on these calculators, the "core" of the Kermit File Transfer Protocol (that is, exclusive of pre/post-processing) is a binary Kermit transfer, with line termination strings sent unchanged, and characters with the 8th bit set changed only when the 7 low-order bits are an ASCII control code or when parity is other than "none" (and any changes are transparently reversed by the receiving Kermit). Outside of the above "core" Kermit process, a "transfer header" (binary or "ASCII") is added to the outgoing transfers, and used by the calculator to determine how to treat incoming transfers. When binary transfer mode is used, this header is the only change from a standard Kermit binary file type transfer. The Kermit "ASCII" mode adds more pre/post-processing, and it's highly specialized for these calculators: decompiling/compiling objects (translation modes 0-3) and optionally translating LF characters (or CRLF pairs) (modes 1-3) to Kermit's "canonic" line termination string, a CRLF pair. It also optionally translates all "non-ECMA" characters 128-159 (mode 2) to a mnemonic "backslash digraph" translation code such as "\<)" for character 128, the angle symbol in the calculator's character set, or all non-ASCII characters 128-255 (mode 3) to either a backslash digraph code, or for the less commonly used characters, to a "\nnn" code (where nnn is the 3-digit decimal value of the corresponding character). With mode 2 or 3, the \ itself is translated to \\. When receiving in translation mode 2, all \nnn codes 000≤nnn≤159, or in mode 3, all \nnn codes 000≤nnn≤255, are also translated to the corresponding characters.
Note that in ASCII mode transfers, with translation mode 1-3, both LF and CRLF are translated to the same CRLF pair, and the CRLF pair is translated to a LF character when it's received back on the calculator, so if you really do want a CRLF within a character string, transferring to another device in ASCII mode and back to a calculator will change it to LF. Many text editors will, by default, treat any of CR, LF, or CRLF as a line termination string when loading a file, and when the file is saved, use only one of these, causing much the same kind of problem.
Note that some objects, such as libraries, grobs, fonts, and minifonts, are always transferred in binary mode, regardless of the state of the binary/ASCII transfer flag -35. With an :IO: tagged name as the argument for the ARCHIVE command, the transfer is always in Kermit binary mode.
The 48G series adds a built-in Xmodem protocol with the commands commands XSEND and XRECV, the 49 series adds a built-in Xmodem Server, and recently an add-in Xmodem Server library for the 48G series has become available with the Conn4x package. Xmodem is, in general, simpler that Kermit, uses single control characters for at least some signals, and uses a larger fixed packet size. This all means less overhead, and thus faster transfers. No doubt Xmodem is less robust than Kermit, but for the connections these calculators normally use, it suffices. Note that many different "Xmodem" applications and variations such as "Ymodem" and "Zmodem" are available, but not all of them can successfully communicate with each other. Xmodem Server seems to be unique to these calculators, so don't expect to find any application not developed specifically for these calculators that can use it. Note that all Xmodem transfers with these calculators are, strictly speaking, binary transfers, with the same binary transfer header that Kermit uses.
If you have a current version MS Windows operating system, use Conn4x, which has a "Text" mode. In text mode transfers, Conn4x uses the calculator's Xmodem Server to tell the calculator to record/force modes, decompile/compile the object, make the Xmodem binary transfer, replace the binary header with a text header, and does the translations itself, on the PC. The translations are similar to Kermit translations, but the option to translate LF to CRLF is separate from the options to translate non-ECMA or non-ASCII characters (and doesn't leave CRLF unchanged; it's changed to CRCRLF if that option is selected, so the reverse translation is back to CRLF). It also has a separate option to translate all other ASCII control characters to \nnn codes, so the problem of any CR or CRLF being changed to LF can be easily avoided, as can the problem of the text editor's display or a printer doing strange things because of any control characters embedded within the data. But note that Conn4x treats \00, \", and \\, the 49 series decompiled NUL (character 0), literal " within a string (not a string delimiter), and \, differently from Kermit, so Conn4x "Text" files and Kermit "ASCII" files aren't always compatible. Also note that Conn4x always uses the translations selected in its own "File Options" window, not the translation parameter in an ASCII file header, which could result in mistranslations. Furthermore, Conn4x doesn't "know" about counted strings (from the 48 series decompiler or typed in with an editor), and doesn't expect a \ (also valid within a name) to ever occur outside of a quote delimited string, so can mistranslate them. It seems that manually editing a \ meant to be a literal \ (not the beginning of a translation code) outside of a quote delimited string to \\ or \092, to prevent it from being treated as the beginning of some other translation code, prevents this mistranslation.
Perhaps the most important advantage of translating all non-ASCII and ASCII control characters (except LF) to printable ASCII characters is that printable ASCII characters are displayed or printed the same in most "text" fonts (even on someone else's newsreader), and they're easy to type in with a standard QWERTY keyboard.
Binary files, whether from Conn4x, other Xmodem transfers, Kermit, or stored on an SD card by the 49g+, are always compatible with the other transfer protocols, assuming that the compiled object within them is compatible with the particular ROM version and revision in the calculator.
A third communications method is the special encoding colloquially known as "Red-Eye". Red-Eye differs from both SIR and IrDA; for example, the method of distinguishing a "1" bit from a "0" bit is different, and 4 error correction bits are included with the 8 data bits in every byte. Red-Eye encoding was developed specifically for the HP 18C and 28C calculators and the HP 82240A IR thermal strip printer, and is also used in many other HP calculators, the HP 82240B printer, some printers currently marketed by Martel Instruments (see http://www.martelinstruments.com/), and various medical and automotive test devices designed to use the HP IR thermal strip printers. The 49g+'s Red-Eye printing does work (at least to the 82240A and 82240B), but the range is much shorter than with the other calculators; up to perhaps 4 inches (100 mm). The printer manuals say 18 inches (0.5 meter), and by experimentation, it seems that the 48SX and 48GX calculators work with the printers from about 1-2 yards (1-2 meters), depending on the calculator's battery condition. Note that HP published INPRT programs for the 48SX and 48G series to capture Red-Eye output from older calculators, and remap (where possible) the older HP Roman-8 character set to the 48's (modified) ECMA 94 Latin No. 1 character set, to facilitate transferring 28 series objects to 48 series calculators. Others have developed INPRT programs that capture the Red-Eye signal, but don't do any character remapping. The INPRT programs on a 48 do not detect the Red-Eye signal from a 49g+, presumably because of the combination of the 48's low-sensitivity IR port and the 49g+'s weak IR signal.
Of course the 49G doesn't have the hardware for IR, but apparently the firmware still allows for it, as changing the flag for transfer or print by IR disables the "via wire" transfer or printing, and the I/O activity annunciator turns on as if the transfer or printing really is being tried.
Notes on the HP 82240A and HP 82240B printers
As noted above, the HP 82240A and HP 82240B IR thermal strip printers use the special Red-Eye encoding. For their "printable" characters, 32-255, the traditional HP Roman-8 character set is used in both the 28 series calculators and the 82240A printer. The printers recognize only four ASCII control characters: 4 (print buffer contents and leave printhead at right), 10 (print buffer contents and advance to next line, leaving printhead at left), 27 (begin escape sequence), and 127 (treated as a "printable" character, a grey box). The defined escape sequences are: 27 255 (Reset printer), 27 254 (start repeating self-test), 27 253 (start printing expanded width, each column printed twice), 27 252 (return to normal width), 27 251 (start underlining, both text and column graphics), 27 250 (stop underlining), 27 n C1 C2 … Cn (Print n columns of graphics. "n" represents the character with decimal value n, 1≤n≤166, "Cn" is the character whose decimal value equals the sum of the values of the dots in column n, with the top dot having a value 2^0, the 2nd 2^1, …, the 8th 2^7.), and on the 82240B only, 27 249 (use ECMA 94 character set), and 27 248 (use Roman-8 character set). Any other ASCII control character (outside of an escape sequence), as well as any undefined escape sequence, is ignored by the printers. Using control character 10 sometimes result in a 1-column "jitter" in the alignment, so control character 4 is preferred, especially for multi-line graphics. When formatting for these printers and for the CR command, the calculators use character 4.
The printer prints in a "text" mode (1 character per byte), or it accepts column graphics escape sequences (1 column per byte, plus 2 bytes overhead, maximum 166 columns, which is 1 line) that the calculators send when printing graphics to them.
The "expanded width" mode (each column printed twice) can cause a problem; when the calculator sends the escape sequence to start printing in expanded width, it also begins formatting for 12 instead of 24 characters per line, and continues this until it sends the escape sequence to return to normal width or to reset the printer (or a calculator memory clear occurs), even if the calculator is warmstarted, but if the printer is turned off and back on, it will be in normal width mode, so printing will be "normal width", but the text lines half as long as expected. Print a "normal width", "expanded width", or "reset" escape sequence to get the printer and calculator back into agreement.
The printer has a 200-byte buffer and a maximum speed of about 1 line per second. Note that nothing is taken out of the buffer until either a control character 4 or 10 is received, so you have to be careful to "break up" the data stream with those characters to avoid buffer overruns. If the printer detects that a byte has arrived when the buffer is already full, it prints a special character (a black box with a white / through it) after printing what's already in the buffer. If it detects a byte with an uncorrectable error, it prints a solid black box character (the same as Roman-8 character 252 or ECMA 94 character 158) for that byte.
The IR printers are "input only", thus can't tell the calculators whether they're ready for more data, so the calculators "pace" the output to avoid overrunning the printer's buffer. On a 28 series, a "battery"/"AC adapter" pacing is selected by flag 52. On the 48 and 49 series, the pacing is controlled by the delay parameter, a real number ≥0 and <6.95. Up to 200 bytes are sent with no delays, and after that, a delay is added after sending each "line". Note that the delay occurs only after sending a character 4 or 10, so how often they occur affect the overall throughput, and whether the printer can keep up with the data stream.
The 48 and 49 series use the ECMA 94 character set, which of course differs from the 82240A's Roman-8, and the 82240B was introduced along with the 48SX. The 82240B has both the old and new character sets, and added escape sequences for switching to each set. When it's first turned on (or after a reset command), the 82240B uses the Roman-8 character set, compatible with the 28 series. In "Print via IR" mode, for any printing command except CR, the 48 series and 49g+ start the output with the escape sequence to switch the 82240B to the ECMA 94 character set, which is ignored by an 82240A. The 48 and 49 series include a method for remapping many non-ASCII characters to match the 82240A's Roman-8 character set according to a remapping string.
End of the document