Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

Peter Coghlan cctalk at
Fri Jun 19 13:59:23 CDT 2020

Dave Wade wrote:
> > -----Original Message-----
> > From: Ethan Dicks <ethan.dicks at>
> > Sent: 19 June 2020 15:44
> > To: Dave Wade <dave.g4ugm at>; General Discussion: On-Topic
> > and Off-Topic Posts <cctalk at>
> > 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>
> > wrote:
> > > Its been ages since I did this but looking here
> > >DPV11
> > >
> > >
> > > 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
> 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.

Peter Coghlan.

> Dave 

More information about the cctalk mailing list