Trouble with FTDI for SIO2PC

[johndias]

Hey all,

 

I have a 400 that I have built a DIY SIO2PC connector for so I can load program files with RespeQt. I'm not having a lot of luck. I bought an FTDI board, built a "franken-cable" to pin the outputs on the FTDI to the appropriate pins on an SIO cable which I connected to the SIO port. I have continuity from the FTDI pins through to the connector.

 

However, I am not able to load anything. RespeQt seems happy with the connection, correct COM port using CTS at 19.2K baud. However, the xex files I try to boot from don't load. Even after I reset (hard or soft) the 400.

 

Is there a step I am missing here?

[_The Doctor__]

make sure the .xex files can work on a 16k machine... assuming your 400 has not been upgraded....

[Kyle22]

Have you tried to load an ATR?

[johndias]

No matter what I do, I can't get anything to show except "MEMO PAD"

 

Can't even get the thing to boot from the Atari DOS folder if I mount it. I also tried on another 400 I have and it's not working on that one either.

 

I tried loading PuTTY, and I can hear some noise from the monitor speaker when I press keys in the terminal session (I have UAV and the sound upgrade installed).

Edited July 30, 2018 by johndias

[1050]

Every time I see FTDI I think of the clone chip troubles.

 

Just over a year ago, FTDI, manufacturers of the most popular USB to serial conversion chip on the market, released an update to their drivers that bricked FTDI clones. Copies of FTDI chips abound in the world of cheap consumer electronics, and if youve bought an Arduino for $3 from a random online seller from China, you probably have one of these fake chips somewhere in your personal stash of electronics.

 

After a year, we have the latest update to FTDI gate. Instead of bricking fake chips, the latest FTDI drivers will inject garbage data into a circuit. Connecting a fake FTDI serial chip to a computer running the latest Windows driver will output NON GENUINE DEVICE FOUND!, an undocumented functionality that may break some products.

 

 

The above dated 2016 and found in the wild with a

simple search on FTDI clone. Unless you use a linux

box there still appears to be no resolution to the

issue. Windows plus FTDI cloned chips is a brick.

 

Since your symptom is a brick and this issue is still

alive, I have no hopes of a solution. I also see no

solutions anytime I look this issue up online. Just

a lot of hate and hot air.

[+DrVenkman]

Hey all,

 

I have a 400 that I have built a DIY SIO2PC connector for so I can load program files with RespeQt. I'm not having a lot of luck. I bought an FTDI board, built a "franken-cable" to pin the outputs on the FTDI to the appropriate pins on an SIO cable which I connected to the SIO port. I have continuity from the FTDI pins through to the connector.

 

However, I am not able to load anything. RespeQt seems happy with the connection, correct COM port using CTS at 19.2K baud. However, the xex files I try to boot from don't load. Even after I reset (hard or soft) the 400.

 

Is there a step I am missing here?

There are a couple possible issues. First off, what platform are you using RespeQt on? If Windows, plug in your device and be 100% certain your device is getting assigned to a COM: port in Device Manager. If OS X or Linux, open a terminal window and make sure you can find your device in /dev, probably something like /dev/tty.usbSOMETHING_OR_OTHER

 

Make sure RespeQt is using that port.

 

Next load up an ATR in D1: of something known to work with a 16K 400 like DOS 2.0. Make sure the status icon at the bottom of the RespeQt window shows that emulation is active. Boot the 400 without a BASIC cart and you should load straight to the DOS window.

 

If not, and if your FTDI device is being seen by the modern machine you’re connected to, the 400 may have a bad SIO port or POKEY chip.

Edited July 30, 2018 by DrVenkman

[johndias]

 

 

After a year, we have the latest update to FTDI gate. Instead of bricking fake chips, the latest FTDI drivers will inject garbage data into a circuit. Connecting a fake FTDI serial chip to a computer running the latest Windows driver will output NON GENUINE DEVICE FOUND!, an undocumented functionality that may break some products.

 

Ah, I did have this issue yesterday when I unplugged/replugged the FTDI into my laptop. But I just deleted the unknown device and it recovered. I'll check into this more - nobody else on Amazon reported issues with this FTDI breakout, but I guess it could still have gotten a fake.

 

 

 

If not, and if your FTDI device is being seen by the modern machine you’re connected to, the 400 may have a bad SIO port or POKEY chip.

 

So, if I were to scope the SIO port and the POKEY, what would indicate a good connection and chip?

[+DrVenkman]

 

Ah, I did have this issue yesterday when I unplugged/replugged the FTDI into my laptop. But I just deleted the unknown device and it recovered. I'll check into this more - nobody else on Amazon reported issues with this FTDI breakout, but I guess it could still have gotten a fake.

 

 

So, if I were to scope the SIO port and the POKEY, what would indicate a good connection and chip?

 

If you're 100% certain you've wired up to the correct pins on the SIO connector you made, remove and reseat the POKEY and then try the device again. If you have another system to use as a testbed, remove the POKEY from the 400 and try it on the test system. If everything works there, then the POKEY is good.

If not, time to check the logic charts in Sam's COMPUTERFACTS for the 400 and compare to what your machine shows during idle operation (see pp. 22 and following). You don't even need a full scope for this, just a logic probe. If you might want to check some of the same pins during SIO data requests from the Atari - for instance, from BASIC see you get activity from CSAVE or CLOAD (the Sam's actually mentions the same idea in a section on troubleshooting cassette troubles).

 

An even simpler test is to plug your board into the Atari but unplugged from your PC and the Atari powered off. Then check continuity from the Tx, Rx and command line pins pin on your FTDI device through the appropriate pads underneath the SIO connector on the Atari board. This will eliminate any kind of physical issue with the SIO port, or potentially reveal a problem like a cold solder joint on a pin or something.

[johndias]

 

If you're 100% certain you've wired up to the correct pins on the SIO connector you made, remove and reseat the POKEY and then try the device again. If you have another system to use as a testbed, remove the POKEY from the 400 and try it on the test system. If everything works there, then the POKEY is good.

If not, time to check the logic charts in Sam's COMPUTERFACTS for the 400 and compare to what your machine shows during idle operation (see pp. 22 and following). You don't even need a full scope for this, just a logic probe. If you might want to check some of the same pins during SIO data requests from the Atari - for instance, from BASIC see you get activity from CSAVE or CLOAD (the Sam's actually mentions the same idea in a section on troubleshooting cassette troubles).

 

An even simpler test is to plug your board into the Atari but unplugged from your PC and the Atari powered off. Then check continuity from the Tx, Rx and command line pins pin on your FTDI device through the appropriate pads underneath the SIO connector on the Atari board. This will eliminate any kind of physical issue with the SIO port, or potentially reveal a problem like a cold solder joint on a pin or something.

 

Finally got back to this. So, I tested the A101 on both boards I have. Both of them give a high on the logic probe, where I should be reading pulse on pins 30 and 32.

 

30 is CS0 and 32 is R/W.

 

I also probed pin 24 after running CLOAD... no pulse.

Does this mean the POKEY is bad?

Edited August 17, 2018 by johndias

[johndias]

Well, I'm sure I learned a lot about the POKEY and SIO - that's the silver lining. Bad news is I wasted a lot of my (and the good folks who tried to help) time - my pinouts for TX/RX were reversed. I'm not ashamed to admit when I make a mistake.

 

Thanks again to all the great folks who tried to help. I've got it working now! On to the next challenge!