Getting to grips with the parallel interface

The Centronics interface seemed such an intrinsic part of a computer’s architecture that, to those of us whose computing coming-of-age was in the 1970s or 1980s, it seemed unimaginable that it would all but disappear. Who knew that serial interfaces would one day reign supreme?

There’s something still very satisfying about hooking up a parallel connection, with fat cables and even fatter plugs and sockets. Only SCSI gave you something similar – a sense of really connecting.

Centronics was the standard I encountered most. But the DB25 sockets and Amphenol 36-way connectors that we all know and love were host to a range of enhancements that built on the original spec, with two-way communication and all sorts of other shenanigans. There’s more than enough detail on Wikipedia, if you care.

For DottyMatrix, my smart serial-to-parallel interface, I don’t want to worry my pretty little head about stuff like that. I just want to implement a basic version of the parallel interface so that I can use my dot matrix printer (if it ever works again).

However, finding definitive details about that interface was harder than I expected. It’s not that there isn’t information out there – there’s tons of it. It’s just that various people have various ways of describing the signals. In particular, is the signal active high or active low? It seems to depend, sometimes, on whether you take the printer’s viewpoint or the host’s. Terms like ‘hardware inverted’ just tend to muddy the picture.

However, I did, finally, come up with this table of how I think the signals work.

Centronics
(Amphenol)
36-way connector
pin
DB25 pin Signal Normally Note
Host outputs / Printer inputs
1 1 /STROBE HIGH Pulsed low then high by host to signal data byte is ready. Pulse should be 0.5-500µs
2-9 2–9 D0–D7 Data
14 14 /AUTOFEED HIGH Pulled low by host to tell printer to use automatic linefeed. Aka: AutoLF, LF
31 16 /INIT HIGH Taken low by host to initialise/reset printer. Aka: RESET
36 17 /SELECT-IN HIGH Used in some standards to indicate sending of printer address. Aka: SELIN, SEL-In
Host outputs / Printer inputs
10 10 /ACK HIGH Pulsed low then high by printer to acknowledge receipt of data byte
11 11 BUSY LOW Taken high by printer when busy. Taken low again to indicate readiness to receive next byte
12 12 PAPER END LOW Taken high by printer if paper out. Aka: PE
13 13 SELECT LOW Taken high by printer to indicate it is online. Aka: SEL
32 15 /ERROR HIGH Taken low by printer to indicate an error. Aka: FAULT
19–30, 33 18–25 GND Used in twisted pairs with some signal lines to provide signal shielding

Although I’ll probably connect all the signals to pins on the microcontroller, I don’t intend to actually use all them. The essential ones are the eight data lines, strobe and busy. The ack signal may be handy, but was often ignored in real-world implementations. The select and select-in signals were used more on cleverer versions of parallel interfaces and I don’t see me using these at all. Paper end and error are obviously worth implementing while autofeed almost certainly isn’t.

Testing, testing…

The good news is that I included most of the essential signals on my parallel interface breakout board, so I can do most of the prototyping and code writing using that.

The next hurdle, though, is to get the printer working so that I can actually measure and verify the signals coming from it. For example, does it hold certain lines – such as error and paper end – in reliably low or high states as appropriate or do I need to add pullup and pulldown resistors on my interface?

Some (slightly dodgy-looking) capacitors have just arrived from China, so it’s time to fire up the Epson again.

[Update: 18/04/2018] I really should know by now to RTFM. In my search for definitive information about the parallel interface, the one place I didn’t think to look was the manual for my Epson MX-80 F/T III.

Because, yes, I still have the original manual. What’s more, it’s a manual from an era when manuals actually told you stuff. These days, if you get a manual with a product, its contents generally consist of little more than: ‘Here’s how you plug it in’ and ‘Here’s why you can’t sue us’.

The Epson manual has things like a logical diagram of the circuit board, Basic programming examples and – bless ’em – an appendix detailing the parallel interface. This mostly confirmed what I’d already worked out above but with the following details (in some cases specific, I imagine, to this product):

  • The pulse length for the /STROBE signal should be a minimum of 0.5µs. That I already knew, but I have seen other figures floating around the interwebs.
  • The /ACK signal from the printer will pulse for around 5µs. It’s not an essential signal – nonetheless, it’s good to know.
  • I still don’t have a clear idea of what SELECT is used for. The manual says: “This signal indicates that the printer is in the selected state”. Say what now? Oh well, I’ll ignore it.
  • The /INIT signal should be pulsed low for more than 50µs. That I definitely didn’t know.
  • The /ERROR signal can mean one of three things: the ‘paper out’ state (for which there’s also a dedicated signal), the printer is offline or there’s an error.
  • The /SELECT-IN signal has to be low for the printer to accept data entry. It can be set low by default using one of the printer’s DIP switches, and that’s how the product is set at the factory. So this can be ignored. But if an interface controls this signal, it’s worth setting it low just to be sure.

I also learned that the several ground lines on the Centronics (Amphenol) 36-way connector are not all connected. Pin 16 is just a logic 0V level. Pins 19–30 and 33 are used as returns for some of the signal pins (the manual states specifically which return pin goes with which signal pin). And pin 17 connects to the chassis ground, which is isolated from the circuit ground. I’m not sure this affects my interface design much as pin 17 on the Centronics port is not connected to the DB25 plug.

Never miss a post

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.