I have an R65C51 (at least I hope so!) and I want to connect it directly to a little FTDI 232RL board I have using the 6 pin header that's soldered on. That header has: DTR, RX, TX, VCC, CTS, and GND pins. I can't seem to find much info on what the best way to connect this to the '51 is (and yes, I did do a search here). I did find someone's attempt to do something similar here (https://subethasoftware.com/2018/02/06/coco-rs-232-pak-to-3-wire-tx-rx-and-gnd-rs-232-device/) where they connected DTR, DSR, and DCD all together. Is this the right way?

I'm sure someone here has already done this, so how did you wire yours up in this configuration?

I've been using the FTDI interfaces for years... with the 65C51 and SCC2691 UARTs. The FTDI pinout you mention doesn't make sense... in general, you look at using RTS/CTS handshaking in a 5-wire connection as:

RxD - TxD
TxD - RxD
CTS - RTS
RTS - CTS
GND - GND

The 6th pin on these interfaces is usually +5V, which you could use to power the board, but I prefer to use a dedicated supply.

On the 65C51, you can tie DTR, DCD and DSR together. Just be sure to configure your terminal program for RTS/CTS handshaking and the 65C51 correctly as well.

Exactly which FTDI interface are you using??

_________________
Regards, KM
https://github.com/floobydust

Right, I did see that wiring on this forum before. I'm using one of these (https://www.tinytronics.nl/shop/en/comm ... rt-adapter) and was hoping I wouldn't have to solder my own headers on. If you zoom in you can see there's a CTS header pin but it has DTR instead of RTS.

Yes, that is a bit of an odd layout on the header. There's probably a reason for it... but doesn't work for what you're trying to do with the 65C51. I've used a few different FTDI adapters, but recently picked up their LC234X. These are quite inexpensive and have the standard header breakout.



It also has a jumper for 3.3v or 5v interface levels. Pinout is:

1- Ground
2- CTS
3- Vbus (+5v)
4- TxD
5- RxD
6- RTS

I guess you'll need to solder another header set to get the required connections. Have you written the code to drive the 65C51 yet?

_________________
Regards, KM
https://github.com/floobydust

The reason for this particular assortment of signals is this interface is designed for programming Arduinos. The Arduino IDE uses a pulse on the DTR pin to reset the Atmega microcontroller as part of the programming process, whilst CTS is grounded by the Arduino and can be used for presence detection.

As floobydust said, you'd be better off finding an FTDI adapter with a more traditional pinout for your purposes.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

The DTR is definitely for Arduinos - I used a similar board and just cut the trace going to the "DTR" pin on the end and used a jumper wire to connect it to RTS from the computer instead. If that link you provided is the board you have, then RTS is available on one side of the board and it looks like the cut&jumper method would work for you. Some of those boards even come with jumpers on the back to let you select between DTR and RTS on the last pin.

One note when using FTDI chips with handshaking is that they do not stop sending characters the instant you deassert CTS. They can send up to 3 more characters. This is only mentioned in a support FAQ for the FTDI232 chips and it took me by surprise because I was expecting no more than 1 additional character after telling the PC to stop sending.

From https://www.ftdichip.com/Support/FAQs.htm: If CTS# is logic 1 it is indicating the external device cannot accept more data. the FTxxx will stop transmitting within 0~3 characters, depending on what is in the buffer.

I ended up going with an interrupt driven receive with a circular buffer and signalling early if I needed the PC to stop sending.

I ended up getting another adapter so I'm using the suggested wiring. Now I'm starting to do the software portion and I have full interrupt based receiving and transmitting complete (I'm pretty happy about this!). However, is there any reliable way to know connection/disconnection using these 6 pins? Would love to be able to reliably send a new prompt after a new connection.

DTR is the signal you'd normally look at to see if the COM port is "open" on the PC. While it can be used for handshaking as well, it's original use was to signal that the terminal (the PC in this case) is ready to talk to the device. Most operating systems assert DTR when the COM port is opened (unless you specifically ask them not to).

For Arduinos, this is sent through a capacitor to generate a quick pulse on the RESET line of the Arduino's micro every time the COM port is opened. This makes programming a breeze because the software just has to open the port to reset the micro into the bootloader mode. This is why many of the USB to 5V RS-232 adapters swapped out the RTS with DTR. It has the annoying side effect, however, of resetting your Arduino every time you open the COM port if you write a program that uses the COM port. I really can't recommend connecting it in the same way the Arduino platform does (to the system RESET) because of that, but I can understand why Arduino folks chose to do it that way (to make it so people who know almost nothing about electronics/computers can program their Arduinos).

If you wanted to use DTR, you would connect the DTR from the USB adapter to the DSR line of your ACIA, and you can poll DSR in the STATUS register of the ACIA (bit 6) to see if the PC has the COM port open or not. You will also get an interrupt on change of DSR if you have interrupts turned on.

By giving up PCs RTS line, the PC won't be able to tell your 6502 machine to stop sending. In most circumstances, this is not an issue as you're not going to overwhelm a modern PC with serial data. You can still have one directional handshaking where the 6502 machine can assert it's RTS (which goes to the CTS input on the USB adapter) to tell the PC to stop sending characters. That kind of one-directional handshaking is actually pretty common where one device is much slower than the other.