DOS serial printer formats

Question

Assume a DOS machine with a serial cable, and a selection of one of Epson FX-80, HP LaserJet, IBM Proprinter. At the other end of the serial cable is a modern machine, e.g. running Linux. On the DOS machine I print some document from some application.

How can I make use of the information on the other end?

Are the formats documented? Any free tools for this situation?

Casual googling just turned up some dodgy-looking Windows sw products.

Answer 1

This question is a near duplicate of 'How can I convert Epson escape codes to a more usable format?', which lists some suggestions for tools for managing Epson sequences, but I'll provide some more background and information as I understand it.

The IBM ProPrinter uses the IBM Personal Printer Data Stream (PPDS) page description language, which is a character sequence of characters to print coupled with escape sequences to set parameters during output (with the relationship between byte sent and character to print defined by the currently active code page). The sequences and general form for PPDS given on this IBM support page.

The Epson FX (ESC/P) format is very similar - here's Epson's own ESC/P reference manual, also summarised in this ESC/P sequence table on SourceForge.

As mentioned by Thorbjørn, the HP LaserJet uses PCL.

I believe if your receiving serial computer has the correct parameters (or you're running in Dosbox and capturing your program's output), you'd receive a PPDS sequence you could find/build an interpreter for.

One such tool for ESC/P is RWAP/PrinterToPDF - I haven't tested it myself, but it describes itself as an ESC/P to PDF page converter.

It's also likely that any modern printer you come across will still support one of those three formats your DOS program outputs, if you find a way to get the data into the printer!

(Another source for the same information you may find useful is the manual for the OKI Microline 3410 IBM compatible printer. It has sections on the serial interfacing, but more importantly full lists of the IBM Control and Character Codes (Appendices A and B). These are given in tables for both the IBM Proprinter and the Epson FX protocols.)

Answer 2

This is a classic data conversion problem. I have done similar things many times over the years with both parallel and serial printer ports and a variety of different operating systems. The other answer focused on actual formatting of the data, which is a real issue. I will discuss the actual transfer process:

• The two machines have to agree on communication protocol. With serial ports (this is RS-232C and similar, not USB), the key parameters are speed, parity and handshaking. Speed and parity are easy - typically 9600 bps or 19200 bps for a DOS printer, and very easy to configure in DOS (not so easy in some older systems...) and Linux. Parity will almost always be None for DOS printers, though other settings are possible. Handshaking is the tricky part - set it as best as you can and then deal with the problems (more below).
• Cabling for standard serial is easy. At least, it is with the right tools. The minimum is transmit, receive and ground, but you will need more if you use hardware handshaking. When the connection is between two similar machines (e.g., any two PC-type systems with standard 9-pin ports) then a null modem cable will (mostly...) do the trick. But a breakout box like this one:

can help figure out pretty much any combination of port pin configurations. For a one-off/temporary situation, I might wire up a breakout box and leave it in place. For a permanent installation, a custom cable (if a standard cable won't do) is a good idea to avoid problems when someone knocks out a jumper wire.

On the receiving side you will need some sort of program to capture the data. This might be a real "communication program" or it may be some command to capture everything coming in from a port to a file until told to stop.

The big problem is often handshaking. Even super-fast computers can end up with funny problems with a 9600 bps data stream if the handshaking doesn't work properly. Sometimes adjusting the handshaking parameters helps, sometimes playing around with the cable configuration helps, and sometimes nothing seems to work. When nothing seems to work right, for example if I can see hardware handshaking happen on a breakout box but a character or two gets lost in each batch due to overflow (slow reaction by the source machine to the request to stop, combined with minimal/no OS port buffer space on the destination machine), then I either try a slower speed, add a buffer box or increase the software (application level) buffer.

If the receiving computer doesn't have a traditional serial port, you can either add a USB Serial port or a PCI card. Generally speaking, I would trust a PCI (or a motherboard serial port) more than USB when it comes to handling handshaking properly.

"Printing" thousands of bakery account records or medical billing history files can take a while. I typically do some short tests to make sure I have the handshaking and capture process working and then let it run overnight (or however long it takes).

Answer 3

Your problem is two-fold:

1. You want to print in a retro-printer language "to a modern PC". That involves a bit of hardware (no modern PC can technically receive parallel or serial printer data out of the box) to capture the data and store it.
2. You want a piece of software that picks up the data captured and transforms it into something a modern computer/printer can understand/print (I suppose PDF format would be a proper choice).

There are a number of solutions on the market that can do stuff like that.

One is Retroprinter, a combined HW/SW solution that consists of a RaspberryPi hat, a PCB that captures data from a parallel or serial port and that can store the captured data as PDF or print it directly to a connected modern printer.

A fully open source solution is not known to me.

Answer 4

I have a not-too-old Brother laser printer which emulates old Epson dot-matrix printers, as noted in the user manual. My one test printed out much too large, but I made no attempt to adjust printer settings which might have fixed that. The same printers emulates HP's PCL, as a very large number of laser printers do.

More universal is software emulation. While I haven't used RWAP, I was able to compile the old "epsonps" code they link to. In my brief testing it seemed to work reasonably well.

Usings the Epson Esc/P2 reference PDF available online, I even wrote my own minimal interperter, which handled the few control sequences used by old business applications that wont go away, and did a few other desirable transformations as well. It's not difficult, just... tedious. Go with epsonps instead if possible.

EDIT: I should really explain. The biggest challenge with Epson print outs is printer settings. Unlike modern printer formats, it doesn't contain a full page description. Often you were expected to hit the buttons on the printer to set the font to what application's instructions told you to use. And sometimes you'd need to change those settings to print from another application. Control sequences can at least change the font, but it wasn't always done that way. And you can run into other settings issues... One Epson printer might have portrait oriented paper fed into it, while another had landscape oriented paper. Or even fanfold paper, where you would tear-off part of the page for one print out, but would need the whole thing for another. You really need a preprocessor to guess at the orientation and font settings to figure out how it can be fit onto a page. That's why writing my own from scratch ended up being the best option (for a busy office environment with several different old programs).

Answer 5

A possible solution could be to virtualise or emulate the DOS environment which makes it easier to capture the print output. For example, DOSBox-X can print to a variety of formats, including postscript. The (now outdated) Boxer app on macOS can print directly to a PDF with selectable text.