Dave Wade wrote: > > -----Original Message----- > > From: Ethan Dicks <ethan.di...@gmail.com> > > Sent: 19 June 2020 15:44 > > To: Dave Wade <dave.g4...@gmail.com>; General Discussion: On-Topic > > and Off-Topic Posts <cctalk@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@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
