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). The menu has 2 pages now. Command CrTT added (Create Translation Table).
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 HP49+ added.
FIRST version 1.2003 (January 2003).
Page 1 of the Ioman
command menu is shown in the left-hand screen. The first four
commands do what they say, but Send, XSend and
XRecv first open an input list as in the screen for the
case 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 in
front of the blinking cursor the file names to be sent with
Xmodem, say. 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 (Quote) to put quoted names on the stack. 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.
Optionally, you could use Recv or the RECN command 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. This works
only in WIRE transmission, not in IR. ??? All four transfer
commands 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. For transfer from and to a PC via USB,
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 a corresponding message.
Most interesting is option IOP. It sets a message box on the current values in IOPAR, which is created in HOME if not present. IOP has its own menu as shown in the screen below at left for choosing Transfer Infrared/Wire (flag -33), ASCII/binary (flag -35), and all admissible values of the parameters from the reserved variable 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 the backspace key, which resets the IOPAR values to the most useful default. Note that Reset doesn't change any flags though, use MODE FLAGS to check flags -33 through -39. Ioman's IOP Reset selects translation mode 3 instead of 1, so all characters 128-255 are translated. Inside this 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. Note that ASCII/binary, checksum, and translation mode affect only Kermit transfers, not Xmodem transfers. Translation mode and parity also affect printing "by wire" (see below). Some object types, such as libraries, graphics objects, and fonts are always transferred in binary mode. Only NXT, CANCEL, ENTER, 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.
 |
 |
|
the menus for selecting admissible parameter values. |
|
Menu page 2 of Ioman looks as
follows: |PrVar|
|PrSTK| |PrLCD| |SSP?|
|LF?| |PrP|
The first command starts
printing after one or several names have been put into the
waiting list, 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, which makes it easy to notice where the end of the
variable is. PrVar turns the calculator off when finished.
PrSTK opens a choose box for printing the stack, with the
choices PR1, PRST, and PRSTC, with the
middle choice 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 prints the entire
display as a graphic object. Note that the PRLCD command is
also available by the [ON]_hold_[CursorUp] key combination from
anywhere except the special "test" screens. SSP? toggles
Single/Double spaced printing (flag -37) and flashes the result
in the header. LF? toggles Add linefeeds/No linefeeds (flag
-38) and flashes the result in the header. When "No linefeed"
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 HOME 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 or 82240B and compatible printers, the second is indeed for printing by wire if "Transfer by wire" is selected, but by IrDA (=Infrared Data Association, a communications standard used in the 49g+) if "Transfer by IR" is selected. Delay 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 is held longer. Choose a value that allows your printer to keep up with the data being sent without overflowing its input buffer, but not waiting long for the next line, just a slight delay at the end of the line. The "best value" will vary with the printer's battery condition (unless an AC adapter is being used). 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. If not found, the system chooses the empty string (default) which suffices for the 82240B for most purposes. The string replaces the remapping string in PRTPAR. The remapping string applies 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 characters 143, 144, 166, 169, 172, 174, 184, and 185. 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 space characters 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 pre-existing or added by wrapping. Most printers are set up to use the sequence 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, you can use the string "This is the 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 (see above). When printing by wire, the I/O parameters for transfer by IR/Wire, baud, parity, and translation mode apply. After visiting IOP you return safely to PrP after leaving with ENTER or CANCEL. For choosing the right flags for serial port connection or other information you may visit APPS and MODE with a safe return to PrP. Reset, invoked by the backspace key, sets the 4 parameters in PRTPAR to the most useful default. Like the Reset in IOP, the one doesn't change any flags; Use MODE FLAGS to check flags -33 through -39. Also, PrP's Reset sets the print delay to 1.8 (appropriate for an 82240A/B printer) instead of the default PRTPAR's 0.
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 48G Advanced Users 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 the command 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 49+ or to its SD-card and have this useful information always available.
By pressing the APPS key, choosing "I/O functions.." 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 from, 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 calculators 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.
Extras in page 3
| visCC | Visualize Control Characters (characters 0 - 31) in stack object. The object, if not already a string, is converted into a string. An 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. |
| remCR | Remove dispensable Carriage Return (=CR, character 13) from a text file without a valid transfer header downloaded with Conn4x in binary mode (ignoring the warning). Text editors most often write a CRLF pair as the line termination string when saving a file, and Conn4x is usually set up to change the CRLF pair to a LF when downloading an ASCII text file. But sometimes you may want to download a text file in binary mode, which makes no changes to the file. remCR replaces all CRLF pairs in a string with LF characters. For instance, if you download Ioman.htm in this way, it is a text but with black squares at the end of lines. These superfluous and irritating black squares are CR characters, removed with remCR. 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 you downloaded the source file in text mode. Downloading in text mode 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, not giving you a choice, but this can be avoided by adding anything, a space character or blank line for example, before the header. |
| addCR | This does the opposite of remCR. 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, but do want any LF characters translated? Here addCR does the translation. |
| 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 rightshift-hold COPY (31.31). 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.
Credits. Thanks to William Graves and Otto Praxl 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, 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".
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 characters 160-255. It does not define characters 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 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. The ISO 8859-1 character set seems to identical to ECMA 94 Latin No. 1.
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 serial 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 start bits, number of data bits, parity, and number of stop bits, but that's usually easy enough. And if you use a "file transfer protocol" such as Kermit or Xmodem, both devices have to use the same protocol and have to agree on (or negotiate) what they have in common. The 49g+'s "wire" port is very different; it's a USB (Universal Serial Bus) device port. USB communications is 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 may have some 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). Of course, if you use a file transfer protocol, the device and host have to use the same protocol and agree on what they have in common. 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 IrDA is not the same as the "SIR" (=Serial IR) used between 48 series calculators, so the 49g+ cannot directly communicate with a 48. IrDA is much faster (and more robust) than the other calculators' SIR.
Basic serial communication commands such as XMIT, SRECV, and associated commands are built-in on all 48 and 49 series calculators.
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 character 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 all characters whose 7 low-order are ASCII control character to "printable" ASCII (7-bit) character sequences only. If parity is used, all characters with the 8th bit set are changed to a printable ASCII sequence by an "eighth bit prefixing" procedure. These are transparently changed back to the original characters when a Kermit program receives them. The only ASCII 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. This makes Kermit very robust (particularly when systems between the Kermit programs might misinterpret control characters or interfere with most 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 8-bit characters. Note that 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". With the Kermit protocol on these calculator, 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 and optionally translating ASCII LF control characters (or CRLF pairs) to Kermit's "canonic" line termination string, a CRLF pair. It also optionally translates all "non-ECMA" characters 128-159 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 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). Note that in ASCII mode transfers, (if LF is translated at all) both LF and CRLF and CRLF are translated to the same CRLF pair, and the CRLF pair is translated to a LF character when it's sent back to the calculator, so if you really do want a CR within a character string, transferring to another device in ASCII mode and back to a calculator will remove it. 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 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 built-in Xmodem Commands XSEND and XRECV, the 49 series adds a built-in Xmodem Server, and recently an Xmodem Server library for the 48G series has become available with the Conn4x package. The 49G also has an additional speed of 15360 bps (=bits per second); it's non-standard, but it allows a 60% speed increase between two 49G calculators. 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 throughput. 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. But 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 control character 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 isn't always compatible with Kermit. 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 48G 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.
A third (one-way only) 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 form 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; 2-4 inches (50-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. 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+ (and vice versa), presumably because of the combination of the 48's low sensitivity to IR signals and the 49g+'s weak IR signal.
.
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 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). Any other ASCII control character, 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. Note that when formatting for the printers and for the CR command, the calculators use character 4. The printer has a 200-byte buffer. 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 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. The printer has as underline mode, applied to both text and graphics printing. The printer also has an "expanded width" mode that 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 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 trying to put too many bytes into the printer's input buffer. On a 28 series a "battery operated"/"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. 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.