• Please review our updated Terms and Rules here

GPIB to Serial or parallel printer adapter with the PET

It kind of goes without saying that the same hardware that could do translation for a serial printer could be used to pipe output into a waiting serial port of any kind.

With custom driver software perhaps, but standard operating system commands such as PRINT#, LLIST, LPRINT, etc all operate with hardware flow control and would require the substitute receiving terminal to report back a faked printer status.
 
With custom driver software perhaps, but standard operating system commands such as PRINT#, LLIST, LPRINT, etc all operate with hardware flow control and would require the substitute receiving terminal to report back a faked printer status.

Since when did Commodore BASIC have LLIST/LPRINT? That’s the point of what I was saying, in the Commodore kernel a printer is just another I/O stream, the same commands are used to interact with everything. To list a program to a printer in PET basic you literally open the printer as the default output channel, run “list”, and then switch back to the default being the screen, IE, permanent device #3. See this:


Technically Commodore Basic cares not in the slightest if the device you’re redirecting to is a printer, an open disk file, a modem, anything, as long as it implements the generic channel protocol. (*)

So, again, there’s no custom software needed. If you made a bidirectional device (which, again, it goes without saying would preferably implement the standard IEEE-488 handshaking in an MCU) you’ll get for free the ability to use it as an input device as well as output.

(* This is a little bit of an oversimplification, but not much. There are differences in what the secondary numbers mean on various devices, etc, with the OPEN but this mostly matters on the receiving side. The subsequent use of the channels are identical, at least for non-random-access.)
 
Last edited:
Commodore doesn't have LLIST and LPRINT, I am just talking in general.

Centronics printers (serial or parallel implementations) use hardware flow control. When you LLIST, LPRINT, LIST# or PRINT# the computer sends its first ASCII character or control code to the printer. The printer then signals that it is busy while it goes about its slow mechanical process of printing the received character. The computer then waits and won't send the next character until the printer signals back that it is ready to receive it. The printer can also halt transmission by signaling that it is out of paper, that it has a fault or that it is off line.

So you can't necessarily just plug the RS-232 of a generic parallel-to-serial printer interface adaptor into a terminal instead of a printer and hope that your vintage computer's line printer commands will operate as normal. The terminal to some degree would have to fake that it is a printer. This could be as simple as just sending a single byte from the terminal to set the "printer" status prior to executing a line printer command, or it might not. I don't know because I don't have a vintage parallel-to-serial centronics printer adaptor of any type to play around with.

Faking the "printer" status is exactly what I had to do in the UART firmware for the line printer mode of my custom TRS-80 serial interface.
 
Last edited:
I just bought a pet this week that's coming with a ADA1450 serial printer adapter. This conversation has got me wondering how to put it to use.

But I also have a real pet printer....

IMG_20220715_005927979.jpg

It's a commodore rebraded Olympia with a IEEE488 port on the rear. This one was bought in England and then moved to the US with the owner.
 
Centronics printers (serial or parallel implementations) use hardware flow control.

I'm not sure what you mean here by a "serial Centronics printer". While I'll grant that Centronics, the printer company that was the OEM for most of Radio Shack's early printers, may have made serial printers, in common parlance "Centronics" means the strobed parallel 8-bit I/O port. And yes, that has hardware handshaking... but not all serial printers do, not remotely. For example, the aforementioned ImageWriter has a DIP switch for hardware or XON/XOFF flow control, which was *very* common. But regardless:

So you can't necessarily just plug the RS-232 of a generic parallel-to-serial printer interface adaptor into a terminal instead of a printer and hope that your vintage computer's line printer commands will operate as normal. The terminal to some degree would have to fake that it is a printer.

I'm confused, what does "fake it's a printer" entail here? If the adapter is set up for hardware flow control you'll need a serial cable that supports that, but that's not a high bar, just set your terminal software appropriately and capture the data as it comes.

Serial printers don't have some standard magic call-and-response dance sequence they have to execute to prime the computer to send data, if they're using hardware handshaking they just set their DTR line to "fire away" and keep it that way until their buffer is full. Strictly speaking I don't think you even need to have the return data line wired between the printer and the computer in most cases if you're using hardware handshaking instead of XON/XOFF.

Faking the "printer" status is exactly what I had to do in the UART firmware for the line printer mode of my custom TRS-80 serial interface.

Obviously if you're *building* a parallel to serial converter (or in the case of a TRS-80 interface, a parallel to serial interface that also incorporates the memory space decoding for said port) you're going to have to figure out how to convert the UART's status register contents (IE, the bits that lights up or goes dark based on whether the handshaking lines are in "go" mode and when a character is ready to be read out of the buffer) into something that looks like what the Centronics port expects, but that's the hardware/MCU's problem (IE, the firmware of your device, if it incorporates it), it doesn't affect the host software unless you choose to implement it some nonstandard way. On an old-fashioned parallel->serial converter from the 70's or 80's that doesn't use an MCU you're probably going to use a really simple "hardwired" UART and a tiny handful of logic which directly converts the handshaking inputs into the equivalent flow control for the Centronics port, there's not a lot to it. (There are schematics for this kind of device in plenty of old TRS-80 publications.)

To bring this all around again, yes, if you want to build a general-purpose IEEE-488 to serial adapter (which could also, by extension, be a printer) of course your device is going to have to be smart enough to convert the serial handshake into the appropriate IEEE-488 handshaking, but... I don't think there was any point where I said you *wouldn't* have to do that. (It in fact would be the main point of the interface.) I'm baffled when it comes to parsing what you think I got wrong here...
 
One thing I was wondering about, wouldn't it be likely that a modern printer is expecting a set of initialization values to configure it, that would come from the 32 bit or 64 bit driver software package associated with it ? Or maybe the defaults it booted with would be "generic" to most printers.
 
One thing I was wondering about, wouldn't it be likely that a modern printer is expecting a set of initialization values to configure it, that would come from the 32 bit or 64 bit driver software package associated with it ? Or maybe the defaults it booted with would be "generic" to most printers.

Interfacing a truly modern USB printer directory to a PET is a whole different kettle of fish. While high-end/networked printers sometimes still have “old-fashioned“ emulations like HP Laserjet and Postscript built into them the majority of modern printers are just dumb raster devices. (IE, they can print pictures and that’s it, the host computer has to render text into bitmaps for them.) If you wanted a little self-contained box to hook something like that up to your PET it would probably need a Raspberry Pi-grade computer running Linux or whatnot inside it.
 
I'm not sure what you mean here by a "serial Centronics printer". While I'll grant that Centronics, the printer company that was the OEM for most of Radio Shack's early printers, may have made serial printers, in common parlance "Centronics" means the strobed parallel 8-bit I/O port. And yes, that has hardware handshaking... but not all serial printers do, not remotely. For example, the aforementioned ImageWriter has a DIP switch for hardware or XON/XOFF flow control, which was *very* common. But regardless:


Its not very complicated. The early serial printers essentially implemented the Centronics communications protocol over RS-232. This why interfacing such a printer to a computer with a parallel printer port just required a dumb UART interface without any brains or processing power. All these adapters had to handle was the parallel-to-serial conversion. There was no processor on board.


I'm confused, what does "fake it's a printer" entail here? If the adapter is set up for hardware flow control you'll need a serial cable that supports that, but that's not a high bar, just set your terminal software appropriately and capture the data as it comes.


I am obliviously not talking about RS-232 flow-control protocol! I am talking about Centronics printer port flow-control, and I even partially described it:

"When you LLIST, LPRINT, LIST# or PRINT# the computer sends its first ASCII character or control code to the printer. The printer then signals that it is busy while it goes about its slow mechanical process of printing the received character. The computer then waits and won't send the next character until the printer signals back that it is ready to receive it. The printer can also halt transmission by signaling that it is out of paper, that it has a fault or that it is off line."

Any firmware for a vintage computer written to drive a Centronics parallel printer port, compliant to the Centronics standard, checks the printer status on a per-character basis. If the substitute terminal over a dumb parallel-to-serial converter cannot to some minimum capacity report a faked "printer" status, then data transmission is likely to hang.


Obviously if you're *building* a parallel to serial converter (or in the case of a TRS-80 interface, a parallel to serial interface that also incorporates the memory space decoding for said port) you're going to have to figure out how to convert the UART's status register contents (IE, the bits that lights up or goes dark based on whether the handshaking lines are in "go" mode and when a character is ready to be read out of the buffer) into something that looks like what the Centronics port expects, but that's the hardware/MCU's problem


Yes, but if your terminal is instead connected to you vintage computer's parallel printer port with nothing more than a dumb generic serial printer adaptor then you have zero capacity for addressing the problem in the adapters "hardware/MCU", simply because there is no MCU and the hardware UART is not programmable.

It would then be entirely up to the substitute terminal to emulate the feedback that would otherwise be sent by the printer.


BTW, you seem to be conflating handshaking between the serial side of the UART and the printer/terminal with handshaking between the parallel side of the UART and the computer. The latter is completely blind to the former and vice versa.
 
Last edited:
I am obliviously not talking about RS-232 flow-control protocol! I am talking about Centronics printer port flow-control, and I even partially described it:

Why do you think these are not effectively the same thing? I am fairly certain I have a reasonable grasp of how both serial and parallel printers work. There are several moving parts here, I get it, but let’s boil it all down: on the sending computer you need to have some kind of way to know two things:

1: the remote end is ready to take data, or not, and:

2: If you’re sending data you’re not shoving data out faster than your physical hardware can handle it, IE, you’ve basically faked the Centronics ‘strobe/ack’ dance that has no direct parallel on a serial line. Is this what you’re obsessing about? Yes, it’s a thing you’re going to have to kind of deal with in your UART interface to prevent transmit buffer overruns but with a dumb UART like the TR1602B that was common in the 1970’s that’s not going to be a huge deal. Look up the datasheet, I think pin 22 will do most of the heavy lifting for you. And obviously this is a problem you need to solve before you even care about printer handshaking.

Anyway, the first item is what handshaking is for, and for now just take my word for it that for a simple serial printer the only line that matters is DTR, IE, that’s the equivalent of the “BUSY” line on a Centronics port. Some serial printers have the option of reusing, say, carrier detect, as an additional “it’s okay to send to me” fault indicator, but it’s extremely common to tie everything to a single line. Serial printers do *not* send special codes to indicate paper out or anything equivalent to those extra lines on the Centronics port, all the computer knows or cares about is “I’m busy” or not. Read page 106 of the Apple ImageWriter user manual if you don’t believe me:


It explains exactly what circumstances in which DTR is set false, IE, the buffer is within 30 characters of being full, and if the sender doesn’t stop characters will be dropped. It’s also set false if the printer is de-selected, and if you dig further in the manual it also applies to any error condition that would halt printing. Again, *there is no higher-level communication about fault or status conditions*, nor is there a specific “ack” sent for each character.

With this clear in your head, the fact that the *only* handshake you care about on a “dumb” serial printer is the status of the DTR line, can you explain to me how this is going to be any different if you have a PC serial port listening instead?
 
Last edited:
The early serial printers essentially implemented the Centronics communications protocol over RS-232.

And FWIW, RS-232 was standardized in 1960, Centronics wasn’t founded until 1971. This is genuinely a non sequitur.

You accuse me of conflating things, but it’s clear that you believe that serial printers somehow universally emulate on the “data layer” something like the hardware “strobe/ack” sequence of the Centronics parallel port. No. The cadence of an async serial transmission itself is solely “time-based”, IE, the sender and receiver have baud-rate clocks that are hopefully close enough to in-step that with the aid of the start/stop bits the receiving UART will be able to properly frame and decode the received data. The “strobe/ack” part of this is abstracted to the UART interface and lives completely there, generally in the form of a control line or status register bit that toggles when an outgoing character is in-flight. If you’re making a Centronics to serial hardware adapter patching this up has *nothing* to do with the device you ultimately hang on the other side of the UART, zero, other than how you choose to handle the “BUSY” signal you *do* get via DTR.

(* edit: If you were building a Centronics to serial adapter that supported XON/XOFF then, yes, you would need to do some crazy stuff to translate the software handshakes into hardware ones… hard to see how to escape the need for a microcontroller to translate in that case. But that’s not the case we’re talking about here, and even if it was I still don’t see how it creates a difference between a printer or a computer at the other side of the serial line.)
 
Last edited:
Lighten up Eudi, that's not what he was talking about.

I'm sorry, but I'd be more inclined to lighten up if I could find a valid point anywhere in what was thrown at me. I'm getting the riot act read to me about a thing that doesn't exist, IE, that there's some magic printer status protocol universally spoken by serial printers that would make it matter if you substituted a computer running a terminal program listening at the other end of the line for said printer.

Again, the point I've repeatedly granted is that you *will*, if you're converting Centronics (in particular, more broadly *any other* bus protocol) to async RS-232 need some kind of state machine (be that hardware or software) to handle the fact that Centronics assumes a 1 microsecond strobe is sufficient to send a character if the receiving end is ready (IE, not "BUSY") and may (or MAY NOT, see below) expect an "ACK" to be returned in response to STROBE. Clearly this means if you're using an unbuffered UART you'll probably need to assert a wait on every character because unless you're running one heck of a serial port clock the character send time is going to be longer than that and you'll need to not clobber your send register, and maybe fake an ACK signal if the driver software is going to time out without one. But that is *entirely* the job of your hardware interface, it has nothing to do with the recipient device on the serial line. Solving this issue is the base requirement of a hardware translator, period. I keep getting told that serial printers do some "additional magic" that needs to find its way back through the UART after each character is sent and that is manifestly not the case. Full stop.

TL;DR, if you're using hardware handshaking typically DTR (although it could also be RTS/CTS) is roughly the equivalent of the "BUSY" line on Centronics. Which is also the only line that *really* matters on Centronics; a lot of this argument invoked the TRS-80's implementation, the TRS-80 doesn't even use "ACK" after strobe, ACK is NC and the TRS-80 just uses a one-shot to assert STROBE automatically after a write for a fixed period. If you were building a Centronics adapter for this that used a zero-buffer UART your transmit handshake would involve combining these two things:

1: The handshake (DTR/RTS) from the printer, to handle when the printer is offline or its buffer is full, and:
2: A one-shot state machine that automatically asserts BUSY after STROBE and clears when the UART is ready to send the next character. (See that TR1602B datasheet for why I mentioned pin 22, "Transmit Holding Register Empty".) You need this because serial is slower.

Obviously if you're using an MCU instead of dumb hardware you'll need to implement those two things in software, not hardware. (Although with an MCU you might have RAM to spare for a buffer so you might not actually have to assert BUSY on every character, only in bursts as your buffer fills.) And whether you're using hardware or firmware once you've handled Busy you're pretty much done, all the other Centronics handshake lines can be tied to a "happy" state. Because a dumb serial printer is never going to tell you anything other than "I'm busy".

Again, I apologize for getting snippy, but I keep getting told "I'm wrong" with no evidence other than a handwaving assertion that serial printers are somehow different from any other serial device. The assertions about them explicitly aping "Centronics" character handshaking seems to have been woven entirely from full cloth, and I don't get the point of it.
 
Excellent writeup. I especially liked the mention of using a one-shot multivibrator to solve a timing issue. In the old days they were often used to pull a rabbit out of a hat. I never like them due to their propensity to miss trigger due to noise, but they could be useful.
 
I just bought a pet this week that's coming with a ADA1450 serial printer adapter. This conversation has got me wondering how to put it to use.

But I also have a real pet printer....

View attachment 1243606

It's a commodore rebraded Olympia with a IEEE488 port on the rear. This one was bought in England and then moved to the US with the owner.
Wow, what a beauty. There can't be too many of these printers around. Does this unit have a continuous paper feed attachment?
 
Fascinating and sometimes amusing discussion ;-)

"The early serial printers essentially implemented the Centronics communications protocol over RS-232."

Oh? Early serial printers were called "teleprinters" AKA Teletypes etc. and were in use long before An Wang et al dreamed of a corporation named Centronics and the interface that became an industry standard. Maybe Centronics really implemented the RS-232 protocol over their Centronics interface? ;-)

Maybe we're splitting hairs but it really makes no sense to talk about "Centronics over RS-232" any more than "RS-232 over Centronics;" you can certainly convert from one to the other but they are two distinctly different protocols both logically and physically for reliably exchanging data between two computers or peripherals. The Centronics standard was designed and optimised for local high speed connections while RS-232 has traditionally been intended for long distance communication and optimised for modems and/or longer connections over fewer wires.

Eudi, take comfort: I for one am not telling you you're wrong; you're right (if I understand everything correctly ;-) )

As to the need for a terminal program to issue printer handshaking signals that is probably irrelevant in practical terms as I would think that pretty well any directly connected terminal program will be able to keep up with a printer stream without the need for any handshaking whatsoever; if not, turn down the baud rate a bit.

BTW, I used the parallel version of Centronics' early (if not first) dot matrix printer, the 101, with my PETs for many years, starting with my brand new chiclet 2001; a great printer, especially on its special stand and a box of paper underneath looking just like what the big boys at IBM were using ;-)

101A.png


A little noisy to be sure, so it sat in the basement while my office was upstairs; don't let them tell you 10 feet is the maximum cable length, mine was at least 40 feet long (it's still around somewhere, I'll have to measure it... )

Back to Hugo's topic: there were a number of PET IEEE printer interfaces back in the day, mostly Centronics parallel ones like the CmC ADA1800, because ultimately there were far more parallel printers around than serial; unless the interface or printer are PET-compatible you will probably have issues with ASCII/PETSCII differences and especially the graphic characters, although there was hardware and software around to deal with that to varying degrees. As a matter of fact I worked with a company designing interfaces (including PET IEEE) to various printers and electronic typewriters and even still have some somewhere if you happen to have an Olivetti typewriter ;-)

Have fun!

m
 
Excellent writeup. I especially liked the mention of using a one-shot multivibrator to solve a timing issue. In the old days they were often used to pull a rabbit out of a hat. I never like them due to their propensity to miss trigger due to noise, but they could be useful.
It says in Horowitz & Hill's book, the Art of Electronics, that the use of monostables or one shots is the mark of a neophyte designer, might have been a tad harsh. They do come in very handy at times, even if just to stretch a very narrow pulse in a logic probe and light an LED. Of course the 555 timer works (configured as one) just as well at the TTL style monostables and probably were the most popular IC on the planet and there is one in the PET's turn-on reset circuit.
 
Back to Hugo's topic: there were a number of PET IEEE printer interfaces back in the day, mostly Centronics parallel ones like the CmC ADA1800, because ultimately there were far more parallel printers around than serial; unless the interface or printer are PET-compatible you will probably have issues with ASCII/PETSCII differences and especially the graphic characters,


m
Wow, thanks, I didn't know the ADA1800 existed. It may well even be rarer than the ADA1450. It turns out it has been reverse engineered, I found the schematic on zimmers ( Attached). I could make that very easily.

Would you happen to know if the user manual is around for this one , DIP settings etc ?
 

Attachments

  • ADA1800.jpg
    ADA1800.jpg
    249.8 KB · Views: 21
...although I'm a little worried about the floating inputs on U12B, maybe he forgot to finish the diagram. They should at least have had tie resistors on those pins. With that sort of thing, it may not be viable to build it as the documentation is questionable.
 
Back
Top