Dilwyn Jones wrote:
...
I think (the article doesn't say this) that pin 6 of a QL serial port
plug is the one nearest the latching pin. It is not connected for the
purposes of these cables and file transfer, but I think it carries +12v,
so might cause some damage to interfaces if wired wrongly, although you
could test my assumption by using a tester to determine which pin is
+12V since that will identify pin 6.
Just to confirm, pin 6 (+12v to be used to assert any control line, eg DSR,
DCD) is next to the clip.
Although ser2 pin 4 is shown in the QL manual as DTR, Tony Firshman told
me a while back it is more like an RTS signal as far as making these
cables is concerned. You can then see that making up a serial cable is a
simple matter of cross connecting the relevant signals, i.e. RxD to TxD
and vice versa, and RTS to CTS and vice versa, and connecting the two
ground signal lines together.
The DSR/DTR & RTS/CTS handshake pairs have always been something of a
confusion to me. As far as I understand these lines, they are:
DTR - Data Terminal Ready: terminal is ready for input
DSR - Data Set Ready: modem is ready to send data to terminal
RTS - Request To Send: ... terminal wants to send data
CTS - Clear To Send: . modem is ready to receive data from terminal.
So logically, crossing RTS/CTS on a DTE-DTE null modem cable makes no sense:
the Request To Send from one terminal is connected to the Clear To Send on
the other; or to put it another way:
If terminal A wants to send data (raises RTS), terminal B gets the signal
telling it it's ok for it to send data to terminal A (CTS goes high), and
terminal A gets no signal that terminal B is ready to input the data
terminal A wants to send to terminal B - that would happen the moment
terminal B decided it wanted to send some data to terminal A and raised its
RTS line (causing terminal A's CTS line to go high).
The serial ports on the QL were rather a cludge. They are both split into
two halves, with the 8749 second processor handling the input side of both,
and the ZX8302 ULA handling the output side of both.
Output of data from the QL is fairly straightforward:
The ZX8302 assumes the relevant request line is raised (use the +12v line if
necessary) and awaits clearance on the relevant control line (Ser1.DTR or
Ser2.CTS). Then it sends the data on the relevant data line (Ser1.RXD or
Ser2.TXD) - shifting out the bits at the baud rate.
Input of data to the QL is rather more complicated:
The input lines (Ser1.TXD & Ser2.RXD) are tied (via logic gates) together
and appear on one data pin (port) of the processor (and the interrupt line).
The start bit causes the processor to interrupt, which then shifts the
data in at the relevant baud rate (I presume). Thus ONLY ONE serial port
can receive data at any one time.
Hardware handshaking is [almost] vital to ensure correct input of serial
data - especially if both ports are being used. The way it is done is that
the 8749 asserts the ready for input line (Ser1.CTS & Ser2.DTR - of the port
on which it is expecting data) for a short time and then clears it. If both
serial ports are open, it then asserts the other one. This flip-flop nature
of the control line(s) can be observed by a LED serial port tester.
Thus, the QL uses the following:
Ser1.CTS & Ser2.DTR to control when it is ready to receive input
Ser1.TXD & Ser2.RXD to recive input from another device
Ser1.DTR & Ser2.CTS to control when another device is ready to receive input
Ser1.RXD & Ser2.TXD to send output to another device
As the QL uses non standard connectors, perhaps it'd be better to rename the
port pins:
PinSer1Ser2
1 GND GND GND = signal GrouND
2 DTQ DFQ DTQ = Data To QL
3 DFQ DTQ DFQ = Data From QL
4 RFF RFT RFF = Ready For From
5 RFT RFF RFT = Ready For To
6 +12 +12
RFF is set by the other device saying it's ready for data From the QL
RFT is set by the QL saying it's ready for data To the QL.
Thus a QL to QL cable would cross DTQ/DFQ and RFF/RFT (for Ser1 to Ser2,
this crossing would occur with a straight through 1-1, 2-2, 3-3, 4-4, 5-5
cable; with Ser1 to Ser1, or Ser2 to Ser2, the crossing would occur with
crossed pairs: 1-1, 2-3, 3-2, 4-5, 5-4).
Thus, I think a cable from the QL to a PC would connect:
DTQ -- TXD = Data transmitted To QL
DFQ -- RXD = Data received From QL
RFT -- CTS = Clear To Send To QL
RFF -- DTR = Ready to receive data From QL*
GND -- GND = Signal ground
*DTR would probably always be asserted by a PC as their serial ports can
usually handle input at any time; thus the RFF control line could be looped
to the +12 line (pin 6) so that the QL always thinks it can send data. The
only vital line is the RFT control line - the QL _MUST_ be allowed to
control the flow of data to the serial port otherwise framing, or other
errors will occur.
