• Please review our updated Terms and Rules here

Model II Serial handshake not working

In the Lifeboat Associates notes for this version, it says:

Hardware handshaking involves the computer monitoring two of the
connections to the DB-25S socket connectors on the TRS-80. The
receiver of a TRS-80 port is enabled with pin 8 (DCD) high, the
transmitter with pin 5 (RTS) high. The computer itself will
generate a high on pin 20 (DTR) when it is able to receive a
character, and so this can be used to control a device
transmitting to a TRS-80 port receiver.


So it is using DTR to indicate readiness to receive, but what is it using DCD for? Confusing, badly worded... I thought it was RTS/CTS that was normally used for handshake. Anyone know?

Well, this is getting way too complicated, so I went back to first principles (RS232 port spec and TRS80 SIO->RS232 pinout)

Now Lifeboat either wrote that VERY POORLY or made a typo, 'cause RTS on the TRS80 is an OUTPUT. So how could you make it high, to control Tx???

Makes you not trust anything they tell you!

gwk
 
They must mean TX on the sending computer. But I still say it is badly written. This is from a readme file on the disk - I haven't found the full manual online (yet).
 
OK, after tracing the schematics, and depending on the DR notes that DTR is used by the TRS-80-II, here is a pinout to try for full handshake...

DB25(ModII)------- DB9(PC)
2>>>>>>>> to >>>>2
3>>>>>>>> to>>>>>3
6-8-9>>>>> to >>>>4
7>>>>>>>>>to >>>>5
20>>>>>>>>to>>>> 8

let me know if this works...
gwk
 
Code:
 DB9		 Ch.A
 RX 2 <--------	 2 TX
 TX 3 -------->  3 RX
DTR 4 ------|->	 6 DSR
	    |->  8 DCD
            |->  9 RTS
GND 5 ---------	 7 GND
CTS 8 <-------- 20 DTR
 
No, unfortunately.

When sending plain text from Hyperterm, I got rows of +- characters on the TRS-80 (using the terminal program). These look like this:
Code:
±

..but I want to go back and double check the connections. Also, under DOS with a specific mode for COM5 (my serial port) which turns off RTS handshake, I got different results using type <file.txt> > COM5 - rows of random characters as if the baud rate was wrong (it isn't).
 
No, unfortunately.

When sending plain text from Hyperterm, I got rows of +- characters on the TRS-80 (using the terminal program). These look like this:
Code:
±

..but I want to go back and double check the connections. Also, under DOS with a specific mode for COM5 (my serial port) which turns off RTS handshake, I got different results using type <file.txt> > COM5 - rows of random characters as if the baud rate was wrong (it isn't).

Well, that sounds like you said, baud rate- or a miswire. You might try disconnecting all but the CTS-DTR, RX,TX, and GND. If you still get problems, it surely won't be the wiring -- it'll be SW setup, somehow...

I seem to remember you are using a USB COM port on the PC -- try reassigning it to COM1 or COM2. Sometimes these act wierd with high com port asignments...
gwk
 
The problems you are having with the terminology is because you are connecting two computers together. The RS232 terminology assumes you are connecting a computer or terminal, known as Data Terminal Equipment or DTE for short, with a modem or Data Communications Equipment (DCE).

So the terminal Outputs on (request to send) RTS and the Modem responds with (Clear to send) CTS. As we don't have a modem we have two computers we cross connect the RTS/CTS lines, so from TRS80(25 pin) to PC(9pin) that should be 8=>4, 5=>7.

Then when the modem connects to the other end it raises Data Carrier Detect (DCD) and Data Set Ready (DSR) so we normally connect these to Data Terminal Read (DTR) on the other end. So from the 25 to the 9 pin that would 6+8 => 4 and 20 => 6+1

that's not quite what is shown above,


Code:
[FONT=Courier New] 
DB9		 Ch.A

 RX 2  <--------  2 TX
 TX 3  -------->  3 RX
 RTS 7  ------->  5 CTS
 CTS 8  <-------  4 RTS
 DTR 4 ------|--> 6 DSR
             |--> 8 DCD
 DCD 1 <--|          
 DSR 6 <--|------ 20 DTR
[/FONT]

This page

http://www.lammertbies.nl/comm/cable/RS-232.html

has lots more info and examples.
 
The problems you are having with the terminology is because you are connecting two computers together. The RS232 terminology assumes you are connecting a computer or terminal, known as Data Terminal Equipment or DTE for short, with a modem or Data Communications Equipment (DCE).

So the terminal Outputs on (request to send) RTS and the Modem responds with (Clear to send) CTS. As we don't have a modem we have two computers we cross connect the RTS/CTS lines, so from TRS80(25 pin) to PC(9pin) that should be 8=>4, 5=>7.

Then when the modem connects to the other end it raises Data Carrier Detect (DCD) and Data Set Ready (DSR) so we normally connect these to Data Terminal Read (DTR) on the other end. So from the 25 to the 9 pin that would 6+8 => 4 and 20 => 6+1

that's not quite what is shown above,
Code:
[FONT=Courier New] 
DB9         Ch.A

 RX 2  <--------  2 TX
 TX 3  -------->  3 RX
 RTS 7  ------->  5 CTS
 CTS 8  <-------  4 RTS
 DTR 4 ------|--> 6 DSR
             |--> 8 DCD
 DCD 1 <--|          
 DSR 6 <--|------ 20 DTR
[/FONT]

This page

http://www.lammertbies.nl/comm/cable/RS-232.html

has lots more info and examples.


That would be normal if 2 DTE devices which respected conventions were to be wired together. Since Lifeboat SPECIFICALLY states that DTR (pin 20) is used as a handshake for sending data TO the TRS-80, the normal RTS/CTS seem to be implied as not involved.

Using DTR is not normal for handshake on a PC, but in this case, it is the only line that is supposedly used on the TRS-80 side, so going to DTE on the PC, it would have to go to CTS -- RTS on the TRS-80 does nothing but stay HIGH, according to DR.

gwk
 
That would be normal if 2 DTE devices which respected conventions were to be wired together. Since Lifeboat SPECIFICALLY states that DTR (pin 20) is used as a handshake for sending data TO the TRS-80, the normal RTS/CTS seem to be implied as not involved.

I wonder how that worked with any other computer as they all use DTR in the normal way. If there are still problems might be worth getting (or making) a breakout box:-

http://www.ebay.com/itm/381274720430

so you can see what is going on...
 
I wonder how that worked with any other computer as they all use DTR in the normal way. If there are still problems might be worth getting (or making) a breakout box:-

http://www.ebay.com/itm/381274720430

so you can see what is going on...

I have read more than I ever cared to in the last few days, on the TRS-80 modII, and everyone talking about RS232 transfers seems to be using:

1. Xon/XOFF SW handshake
2. Very low baud rates (typ 300 baud), and then it still looses chars when the FDC goes active...

So I'm not sure that ANYONE has ever done this using HW handshake, at high baud rate, between a DTE TRS-80-II and a DTE PC - seems like most RS232 is between the TRS-80 and a printer, or some such - and when between computers, everyone seems to use XON/XOFF or just 300 baud and an amulet, or swinging a cat around in a bag at midnight - sort of occult invocation to HOPE it works... :}

gwk
 
I wonder how that worked with any other computer as they all use DTR in the normal way. If there are still problems might be worth getting (or making) a breakout box:-

http://www.ebay.com/itm/381274720430

so you can see what is going on...

I agree - a breakout w/LEDs, a logic probe, or an OScope would be preferable to hand wringing in the dark. But this is so non-standard, that I have to believe that DTR REALLY is being used for handshake, so that's a good start at any rate (however squirrely it is) -

The idea of using DTR/DSR as bidirectional handshake was never meant to be the primary toggling pair by the EIA - Only static indicators of "aliveness" (I know-I sat on the EIA committee for RS232A-C and the CEBUS committee, as well as the IEEE advisory committees), but people have a way of breaking convention all of the time, and the way the documents were written leaves a lot to the imagination...

gwk
 
That would be normal if 2 DTE devices which respected conventions were to be wired together. Since Lifeboat SPECIFICALLY states that DTR (pin 20) is used as a handshake for sending data TO the TRS-80, the normal RTS/CTS seem to be implied as not involved.

That is should be OK because the PC should still stop sending when Data Set Ready is dropped, and the null modem should connect DTR to DSR....
.... the problem may be the buffering in the PC UART. I wonder if its work setting the transmit buffer smaller. You can only set that in Device Manager....
 
No, unfortunately.

When sending plain text from Hyperterm, I got rows of +- characters on the TRS-80 (using the terminal program). These look like this:
Code:
±

..but I want to go back and double check the connections. Also, under DOS with a specific mode for COM5 (my serial port) which turns off RTS handshake, I got different results using type <file.txt> > COM5 - rows of random characters as if the baud rate was wrong (it isn't).

The +- you re seeing could just be a toggled HndShk line miswired or missetup going to the Rx line on the TRS-80. Recheck wiring, and pull ALL handshake lines so you just have RX,TX, and GND. Then test at 300 baud and see what you get.

If OK, leave the baud rate, and add the DTR->CTS back in --- NOW what do you get?, if OK, add another connection, test, and repeat. THEN up the baud rate to 9600, and see what happens!

gwk
 
They must mean TX on the sending computer. But I still say it is badly written. This is from a readme file on the disk - I haven't found the full manual online (yet).

The Tandy official Users and Technical manual are written poorly too. Obviously NOT an EE writing 'cause pinouts for the RS232 do NOT include signal origination notations---you don't know from their charts, when a signal is IN or OUT of the I/F!!!, and whether its HIGH/LOW always, or is toggelable!!!

How technical writers can so goof up a manual for a major piece of equipment is beyond me - specially the Ref Manual!

gwk
 
It further surprises me that the serial ports behave like this, yet they use standard Z80 SIO chips. One might expect that, if Tandy had chosen some odd combination of TTL, line drivers and other stuff to implement the ports, that you'd see these anomalies, but surely with a standard implementation, the interface's behaviour should likewise be standard.

Unless the SIO isn't that clever - I haven't read the datasheet on it.

@griffk - It works at 300 baud with character pacing, but as I said, there's no pause for disk access. So I will have to determine the maximum buffer size. Your incremental approach looks good, though, so I will give it a shot.
 
Back
Top