Dave Wade wrote:
-----Original
Message-----
From: Ethan Dicks <ethan.dicks at gmail.com>
Sent: 19 June 2020 15:44
To: Dave Wade <dave.g4ugm at gmail.com>; General Discussion: On-Topic
and Off-Topic Posts <cctalk at classiccmp.org>
Subject: Re: Synchronous serial Re: E-Mail Formats RE: Future of
cctalk/cctech
On Fri, Jun 19, 2020 at 4:26 AM Dave Wade via cctalk <cctalk at classiccmp.org>
wrote:
Its been ages since I did this but looking here
DPV11
https://www.aggsoft.com/rs232-pinout-cable/RS232.htm
I see we have a transmit clock output on pin 24, transmit clock input on 15
and
RX clock input on 17.
So if on checking with a scope I have clocks on
24, I would try linking 24 and
15 on one side to 17 on the other side.
If you have only one clock running then that goes
to 15 and 17 on both
ends....
None of the devices I worked with in the 80s and 90s had clock available on
pin 24. I'm not saying none exist, but they weren't around in the era I was
doing this.
Ethan,
Well some do, some don't. In general we avoided using it because we probably
wanted to set other signals,
However the first card for which I could find documents, the QBUS DPV11 has
a configurable clock on pin 24
http://www.bitsavers.org/pdf/dec/qbus/EK-DPV11-UM-001_Aug80.pdf
page 2-5 and 2-7. Its called "null modem" but you can see its connected back
to the clocks so you can test the interface.
I took a look at pin 24 on my setup and it has a steady negative voltage
so it is getting driven at least. It looks very likely that it can be
configured to generate a clock signal for loopback tests.
Before figuring out how to do that, I had a go at making a clock from a 555.
The random bunch of components I grabbed produced a roughly 600Hz output
according to the frequency range on my multimeter and it is probably far
from square. I decided to live dangerously, skip the
MAX232 and connect
the output of the 555 directly to the clock signal inputs. Along
with
a birds nest of crossover connections, this allowed the example programs
to successfully write and read some data over the line!
Next, I tried starting up HUJI-NJE. Initially, the link failed to connect
because one end wasn't listening when the other end was sending. However,
I found that if I started both ends at more or less the same time, the
link managed to connect successfully. It looks like I need to tweak the
handshaking crossovers so that this works more reliably.
I suspect the meaning of the lack of support for "BISYNC" in the DST32 may
be that I don't get the ability to generate the bisync CRCs in the hardware.
By coincidence, I was involved in a thread on generating CRCs for bisync
links on another mailing list recently so I am now fairly well versed in how
to do this in software.
Many thanks to everyone for your help with this project, especially Antonio,
Ethan, Paul and Dave.
Regards,
Peter Coghlan.
Dave