No RS232 communcation between Amstrad CPC 464 and laptops

[Laurence Morgan]

A bit of background: Connecting a CPC 464 to a Raspberry Pi

I've managed to buy an Amstrad RS232C Serial expansion (the original one that needs power) however it doesn't seem to be working correctly, however I can't track which part along the chain the fault is since there's a few point of failure:

   
• I don't have an original PSU for the Amstrad RS232C
• The expansion port is plugging into a 25 pin to 9 pin connector
• Which is plugged into a 9 pin to USB converter

I'm getting no output on either |terminal (on Amstrad) nor screen /dev/ttyUSB0 9600 on Linux
What I've tried already is:

   
• changing the PSU - still no output on either terminals (CPC nor Linux)
• changing the baud rates - still no output on either terminals
• Swapping laptops, this time with a Linux machine that has a hardware 9 pin serial port so no need for the USB converter - still no output
• Plugging a different (albeit none RS232 compliment) device into the 9 pin connection to see if my computer could register input. - this did register input on Linux however it was obviously garbage because the device doesn't output RS232. However that would confirm that the 9 pin serial to USB cable works.
• I've also got a second CPC 464, which I've swapped around and that made no difference either.

So I think the fault is either:

   
• A dodgy RS232C expansion (how would I test this?)
• A dodgy 25 pin to 9 pin connector (are they just dumb plugs? In which case unlikely to be broken)
• Or user error! (am I missing some important step or completely misunderstanding how the RS232C device works?)

I'm really at a loss about what to try next. Any ideas anyone?

[gerald]

A dodgy RS232C expansion (how would I test this?)

Do a simple loop-back on the connector (TX on RX sould be enough as long as you configure it to not use HW flow control).

Or user error! (am I missing some important step or completely misunderstanding how the RS232C device works?)I'm really at a loss about what to try next. Any ideas anyone?

What cable are you using. You may need a need a null modem cable.

[Laurence Morgan]

The cable I'm using is this type of thing: USB 2.0 Male to RS232 Serial DB9 9 Pin and 25 Pin Adapter Connecter | eBay
(not exactly that product, but same sort of thing)

I'm now going to ask a few dumb questions:

1) How would I create a loop-back?
2) what's a null modem cable? Is it a bit like a crossover cable vs patch cable in Ethernet terms?

Thanks for the help by the way. It is hugely appreciated!!

[Audronic]

@Laurence Morgan



Please clean the Edge connector on the 464 and then short out On The 25 Pin D Type connector on the rs232 interface (Temporally ) Pins 2 and 3 and type some letters, they should echo back.
Good luck     Ray

[Laurence Morgan]

I tried shorting pins 2 and 3, nothing echoed back when i typed 

[Audronic]

I tried shorting pins 2 and 3, nothing echoed back when i typed 

Do You have a manual on how to operate the RS232 Interface.


RS232C Serial Interface (Amsoft UK) Manual

Have a look in the manual as to how too use the Interface and call up the RSX.


Good luck   Ray

[Laurence Morgan]

Do You have a manual on how to operate the RS232 Interface.


RS232C Serial Interface (Amsoft UK) Manual

Have a look in the manual as to how too use the Interface and call up the RSX.


Good luck   Ray

I read through that before installing the thing and and multiple times since. From what I can gather, I just use |teminal

I've also tried displaying the control characters (|ctrldisplay) and running in half duplex (|halfduplex) to echo the local characters just to prove that was accepting |teminal input.

I'm definitely not confident that this is the "correct" way to use it though, but I can't find anything else in the manual to suggest another nor even better method of doing this (happy to be proven wrong though).

[Laurence Morgan]

I've found the problem, there's no pathway on the board for the receive pin. Very weird. It looks like it was designed this way though so now I need to work out what pin it's expecting to receive on (I can't for one second believe the Amstrad Serial Interface was only designed for transmitting data).

Any ideas anyone?

[pelrun]

Pin 3 is explicitly mentioned in the manual as Receive - are you certain you're counting the pins the right way? Also, tracks can potentially be on either side of the board, depending on how it was made.

[Munchausen]

Couple of additional things:

1. If you have hardware flow control enabled then shorting pins 2 and 3 wont work (you'd also need to short another couple of pins).
2. In Linux you may need to do more than that to configure the serial port, as screen used like that may not turn off flow control etc. You can also short pins 2 and 3 on the serial connector of the USB->serial adapter to check that you are echo characters typed on the Linux machine as well. To get more control have a look at stty or putty.

[Laurence Morgan]

Pin 3 is explicitly mentioned in the manual as Receive - are you certain you're counting the pins the right way? Also, tracks can potentially be on either side of the board, depending on how it was made.

I know it sounds a dumb comment to make but I promise you the receive pin isn't connected to anything:





This is the underside of the board (obviously) so the pins will be reversed. On the right you'll see the solder joints for the DB-25 connector. The transmit date (TD) DTE pin has a track yet the receive data (RD) DCE does not. (and yes I have checked both sides).


When I have a laptop connected to the DB-25 connector sending data down the line it does not receive on the CPC. When send data from the CPC it is received on the laptop. So I definitely know the send pin on the Amstrad Serial Interface works. However when I short the RD and TD pins on the solder joints (so that the cable is still inserted) then whatever I type on the laptop gets echoed back on the laptop - even when running in full duplex mode (ie disabling local echo).


So I'm confident my Amstrad Serial Interface isn't "wired" up to receive. Whether that's a deliberate design decision or not I can't tell. From the look of the tracks that are on the board, I can't see the RD pin was ever intended to connected. However the software that comes on the ROM defaults to full duplex which would imply it was always intended to handle two way RS232 comms. Yet when looking at (admittedly low quality) photos of the PCB of the same device online to see if there was any post-machining fixer cables that may have been missed off my device, my Serial Interface looks identical to those online.


So what I essentially have is a Amstrad Serial Interface which is by all measures looks like it's designed to do full duplex RS232, yet does not have the RD DCE pin connected.


I'm very confused by this all. It makes no sense and I'm sure what I've got is a dodgy device because I can't find any reference to other people having these issues. Yet I really can't fathom out how my PCB differs from working models. So very strange.

[Laurence Morgan]

Couple of additional things:

1. If you have hardware flow control enabled then shorting pins 2 and 3 wont work (you'd also need to short another couple of pins).
2. In Linux you may need to do more than that to configure the serial port, as screen used like that may not turn off flow control etc. You can also short pins 2 and 3 on the serial connector of the USB->serial adapter to check that you are echo characters typed on the Linux machine as well. To get more control have a look at stty or putty.

1. shorting pins 2 and 3 work as a loop back for any equipment connected to the DB-25 port, but not for the Amstrad who's this expansion ROM is connected to.
2. I'd tried different flow controls as well (both on the CPC and on the laptop end). Also tried PuTTY on Windows (as much as I loathe that crappy OS ) - same results regardless of whatever terminal I use.

Maybe there is a flow control option that forces the same pin to be used send and receive? This is where my experience of RS232 falls short. But I can't see anything obvious in stty's man page to support this. Any ideas?

[gerald]

This is the underside of the board (obviously) so the pins will be reversed. On the right you'll see the solder joints for the DB-25 connector. The transmit date (TD) DTE pin has a track yet the receive data (RD) DCE does not. (and yes I have checked both sides).

The RD pin is connected on the component side and than goes to pin 13 of IC9 (MC1489) from closest to the connector via.

When I have a laptop connected to the DB-25 connector sending data down the line it does not receive on the CPC. When send data from the CPC it is received on the laptop. So I definitely know the send pin on the Amstrad Serial Interface works. However when I short the RD and TD pins on the solder joints (so that the cable is still inserted) then whatever I type on the laptop gets echoed back on the laptop - even when running in full duplex mode (ie disabling local echo).

if you're not receiving anything on the CPC, your options are :
- defective MC1489, which translates +12v/-12v signal to 5v/0v ones
- defective Z80-DART
- defective 8253 timer, which generates independent RX and TX clocks
- defective PSU module (the one that make the +12/-12 from 5V)

Making a diagnostic requires at least a oscilloscope to see up to where the RX signal is going.

However when I short the RD and TD pins on the solder joints (so that the cable is still inserted) then whatever I type on the laptop gets echoed back on the laptop - even when running in full duplex mode (ie disabling local echo).

That's not a good thing to do. You're shorting the CPC RS232 TX with your laptop RS232 TX.

[Laurence Morgan]

The RD pin is connected on the component side and than goes to pin 13 of IC9 (MC1489) from closest to the connector via.

Doesn't appear to be on my board:



That's a terrible picture though. I'll take another look at my PCB later today when my 2 year old isn't trying to climb over me.....

if you're not receiving anything on the CPC, your options are :
- defective MC1489, which translates +12v/-12v signal to 5v/0v ones
- defective Z80-DART
- defective 8253 timer, which generates independent RX and TX clocks
- defective PSU module (the one that make the +12/-12 from 5V)

Making a diagnostic requires at least a oscilloscope to see up to where the RX signal is going.
[/size]

Ah damn. I don't own an oscilloscope. Sounds like fixing this might be beyond me though

[/size]

That's not a good thing to do. You're shorting the CPC RS232 TX with your laptop RS232 TX.

I know. That was the point because I wanted to prove that the cables, terminals, etc were all working. Doing so has proven that the problem lies with the expansion device. I was just holding a wire to the joints though - I've not taken a soldering iron to it yet

[Laurence Morgan]

Ahhh there is a track on the component side. I swear I did look for it yesterday. Not sure how I missed it.


Thanks for your help guys.


[edit: I didn't miss it. I dismissed it because that track doesn't connect to the RD (pin 3) on the DB-25 connector. See next post]

[Laurence Morgan]

The RD pin is connected on the component side and than goes to pin 13 of IC9 (MC1489) from closest to the connector via.

Ok, spent a little more time looking at this thing and I'm now going to contradict both you and my previous post. I'm certain that the RD pin is not connected on either side, nor is pin 3 of the MC1489 connected to anything.

Looking at the front of the PCB, I've labelled which side pin 1 starts and the only track coming from the DB-25 connector is the opposite side. Baring in mind that RD is pin 3, it would be impossible for the component side track to be the RD given it's the wrong side of the DB-25 connector (ok maybe not impossible but highly unlikely and a really weird PCB design if it was)


(by the way, please excuse the bad editing of these photos. Linux badly needs a Paint.NET clone )

Here is the reverse side of the PCB. I've labelled pin 3 to demonstrate that it's not connected to anything on that aside either:



I've also got photos of the MC1489 chip:

This is the component side:



Then the PCB is flipped vertically:



It's possible I'm looking at the wrong pin, but the chip does clearly say MC1489 so that's got to be the chip you described. In neither picture there's anything on what I've identified as pin 13.

Would you normally expect the RD pin on the DB-25 to connect to pin 13 on the MC1489? And if so, would I need any resisters or just a straight wire?

[gerald]

Some Hints 
Top side
[attach=2]
Bottom Side
[attach=3]

I swear the pin 3 IS connected. You can check it with a continuity tester.

[Bryce]

Nope, that's pin 6. Pin 13 is the second from left on the top row.

Eitherway, I doubt there's anything wrong with your device. The CPC RS232 is expecting a 12V RS232 signal and many laptops only had TTL level (5V) RS232 ports. I'd check what the laptop signals are first before I'd start looking for problems on the RS232 board.

Bryce.

[Munchausen]

Since he shorted pins 2 and 3 on the CPC RS232 expansion and didn't get any echo back there is a problem with the expansion that's nothing to do with laptop voltage levels.

Most problems I've had with CPC expansions have been due to contact issues mating to the CPC expansion connector.

[Bryce]

I missed that bit where he said he'd done a loopback test.

Bryce.

[Laurence Morgan]

Some Hints 
Top side
[attach=2]
Bottom Side
[attach=3]

I swear the pin 3 IS connected. You can check it with a continuity tester.

Ahh yes, good spot. The RD pin is connected to the aforementioned chip and I've confirmed that with a continuity tester.