Antonio Carlini wrote: 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: KA41-D V1.0 [snip] DSH32-A 00FF.0001 V1.0 DSH32-S 0000.0001 V3.0 NI 0000.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] 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? 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.

On 2020-06-18 3:34 p.m., Chuck Guzis via cctalk wrote: 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.

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

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

On 2020-06-18 6:06 a.m., Peter Coghlan via cctalk wrote: 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.

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

On 6/18/20 11:55 AM, Ethan Dicks via cctalk wrote: 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

Wow, that's weird. 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

That rings a bell (so to speak). Chances are those specs were all pretty lenient and the 126 bps used by PLATO was non-standard but not a real problem. I don't know how common those connections were or what distance was needed. A large number of PLATO terminals were fed via a microwave video signal. That was a pretty neat setup: all 1008 terminal lines, TDM muxed into what looked like a video signal (so 60 frames per second). Devices called "site controllers" would receive that and extract the data streams for 32 terminals from that data. They'd also accept the 126 bps terminal->host data stream and stat-mux it into a single data stream going to the host, I don't remember seeing the format for that. The data center had a TV monitor that showed the outgoing signal. It looked vaguely like a punched card with a lot more than the usual number of holes in it. paul

Paul Koning wrote: 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.

Ethan Dicks wrote: 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. 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. 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.

On Fri, Jun 19, 2020 at 4:26 AM Dave Wade via cctalk <cctalk at classiccmp.org> wrote: 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

Dave Wade wrote: 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 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.

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

Ethan Dicks wrote: 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.

On 6/18/20 2:55 PM, Peter Coghlan via cctalk wrote: 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

On Thu, 18 Jun 2020, Peter Coghlan via cctalk wrote: Yep, last Sat on the VAX/NetBSD mailing list. Maciej

On Thu, 18 Jun 2020 at 11:10, ED SHARPE via cctalk <cctalk at classiccmp.org> wrote: Dear hypothetical deities, no. That causes problems with translation, people not knowing the name of another country's currency in a foreign language, etc. There is a standardized internationally-agreed set of 3 ASCII letter symbols for this reason and this is why people use them. USD = US dollar GBP = GB pound EUR = Euro CZK = Czech crown (korun/koruny/koruna, depending on quantity, in Czech) Etc etc. -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053