6

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.

Improve this question
7
  • 2
    Is it configured to use hardware flow control or XON/XOFF?
    – mannaggia
    Commented Sep 14, 2020 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
    Commented Sep 14, 2020 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
    Commented Sep 14, 2020 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
    Commented Sep 14, 2020 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
    Commented Sep 15, 2020 at 20:12

1 Answer 1

Reset to default
11

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
16
  • 3
    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
    Commented Sep 15, 2020 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
    Commented Sep 16, 2020 at 7:03
  • 5
    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
    Commented Sep 28, 2020 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
    Commented Sep 28, 2020 at 18:04
  • 1
    @supercat Yes both FIFOs are either disabled or enabled, but the driver can itself decide how much of TX FIFO, if any, it wants to use. From TX FIFO, all that is known if it is empty, or not. When empty, driver can simply send 1 byte at a time, or up to 16 at a time. And RX treshold has 4 configurable levels when to trigger. Yes, RTS/CTS does not apply to FIFO. Indeed USB chips and their serial engines or firmware can be made to react to CTS better. For example the USB chipset I typically use, the manufacturer datasheet guarantees that when CTS rises, from 0 to up to 3 bytes are transmitted.
    – Justme
    Commented Sep 29, 2020 at 16:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .