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.