After plugging in the printer cable (a full null modem cable works, but so does a more minimal one — YMMV) and turning the printer on and switching the printer to ‘Terminal’, go into Windows printer dialog and add a printer:
Choose: The printer that I want isn’t listed
Choose “Add a local printer or …”
Choose the port (probably COM1)
Choose generic, text only as the driver and create the printer
Then go into printer properties and go to port and configure:
1200 bits per second (baud), 8 bit data, parity none (N), 1 stop bit, hardware flow control (if your cable allows hardware handshaking — see ‘Full handshaking’ at https://en.wikipedia.org/wiki/Null_modem).
On the printer, hit red C button and set 1200 baud, 8 bit data, N parity, Y for error and I’m not sure code type matters too much unless you want to print some interesting characters.
This is relatively simple. We set the serial port settings as per the SiPix instructions (see link below), we make a binary file according to the recipe at OpenPrinting (link below) and we send that binary file to the requisite device. That shows that it works. But then … then it turns out we can use CUPS, like a real printer.
We have a hardware serial port, and the user is in the dialout group so:
Then we follow the steps here to make a binary file then we cat it to the printer. Make a new file then print it. (Writer is my script that creates an empty ODT file then opens it.)
$ Writer newfile.odt
Make an A4 page of text, export to PDF from LibreOffice, then …
In other words, it ‘just works’ with a real hardware serial port. Now, to set it up as a CUPS printer … we can ask openprinting.org to generate us a PPD file, and we have the serial port settings, because you can find a manual online (eg https://images-na.ssl-images-amazon.com/images/I/81kQgwUCBXL.pdf) so …
Choose settings: 115200 baud, no parity, 8-bit data, DTR/DSR hardware control (this was a guess, and turned out to be wrong)
Name it (sipix)
Choose the make and model — SiPix is in there! And this is the only model (can browse to the PPD from http://openprinting.org/driver/sipixa6.upp if it is not in the list of printers already)
Do not change anything else. Leave input paper size as A4, to be scaled by the driver not the application
Add printer
Print test page
Nope, printer just turns off
Try RTS/CTS flow control
Success!
The CUPS test page — looks fine (real size is on 1/4 of an A4 page).
The printer itself:
Can we print from the command line? Plain text:
$ lp -d sipix a-file-with-some-text.txt
Yep, fine, though it feeds some wasted paper through first. PDF file:
$ lp -d sipix newfile.pdf
Yep. All right.
Now, If I use a good-quality USB to serial dongle, I can print from a USB port. That means the SiPix is still a viable portable printer
Short story to save reading the rest: I did not get it to work and may have bricked the typewriter.
Long story…
First, need cables. From ebay — a USB to DB-9 (actually DE-9) cable ($4), plus a DB-9 to DB-25 adapter — to print from a modern machine like my NetBook. $4.
USB to serial cable plus driver disk and DB-9 to DB-25 adapter.
I can verify that using drivers that came on the CD, it works on Windows 10 — see this post. But it doesn’t work on Linux, making me wonder if there’s a problem with the drivers.
To use it as a terminal I expect I’ll need a null modem cable but for now one thing at a time.
Anyway, when I plug it into my Linux box, /dev/ttyUSB0 is created (good) and I can send characters to the printer but it does not work properly.
When I try to send characters to the serial device (just a thermal printer), I find that they’re all messed up. If I use GTKterm to send hex codes, I find that 0x19, 0x39, 0x59 etc up to 0xF9 all print ‘y’ (correct code, 0x79). Playing with the various options makes no difference. So something is going wrong.
Using lsusb, I get
vendor=0x1a86 product=0x7523
And lsmod | grep USB gives a bunch of stuff, including showing that usbserial and ch341 have been loaded.
$ modinfo ch341
confirms that it is the one that is associated with the vendor and product above, but the CD that came with the converter provides pl2303.c (a .c file that can only be compiled against outdated Linux kernel headers, so is no use).
If I use modprobe or rmmod to remove ch341 and insert (the modern version of) pl2303, the /dev/ttyUSB0 device vanishes. If I unplug and replug the USB device, ch341 is reloaded.
I am wondering if the vendor/product info should be associated with pl2303 instead of ch341. So I recompiled the two modules and moved the vendor and product ID information out of ch341 and into pl2303. Here is the compiling procedure — keeping in mind this is all new to me…
$ sudo modprobe -r ch341
[sudo] password for username:
$ ls /dev/ttyU*
ls: cannot access '/dev/ttyU*': No such file or directory
OK, it’s gone.
Now, manually insert the new pl2303.ko
(I’ve cd to the directory where it lives)
$ sudo modprobe usbserial
$ sudo insmod pl2303.ko
insmod: ERROR: could not insert module pl2303.ko: Invalid module format
uh-oh.
Hang on … version magic?
But that needs modprobe which needs the module to be in /lib/modules/$(uname -r). That’s the actual file system. OK, copy it there (after backing up the old one).
17. Go to actual modules dir
$ cd /lib/modules/4.9.0-7-amd64/kernel/drivers/usb/serial
$ sudo cp pl2303.ko pl2303.ko_bak
Copy in the old one
$ sudo cp /path/to/new/pl2303.ko .
18. modprobe with force
$ sudo modprobe --force pl2303
19. Does /dev/ttyUSB0 exist now?
Yes!
20. Check lsmod
Now, pl2303 is appearing where ch341 was previously. Now the real test — can I print?…
21. Nope!
Next, change module code to include the PL2303_QUIRK_UART_STATE_IDX0
22. Nope! OK.
OK, tried that, did not work, copied all the original modules back.
Since the device worked fine on Windows 10 through RealTerm, I am wondering if there’s something odd about the drivers on Linux. On the other hand, the drivers I used on Windows were off the disk that came with the device, whereas the Linux drivers come with the OS. If the chip in the device is a cheap knock-off, maybe they provide drivers that work with their chip but since the Linux ones would be developed for the original chip, they might not work with a knock-off. I really don’t know, this is way beyond my knowledge.
It’s unlikely that the Linux driver is really flaky.
So, for now, the converter does not work on Linux. This is not an uncommon issue with these cheap chips.
PS:
Tried using it via a Windows 7 VM on a Linux box; installed the driver for the converter and then RealTerm. Sent some text to the printer OK, then it started printing in a weirdly, ultra-compressed font and I cannot figure out how to switch the typewriter back to working properly. I must have written some weird command into it’s settings, and even ‘factory rest’ does not seem to work; I may have bricked it! Do’h.
Let’s call it ep44print.bat. To use it, put it in the path and type:
C:\> ep44print filename.txt
Here the batch file is typed out:
C:\> type ep44print.bat
@echo off
echo .
echo Set printer to 110 baud, 8 bit data
echo .
pause
"c:\Program Files (x86)\Bel\Realterm\realterm.exe" baud=110 port=3 sendquit=%1
echo .
echo %1 printed, I hope
the command ‘sendquit’ just sends the file then quits RealTerm.
It’s good to first format the document to be less than 80 cols wide. But there we go.
One important conclusion — the main reason for setting up on Windows was to test the USB to serial device, since I could not get it to work on Linux; and … the converter does seem to work. So its problems on Linux seem to be driver-related. That’s useful to know.
Appendix
First need cables. From ebay — a USB to DB-9 cable ($4), plus a DB-9 to DB-25 adapter — to print from a modern machine like my NetBook. $4.
USB to serial cable plus driver disk and DB-9 to DB-25 adapter.
The EP-44 is a serial printer/terminal/typewriter made by Brother around 1984. Used as a printer, it can print ASCII text, though only the characters you can find on its keyboard, and possibly not all of them (eg I’m not sure about accents). Lines are 80 columns wide.
Here is Linux script to format for printing on the EP-44 (called ‘text file formatter’, tff):
Yes, it’s a trivial use of fold and pr, and a slightly less trivial use of sed, which I stole from here. And yes I know I could probably do it all in sed. But it works nicely.
How it works:
(1) The sed line joins non-empty lines until it finds an empty line, which it leaves alone. I’ve done this on the assumption that an empty line is a paragraph separator and I am printing text, not code or data. The result is piped into…
(2) fold, which cuts it into 70 character wide columns, breaking the line on spaces (-s). This could be done in sed pretty simply, but anyway…
(3) pr puts an indent of 5 spaces (so the text column is centred with 5 spaces to either side). The header bit is because the file name information is lost on piping the output.
The EP-44 has 80-character lines, but a 5 character margin gives much more readable output. That leaves a page width of 70.
The result looks something like this:
$ tff fallofforts.txt
2018-08-03 09:51 fallofforts.txt Page 1
This is a very fine book. Bendiner was not a famous pilot like Guy
Gibson (Enemy Coast Ahead) -- he was a navigator who managed to
complete a tour of 25 operations over occupied Europe in B-17 Flying
Fortresses that steadfastly continued to attack during daylight
hours, and suffered horrendous losses as a result. When 10% per
mission was considered an acceptable loss rate, not many can have
made it through 25.
But what makes the...
Or, as printed on the EP-44:
Text formatted on an old AlphaServer and printed to a Brother EP-44 typewriter that is even older.
But sending it to the printer is not as simple as I had hoped.
To print a substantial file to the EP-44, I run linebyline.sh, which looks like this:
stty -F /dev/ttyS1 1200
while IFS= read line
do
echo "$line" > /dev/ttyS1
sleep 6s
done < $1
$ linebyline.sh filename.tff
Now, this is pretty nifty!
The problem with just sending the whole text file is that the printer cannot keep up; it does not have enough memory to buffer much text — about 4 or 5 lines. I found that even if I set the baud rate to 75 on each device, the bits still come too fast and eventually the output fragments as it just prints whatever characters it can make sense of. There might well be a serial port setting that can fix this. I have a vague idea I printed once before and all was well. Anyway, this might be a bodge, but it works.
linebyline.sh just sends one line at a time to the printer then waits 6s and sends the next one. The print speed is about 15 characters per second, and with a line 80 characters wide that means it takes a little under 5s to print a line. Add on the time it takes to return the print head and then a little margin for error and the 6s wait means it can keep up.
The computer only sends one line at a time. One line can fit easily in the printer’s memory, and it’s printed by the time the next line is sent.
The EP-44 is a thermal printing typewriter from around 1984. It also comes with an RS-232c port and the documentation sys it can be used as a printer and terminal.
Here’s some stuff about escape sequences and formatting text when printing to the EP-44.
The EP-44 can be set to expect text encoding as ‘7BIT’, ‘8BIT’ and ‘T/W’. 7 and 8 bit correspond to ASCII codes and T/W is a slightly different code table that includes a couple of escape sequences for controlling the typewriter.
T/W mode
If we set the typewriter in T/W mode, we can make it do superscripts, subscripts and underlines by entering escape sequences into the string of text sent to the machine. One can enter escape sequences in Vim by going into insert mode and typing Ctrl+v then Esc. In the editor screen it should look like ^[ (but typing caret then square bracket won’t work!). Then type the key. ^[D scrolls to give superscript; scroll back down with ^[U; reverse the order to do subscript. ^[E turns underline on, ^[R turns it off.
Here is a screenshot of a text file in Vim:
A file, with escape codes, viewed in Vim.
Vim kindly syntax highlights the escape codes.
Here is the printout, printed by simply catting the file to /dev/ttyS1 (in this case):
The printout.
So we can see that the escape codes do their job. Remember, this is with the typewriter in T/W mode; in 7BIT or 8BIT this does not work.
Quirks of T/W mode include: if you send a keyboard caret (^) it prints a raised 2 (like a squared). Left brace gives a one-quarter symbol, right brace gives pilcrow, back tick gives degree symbol, pipe gives one-half and tilde gives section mark. Actually, probably this is pretty useful.
So that’s T/W mode — ideal if super- and subscript and underline are important and the unaccented, first 128 ASCII characters are all you need. (Basically, the characters you can access using the keys with or without the shift key).
Also, for some reason ^[Y gives a plus/minus symbol.
8BIT mode
8BIT mode gives access to (some of) the ASCII characters up to FF (number 256). But if we set the typewriter to 8BIT and send the text file shown above, we get this:
Same file, 8BIT mode.
So the escape codes don’t work. But we do get access to some more characters.
I fired up bvi and made a file consisting of hex values from 20 (a space) up to FF, plus a little trick in the second half. Here’s what it looks like in bvi (I love that VGA font):
Hex view of the file.
When we print this file, we get:
Printing to the typewriter using ASCII values up to 256 (FF).
First, we can see that the caret etc are correctly interpreted. Though I cannot see a pilcrow anywhere! So what’s the code for that?
Second, we see that (as the EP-44 manual shows) we get access to a lot more characters. Most can be entered from the EP-44 keyboard, though not all (I can’t see guillemets on the EP-44 keyboard, but I guess they’re in the ROM somewhere since they’d be used on French versions, for example).
The line shown as: 0000…///###.##
Actually consists of four O, three backspace characters (hex value 08), three slashes, three hashes, one tab character and two hashes.
We can see that the backspaces work, and give us three slashed O. This means in 8BIT mode we can superimpose characters; for example we could put a hat (caret) on top of a variable, or a degree symbol for an accent (though accented A and a are available elsewhere).
The last bit of the file shows that this lets us overcome the lack of underline escape codes in 8BIT mode — we can backspace and then print an underscore character. I’ve done it character-by-character, but based on the clattering of the typewriter that this engendered, it might be better to write the whole phrase then backspace and do the underline all in one go.
This would also allow strike-through, using a series of hyphens, though of course they would not meet, so it would be a dashed line.
This is about using it to print from a DB-9 (actually DE-9) serial port on the back of an old desktop computer. First needed cables; a serial printer cable as discussed here. I made one up from bits from Jaycar. Total cost — about $4.
So, first I used an older computer (i386) that actually has a DB-9 serial port. I bought a male DB-25 plug and a female DB-9 from Jaycar and used some hook-up wire in the shed to solder up a cable.
I then plugged the cable into the computer and the printer.
Here is the story, typed up on the old computer and printed to the EP-44.
Printed using this command
$ cat testfile.txt > /dev/ttyS0
Typewriter settings
-------------------
Baud Rate: 1200
Bit Length: 8
Parity: N
New Line: CR
Code: 8bit
Er: Y
Printing out ttyS0 configuration information
--------------------------------------------
$ stty -F /dev/ttyS0 -a
speed 1200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U, eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext ^V; flush = ^O; min = 1; time = O; —parenb —parodd cs8 hupcl
-cstopb cread clocal -crtscts -ignbrk —brkint ~ignpar
—parmrk —inpck -istrip -inlcr —igncr icrnl ixon —ixoff
—iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr
-onocr -onlret -ofill -ofdel n10 cr0 tab0 bs0 vt0 ff0 isig
icanon iexten echo echoe echok —echon1 ~noflsh
-xcase -tostop -echoprt echoctl echoke
This is printed out but saved for input back into stty (later I was to find that this did not work)
---------------------------------------------------------------------------------------------------
$ stty —F /dev/ttyS0 --save
500:5:cb9:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
What I did was pretty simple
----------------------------
(1) Made up the cable as per the website.
(2) Booted up the old computer (old Ubuntu)
$ uname -r
Linux computername 3.0.0-32-generic #51-Ubuntu SMP Thu Mar 21 15:51:26 UTC 2013 1686 i686 i386 GNU/Linux
$ cat /etc/debian_version
wheezy/sid (Seems to be Oneric something-or-other)
(3) Made the tty agree with the typewriter:
$ stty -F /dev/ttyS0 speed 1200
$ stty -F /dev/ttyS0 cs8
Note: I did all this as root.
Then catted the file to the device.
Notes
I did that as root, but regular user username can do it if I run:
$ sudo usermod -a -G dialout username
Output has empty lines in it — I think I should switch to CR + LF for the New Line setting (yes — fixed).
It is at least quite notionally possible to make up a script that would reformat a text file, add any appropriate codes, page the text sensibly, possibly including pauses or whatever, and send it to the printer. In fact, I have done this (link to post).
So … it works from an old-fashioned hardware serial port. Will it work using the USB converter (turns out Windows yes, Linux no, at least not for me)? Then I’II have a battery-powered printer to carry with my netbook.
It would be nice if it could be accessed like a proper printer, through a print dialogue, for example, but I do not think that is critical, given the limited capabilities of the machine. (No sheet feeder (though could set it up to use a fax roll), no fonts, only the possibility of underline, not many characters per line, and so on.)
I would also like to develop a serial plug for the HP 200LX. A handmade rectangular plug with a short cord to a male DB-9 (less than $2 at Jaycar) and no doubt I could print from the palmtop.
The type works well with OCR as long as the darkness is OK.
It would be able to cope with the output from dvi2tty if the column width is set correctly in dvi2tty.
To use it at a terminal I expect I’ll need a null modem cable but for now one thing at a time.
Here is part of the printout from the serial port to the EP-44, scanned. It can look better than this — this is thermally printed on a battered old fax roll that had creases and blotchy stains on it.
A scan of text output from the EP-44 via the serial port. I did have to make quite a few corrections after OCR.
I followed up by trying to print from my AlphaServer, running Debian 5. It worked from COM2 (but not COM1), and all I had to do was set the baud rate.
I was also able to set it up to run through lp on the command line. Like this:
Open browser, go to localhost:631 (Cups web interface).
Administration: Add printer
Name: EP-44
Location: Mobile
Description: Print from the command line, send only ASCII text
Note: Since this is my old AlphaServer, Cups version is 1.3.8.
This did not work for printing from gui, even from text editors like gedit — even though set to raw, gnome (gnome 2 in this case, since it is old Debian) still puts postscript wrappers around the files. Why, I don’t know. Could not be bothered chasing it up.
I tried printing from the terminal emulator. I found that no matter what New Line setting I put on the printer, I got that stepping down effect:
Where the text
Does a line feed but not a newline
at the end of each line of the text file.
but, if I used vim (or unix2dos) to make it a DOS file (:set ff=dos) then I could use
DSPACE 