RE: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
Dave Wade wrote: > > -Original Message- > > From: Ethan Dicks > > Sent: 19 June 2020 15:44 > > To: Dave Wade ; General Discussion: On-Topic > > and Off-Topic Posts > > 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 > > 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
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
> On Jun 19, 2020, at 10:43 AM, Ethan Dicks via cctalk > wrote: > > On Fri, Jun 19, 2020 at 4:26 AM Dave Wade via cctalk > wrote: >> Its been ages since I did this but looking here >> >> 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. I had the same reaction. The sync serial devices I know use modem-supplied clocks. That's why there is such a device as a "modem eliminator", which is different from the familiar asynchronous "null modem". A modem eliminator is essentially a null modem plus a clock source along the lines discussed a day or two ago. If you had a sync device that had the ability to send a local clock out, you could make a sync null modem that would just be wires, as an async null modem is. Perhaps this is something RS232 standardized but that wasn't adopted in the real world. paul
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On 19/06/2020 11:07, Peter Coghlan via cctalk wrote: I already tried extracting ZSDRIVER.EXE from the DECnet/OSI kit for VAX/VMS 7.3 and placing it in SYS$LOADABLE_IMAGES but ZSA0: remained stubbornly offline until I installed the rest of DECnet/OSI and the LES$ACP_V30 process started. I think I have an old CD containing a WANDD kit somewhere but I can't seem to put a hand on it right now. I probably put it in a "safe place" :-( I think messing with the kits isn't likely to produce a working system. You need more than the driver to make everything work. At the very least LES (Layered Environment Services) has to be available. These manuals mention the DSV11 and DST32 but there is no reference to the DSH32 anywhere. The installation guide says the device driver for the DST32 is ZSDRIVER.EXE so this seems to suggest that the DST32 and DSH32 are the same thing or at least very similar. Maybe there was a difference of opinion between the hardware people and the software people as to what it should be called :-) I've found some notes that suggest that the DST32 and DSH32 both use the same driver (ZSDRIVER, as you've found). The other "busless" one was the DSW21/DSW41/DSW42. I can't find a WANDD SPD either locally nor online, but (iirc) V1.2 was Phase IV and certainly ran on V5.5-2. A bunch of stuff changed radically in V6.0 so if there was a Phase IV release for V6 then it would almost certainly have been post-V1.2. Antonio -- Antonio Carlini anto...@acarlini.com
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On 2020-06-19 11:43 a.m., Ethan Dicks via cctalk wrote: On Fri, Jun 19, 2020 at 4:26 AM Dave Wade via cctalk wrote: Its been ages since I did this but looking here 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 On the machines I worked on it was an option, but I never saw it used as the modem clocking was usually synchronized across the common carrier's network making it much more reliable. Most customers also used modems provided by the common carrier, which was a good thing as it was pretty easy to determine where the fault was. When one of our modems was used trouble shooting was more difficult, but I do recall discussing with the common carrier that receive level was too low, and having the deny that was possible only to have the level come up while still on the phone with them. Paul.
RE: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
> -Original Message- > From: Ethan Dicks > Sent: 19 June 2020 15:44 > To: Dave Wade ; General Discussion: On-Topic > and Off-Topic Posts > 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 > 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. Dave > -ethan
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 wrote: > Its been ages since I did this but looking here > > 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
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
> On Jun 19, 2020, at 6:07 AM, Peter Coghlan via cctalk > wrote: > >> ... > > The specifications manual says that the maximum speed for the DST32 is > 19200 bps (for HDLC or SDLC) or 9600 bps (for DDCMP) but worryingly > doesn't list a speed for BISYNC which is what I want to do with it :-( > > It also says the supported line interfaces for the DST32 are: > RS-232-C/V.24/V.28, RS-423-A/V.10/RS-449 and RS-422-A/V.11/RS-449 but not > V.35 which seems strange because the only reaction I have got from it so > far is using the V.35 interface cable. At least it suggests it should work > with the V.24 cables when once I manage to come up with a suitable clock. The interfaces should all work about the same, for short cables. RS232 isn't rated as high as the others but if you're just running a 6 foot cable across the bench that isn't much of a problem. Interesting that DDCMP is rated lower. I wonder why that would be. If the device handles the data CRC, the software would do the header CRC but that is easy. I'd expect 9600 or so for BISYNC. I forgot how CRC works -- are the escape characters in BISYNC included in the CRC, or not? If not then you're probably looking at software CRC. Still, 9600 baud with software CRC is doable for a J-11, so it should be for a MicroVAX as well. paul
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
Antonio Carlini wrote: On 18/06/2020 14:06, Peter Coghlan via cctalk wrote: > > I have found the whole thing very confusing too. My suspicion was also > that they were pretty much the same thing but the DST32 had exernal > connectors suitable for mounting in a MicroVAX 2000 while the DST32 had > external connectors that could be mounted in a MicroVAX 3100. That is, > until I also came across the preliminary version of EK-283AA-AD-001 > which threw cold water on that theory. Unless it was originally called > the DSH32 and then renamed to DST32 for the MicroVAX 2000 or something... I expect that the uVAX 2000 interface was around well before the uVAX 3100 one. I suspect that the docs was wrong or that something got renamed at some stage. If I ever frind my notebooks from the time I can take a look. I'd be very interested to know what the story was if you manage to locate those notebooks. > > I was hoping to use VAX WANDD but I ended up having to install DECnet OSI > on VMS 7.3. Perhaps if I dig up an earlier VMS version, I can avoid > using > DECnet OSI? If you further along it got renamed to DECnet-Plus ... would that help :-) I don't know when Phase IV support stopped for WANDD. DECnet-VAX Extensions went out in the V5.4-3 timeframe IIRC. Certainly for a while you have a choice and were not required to run DECnet/OSI. In fact the only reason that DECnet-VAX Extensions shipped was (iirc) that PSI/WANDD was ready and DECnet/OSI wasn't. Anyway, pre VMS V6.0 I'm sure you can just pull the latest contemporary WANDD kit off a VMS CD and you'll be fine. I already tried extracting ZSDRIVER.EXE from the DECnet/OSI kit for VAX/VMS 7.3 and placing it in SYS$LOADABLE_IMAGES but ZSA0: remained stubbornly offline until I installed the rest of DECnet/OSI and the LES$ACP_V30 process started. I think I have an old CD containing a WANDD kit somewhere but I can't seem to put a hand on it right now. I probably put it in a "safe place" :-( I was pleased to find that I have a grey DEC folder containing AA-LN26B-TE VAX WAN Device Drivers Installation Guide, Specifications and Programmer's Guide for VAX/VMS 5.0 Software Version: VAX Wide Area Network Device Drivers V1.1 First Printing July 1988 Revised, January 1989. I'd forgotten I had these! These manuals mention the DSV11 and DST32 but there is no reference to the DSH32 anywhere. The installation guide says the device driver for the DST32 is ZSDRIVER.EXE so this seems to suggest that the DST32 and DSH32 are the same thing or at least very similar. Maybe there was a difference of opinion between the hardware people and the software people as to what it should be called :-) The specifications manual says: "The DST32 is a single line interface for single board VAX systems. It provides RS-232-C, RS-442-A and RS-423-A connections to dial-up or leased synchronous communications lines and operates in both character-oriented and bit-stuffing mode. On the synch side the idea was to get away from having a set of (often different) cables for each interface. Instead everything had the same 50-pin connector and then you picked the appropriate cable for V.25 or X.21 or whatever you needed. My DST32 has such a connector, as does your DSH32. I expect that the DSV-11 also is the same. DECnis certainly is. > > and I also have two Nokia DS 60100 baseband modems, one with a V.35 > interface card and one with an X.21 interface card. When I hook up the > former with the BC19F cable, I can get the lights on the modem to react > when I try to access ZSA0: on the MicroVAX. However, I can't get any > reaction when I use the BC19C cable with the latter even when I jumper > the modem to take account of the fewer signals available in X.21. It > may be that the BC19C is meant for something other than the DSH/T32... I don't remember the cable part numbers (although they will be in the manuals) but if it plugs into the 50-pin connector then it should work. I found details about many of the interface cables, including wiring diagrams in EK-DRT90-OM DEC WANrouter 90 Owner's Manual on the web and more stuff in EK-A0497-IN DEC WANserver 150 Installation/Owner's Guide. > Anyway, this whole line of attack is fairly academic as the modems can > only do 48kbps - 160kbps and the maximum for the DSH/T32 seems to be > 19200bps. > I'd be surprised if they don't work at up to 56k at least. Maybe not 64k (I remember the DSV11 firmware engineer telling my that some extra work had to be done to get one of the DSV11 modes to work properly at 64k even in pathological cases, so maybe other, lower-end interfaces didn't get the same love). Above 64k would not have been a normal use case back in the day - I don't have any data handy to check what should work though. The specifications manual says that the maximum speed for the DST32 is 19200 bps (for HDLC or SDLC) or 9600 bps (for DDCMP) but worryingly doesn't list a speed for BISYNC which is what I
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On Fri, Jun 19, 2020 at 12:21:14AM +0100, Pete Turnbull via cctalk wrote: > [...] Some of the UK banking systems like HOBS survived using viewdata that > way up to the end of the 1990s, and I still have at least a couple of 1275 > modems. Hobbyists are still running Viewdata BBSes. Here's one connected to the Internet and provided with a JavaScript client so you can log in and have a poke around: http://fish.ccl4.org/java/. Offering access to one's BBS via TCP/IP isn't really optional any more now that many of us no longer have suitable analogue POTS lines to plug our old modems into, what with a mobile being a better choice for most purposes. I think (HS)CSD might have carried over from GSM into 3G, and it's even possible that my tinpot telco would connect such a call, but the odds that I could convince my mobile to make the call is pretty much zero. How do you enter AT commands on an iPhone anyway? Also, I resent paying per minute for low-bandwidth phone calls when I've got unmetered VDSL. I would write Viewdata clients in the nostalgia wave of the late 1990s and early 2000s, as it was also a nice easy introduction into a new platform's graphics and I/O subsystems. Maybe I'll do one in WebAssembly for old time's sake. > The idea was to use 1200 for the transmission from central computer to > consumer, and the back channel for user responses/commands. Not many people > type faster than 7.5cps. That's 75WPM with the usual rule of thumb of six characters per word. I can copy-type at about 75-85WPM, which would interact badly with a small FIFO on a very basic terminal, what with that being an average and some words are typed at a faster rate. Fortunately, I've never suffered a Viewdata terminal that awful: the BBC Micro backed its 6850 UART and its 1-byte FIFO with a luxurious 192-byte software FIFO, for example. Having to stop for a sip of tea while the buffer drains isn't so terrible. Normally one would compose longer bits of text offline, of course, so that BT would get the smallest pound of flesh possible. Definitely a company with the "never mind the quality, feel the price" mentality, but that's all telcos for you.
RE: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
> -Original Message- > From: cctalk On Behalf Of Peter Coghlan > via cctalk > Sent: 18 June 2020 23:11 > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: Re: Synchronous serial Re: E-Mail Formats RE: Future of > cctalk/cctech > > Ethan Dicks wrote: > > On Thu, Jun 18, 2020 at 2:42 PM Peter Coghlan via cctalk > > wrote: > > > Thanks for your reply Paul. My eventual goal is to be able to use > > > the synchronous serial interface on a MicroVAX to connect to IBM > > > machines that only support bisync lines. I trimmed this because we seem to be missing the crux of clocks and why we need them! In async data we take our clock from the edge of the start bit, and we have a stop bit which is really there to stop characters running together. With sync we just have a stream of digital data and we use the clock to know when to sample it. There are no stop bits or start bits, and we use a synchronisation character at the start of each block to work out how the characters are positioned in the data stream. So we need clocks... Its been ages since I did this but looking here 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 as suggested here:- https://www.synclink.com/nullmodem.html This assumes you have RS232 interfaces. If its X21 then eliminators are available on e-bay for a few pounds. Dave
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
> On Jun 18, 2020, at 5:47 PM, Antonio Carlini via cctalk > wrote: > > ... >> Anyway, this whole line of attack is fairly academic as the modems can >> only do 48kbps - 160kbps and the maximum for the DSH/T32 seems to be >> 19200bps. >> > > I'd be surprised if they don't work at up to 56k at least. Maybe not 64k (I > remember the DSV11 firmware engineer telling my that some extra work had to > be done to get one of the DSV11 modes to work properly at 64k even in > pathological cases, so maybe other, lower-end interfaces didn't get the same > love). > > > Above 64k would not have been a normal use case back in the day - I don't > have any data handy to check what should work though. Not with modems, but of course the "local" line cards (coax pairs) for the DMC/DMR/DMP sync DDCMP controllers could go at 1 Mb/s. DMC only barely (with a few bugs). The DMV doesn't have that capability if I remember right. paul
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
> On Jun 18, 2020, at 5:55 PM, Peter Coghlan via cctalk > wrote: > > ... > I can rustle up +/-12V with a bench supply or two but I don't have a > 1488 handy. I should be able to borrow a MAX232 from something though. > I don't have any baud rate generators lying around either. How about a > 555 generating square waves round about 10kHz for something approximating > 9600 bps? Does it have to be spot on a "valid" rate or will anything > "close" do as long as it is the same at both ends? > > To be absolutely clear, do I have to drive pins 15 and 17 going to both > interfaces ie four loads on the driver in total? Yes. Both sides are looking for a receive clock to tell them were the incoming bits begin, and a transmit clock to control the shifting out of the transmit bits. Any speed should work so long as it's slow enough. So a 555 feeding a MAX232 should be fine. Most variants of that device have several drivers so you can split the four loads over more than one driver if you want to. That's probably not necessary. paul
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On 6/18/20 2:55 PM, Peter Coghlan via cctalk wrote: > Ethan Dicks wrote: > I can rustle up +/-12V with a bench supply or two but I don't have a > 1488 handy. I should be able to borrow a MAX232 from something though. > I don't have any baud rate generators lying around either. How about a > 555 generating square waves round about 10kHz for something approximating > 9600 bps? Does it have to be spot on a "valid" rate or will anything > "close" do as long as it is the same at both ends? Sync, in my recollection, is a bit fussier than async with respect to the clock signal. Unlike async, which "samples" the bit cell more-or-less in the center (hexce the 16x or 64x clock rate), synchronous is edge-sampled, so that the clock signal must match the data signal with respect to phase. The clock signal for receive data is recovered by the receiving modem and so is always in-phase. Such stuff as protocol details can differ greatly (e.g. Bisync vs. SDLC), but remember that there are no start or stop bits like as in async. Synchronization is done by pattern-matching with "idle" bits being sent to fill gaps or to form preamble to sync. In some respects, not terribly different from hard disk recording. It's been years since I fooled with the stuff, so I may have quite a bit wrong. --Chuck
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On 18/06/2020 21:31, Paul Koning via cctalk wrote: I did see something vaguely similar. Bell 202 modems are 1200 baud FSK, so on a voice channel they normally are 1200 bps half duplex. They can also be hooked up to 4-wire fixed circuits. But they have a reverse channel, good for 150 baud if I remember right. IIRC the Bell standard allows for only 50 baud and the back channel uses ASK (basically switching a carrier on and off). The CCITT equivalent standard is 1200/75 baud, FSK both ways, and in the 1980s and early 90s that was used for Prestel and similar systems, including Micronet, Telecom Gold email, Packet SwitchStream (PSS), BT Tymnet and some online banking systems, here in the UK. It was also used for Minitel in France, BTX in Germany and later for Telidon in Canada. Some of the UK banking systems like HOBS survived using viewdata that way up to the end of the 1990s, and I still have at least a couple of 1275 modems. The idea was to use 1200 for the transmission from central computer to consumer, and the back channel for user responses/commands. Not many people type faster than 7.5cps. -- Pete Pete Turnbull
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
Ethan Dicks wrote: > On Thu, Jun 18, 2020 at 2:42 PM Peter Coghlan via cctalk > wrote: > > Thanks for your reply Paul. My eventual goal is to be able to use the > > synchronous serial interface on a MicroVAX to connect to IBM machines that > > only support bisync lines. > > I'm curious which software package you are using. In the 80s and 90s, > I worked for Software Results Corp, and we sold hundreds (small > thousands?) of Unibus, Qbus, and VAXBI interfaces and software suites > under the name COMBOARD for Bisync and SNA comms from DEC-to-IBM > (RSTS, RSX-11, VMS, and UNIX). In my experience, people paid us > $10K-$25K per line because they had problems with whatever other > solution they were looking at that cost less. I don't know any > specific details on where the gaps were, but just that people did > experience bugs or missing features that made them come to us. I'd > like to hear about what you are encountering once you get to the point > of passing bytes. > I am using a very old package called HUJI-NJE which implements NJE links on VAX/VMS and UNIX. This was later developed into "funetnje" which added some enhancements but broke the VMS functionality. I backported some of the funetnje enhancements into HUJI-NJE in order to use them on VMS. NJE over TCP/IP is implemented on both platforms but on VAX/VMS, there is also supposed to be support for using synchronous serial interfaces in the form of a DMF32, DMB32 or DSV32 (is that like a DSV11 I wonder?). If this all works out, it may be possible to use it to get NJE links into IBM mainframe hardware that only has support for bisync lines. It might also have applications in talking to 3270 terminals connected via bisync lines. HUJI-NJE is not great for debugging the hardware with so I am also using a pair of of example programs I found in AA�PHEPB�TE DECnet/OSI for VMS VAX WANDD Programming. > > > However, I don't have access to any such IBM kit > > at the moment so I have to make do with trying to get the MicroVAX to talk > > to another instance of itself for now. > > For bisync (3780/HASP) that should be just fine. There's a simple > difference in the protocol so that each end can tell who is the > master, and AFAIK, any implementation you encounter should be able to > be set in the appropriate mode, but you _do_ have to tell each end > what their role is or they will chatter endlessly if they both think > they are the master. > NJE is supposed to be able to use hardware features of devices such as the 2703 to be able to decide which end gets to be primary and which end gets to be secondary. Sounds like it will be fun to implement... I think endless chatter whether idle or not seems to be a feature of bisync. > > Apologies if you already know this. It's been a long time and I'm not > sure who remembers what details about obscure comms from 30-40 years > ago. I myself haven't even set up a bisync connection in 25 years. I > used to do this stuff every day, then by the mid-90s, it entirely > evaporated. > I am fairly well up on NJE but only over TCP/IP until now. All this synchronous serial stuff is completely new to me so I am grateful for any and all information I can get about it. Regards, Peter. > -ethan
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On Thu, Jun 18, 2020 at 6:08 PM Peter Coghlan via cctalk wrote: > Ethan Dicks wrote: > > As for the clocking, yes, a modem or modem eliminator provides the > > baud rate clocking on pins 15 and 17. You could use any one of a > > number of baud rate generators... > I can rustle up +/-12V with a bench supply or two but I don't have a > 1488 handy. I should be able to borrow a MAX232 from something though. I have an abundance of 1488/1489 chips, but I used to make comms devices. I only have a few MAX232 devices not already baked into projects. > I don't have any baud rate generators lying around either. How about a > 555 generating square waves round about 10kHz for something approximating > 9600 bps? Does it have to be spot on a "valid" rate or will anything > "close" do as long as it is the same at both ends? It does need to be the same on both ends, and, yes, a 555 should work, but it's unlikely to be within 1% of a "real" rate. > To be absolutely clear, do I have to drive pins 15 and 17 going to both > interfaces ie four loads on the driver in total? Yes. Pins 15 and 17 on both ends. 4 loads. You can do asymmetric speeds, but the TX for one end has to match the RX for the other end. I see some discussion of that in this thread, but in my experience, we always had same-room direct connect lines, or dial-up lines over POTS and modem speeds like 1200 bps or 2400 bps because we didn't want to pay for leased or conditioned lines. Every connection I ever set up was symmetric. 99.9% were 56kbps or slower. -ethan
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
Ethan Dicks wrote: > On Thu, Jun 18, 2020 at 5:53 AM Peter Coghlan via cctalk > wrote: > > To get somewhere near back on topic, I am trying to set up a synchronous > > serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe) > > interfaces. One of the options I have is a BC19D cable and a BC19V cable > > which seem to be identical or nearly identical. Each plugs into a DSH32 > > at one end and has a V.24 DB25 connector at the other end. I don't seem > > to have anything available in the way of a pair of suitably similar modems > > or a modem eliminator to put between the two V.24 connectors. Can anyone > > suggest some kind of a quick hardware hack that I could use to fill the > > gap? Is a pair of DB25 sockets with crossed over wiring betweeen them > > sufficient or do I need something that generates clock signals too? > > If both ends don't care about delays in the handshake lines that would > be natural with a modem or high-end modem eliminator, you can just > match up the signals between the two devices as you would for a null > modem. > > As for the clocking, yes, a modem or modem eliminator provides the > baud rate clocking on pins 15 and 17. You could use any one of a > number of baud rate generators, from the COM 8116 (one that we used at > work in the early 80s for a simple modem eliminator) to a modern > microcontroller thumping out pulses at the right frequency. You'll > need to drive both sides of the connection at RS-232 levels, so a > level shifter (1488 if you have +/-12V handy, or MAX232 if you do > not). AFAIK, you can drive both ends from one line driver, but the > safer course would be to drive each clock pin independently. > Hi Ethan, Thanks for your reply. I can rustle up +/-12V with a bench supply or two but I don't have a 1488 handy. I should be able to borrow a MAX232 from something though. I don't have any baud rate generators lying around either. How about a 555 generating square waves round about 10kHz for something approximating 9600 bps? Does it have to be spot on a "valid" rate or will anything "close" do as long as it is the same at both ends? To be absolutely clear, do I have to drive pins 15 and 17 going to both interfaces ie four loads on the driver in total? Regards, Peter. > -ethan
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
Paul Koning wrote: > > > On Jun 18, 2020, at 2:14 PM, Peter Coghlan via cctalk > > > ... > > As I mentioned in another reply, I have a pair of baseband synchronous mode > > and were it not for a speed incompatibility between them and the MicroVAX > > synchronous serial interfaces I have access to, ... > > I'm curious about that. Synchronous modems supply the bit clock to the > interface. So a synchronous interface works at whatever speed the modem > delivers, so long as it's not too fast for the interface. What are the > Microvax sync interfaces you have? DMV? DUV? A DMV will work at up to > 56 kbps. > There is conflicting information about what exactly the interface I have which is fitted in a MicroVAX 3100 is called. It looks most likely to be a DSH32 or a DSH32-B which may amount to the same thing but it could also be a DST32 which may also amount to the same thing... Documentation suggests that the synchronous interface part of a DSH32 (which for added confusion is referred to as DSH32-S) is DSV11 compatible but limited to a maximum of 19200 bps. The modems I have (which were intended for use with 64 kbps lines attached to Cisco routers) don't have jumpers for clock speeds lower than 48 kbps. Regards, Peter. > paul
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On 18/06/2020 14:06, Peter Coghlan via cctalk wrote: I have found the whole thing very confusing too. My suspicion was also that they were pretty much the same thing but the DST32 had exernal connectors suitable for mounting in a MicroVAX 2000 while the DST32 had external connectors that could be mounted in a MicroVAX 3100. That is, until I also came across the preliminary version of EK-283AA-AD-001 which threw cold water on that theory. Unless it was originally called the DSH32 and then renamed to DST32 for the MicroVAX 2000 or something... I expect that the uVAX 2000 interface was around well before the uVAX 3100 one. I suspect that the docs was wrong or that something got renamed at some stage. If I ever frind my notebooks from the time I can take a look. The console code in one of my MicroVAX 3100 machines shows this: test 50 KA41-D V1.0 [snip] DSH32-A 00FF.0001 V1.0 DSH32-S .0001 V3.0 NI .0001 Yet in VAX/VMS 7.3, I see this: $ ANALYZE /SYSTEM OpenVMS (TM) VAX System analyzer SDA> show dev zsa0 I/O data structures --- ZSA0 ZS_DST32 UCB address: 814EAA40 [snip] Wonderfully confusing :-) I was hoping to use VAX WANDD but I ended up having to install DECnet OSI on VMS 7.3. Perhaps if I dig up an earlier VMS version, I can avoid using DECnet OSI? If you further along it got renamed to DECnet-Plus ... would that help :-) I don't know when Phase IV support stopped for WANDD. DECnet-VAX Extensions went out in the V5.4-3 timeframe IIRC. Certainly for a while you have a choice and were not required to run DECnet/OSI. In fact the only reason that DECnet-VAX Extensions shipped was (iirc) that PSI/WANDD was ready and DECnet/OSI wasn't. Anyway, pre VMS V6.0 I'm sure you can just pull the latest contemporary WANDD kit off a VMS CD and you'll be fine. I have two boards in two MicroVAX 3100 machines. Each board has one Synchronous serial port (50 pin D connector) and eight asynchronous terminal lines (36 pin Centronics connector). To add further confusion, I have a third MicroVAX 3100 which has the 50 pin and 36 pin external connectors on the back but no actual DSH32/DHT32 board inside! I also have the following cables: 1 BC19C Rev B1 50 pin D (female) to 13/15 pin D (male) X.21 1 BC19D Rev B 50 pin D (female) to 16/25 pin D (male) V.24 1 BC19F Rev B 50 pin D (female) to 17/34 pin "square" thing (male) V.35 1 BC19V 50 pin D (female) to 16/25 pin D (male) V.24 On the synch side the idea was to get away from having a set of (often different) cables for each interface. Instead everything had the same 50-pin connector and then you picked the appropriate cable for V.25 or X.21 or whatever you needed. My DST32 has such a connector, as does your DSH32. I expect that the DSV-11 also is the same. DECnis certainly is. and I also have two Nokia DS 60100 baseband modems, one with a V.35 interface card and one with an X.21 interface card. When I hook up the former with the BC19F cable, I can get the lights on the modem to react when I try to access ZSA0: on the MicroVAX. However, I can't get any reaction when I use the BC19C cable with the latter even when I jumper the modem to take account of the fewer signals available in X.21. It may be that the BC19C is meant for something other than the DSH/T32... I don't remember the cable part numbers (although they will be in the manuals) but if it plugs into the 50-pin connector then it should work. Anyway, this whole line of attack is fairly academic as the modems can only do 48kbps - 160kbps and the maximum for the DSH/T32 seems to be 19200bps. I'd be surprised if they don't work at up to 56k at least. Maybe not 64k (I remember the DSV11 firmware engineer telling my that some extra work had to be done to get one of the DSV11 modes to work properly at 64k even in pathological cases, so maybe other, lower-end interfaces didn't get the same love). Above 64k would not have been a normal use case back in the day - I don't have any data handy to check what should work though. Antonio -- Antonio Carlini anto...@acarlini.com
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On 2020-06-18 3:34 p.m., Chuck Guzis via cctalk wrote: On 6/18/20 6:06 AM, Peter Coghlan via cctalk wrote: and I also have two Nokia DS 60100 baseband modems, one with a V.35 interface card and one with an X.21 interface card. When I hook up the former with the BC19F cable, I can get the lights on the modem to react when I try to access ZSA0: on the MicroVAX. However, I can't get any reaction when I use the BC19C cable with the latter even when I jumper the modem to take account of the fewer signals available in X.21. It may be that the BC19C is meant for something other than the DSH/T32... Anyway, this whole line of attack is fairly academic as the modems can only do 48kbps - 160kbps and the maximum for the DSH/T32 seems to be 19200bps. We would have been delighted to get 19.2K on our 11/750. Leased line with a Bell 209 modem, 9600 sync. Back then, that ran about $5K/month for the hookup. --Chuck When I started out in customer service many years ago anything faster than 9600 was very rare and even then they where often split off using stat muxes or multi-drop lines. I call one store have a 9600 line back to head office in Toronto that served two store controllers, four 3777s with 3203 to print orders, one with a tape drive to transmit orders entered on a Nixdorf mini, as well as some miscellaneous terminals in the local warehouse and order office. It was not uncommon for users of 3270 terminals to have the controllers in a few offices sharing a multi-drop line, the banks did the same thing with their terminal controllers and ATMs. I also remember some data centers having conditioned dial-up lines that included a handset that you could talk on, but it was pretty weird as the conditioned lines did not have echo suppressors. The first banking terminal I worked on where on a multi-drop 300 baud async line and I also worked on finance company terminals that where on a multi-drop telegraph line at a speedy 75 baud. Paul.
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
> On Jun 18, 2020, at 3:26 PM, Ethan Dicks via cctalk > wrote: > > On Thu, Jun 18, 2020 at 3:08 PM Chuck Guzis via cctalk > wrote: >> On 6/18/20 11:55 AM, Ethan Dicks via cctalk wrote: >> >>> We used to run our sync serial stuff between 9600 and 56kbps, both our >>> own Bisync products, and DDCMP over interfaces like the one that's >>> part of the DMF32... >> >> My recollection of the Bell 209 is that it supported a low-speed reverse >> channel in addition to the FDX primary. > > I had to look that up. Yes. I see that in the spec, at *5*bps. Wow, that's weird. >> Did any DEC equipment ever take advantage of that? > > I've never encountered it before, so I cannot confirm. Not that I know of. I did see something vaguely similar. Bell 202 modems are 1200 baud FSK, so on a voice channel they normally are 1200 bps half duplex. They can also be hooked up to 4-wire fixed circuits. But they have a reverse channel, good for 150 baud if I remember right. PLATO used that in its original terminal connections, in a slightly strange way: 1260 bps data to the terminal, and 126 bps data from terminal to host. The protocols are peculiar: terminal output is "synchronous", 21 bit frames at 60 frames per second, but each frame has a start bit (no stop bit). Data to the host is asynchronous, 1 start, 1 stop bit, 10 data bits. Since a 202 modem is just plain FSK, it doesn't matter that the data rate is not quite the standard 1200 bps. paul
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On Thu, Jun 18, 2020 at 3:08 PM Chuck Guzis via cctalk wrote: > On 6/18/20 11:55 AM, Ethan Dicks via cctalk wrote: > > > We used to run our sync serial stuff between 9600 and 56kbps, both our > > own Bisync products, and DDCMP over interfaces like the one that's > > part of the DMF32... > > My recollection of the Bell 209 is that it supported a low-speed reverse > channel in addition to the FDX primary. I had to look that up. Yes. I see that in the spec, at *5*bps. > Did any DEC equipment ever take advantage of that? I've never encountered it before, so I cannot confirm. -ethan
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On Thu, 18 Jun 2020, Peter Coghlan via cctalk wrote: > However, Peter uses PMDF MAIL to post to the list because it has been > pointed out to him that VMS MAIL doesn't do References: and In-Reply-To: > headers correctly. On that note, has anyone heard from Mouse? I haven't > seen anything posted by him in a very long time now. Yep, last Sat on the VAX/NetBSD mailing list. Maciej
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On 6/18/20 11:55 AM, Ethan Dicks via cctalk wrote: > We used to run our sync serial stuff between 9600 and 56kbps, both our > own Bisync products, and DDCMP over interfaces like the one that's > part of the DMF32. We had customers in Europe running our products at > 64kbps with no problems, and we did have one modem eliminator clocked > at 115kbps for testing, which is the max speed for V.24, IIRC. > > 56kbps should be safe for the devices you are describing, but it might > go a little faster. My recollection of the Bell 209 is that it supported a low-speed reverse channel in addition to the FDX primary. Did any DEC equipment ever take advantage of that? --Chuck
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On Thu, Jun 18, 2020 at 2:42 PM Peter Coghlan via cctalk wrote: > Thanks for your reply Paul. My eventual goal is to be able to use the > synchronous serial interface on a MicroVAX to connect to IBM machines that > only support bisync lines. I'm curious which software package you are using. In the 80s and 90s, I worked for Software Results Corp, and we sold hundreds (small thousands?) of Unibus, Qbus, and VAXBI interfaces and software suites under the name COMBOARD for Bisync and SNA comms from DEC-to-IBM (RSTS, RSX-11, VMS, and UNIX). In my experience, people paid us $10K-$25K per line because they had problems with whatever other solution they were looking at that cost less. I don't know any specific details on where the gaps were, but just that people did experience bugs or missing features that made them come to us. I'd like to hear about what you are encountering once you get to the point of passing bytes. > However, I don't have access to any such IBM kit > at the moment so I have to make do with trying to get the MicroVAX to talk > to another instance of itself for now. For bisync (3780/HASP) that should be just fine. There's a simple difference in the protocol so that each end can tell who is the master, and AFAIK, any implementation you encounter should be able to be set in the appropriate mode, but you _do_ have to tell each end what their role is or they will chatter endlessly if they both think they are the master. Apologies if you already know this. It's been a long time and I'm not sure who remembers what details about obscure comms from 30-40 years ago. I myself haven't even set up a bisync connection in 25 years. I used to do this stuff every day, then by the mid-90s, it entirely evaporated. -ethan
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On Thu, Jun 18, 2020 at 2:48 PM Paul Koning via cctalk wrote: > > On Jun 18, 2020, at 2:14 PM, Peter Coghlan via cctalk > > wrote: > > As I mentioned in another reply, I have a pair of baseband synchronous > > modems > > and were it not for a speed incompatibility between them and the MicroVAX > > synchronous serial interfaces I have access to, ... > > I'm curious about that. Synchronous modems supply the bit clock to the > interface. So a synchronous interface works at whatever speed the modem > delivers, so long as it's not too fast for the interface. What are the > Microvax sync interfaces you have? DMV? DUV? A DMV will work at up to 56 > kbps. We used to run our sync serial stuff between 9600 and 56kbps, both our own Bisync products, and DDCMP over interfaces like the one that's part of the DMF32. We had customers in Europe running our products at 64kbps with no problems, and we did have one modem eliminator clocked at 115kbps for testing, which is the max speed for V.24, IIRC. 56kbps should be safe for the devices you are describing, but it might go a little faster. -ethan
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On Thu, Jun 18, 2020 at 5:53 AM Peter Coghlan via cctalk wrote: > To get somewhere near back on topic, I am trying to set up a synchronous > serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe) > interfaces. One of the options I have is a BC19D cable and a BC19V cable > which seem to be identical or nearly identical. Each plugs into a DSH32 > at one end and has a V.24 DB25 connector at the other end. I don't seem > to have anything available in the way of a pair of suitably similar modems > or a modem eliminator to put between the two V.24 connectors. Can anyone > suggest some kind of a quick hardware hack that I could use to fill the > gap? Is a pair of DB25 sockets with crossed over wiring betweeen them > sufficient or do I need something that generates clock signals too? If both ends don't care about delays in the handshake lines that would be natural with a modem or high-end modem eliminator, you can just match up the signals between the two devices as you would for a null modem. As for the clocking, yes, a modem or modem eliminator provides the baud rate clocking on pins 15 and 17. You could use any one of a number of baud rate generators, from the COM 8116 (one that we used at work in the early 80s for a simple modem eliminator) to a modern microcontroller thumping out pulses at the right frequency. You'll need to drive both sides of the connection at RS-232 levels, so a level shifter (1488 if you have +/-12V handy, or MAX232 if you do not). AFAIK, you can drive both ends from one line driver, but the safer course would be to drive each clock pin independently. -ethan
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
> On Jun 18, 2020, at 2:14 PM, Peter Coghlan via cctalk > wrote: > > ... > As I mentioned in another reply, I have a pair of baseband synchronous modems > and were it not for a speed incompatibility between them and the MicroVAX > synchronous serial interfaces I have access to, ... I'm curious about that. Synchronous modems supply the bit clock to the interface. So a synchronous interface works at whatever speed the modem delivers, so long as it's not too fast for the interface. What are the Microvax sync interfaces you have? DMV? DUV? A DMV will work at up to 56 kbps. paul
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
Paul Berger wrote: On 2020-06-18 6:06 a.m., Peter Coghlan via cctalk wrote: > > > To get somewhere near back on topic, I am trying to set up a synchronous > serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe) > interfaces. One of the options I have is a BC19D cable and a BC19V cable > which seem to be identical or nearly identical. Each plugs into a DSH32 > at one end and has a V.24 DB25 connector at the other end. I don't seem > to have anything available in the way of a pair of suitably similar modems > or a modem eliminator to put between the two V.24 connectors. Can anyone > suggest some kind of a quick hardware hack that I could use to fill the > gap? Is a pair of DB25 sockets with crossed over wiring betweeen them > sufficient or do I need something that generates clock signals too? > > Regards, > Peter Coghlan. > > While I have no experience with MicroVAX, I do recall that on the machine I was involved with synchronous communications on, IBM terminals and systems, there was an option for the interface to provide clocking and I suppose it might be possible to set one side to provide the transmit and receive clocks and cross them over to the other interface, but I have never tried that. When I worked in a development center with a room full of S/38 and S/36 we had a modem rack with a large number of Gandalf modem eliminators that provided clocking to the interface. In the field the most common setup was to have the modem provide the clocks as the common carrier could synchronize them over a long distance. Thanks for your reply Paul. My eventual goal is to be able to use the synchronous serial interface on a MicroVAX to connect to IBM machines that only support bisync lines. However, I don't have access to any such IBM kit at the moment so I have to make do with trying to get the MicroVAX to talk to another instance of itself for now. As I mentioned in another reply, I have a pair of baseband synchronous modems and were it not for a speed incompatibility between them and the MicroVAX synchronous serial interfaces I have access to, plus another probably minor snag, it looks very much like they would do the job when suitably jumpered. There is even a card in the bottom of each modem case giving details of all the jumper settings! Regards, Peter. Paul.
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On 6/18/20 6:06 AM, Peter Coghlan via cctalk wrote: > and I also have two Nokia DS 60100 baseband modems, one with a V.35 > interface card and one with an X.21 interface card. When I hook up the > former with the BC19F cable, I can get the lights on the modem to react > when I try to access ZSA0: on the MicroVAX. However, I can't get any > reaction when I use the BC19C cable with the latter even when I jumper > the modem to take account of the fewer signals available in X.21. It > may be that the BC19C is meant for something other than the DSH/T32... > Anyway, this whole line of attack is fairly academic as the modems can > only do 48kbps - 160kbps and the maximum for the DSH/T32 seems to be > 19200bps. We would have been delighted to get 19.2K on our 11/750. Leased line with a Bell 209 modem, 9600 sync. Back then, that ran about $5K/month for the hookup. --Chuck
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
Antonio Carlini wrote: On 18/06/2020 10:06, Peter Coghlan via cctalk wrote: > > To get somewhere near back on topic, I am trying to set up a synchronous > serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe) > interfaces. One of the options I have is a BC19D cable and a BC19V cable > which seem to be identical or nearly identical. Each plugs into a DSH32 > at one end and has a V.24 DB25 connector at the other end. I don't seem > to have anything available in the way of a pair of suitably similar modems > or a modem eliminator to put between the two V.24 connectors. Can anyone > suggest some kind of a quick hardware hack that I could use to fill the > gap? Is a pair of DB25 sockets with crossed over wiring betweeen them > sufficient or do I need something that generates clock signals too? > I can't find my DHS32/DST32 docs right now but it's probably a simple re-spin of the DSH32. I think that the DST32 was the uVAX2000 option and the DSH32 was for the uVAX 3100 series. My notes say that my MicroVAX 2000 has a DST32 (54-17230) but the preliminary version of EK-283AA-AD-001 is for the DSH32 and that talks about the MicroVAX 2000! Thanks for your reply Antonio. I have found the whole thing very confusing too. My suspicion was also that they were pretty much the same thing but the DST32 had exernal connectors suitable for mounting in a MicroVAX 2000 while the DST32 had external connectors that could be mounted in a MicroVAX 3100. That is, until I also came across the preliminary version of EK-283AA-AD-001 which threw cold water on that theory. Unless it was originally called the DSH32 and then renamed to DST32 for the MicroVAX 2000 or something... The console code in one of my MicroVAX 3100 machines shows this: test 50 KA41-D V1.0 [snip] DSH32-A 00FF.0001 V1.0 DSH32-S .0001 V3.0 NI .0001 Yet in VAX/VMS 7.3, I see this: $ ANALYZE /SYSTEM OpenVMS (TM) VAX System analyzer SDA> show dev zsa0 I/O data structures --- ZSA0ZS_DST32 UCB address: 814EAA40 [snip] I think that in the lab at DEC I used a modem eliminator (I used to support all of the synch devices supported by VAX WANDD). I may even have some of those modem eliminators in the garage. I was hoping to use VAX WANDD but I ended up having to install DECnet OSI on VMS 7.3. Perhaps if I dig up an earlier VMS version, I can avoid using DECnet OSI? Just to double check ... you definitely have synch boards and not (for example) 8-way asynch lines? There were a whole bunch of designators that were so very close: DST32, DHT32, DSH32, DHW41, DSW41! I have two boards in two MicroVAX 3100 machines. Each board has one Synchronous serial port (50 pin D connector) and eight asynchronous terminal lines (36 pin Centronics connector). To add further confusion, I have a third MicroVAX 3100 which has the 50 pin and 36 pin external connectors on the back but no actual DSH32/DHT32 board inside! I also have the following cables: 1 BC19C Rev B1 50 pin D (female) to 13/15 pin D (male) X.21 1 BC19D Rev B 50 pin D (female) to 16/25 pin D (male) V.24 1 BC19F Rev B 50 pin D (female) to 17/34 pin "square" thing (male) V.35 1 BC19V 50 pin D (female) to 16/25 pin D (male) V.24 and I also have two Nokia DS 60100 baseband modems, one with a V.35 interface card and one with an X.21 interface card. When I hook up the former with the BC19F cable, I can get the lights on the modem to react when I try to access ZSA0: on the MicroVAX. However, I can't get any reaction when I use the BC19C cable with the latter even when I jumper the modem to take account of the fewer signals available in X.21. It may be that the BC19C is meant for something other than the DSH/T32... Anyway, this whole line of attack is fairly academic as the modems can only do 48kbps - 160kbps and the maximum for the DSH/T32 seems to be 19200bps. Regards, Peter Coghlan. Antonio
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On 2020-06-18 6:06 a.m., Peter Coghlan via cctalk wrote: To get somewhere near back on topic, I am trying to set up a synchronous serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe) interfaces. One of the options I have is a BC19D cable and a BC19V cable which seem to be identical or nearly identical. Each plugs into a DSH32 at one end and has a V.24 DB25 connector at the other end. I don't seem to have anything available in the way of a pair of suitably similar modems or a modem eliminator to put between the two V.24 connectors. Can anyone suggest some kind of a quick hardware hack that I could use to fill the gap? Is a pair of DB25 sockets with crossed over wiring betweeen them sufficient or do I need something that generates clock signals too? Regards, Peter Coghlan. While I have no experience with MicroVAX, I do recall that on the machine I was involved with synchronous communications on, IBM terminals and systems, there was an option for the interface to provide clocking and I suppose it might be possible to set one side to provide the transmit and receive clocks and cross them over to the other interface, but I have never tried that. When I worked in a development center with a room full of S/38 and S/36 we had a modem rack with a large number of Gandalf modem eliminators that provided clocking to the interface. In the field the most common setup was to have the modem provide the clocks as the common carrier could synchronize them over a long distance. Paul.
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On 18/06/2020 10:06, Peter Coghlan via cctalk wrote: To get somewhere near back on topic, I am trying to set up a synchronous serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe) interfaces. One of the options I have is a BC19D cable and a BC19V cable which seem to be identical or nearly identical. Each plugs into a DSH32 at one end and has a V.24 DB25 connector at the other end. I don't seem to have anything available in the way of a pair of suitably similar modems or a modem eliminator to put between the two V.24 connectors. Can anyone suggest some kind of a quick hardware hack that I could use to fill the gap? Is a pair of DB25 sockets with crossed over wiring betweeen them sufficient or do I need something that generates clock signals too? I can't find my DHS32/DST32 docs right now but it's probably a simple re-spin of the DSH32. I think that the DST32 was the uVAX2000 option and the DSH32 was for the uVAX 3100 series. My notes say that my MicroVAX 2000 has a DST32 (54-17230) but the preliminary version of EK-283AA-AD-001 is for the DSH32 and that talks about the MicroVAX 2000! I think that in the lab at DEC I used a modem eliminator (I used to support all of the synch devices supported by VAX WANDD). I may even have some of those modem eliminators in the garage. Just to double check ... you definitely have synch boards and not (for example) 8-way asynch lines? There were a whole bunch of designators that were so very close: DST32, DHT32, DSH32, DHW41, DSW41! Antonio -- Antonio Carlini anto...@acarlini.com
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
Dave Wade wrote: > > > -Original Message- > > From: cctalk On Behalf Of Peter Coghlan > > via cctalk > > Sent: 18 June 2020 08:22 > > To: General Discussion: On-Topic and Off-Topic Posts > > > > Subject: RE: Future of cctalk/cctech > > > > ED SHARPE wrote: > > > Use modern email program that sees expanded char. Sets and > > > graphics it is a brand new world !I love old hardware to look > > > at but if communicating I like the ability to see graphical > > > things... and I think tell majority of people like images of > > > things.. Ed# > > > > > > > Just beware. Some environments, especially old EBCDIC ones put different > currency symbols on the same code points > So:- > > I wrote this as one dollar => $1.00 > This as one pound => $1 > And this as one euro => €1 > Lastly one cent => ¢1 > > I expect you all get that as sent except for perhaps the Euro which didn't > exist when Peters VAX was built > ... but on an old UK EBCDIC mainframe Dollar becomes Pound and Cent becomes > dollar. This was a real pain as a UK user of Bitnet. Well, Peter reads cctalk using VMS MAIL on his alphas and this has it's own problems. Around VMS 8.something, someone had the bright idea that VMS MAIL should replace certain "unusual" characters (such as the tilde for example) with (you guessed it) a dollar sign rather than present them directly to the reader for some unknown reason... However, Peter uses PMDF MAIL to post to the list because it has been pointed out to him that VMS MAIL doesn't do References: and In-Reply-To: headers correctly. On that note, has anyone heard from Mouse? I haven't seen anything posted by him in a very long time now. To get somewhere near back on topic, I am trying to set up a synchronous serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe) interfaces. One of the options I have is a BC19D cable and a BC19V cable which seem to be identical or nearly identical. Each plugs into a DSH32 at one end and has a V.24 DB25 connector at the other end. I don't seem to have anything available in the way of a pair of suitably similar modems or a modem eliminator to put between the two V.24 connectors. Can anyone suggest some kind of a quick hardware hack that I could use to fill the gap? Is a pair of DB25 sockets with crossed over wiring betweeen them sufficient or do I need something that generates clock signals too? Regards, Peter Coghlan. > Dave
