is it possible to configure two pidp 211bsd's to talk to each over serial

[will...@gmail.com]

Forgive me if this is a dumb, off kilter question, but I'm trying to wrap my head around how things used to work and how they work in the virtual world of today. Specifically, when I was much younger, I'd hook up my 300 baud modem to my pc and dial up phone numbers. One phone number of particular awesomness, was the local university's VMS system. VMS wasn't all that cool, but from my pc, I could access the internet via that VMS gateway and use ftp, gopher, xmodem and kermit, etc. to feel like I was a bonafide netizen.. this was lightyears beyond the bbs's that I'd experienced prior. I get the feeling, reading old documentation, that unix systems did something similar to copy files around and to send mail from one system to another. That is, not over ethernet, or t1's or anything I'm familiar with, but over dial up lines. Now, I've been messing with simh and old unix for 5+ years and I can do a lot on a single multi-user system like v6/v7 etc. and I can even set things up so that I can telnet in over DCI and DZ devices and get multiple sessions going at once.

What I haven't quite figured out is how to get instances to talk to each other. I figure I can probably use ethernet/tcp/ip with 211bsd and talk between those instances, but in my current view, that's cheating. In the real world, I'm guessing that folks had their pdp-11's sitting in a lab and those pdp-11's (or vaxes, etc) had devices (DCI is apparently ancient, so DZ's maybe) that had wires coming out of them going to whatever the ancient equivalent of a hayes modem was and from their to the wall phone line? They would dial up a remote location and the reverse would be the case (wall to modem to dz to pdp-11)? Or, maybe it was just pdp-11 had dz and dz was a modem that could hook up to the phone line? At the same time, maybe the wires from the DCI/DZ on one pdp-11 could be attached directly to another pdp-11 on the other side of the lab.

Anyhow, here we are in SimH land. I can pretty much configure any device simh supports. Can I get two instances talking over these virtual DCI/DZ lines and if so, how? and once they're magically connected, how do I start a conversation on one to the other? If I'm on A and want to talk to B (in the same room, so to speak) how do I dial up B and talk, copy a file, etc? telnet, rsh, rcp, uucp, mail, what's possible and what was common?

I'm comfortable with and willing to fire up and modify v6, v7, 211, 4.2, att3b2 svr2.0.5, etc. I also already know how to enable and configure the lines in simh as I mentioned above, it's the talking to each other that's been the challenge. I can use my host to login over telnet to these systems without issue.

Thansk!

[Johnny Billquist]

You're thinking of UUCP. It's purely mail and file copying. No
interactive use.
And it was most Unix, and it was getting pretty defunct already in the 90s.
But if you search around you should find documentation on how to set UUCP.

But the question of how you connect two machines together via serial
ports is sortof not answered there. If you have something like Raspberry
Pis that you run your simulated machines on, you could connect your
simulated machines serial port to an actual serial port, and then
physically connect the two together, like the real world back in the
day. If you're all virtual, then you need to get some small program that
can connect together two telnet ports, which would be your virtual cable.

Not super complicated, and I think there might be people out there who
are doing this (the whole UUCP). But for me, I'd rather stick with
ethernet and tcp/ip.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/6c13265a-5bd5-414f-912e-b5a9fda727f5n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/6c13265a-5bd5-414f-912e-b5a9fda727f5n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Clem Cole]

On Fri, Jan 21, 2022 at 1:41 AM will...@gmail.com <will...@gmail.com> wrote:

I get the feeling, reading old documentation, that unix systems did something similar to copy files around and to send mail from one system to another.

It is called UUCP [UNIX to UNIX Copy Protocol] and the USENET was created to exploit it.  The docs describing it are part of Seventh Edition in /usr/doc.

BTW: later implementations of UNIX could do IP over serial lines also ...  IIRC Scott Braden or one of his minions wrote the first version for the Berkeley IP stack in the mid-1980s.

 

What I haven't quite figured out is how to get instances to talk to each other. I figure I can probably use ethernet/tcp/ip with 211bsd and talk between those instances, but in my current view, that's cheating. In the real world, I'm guessing that folks had their pdp-11's sitting in a lab and those pdp-11's (or vaxes, etc) had devices (DCI is apparently ancient, so DZ's maybe)

As I have said before, the prefered interface for UNIX systems back in the day for both PDP-11s and Vaxen, particularly when running UUCP was the DH11 - although we used the implementation from Able Computer called the DMAX or DHDM - because it was much smaller and less expensive.  The prefered modem for UUCP was a Telebit Trailblazer  [which had the UUCP G protocol built in].  Note that the Able version of the DH could support 56K - I'm not sure the original DEC could go that fast [I never tried it on the few real DH11s I had access]. DZs and DLs and DC were two slow, lacked buffering and tended to drop characters at speeds over 120 cps.

 

They would dial up a remote location and the reverse would be the case (wall to modem to dz to pdp-11)?

Correct except it was traditionally a DH port and Telebit not a DZ or a Hayes.  BTW: the v7 code, need a DN11 to do the dialing for the phone line and assumes a WE212 modem and their associated autodialer for the modem rack [see the docs].  Remember that Hayes style 'in-band dialing did not yet exist when UUCP was written in the mid'70s and when those unit did appear on the general market in the late 1970s, were considered was a bit of an anathema to the AT&T BTL/WE folks.

 

Also, by the late 1990s [after cheap Broadband Internet was available] and use of UUCP fell off, many of us replaced the Telebit's with Couriers [I still have two] which did not have the g protocol, but could do 56K with regular dial in. 

 At the same time, maybe the wires from the DCI/DZ on one pdp-11 could be attached directly to another pdp-11 on the other side of the lab.

Yes - this is also how the BerkNET code works - which you will see in later versions of the BSD distributions.   I will say, we did run a few BerkNET lines to DZ ports on some of the smaller PDP-11s at UCB.   But again most of the larger systems and Vaxen were DH11s.

Anyhow, here we are in SimH land. I can pretty much configure any device simh supports. Can I get two instances talking over these virtual DCI/DZ lines and if so, how? and once they're magically connected, how do I start a conversation on one to the other? If I'm on A and want to talk to B (in the same room, so to speak) how do I dial up B and talk, copy a file, etc? telnet, rsh, rcp, uucp, mail, what's possible and what was common?

Please read the UUCP documentation included in V7 and/or find the O'Reilly 'UUCP In a Nutshell' book from '85 [it's quite possible Tim wrote the original version, maybe someone like Cindy Lamb - I forget and my copy is in storage right now.   FYI: I was one of the original reviewers].

The short form is: A DH11 port on each system is connected via fully pinned NULL modem. System B leaves a getty/login on the associated dedicated port on it's side [but System A does not have a login].  When system A wants to send data to B, it has been configured so that a specific tty on it's own system is the direct connection to B.  The UNIX uucico(8) program will open the tty, and the login from system B will appear to System A.    What is now called the expect(1) protocol will run [the program expect(1) was written being modeled from the original code in uucico].   System A will login as the uucp user to System B, and both will start running the uucico with the g protocol after configuring the line on each end to 8b no parity, 'raw mode' with calls to ioctl(2) on each system [the g is for the late Greg Chesson's protocol - BTW].    Files will then be exchanged. Finally System A will log out of system B, which will put a new getty/login on its line go back to awaiting for System A to try again.

Unless there are two dedicated lines [i.e. system A has a getty/login awaiting] system B is 'passive' and queues up all data until system A polls it.  

 

I'm comfortable with and willing to fire up and modify v6, v7, 211, 4.2, att3b2 svr2.0.5, etc. I also already know how to enable and configure the lines in simh as I mentioned above, it's the talking to each other that's been the challenge. I can use my host to login over telnet to these systems without issue.

RTFM 🤔   Really this is well documented -- start with the V7 docs.  I do think that the ORA book was the best, but most UNIX System Admin books from the day describe the set up process also.

Clem

[Will Senn]

Ah, "you could connect your simulated machines serial port to an actual

serial port, and then physically connect the two together, like the real

world back in the day." This is what I've been working on, on a single
machine, for another project and I like the "real world back in the day"
part. I'll pursue that a bit. If anybody's done uucp between machines,
I'd be interested to know that as well.

Will

[Heinz-Bernd Eggenstein]

Interesting, something similar is on my wish-list as well, I want to connect my PiDP-8 and my PiDP-11 over serial, which I think would not be historically incorrect :-). The PiDP-8 is currently driving an LED-dot matrix display ("ticker tape style", like PDP-8s used to drive big stadium scoreboards etc) which I can feed manually via the PiDP-8 console, but I'd like instead that the PiDP-11 is generating content for it.

So I guess the first step for all our projects would be to configure a simulated serial device in SIMH to attach to a real Raspi (USB) serial device (I've done that already and there are numerous threads in this group about it!) but in a way that BSD doesn't use it automatically as an endpoint for a login shell (so it could be used by cu or any other similar program) ,.....but....how??

Cheers

HB

[Johnny Billquist]

On 2022-01-21 17:34, 'Heinz-Bernd Eggenstein' via [PiDP-11] wrote:
> Interesting, something similar is on my wish-list as well, I want to
> connect my PiDP-8 and my PiDP-11 over serial, which I think would not be
> historically incorrect :-). The PiDP-8 is currently driving an LED-dot
> matrix display ("ticker tape style", like PDP-8s used to drive big
> stadium scoreboards etc) which I can feed manually via the PiDP-8
> console, but I'd like instead that the PiDP-11 is generating content for
> it.
>
> So I guess the first step for all our projects would be to configure a
> simulated serial device in SIMH to attach to a real Raspi (USB) serial
> device (I've done that already and there are numerous threads in this

> group about it!) *but* in a way that BSD doesn't use it automatically as

> an endpoint for a login shell (so it could be used by cu or any other
> similar program) ,.....but....how??

That's easy. Just don't have it in /etc/ttys
That file is what tells which terminals you'll get a login process
running for.

Johnny

> <https://groups.google.com/d/msgid/pidp-11/6c13265a-5bd5-414f-912e-b5a9fda727f5n%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/pidp-11/6c13265a-5bd5-414f-912e-b5a9fda727f5n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> >>
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/984d8dda-cdd3-4e4a-bf1e-433e9621af5bn%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/984d8dda-cdd3-4e4a-bf1e-433e9621af5bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Clem Cole]

I should add one more thing.  It's not in the original V7 UUCP, but if you search the USENIX archive the 'e' and 't' protocols are easy to add to uucico [it's a table - think the [bc]devsw table in the kernel. [I'm pretty sure both are in Taylor UUCP by default and maybe Honey-Dan-Ber, but it's not in the original code base].  Either of these will allow you to run uucico over a tcp socket. 

As for why would an admin do that is because with the change to uucico, you don't need an SMTP [or something like sendmail].  V7's mailer 'knows' about uucp site1!site2...!siten!user style addressing, not RFC 733/822 style [remember AT&T was on the ARPAnet].  So if you add the code to the uucico, the upper level works unmodified.   Let's just say that sendmail was a tad intrusive when it was released as part of 4.2BSD.  Also, getting an Internet connect was difficult in those days and quite expensive.  So my letting mail stay using UUCP style addressing it was fairly easy to add a workstation without a big administrative change over.

That said, once cheap broadband connections appeared, and since the SMTP Daemon for 4.2BSD was >>part<< of sendmail, sendmail and just using Internet style (flat addresses) became the default.

[Clem Cole]

On Fri, Jan 21, 2022 at 10:15 AM Will Senn <will...@gmail.com> wrote:

Ah, "you could connect your simulated machines serial port to an actual
serial port, and then physically connect the two together, like the real
world back in the day." This is what I've been working on, on a single
machine, for another project and I like the "real world back in the day"
part. I'll pursue that a bit. If anybody's done uucp between machines,
I'd be interested to know that as well.

Will

It has been. For UNIX's 50s anniversary a small 'usenet' clone was set up doing exactly this.  Again, follow my instrux, if you have real serial ports working with simh, it should 'just work.'

Clem

 

[Clem Cole]

On Fri, Jan 21, 2022 at 11:34 AM 'Heinz-Bernd Eggenstein' via [PiDP-11] <pid...@googlegroups.com> wrote:

So I guess the first step for all our projects would be to configure a simulated serial device in SIMH to attach to a real Raspi (USB) serial device (I've done that already and there are numerous threads in this group about it!)

Did you use a fully pinned serial port with all of the modem controls or just a 3-wire one.

 

but in a way that BSD doesn't use it automatically as an endpoint for a login shell (so it could be used by cu or any other similar program) ,.....but....how??

So Hayes style (inband dialing worked) later version of the UNIX TTY driver has two names for the device -- the inbound (/dev/ttyXX) device and the output (/dev/cuXXX) name. They differ in the minor number and code in the open routine for them both are linked.  The earlier version /dev/cuXX was the DN11 [which is also linked together, but I'm going to ignore all that for now - send me email off line and I'll explain how the phone system HW actually worked so you can read the code and see what happens but I do not believe you are trying to emulate a real Western Electric ACU].

When getty/login 'opens' /dev/ttyXX it sleeps awaiting the assertion of if the "He's alive" signal from the modem [DCD traditionally]  At that point it allows the open system call to complete and blocks any open of the /dev/cuXX device.  On the other hand, if the /dev/cuXX device is opened (by the cu or uucico programs) it will not wait for 'He's Alive' and will block the open of the companion /dev/ttyXX device and let the open call return.   

[Will Senn]

On 1/21/22 9:00 AM, Clem Cole wrote:

On Fri, Jan 21, 2022 at 1:41 AM will...@gmail.com <will...@gmail.com> wrote:

I get the feeling, reading old documentation, that unix systems did something similar to copy files around and to send mail from one system to another.

It is called UUCP [UNIX to UNIX Copy Protocol] and the USENET was created to exploit it.  The docs describing it are part of Seventh Edition in /usr/doc.

BTW: later implementations of UNIX could do IP over serial lines also ...  IIRC Scott Braden or one of his minions wrote the first version for the Berkeley IP stack in the mid-1980s.

Interesting. I've done IP over my mains - slow, but it worked.

 

What I haven't quite figured out is how to get instances to talk to each other. I figure I can probably use ethernet/tcp/ip with 211bsd and talk between those instances, but in my current view, that's cheating. In the real world, I'm guessing that folks had their pdp-11's sitting in a lab and those pdp-11's (or vaxes, etc) had devices (DCI is apparently ancient, so DZ's maybe)

As I have said before, the prefered interface for UNIX systems back in the day for both PDP-11s and Vaxen, particularly when running UUCP was the DH11 - although we used the implementation from Able Computer called the DMAX or DHDM - because it was much smaller and less expensive.  The prefered modem for UUCP was a Telebit Trailblazer  [which had the UUCP G protocol built in].  Note that the Able version of the DH could support 56K - I'm not sure the original DEC could go that fast [I never tried it on the few real DH11s I had access]. DZs and DLs and DC were two slow, lacked buffering and tended to drop characters at speeds over 120 cps.

Somebody oughta add DH support to SIMH :), but then I'd be needing a virtual Trailblazer / Courier / DN-11 / WE212 and autodialer (and phone system) to sit between them?

 

They would dial up a remote location and the reverse would be the case (wall to modem to dz to pdp-11)?

Correct except it was traditionally a DH port and Telebit not a DZ or a Hayes.  BTW: the v7 code, need a DN11 to do the dialing for the phone line and assumes a WE212 modem and their associated autodialer for the modem rack [see the docs].  Remember that Hayes style 'in-band dialing did not yet exist when UUCP was written in the mid'70s and when those unit did appear on the general market in the late 1970s, were considered was a bit of an anathema to the AT&T BTL/WE folks.

 

Also, by the late 1990s [after cheap Broadband Internet was available] and use of UUCP fell off, many of us replaced the Telebit's with Couriers [I still have two] which did not have the g protocol, but could do 56K with regular dial in. 

 At the same time, maybe the wires from the DCI/DZ on one pdp-11 could be attached directly to another pdp-11 on the other side of the lab.

Yes - this is also how the BerkNET code works - which you will see in later versions of the BSD distributions.   I will say, we did run a few BerkNET lines to DZ ports on some of the smaller PDP-11s at UCB.   But again most of the larger systems and Vaxen were DH11s.

I saw berknet in 4.2bsd, when I fired it up, interesting. Added to the list of never heard of it, but may need it later items.

Anyhow, here we are in SimH land. I can pretty much configure any device simh supports. Can I get two instances talking over these virtual DCI/DZ lines and if so, how? and once they're magically connected, how do I start a conversation on one to the other? If I'm on A and want to talk to B (in the same room, so to speak) how do I dial up B and talk, copy a file, etc? telnet, rsh, rcp, uucp, mail, what's possible and what was common?

Please read the UUCP documentation included in V7 and/or find the O'Reilly 'UUCP In a Nutshell' book from '85 [it's quite possible Tim wrote the original version, maybe someone like Cindy Lamb - I forget and my copy is in storage right now.   FYI: I was one of the original reviewers].

The short form is: A DH11 port on each system is connected via fully pinned NULL modem. System B leaves a getty/login on the associated dedicated port on it's side [but System A does not have a login].  When system A wants to send data to B, it has been configured so that a specific tty on it's own system is the direct connection to B.  The UNIX uucico(8) program will open the tty, and the login from system B will appear to System A.    What is now called the expect(1) protocol will run [the program expect(1) was written being modeled from the original code in uucico].   System A will login as the uucp user to System B, and both will start running the uucico with the g protocol after configuring the line on each end to 8b no parity, 'raw mode' with calls to ioctl(2) on each system [the g is for the late Greg Chesson's protocol - BTW].    Files will then be exchanged. Finally System A will log out of system B, which will put a new getty/login on its line go back to awaiting for System A to try again.

This sounds promising. I'll dig up the documentation and proceed with hooking up the connectors via simh for a test spin.

Unless there are two dedicated lines [i.e. system A has a getty/login awaiting] system B is 'passive' and queues up all data until system A polls it.  

 

I'm comfortable with and willing to fire up and modify v6, v7, 211, 4.2, att3b2 svr2.0.5, etc. I also already know how to enable and configure the lines in simh as I mentioned above, it's the talking to each other that's been the challenge. I can use my host to login over telnet to these systems without issue.

RTFM 🤔   Really this is well documented -- start with the V7 docs.  I do think that the ORA book was the best, but most UNIX System Admin books from the day describe the set up process also.

Clem

Oh yeah, RTFM :), totally. I am definitely going that route in tandem with asking the question. But here's a take on background (a little bit stream of consciousness, beware)...

I've got Nemeth's Unix System Administration Handbook out my table and the manpages pulled up in my virtual 4.2BSD on Microvax 3900... BTW, I really appreciate the information you and Johnny have shared on this topic. Things are definitely becoming clearer. Nemeth has a lot of detail, maybe too much for my pea brain.

Here's the thing... If I had my Microvax sitting here with manuals arrayed around me, and some inkling of what the various connectors were meant to connect to, it'd probably be patently obvious what the limitations were - on the wall, I have an rj11 jack, a coax connection, and 110 power connections. On my various laptops and desktops, I've got USB-c, USB-a, 9-pin serial, parallel ports, DVI, etc. I'd look on the back of the microvax and see what "could" be connected and I could try connecting them, looking online for the gaps in the manual, for adapters, and so on. Interestingly, I could open the vax and observe if there were any addons - cards or modules or what-nots (my macpro is built kinda like that with CPU modules and Graphic cards and such, as is my dell 755). I could go on ebay and order up devices that would do what I thought I wanted to do and I could then look up the modules in the manuals and learn more about them. I would still be limited to what connectors the machine had exposed, at the end of the day, but I'd be able to see and touch them, physically.

In the virtual world, there's some semblance of analogy, sure. The SIMH PDP-11/Vax/Vax780 handbooks kind of explain what's in the box, well they pretty much do explain, but, and it's a big but, the combinations of what can go in the box are nearly inexhaustible and can be 'realized' instantaneously without materially affecting the appearance of the box. A simple addition of an enable command can add 48, invisible to the naked eye, connection ports.  I think where I struggle the most is that, while in your minds eye, you can actually envision what was actually connected to what, how they were connected, and how they were accessed, I cannot. I have to rely on hypothetical models based on legends of how they used to work and then try to recreate the model on my trusty SIMH. When it's something local to the machine, this has a typical learning curve, which thankfully, has a direct analog in the modern world - how do I add a new NVMe PCIe M.2 ssd to my supposedly non-user upgradable mac. Read up, buy the ssd and an NGFF M.2 nVME SSD Adapter, plug stuff in, make the necessary configuration changes, et voiala, it works... or not. So, you say, add a DH (hypothetically), I pull up the SIMH PDP-11 manuals, find no reference to a DH device in my handbook and start looking for somebody who got it working... no luck, cuz, as you later tell me, it's not supported on my brand of simulated hardware. Next up DZ, or whatever. Same trick. Sure enough, my pdp11 supports DZ, as does unix, kind of, after a bit of tweakage, it's talking via telnet with a few oddities, but working (reminds me of the Cukoo's Egg, so I'll take it). So, that gets me thinking about maybe, just maybe having one hosted unix talk to another (not over TCP/IP cuz with the later OS's, even running on SIMH, that's too easy), but over something more primitive... and that's what brought me here today.

When I say, something more primitive, it may not be super clear that I only have a vague idea myself of what that means and it gets fuzzier and fuzzier as it gets closer and closer to the 1970's. I really appreciate the detailed answers y'all give... I don't understand it all as it applies to the simulated world, but I do learn, incrementally and eventually.

What I keep hoping is that somebody says - oh yeah, I run a couple of simulated vax 3900's at home and I use BSD 4.2 (what I'm currently playing with), or V7, or SysVr2, and they talk to each other like they did back in the day using uucp over serial (see nemeth for details on how that works) but in a nutshell, you need to add a DZ and however many lines you think you'll need to your vax'es. You also need to hook up the serial cables (null modem between, no special pinouts). Then follow nemeth (or whatever manual) to configure the two endpoints. I use uucico and uusend and it works great. Or, and this harks back to my fuzzy idea of more primitive, maybe uucp wasn't really the bomb back in the day, even though it's mentioned EVERYWHERE... oh, yeah, dude, just set up the serial-null modem-serial contraption like you already know how to do, and then the DZ's like we talked about, but kermit (vX.Y will build fine) works better for sending and receiving, and for remote login, you should be able to rsh in or telnet direct over serial (I wish). It's hard for me to guess what primitive means relative to the cushy ssh over tcp/ip world of today... other than through reading and asking for help from oldtimers who lived it. Sadly, sort of - everybody who lived this reality and are part of the active online world, tend to be heavy-weight hitters and know WAY more about EVERYTHING, hardware, software, os, and so on than your average programmer/retro enthusiast Joe (that's me) who likes to tinker and make things work that other folks though were dead.

I'm thinking we need a sim-retro-unix-enthusiast club for newbs. TUHS is more for reminiscing, SIMH is for hardcore simulation nerds, pidp11 is really for pidp11 users :), pdp11, retrocomp, and so on, are for people with real hardware. There's really nowhere, that I know of, where hobby sim unix users congregate, or is it that too niche, even in a world of 7 billion?

Anyway, off to trying the simh pdp-11's (running v7) with DZ's enabled and connected to the serial ports exposed by my usb-serial-null modem-serial-usb contraption hooked up to the two usb ports on my mac to see if I can configure and run uucb so I can maybe:

    mail -v ruby!joe

on emerald, and:

    mail -v emerald!will

on ruby...

Wish me luck!

Will

[Heinz-Bernd Eggenstein]

Hi!

Thanks for the hint about /etc/ttys

> Did you use a fully pinned serial port with all of the modem controls or just a 3-wire one.

her's my setup: I've got an external  Raspi  (*not* the one hosting pidp11) using just the RX/TX GPIO pins, those are then level-shifted with a little breakout board (more or less just a MAX232 chip), that one is connected with a null modem cable to a RS232-USB adapter  plugged into the Raspi hugging the PiDP-11 PCB. Logging in to the PiDP-11 via minicom via the serial line at 9600 baud, 7 bit,  works like a charm  and somehow feels "just right" :-).

All it takes in the boot.ini seems to be a

set dz enabled

set dz lines=8

attach dz -m 4000 ; the usual telnet over port 4000 access

attach -v dz  line =7,connect=/dev/ttyUSB0  ; so the last line is instead attached to the USB<>serial device, your device name may vary

Cheers

HB

[Johnny Billquist]

Don't worry too much about the DZ inefficiencies. Nor the limited modem
control of the hardware. I think you should be fine running them for
your UUCP playing. As long as you get any kind of serial port working,
you're probably good, and should continue down the rabbit hole with the
actual software and protocols you want to use instead of doing more work
on the hardware simulation level. (Heck, even a DL11 ought to be fine
for your needs here.)

But be aware that for UUCP, it's all about transporting files in a batch
mode. Be that just plain files or emails or whatever.

Any interactive work will either be by using tip, cu, kermit, or
something similar, and just communicating over the serial line, and
logging in to the remote system in a very similar fashion to a directly
connected terminal on that serial port.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/c32c74d8-bcb3-d10c-5183-7d17bffaac36%40gmail.com
> <https://groups.google.com/d/msgid/pidp-11/c32c74d8-bcb3-d10c-5183-7d17bffaac36%40gmail.com?utm_medium=email&utm_source=footer>.

[Clem Cole]

On Fri, Jan 21, 2022 at 12:39 PM Will Senn <will...@gmail.com> wrote:

Somebody oughta add DH support to SIMH :),

Try configuring the VH interface from the QBUS  - when it on a Unibus machine, >>I think<< it will be a DH.  Supposedly that got fixed, but I have not had a chance to try it.

 

but then I'd be needing a virtual Trailblazer / Courier / DN-11 / WE212 and autodialer (and phone system) to sit between them?

No.  just set them up as a hardwired with a null modem.

 I saw berknet in 4.2bsd, when I fired it up, interesting. Added to the list of never heard of it, but may need it later items.

Don't bother ... nothing really interesting there.  It was a hack ...

This sounds promising. I'll dig up the documentation and proceed with hooking up the connectors via simh for a test spin.

Do try to find the old ORA UUCP manual.

Oh yeah, RTFM :), totally. I am definitely going that route in tandem with asking the question. But here's a take on background (a little bit stream of consciousness, beware)...

I've got Nemeth's Unix System Administration Handbook out my table and the manpages pulled up in my virtual 4.2BSD on Microvax 3900... BTW, I really appreciate the information you and Johnny have shared on this topic. Things are definitely becoming clearer. Nemeth has a lot of detail, maybe too much for my pea brain.

Evi's book should have a section on setting up UUCP.

 

Here's the thing... If I had my Microvax sitting here with manuals arrayed around me, and some inkling of what the various connectors were meant to connect to, it'd probably be patently obvious what the limitations were - on the wall, I have an rj11 jack, a coax connection, and 110 power connections. On my various laptops and desktops, I've got USB-c, USB-a, 9-pin serial, parallel ports, DVI, etc. I'd look on the back of the microvax and see what "could" be connected and I could try connecting them, looking online for the gaps in the manual, for adapters, and so on. Interestingly, I could open the vax and observe if there were any addons - cards or modules or what-nots (my macpro is built kinda like that with CPU modules and Graphic cards and such, as is my dell 755). I could go on ebay and order up devices that would do what I thought I wanted to do and I could then look up the modules in the manuals and learn more about them. I would still be limited to what connectors the machine had exposed, at the end of the day, but I'd be able to see and touch them, physically.

Ouch -- becareful - DEC used a special connector for some of the serial lines.   It looks like a 6 wire RJ11 but the clip is on the side.   It's also short pinned and #$%^& disaster -- again why UNIX people used DH11's -- real 25 pin EIA RS-232C wiring and pinning.

 

What I keep hoping is that somebody says - oh yeah, I run a couple of simulated vax 3900's at home and I use BSD 4.2 (what I'm currently playing with), or V7, or SysVr2, and they talk to each other like they did back in the day using uucp over serial (see nemeth for details on how that works) but in a nutshell, you need to add a DZ and however many lines you think you'll need to your vax'es. You also need to hook up the serial cables (null modem between, no special pinouts).

That >>is<< what I told you.  Just make sure everything is properly wired and supported.  Then map it back to a DL11E for now.   Then if you can get the DH/VH working use that.

 

I'm thinking we need a sim-retro-unix-enthusiast club for newbs.

Maybe folks did set up a retro USENET for the 50th, but nobody came. so after the anniversary iot stopped being.   Really no need for it.

[Clem Cole]

On Fri, Jan 21, 2022 at 12:43 PM 'Heinz-Bernd Eggenstein' via [PiDP-11] <pid...@googlegroups.com> wrote:

Hi!

Thanks for the hint about /etc/ttys

> Did you use a fully pinned serial port with all of the modem controls or just a 3-wire one.

her's my setup: I've got an external  Raspi  (*not* the one hosting pidp11) using just the RX/TX GPIO pins, those are then level-shifted with a little breakout board (more or less just a MAX232 chip),

That's a 3-wire interface -- you are likely to have issues.

 

that one is connected with a null modem cable to a RS232-USB adapter  plugged into the Raspi hugging the PiDP-11 PCB. Logging in to the PiDP-11 via minicom via the serial line at 9600 baud, 7 bit,  works like a charm  and somehow feels "just right" :-).

Note quite actually - because DCD and DTR are not emulated the UNIX open system call for /dev/ttyXXX will not get the proper mapping as I explained. It will complete immediately and return to the caller, which will then send the login down the line.   In this case it will get buffered in the RPi HW (not thrown on the floor as it would have in real life).

i.e. You are getting a login, but frankly too early.    3-wire has been made to work on traditional HW for dedicated lines, but frankly it's a real PITA.  UUCP and modems really want that there -- remember UNIX is from the Phone Company.   The assumption in the SW is users are being connected with modems.  

As I said, experienced UNIX folks from the old days, want the real thing for serial HW. 

A suggestion is to get a USB to Serial that is fully pinned and then use with a real null modem - which has in effect 6 signal lines and one reference ground [at least 7 wires not 3 or 6].  I have a couple of these that are based on the FTCI chip set but >>I think<< the Prolific chip can be full wired.  An issue with the FTCI is it will not work @ 10cp properly - so ASR33 emulation is a tad funky.  I have not tried it in a while, but believe the Prolific ones will work properly at slow speeds.

[Will Senn]

On 1/21/22 11:52 AM, Clem Cole wrote:

On Fri, Jan 21, 2022 at 12:39 PM Will Senn <will...@gmail.com> wrote:

Somebody oughta add DH support to SIMH :),

Try configuring the VH interface from the QBUS  - when it on a Unibus machine, >>I think<< it will be a DH.  Supposedly that got fixed, but I have not had a chance to try it.

I'll give this a shot, next.

 

but then I'd be needing a virtual Trailblazer / Courier / DN-11 / WE212 and autodialer (and phone system) to sit between them?

No.  just set them up as a hardwired with a null modem.

 I saw berknet in 4.2bsd, when I fired it up, interesting. Added to the list of never heard of it, but may need it later items.

Don't bother ... nothing really interesting there.  It was a hack ...

OK. Thanks!

This sounds promising. I'll dig up the documentation and proceed with hooking up the connectors via simh for a test spin.

Do try to find the old ORA UUCP manual.

Done and done :).

Oh yeah, RTFM :), totally. I am definitely going that route in tandem with asking the question. But here's a take on background (a little bit stream of consciousness, beware)...

I've got Nemeth's Unix System Administration Handbook out my table and the manpages pulled up in my virtual 4.2BSD on Microvax 3900... BTW, I really appreciate the information you and Johnny have shared on this topic. Things are definitely becoming clearer. Nemeth has a lot of detail, maybe too much for my pea brain.

Evi's book should have a section on setting up UUCP.

Oh it does, and it's filled with terminology from a bygone era, but - with y'alls comments, I've got a pretty good idea of how that side of things will work, once I get the bits flowing.

 

Here's the thing... If I had my Microvax sitting here with manuals arrayed around me, and some inkling of what the various connectors were meant to connect to, it'd probably be patently obvious what the limitations were - on the wall, I have an rj11 jack, a coax connection, and 110 power connections. On my various laptops and desktops, I've got USB-c, USB-a, 9-pin serial, parallel ports, DVI, etc. I'd look on the back of the microvax and see what "could" be connected and I could try connecting them, looking online for the gaps in the manual, for adapters, and so on. Interestingly, I could open the vax and observe if there were any addons - cards or modules or what-nots (my macpro is built kinda like that with CPU modules and Graphic cards and such, as is my dell 755). I could go on ebay and order up devices that would do what I thought I wanted to do and I could then look up the modules in the manuals and learn more about them. I would still be limited to what connectors the machine had exposed, at the end of the day, but I'd be able to see and touch them, physically.

Ouch -- becareful - DEC used a special connector for some of the serial lines.   It looks like a 6 wire RJ11 but the clip is on the side.   It's also short pinned and #$%^& disaster -- again why UNIX people used DH11's -- real 25 pin EIA RS-232C wiring and pinning.

Funny. I'll be careful.

 

What I keep hoping is that somebody says - oh yeah, I run a couple of simulated vax 3900's at home and I use BSD 4.2 (what I'm currently playing with), or V7, or SysVr2, and they talk to each other like they did back in the day using uucp over serial (see nemeth for details on how that works) but in a nutshell, you need to add a DZ and however many lines you think you'll need to your vax'es. You also need to hook up the serial cables (null modem between, no special pinouts).

That >>is<< what I told you.  Just make sure everything is properly wired and supported.  Then map it back to a DL11E for now.   Then if you can get the DH/VH working use that.

I totally forgot that I was going to retry with the DL11E... gotta go back and redo that test. Thanks for reminding me.

 

I'm thinking we need a sim-retro-unix-enthusiast club for newbs.

Maybe folks did set up a retro USENET for the 50th, but nobody came. so after the anniversary iot stopped being.   Really no need for it.

Ha! Maybe we can get something going for the 60th.

Will

[Johnny Billquist]

On 2022-01-21 19:19, Will Senn wrote:
> On 1/21/22 11:52 AM, Clem Cole wrote:
>>
>>
>> On Fri, Jan 21, 2022 at 12:39 PM Will Senn <will...@gmail.com> wrote:
>>
>>
>> Somebody oughta add DH support to SIMH :),
>>
>> Try configuring the VH interface from the QBUS  - when it on a Unibus
>> machine, >>I think<< it will be a DH. Supposedly that got fixed, but I
>> have not had a chance to try it.
>>
>>
> I'll give this a shot, next.

Don't bother. The VH for the Qbus is the DHV11. Which is software
compatible with the DHU11 for Unibus. Which is *not* compatible with a DH11.
And yes, it also works on a simulated Unibus machine, if you have a
driver for the DHU11. RSX have that, as do 2.11BSD. But older Unixes
most likely do not.

The DU[UV]11 do have modem control, but it's basically just giving
software the bits, and is not handling things like flow control in
hardware. It's designed to mostly work with full duplex modems, and to
easily handle dial up lines. Nothing beyond that.

The DH[UV]11 is a nice interface. It does DMA on output, and have good
buffering on input, and can run up to 38400 bps.

Johnny

[Clem Cole]

One other thought -- I'm not sure if minicom on the RPi will do this, but some of the serial applications on the Mac [Serial.app and Serial Tools.app] and similar ones on a PC will. If you program you are using will allow you to monitor and control the modem pins from the application program, connect to the device without asserting DTR [i.e. the I'm alive pin] with your user application.   Now set the baud to something slow (10 cps if you can, but 30 cps is probably good enough to see this in action).

connect to that serial port to the remote serial port thru the null modem.  Because DTR is not (yet) asserted nothing should be seen coming back from the remote side.   On the console of the Unix side, do a ps -lax and you should see a getty process waiting in the open system call [that's the number called the wchan field -- map it back the OS symbol table, and you will see its maps to the sleep call in the tty handler in open] - note the value of the pid. [You can go to TUHS and download the tty handler for v7 if you have not already].

Now on the Mac/PC side separately assert DTR and you should then see the ';login: ' prompt be sent from the remote side at whatever speed the serial port on the UNIX box is configured. Now look again on the UNIX console, and find the same pid but note that the process will have changed to 'login' from getty and it will be waiting for a different wchan/address - which is in the tty handler in the read call, not the open call.

Now de-assert DTR, wait a little and look again - you'll see getty again waiting in open again on that original wchan value (but with a new pid).

Re-assert DTR and magically you will get a new login process but with that same new pid.

What's happening is when DTR is asserted on the Mac/PC side it is seen on the remote side a DCD - i.e. the "he's alive" signal.   So as I explained UNIX says -- "the connected modem told me that it's alive, so UNIX can proceed from the sleep" so the open system call finishes up, the user mode getty process returns and then does an exec(2) of the login process which hangs awaiting the user to type in their username.    When DTR is dropped - which means UNIX sees DCD drop (or the remote just told me that he's NOT alive), UNIX will send a SIGHUP to the pid [which is current login] - which means it will die.  The UNIX Init process (pid 1) will see the death of the login process and now fork a new pid and exec a new getty on it.

[Heinz-Bernd Eggenstein]

> One other thought -- I'm not sure if minicom on the RPi will do this, but [...]

I understand what you are saying but I'm not sure how this applies to my setup. Even tho minicom can theoretically control DTR, the host that the minicom is running on doesn't connect the DTR line in the cable, it's really just a three wire connection. So whatever I tell minicom to do with DTR is inconsequential. I'm sure that 2.11BSD on the PiPD-11 side sees a DCE signalling it is alive (as it allows me to login), but I'm not quite sure which layer adds this signalling, perhaps SIMH's DZ implementation or the USB-to-RS232 driver on the Raspi on the PiDP-11 side. But should I care? (It works for me.)

As an aside, I think there is also a way in 2.11BSD to configure a line connecting via a DZ11 to force pretending  a carrier was detected (by setting a certain bit in the minor device number, see "man dz"). So either way, three wire connection should not be a problem, right? Or am I missing something here?

Cheers
HBE

[Clem Cole]

Suit yourself but Yes I think you are missing something.  3 wire connections for uucp are terribly unreliable and you are working against the grain if you insist. I have explained what is happening in the Unix kernel and how uucico works with the kernel and assumes it talking to a modem.  Thus why 3-wire is not recommended. 

If your hardware only has 3 wires you are highly like to run into a number difficult issues.

My suggestion is that start with a different usb to serial device.  Get one based on the FTCI chip and make sure it’s set up correctly to support all the modem control pins on a basic RS-232C just like what is provided DL11 or DH11 serial port.  And make sure your host OS follows gives simh it’s expected behavior so Mark can model the order final HW appropriately. 

Remember that on real HW - unix people generally tried to stay away from the 3-wire hack because of start up/ hang up issues (and we also stayed away from using DZs for performance and they too are sub pinned compared to DL11E or DH11 - although under emulation it’s not clear if the performance issue will be as much of a problem as it was the in real life).  

The original V7 Nowitz uucp (described in the V7 docs) was designed for modems based links were DCD and DTR is used to control the sequencing of each part of the start up protocol and the chat session.  Also CTS/RTS is used for flow control as uucp’s G protocol relies on a raw 8 bit path where all values are used.  This becomes more important later when speeds got up to 56k.  The original uucp will work on dedicated wires but it assumes fully pinned with a null modem. 

That said, the Later tty drivers and many many uucico hacks later some people did mange to make 3-wire work but to honest it was just cheaper and easier to use fully wired cables and a full null modem. 

But The point is if you want to run base V7 or 4.1BSD the code on simh you will have to supply Unix fully pinned HW if you want the system to behave as it was designed.   So If you want to model the way we ran it - follow my suggestions which are based on best known methods from those days by those of us that ran large uucp sites on 11/70s, 750s and 780s. With those kernels and versions of the application code.  If you try to deviate you may get it work to some level but you are likely to run into a number a issues - particularly since emulation is masking so much from reality and trying to figure out where fault is being injected can be difficult.

I’m telling you what we expected at the Unix layer when we wrote that code in the mid/late 1970s [and yes I was there 😎]. So If your emulation does not provide what we expected - the code we wrote may not work as you desire. 

--

You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/ec579019-bdb0-469f-99b9-49bc779bbf36n%40googlegroups.com.

--

Sent from a handheld expect more typos than usual

[Heinz-Bernd Eggenstein]

> Suit yourself but Yes I think you are missing something.  3 wire connections for uucp are terribly unreliable and you are working against the grain if you insist.

I see, but I wasn't talking about uucp at any time  (remember I'm trying to connect a PiDP-8 (!!!) and a PiDP-11) , nor was the original message starting this thread (as it was reminiscing about using a dialup connection into a VMS system to do **interactive** stuff...and then the uucp tangent started :-) ).  But the original question was (quote)

>Anyhow, here we are in SimH land. I can pretty much configure any device simh supports.

>Can I get two instances talking over these virtual DCI/DZ lines and if so, how? and once they're magically connected,

>how do I start a conversation on one to the other? If I'm on A and want to talk to B (in the same room, so to speak)

> how do I dial up B and talk, copy a file, etc? telnet, rsh, rcp, uucp, mail, what's possible and what was common?

So this would be also about things like kermit I guess, and interactive shells, rather than the uucp driven once-in-a-while, behind-the scenes , machine-to-machine communication that this thread has since drifted to. So before going into the dark long rabbit hole of uucp, maybe this thread should take a step back and discuss the first layer of the problem which is connecting two instances of simulated '70s comps via serial line in a useful (and fun) way. Just my two cents.

Cheers

HB

[Clem Cole]

On Sat, Jan 22, 2022 at 8:12 AM 'Heinz-Bernd Eggenstein' via [PiDP-11] <pid...@googlegroups.com> wrote

So this would be also about things like kermit I guess, and interactive shells,

It's true for all serial ports - particularly Unix based ones.  As you have discovered some pieces of software don't care/are less at issue, but others do/are.  SW with start up sequences (like the uucico chat scripts) are particularly susceptible to failures if the line protocol is not followed -- particularly as the speeds get faster.  Will Senn asked about setting up uucico (uucp subsystem). I answered. But what I said is just as applicable to other programs. The question is does your SW care about the start up sequence for the serial port or not.   The key is that if it's an old piece of SW, written when those specs were the norm, it very likely could.  If you try to cheat from the way it was originally designed because you saw the cheap work for one set of programs, does not make the cheat right or that you should expect it to work all the time -- which was my point -- you could (probably are likely) to see failures when you least expect it.

FWIW: ASR33 used 20ma current loop and did not care about the modem control [it did not have it].  ASR33's were 10cps and frankly the slow line speeds mask a lot of the start up sequence issues.   The 3/4-wire trick was left over from 20ma and people had been using traditional phone 2 pair phone wire to set up terminal rooms [IIRC McNamara talks a bit about this in his chapter 'how far/fast'.]   With wide spread use of modem banks, the need to have the EIA control signals became apparent as the line startup sequence needs became more important.  Plus faster line speeds just made the issues more frequent, although on a dedicated terminal, it often (usually) did not matter.

Can you get around them with tricks like N-second delays, sending break chars and the like? Sometimes yes - history shows that's often "good enough" -- and people did use those tricks in the old days too [many kermit implementations, for instance, has a bunch of them programmed into it].  But if you want to emulate what was expected and ensure things should "just work;" it's a smart idea to not try to cheat on the wiring 🠪 particularly as Will has admitted, many of these types of technical details are all issues that occurred and needed to be solved before he was born. As their use fell away, the reasons why they exist were forgotten.

I on the other hand, being an old guy, lived many of them and worked through and helped to some some of them.

The bottom line is that those pins are there for a reason [which I explained how UNIX uses them - can not speak for VMS, but as a ex-DECie my experience was that Cutler, Hustvedt and Lipman tended to follow the EIA specs pretty close too and I expect McNamara and the folks in Data Comm group would have complained].   The bottom line is that >>some<< system and user mode SW expects them to have a defined behavior.  I described it.

Now you know what is occuring, how and why it works the way it does -- you can choose to use the information or not.

Clem

[jon....@gmail.com]

I have written guides on getting UUCP set up on v7 Unix and 2.11 BSD. These only cover getting UUCP communication set up between the emulated system and the host Pi, with the host system placing the call (and can fairly easily be extended to any modern system on your LAN being the one that communicates with the emulated system). I haven't done anything with hardware as I don't have more than one PiDP-11 system. It should give good information on setting UUCP up on the guest, though.

My guides can be found on github at:

https://github.com/jwbrase/pdp11-tools/tree/master/howtos

I've also proposed a "Usepi" network: several people have expressed interest if such an endeavor gains critical mass, but are cautious about putting effort into it only for it never to get off the ground, see this thread:

https://groups.google.com/g/pidp-11/c/o7sfURASc8I/m/mhR3WWTkBAAJ

[will...@gmail.com]

Yeeha! I'm gonna have to give it another go, this weekend. Thanks for putting these together.

Will

[Regan Russell]

Hi,
Greetings from Sydney Australia.
As far as serial networking goes... 

I used SLIP in the early 1990s, I think between a DECstation 3100 and a Linux 0.99pl13 machine.
Then I got coax and the BNC T connectors.
A quick google came back with:
https://www.linuxjournal.com/article/2820
https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol

I vaguely remember other serial options like PPP

Hope this helps.

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/edc87b80-1be8-4c9e-9428-dbc9a70e1492n%40googlegroups.com.

--

All the best,

Visit Pymblesoftware.com.au

[D Gillies]

I was in the group at MIT that invented SLIP in the early 80s, it was MIT Lab For Computer Science CSC/CSR group (5th floor at 545 tech square, Cambridge MA).  Our group wrote the earliest PC Internet suite, PC/IP.  You dialed into a remote computer, logged in, got a shell and started the SLIP program on the remote end.  SLIP is simply a framing protocol it used a well known byte to indicate the end of a packet (which gets quoted if it shows up in an actual packet - really simple).  Then you start a SLIP on your local machine to send data over the serial port.  The problem with SLIP was that it wasn't dynamic you had to configure a static IP address on the shell computer and you had to configure the same static IP address on your local computer and SLIP acted as a transparent bridge.  You might even have needed to program ARP and the routes on both ends before starting it on the remote computer.  I still have contact info for John Romkey who was the author of SLIP.

https://en.m.wikipedia.org/wiki/John_Romkey

PPP (point to point protocol) was a big enhancement it would do all those things above. It could allocate an IP address from a pool on the remote computer and would authenticate the person dialing in and then like DHCP it would assign you one of the dynamically allocated IP addresses and would set up ARP spoofing and routing default routes.  The ISP could set PPP as the login she'll on the modem serial port, in server mode.  

In 1995 I worked at a company called Empac International with a software web-managed UNIX invented at BBN, and we sold a CD which turned any PC into a $10,000 ISP machine with as many as 256 octopus ports.  I tuned a very popular open source PPP called IIJ PPP to work with this computer.  IIJ was a big ISP in Japan and it stood for internet initiative of Japan.  With my changes you could program a web page to dial on demand when a packet arrived at your web server so that a company could have a dial on demand internet attachment point with email, webserver, router (a big deal Cisco was charging thousands for these) and a file server functionality - pretty cool - on a cheap FreeBSD PC!  We used to brag that we could make any idiot into an ISP I'm not sure that was a good thing!   Jordan Hubbard came to visit us when we modified FreeBSD Unix to start without the internet!  UNIX was pretty Internet-dependent by then!   

- Don Gillies

Palo Alto, CA