ExtraPutty provides additional features/functions. One which I use is the Xmodem CRC download. My monitor supports loading code via ExtraPutty to the board itself. For basic terminal support, either will work fine.

You can also download the WDC Tools for free as well. I use it for my little projects and in general it's fine for what I do. Everyone has their own preferences in tools and some have built up their own over the years. If you're just starting out, you have options.

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

Ok. I'm gonna try and describe my setup as accurately as I can. I am starting to think it is a problem with me using the terminal software, so I am gonna start using Putty, since there some here that are familiar with it.

I have each pin on the FTDI adapter attached to the same named pin on the ACIA, as per the diagram for the MALE 5v part I posted. There is one exception. I haven't hooked up the RI pin to anything. I don't believe that's a relevant pin here, but maybe I'm wrong.

On the ACIA, I have CTS, DSR, and DCD grounded on the ACIA (which in turn means the same pins on the adapter are grounded)

when I setup the ACIA, I put 00011110 in the control reg, and 00001011 in the command reg

Using various terminal programs, I can put data on the ACIA Tx register, and get it to display correctly in the terminal window. This works flawlessly.

I have my scope hooked up to the RxD pin on the ACIA, so I can intercept data coming FROM the terminal TO the ACIA. I am not trying to test the ACIA, I'm trying o earn how to get data out of the terminal, and in turn, out of the FTDI adapter. I have also tried probing the RxD pin on the adapter with it unhooked from the ACIA.

My voltages on the handshake pins are:
DTR .4v (weird, that) grounding the adapter's DTR pin (rather than hooking it to the ACIA) changes nothing
TxD passing serial data correctly
RxD 5v (no data, even when I attempt to send it with the terminal)
DCD 0v
CTS 0v
RTS 0v
DSR 0v

Ok, my current leaning is that I am misusing the terminal software somehow. My main terminal that I use is RealTerm, because it seems to be the most geared to this kinda thing. But I want to use Putty for a bit just to have a common terminal with some here that use it.

In Putty, assuming that the port is set correctly (it seems to be,, as I can get data to display from the ACIA), what is the exact procedure to send data OUT of the terminal. Again, I'm not trying to get data into the ACIA from the terminal yet. Just trying to get activity I can see on the scope at the RxD pin.

I'm not purposely being "acidic" as one fellow said. I'm just trying to be specific, as some posters seem to be confused by my setup and goal. I'm very thankfull for all the help!

Okay, so let's try this again. I strongly suggest you wire things up as shown below using the FTDI adapter and the 6551:

TxD to TxD
RxD to RxD
CTS to CTS
RTS to RTS
DSR to DSR
DTR to DTR

Pin 5 on the FTDI goes to ground
DCD (Pin 1 on the FTDI) goes to ground
DCD (Pin 16) on the 6551 goes to ground

RI (ring indicate) on the FTDI is no connection

Setup Putty or ExtraPutty for RTS/CTS handshaking and (based on your 6551 parameters) 9600, 8, N, 1

The above should work fine for transmit and receive. In fact, I have this working (as I type) based on the above.

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

I have duplicated your setup. No dice. In fact I have to turn flow control off, and manually ground CTS on the ACIA to get the ACIA to still send TO the terminal.

I'm still not certain I know how to send stuff OUT of putty.

My program just sends data to the terminal once a second. (It is counting from 1 to 255, and sending a CR after every number)

How specifically with Putty do I send data back? Do I just click on the terminal window and type?

Yes.

Do you have any other FTDI devices that you can try ?

I've tried both adapters that I ordered in case one was faulty.

I have a FTDI adapter that would require line drivers.

I also have a Bus Pirate that probably could work.

Someone(you?) mentioned trying older drivers that pre-date the whole FTDI driver fiasco. I doubt that is the problem (my understanding was that the current ones just don't let Windows recognise the counterfeits, rather than bricking them).

Have you done a simple loopback test to see if the ftdi adapter is working?

Hi Dan,

as you can read (e.g. EugeneNine's post) everyone here is trying to help you by doing a stepwise approach to this problem.

The newest FTDI drivers for Windows behave somewhat ugly. Sometimes (depending on the used adapter AND on the Windows version (!) as well) they "detect" alienware and response in an unpleasant way: for every character they receive, they return one character of a fixed counterfeit message to the OS instead.

The very first hurdle you have to conquer is having a reliable terminal (emulation). That is why Eugene and others asking for the loop-back test. It is mandatory that this is working. On the PC side you need to bridge pins 2 and 3 on the D-sub-connector (whether 9 pole or 25 pole doesn't matter, it is always pin 2 and 3). The terminal program needs to be configured for NO handshake (neither HW nor SW) and no local echo. Set the baudrate and frame format ("9600, 8N1") to whatever you like (and later will use). Then save this configuration and restart the terminal emulation. When you have asserted the bridge between pin 2 and 3 of your adapter, hitting a key should gave you an echo (in this case, the pressed key is printed on the screen on some window). Without the bridge you get no "echo".

As none of us is sitting beside you, we can only try to express in various ways what you should do. And this local-feedback-loop is the very first step, assuring that the terminal side is working. If you get a response, but it is not what you keyed in, it may this FTDI problem you are sticking in. But first - make it having ANY response. If you get something, do a screenshot and post it with a comment.

Good luck!
Arne

loopback (Rx Tx tied)does nothing. No handshake, CTS/RTS, and DTS/DTR all tried and failed. No output on screen. Neither in Putty, or RealTerm. Nothing on scope either. Realterm actually gives you the status of the Rx and Tx lines on the PC side, and it lights up Tx when I try to send. So I think the terminal at least thinks its working.

I'm wondering if its a drive setting thing. From what you guys are saying, and what I have read in the past about the known FTDI anti-counterfeit measures, I'd either get garbage, or windows wouldn't recognize it as an FTDI. I get recognized, and just no output. Plus, it receives just fine.

Just so I understand, if I have handshaking "off" on the PC side, there is very little I can get wrong with those lines as far as transmitting FROM the PC, right?

Thanks again for the help!

Okay, this is the simplest test which I just did using nothing but a FTDI DB9-USB-5M USB/Serial adapter. Use four jumpers as:

RTS to CTS
DTR to DSR
RxD to TxD
DCD to ground

Using ExtraPutty, I setup the com port (varies based on your Windows config) for 9600, 8, N, 1 and handshaking as RTS/CTS.

Simply put, typing in the terminal windows shows everything I'm typing. If you can't get this to work, then you either have a cable and/or hardware problem, a Windows problem (possibly a FTDI driver problem) or you wired it incorrectly. It just can't be that difficult to get this scenario to work. It's too simple not to work.

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

If handshaking is off data is sent regardless wether someone is listening.

The handshake mechanism is only used if either side of the communication link fears to loose some information or simply cannot process the information quick enough. But even a 1 MHz clocked 6502 is fast enough to process a download (say via Intel hex format or Motorola S19) at 9600 Baud (me think 38400 would work as well) - without handshake!

So if you really configured your terminal emulation programs for no handshake, and it stll doesn´t work, you simply get sticked by something else. Well, check the device manager: plugging/unplugging your USB-RS232-device should cause corresponding action. And plugged you should have one COMx, unplugged there is no serial port. Verify if you always get the same COM number - sometimes they change. Is the COM number you get via device manager the number you have setup in the terminal emulation?

So far

yes to all. It shows up on COM5 every time, and that's how I'm configured.

Also, stuff gets into the terminal fine, and uncorrupted, so I'm pretty sure its good on that front.

I tried two different specimens of the adapter, with the same result.

I just hooked up my Bus Pirate, which also talks to the PC through an FTDI serial/USB interface, and it works fine.

I even tried a different USB cable.

I'm wondering if it's a driver problem. I'm totally stymied here.

I hope this is not a HW problem. Perhaps you give this http://www.dlpdesign.com/CDM-Uninstall-Manual.pdf a try and report what happens.

Good luck!

Your schema would make the FTDI gadget a DCE, not a DTE. Are you sure that is correct?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Ok, first, I did the suggested Driver reinstall exactly as the link directed. My comport number went from 5 to 3 (which is inline with what the link said could happen) but otherwise no dice.

BDD, that hookup is exactly what the datasheet calls for for the male part. Here is what I have gathered from the datasheet. This part is so designer can take an existing product that has an RS232 port, and direct swap this adapter in its place. So the adapter is just kind of an extension of my ACIA, rather than the target of the ACIA. In the datasheet diagram for the male part, it has a box around both the UART, and the adapter labled DTE, so I think with this adapter, you are almost meant to think of the adapter and the UART as one part sort of.

That said, I'm still spinning my wheels here, so who knows! I know what the initials stand for, but exactly what is the difference between a DTE and DCE anyway? My part is for a DTE it would seem. Any possibility I should have gotten the female (DCE) part instead?

I'm real close to just getting a different product. Only thing that holds me back is that both specimens of this part have acted identically, so I feel the problem is me, not the component.