5

I recently rescued my Tandy CGP-115 plotter from the attic and had the idea to try and drive it from a modern machine.

I have a FTDI CHIPI-X10 RS-232 adapter and installed drivers on a MacBook.

I have assembled a lead (DE-9 female to 4-pin DIN), according to what I've been able to read up about the Tandy Color Computer serial port, as per the following:

  • TXD - pin 3 -> DIN pin 4
  • GND - pin 5 -> DIN pin 3
  • CTS - pin 8 -> DIN pin 2

I believe I have the correct Python code to send data to the plotter:

import serial
import time

ser = serial.Serial(port='/dev/tty.usbserial-FT2XIBOF', bytesize=serial.SEVENBITS, baudrate=600, rtscts=True, dsrdtr=True, stopbits=serial.STOPBITS_TWO)
ser.write(b"Hello, world! This is a message from a MacBook in 2020.\n")
#ser.write(b"ABCDEFGHIJKLMNOP")
ser.flush()
time.sleep(5)
ser.close()

Something seems to be not right - when I send the following:

ABCDEFGHIJKLMNOP I get the following: AJKLMNOPIJKLMNOP. Occasionally this comes out right.

Likewise Hello, world! This is a message from a MacBook in 2020. prints as something like:

Hello, world! This is a messaa i 
                                 2020.

2020.

2020.

So something's up, obviously, arguably something to do with the handshaking. Have I wired the cable correctly? I have tried the parallel port and that appears to work fine. (And why the echoing of the last few chars? Could that be electrical rather than logical?)

I have also tried wiring other pins to DIN pin 2 in case I've misunderstood the handshaking: DSR, DTR, DSR/CTS together, even RXD, with similar results. Sometimes the printing is delayed for a second or two, suggesting the sender timed out the handshake and just flushed the data anyways. I've also tried various combinations in the code, serial.EIGHTBITS, rtscts=False, dsrdtr=False, without success.

Any advice much appreciated.

  • 2
    Is it configured to use hardware flow control or XON/XOFF? – mannaggia Sep 14 at 20:08
  • 2
    To figure out if this is a handshaking problem, try sending a character at a time with a second of sleep between characters. – manassehkatz-Moving 2 Codidact Sep 14 at 20:33
  • @mannaggia as I understand it this is hardware flow control. It was designed to be used with the Tandy CoCo and according to atarimagazines.com/compute/issue37/coco_printer.php generic printers should connect pin 2 to DTR. – EBCDIC Sep 14 at 20:42
  • 1
    @manassehkatz-Moving2Codidact Yes sorry I forgot to add that, I did do exactly that and it printed the characters ok. (Actually with 0.25 seconds of sleep between characters.) – EBCDIC Sep 14 at 20:43
  • 1
    @manassehkatz-Moving2Codidact one thing I actually do have is a pair of DE-9 breakouts, male and female, and I can patch between them and add LEDs etc. That's almost as good. – EBCDIC Sep 15 at 20:12
9

The manual says nothing more than it can print 12 characters per second and it uses BUSY pin.

Even if you have connected BUSY output to CTS input, and turned RTS/CTS handshaking on, there is still a possibility that one or two extra bytes are sent out on the data pin, because the serial string write happens as a single large block, and also the USB packets contain multiple bytes to send in one packet, so it is up to the drivers and the chip how fast it can react to the BUSY/CTS signal.

To be sure, write only single byte at a time, flush buffers after each byte written, and preferably add a delay of at least 84 milliseconds after flushing the single byte. Then, after that is up to the serial chip driver and USB controller driver and the chip itself how will it behave.

| improve this answer | |
  • 1
    Thank you, I think this is the answer. I added the delay and also a loop to poll ser.cts, partly because the plotter's graphics mode would take longer than 84 ms to draw a line. The working assumption here is that the plotter is slow to raise CTS and the chip isn't expecting that. This seemed to work and I observed CTS going up and down; I can now experiment with the delay length and see how short it can be before problems arise. If my question is of general interest it might be around "are there timing issues in vintage serial devices" or "do they degrade as they age and why" – EBCDIC Sep 15 at 20:08
  • 1
    And the answers to that general questions would be "Of course", and "YMMV" - As it is, with a specific example, it is much better ;) – tofro Sep 16 at 7:03
  • 3
    The buffering behavior of PC UART chips is IMHO horrible. When a receiving device deasserts CTS, that should cause a transmitting device to refrain from starting any new characters. Unfortunately, on many PC UART chips, there's no way to enable receive buffering without also causing the devices to transmit up to 64 bytes after the far end has deasserted CTS, which will virtually guarantee data loss if the far-end device doesn't have 64 bytes of buffer remaining when it deasserts CTS. Since many devices... – supercat Sep 28 at 18:04
  • 1
    ...have less than 64 bytes of buffering in total, it is grossly unreasonable to expect them to deassert CTS while 64 bytes or more of buffering remain. – supercat Sep 28 at 18:04
  • @supercat The 16550 UART only has a 16-byte FIFO.. – Ross Ridge Sep 29 at 15:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.