On Thu, Aug 20, 2009 at 05:30:25PM -0400, Jason Stevens wrote:
It was pretty simple too...!
I kept my notes here:
http://gunkies.org/wiki/Networking_with_SIMH#HECnet
And as you can see... it was pretty easy.
Oh, that's quite cool!
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Excerpt of message (sent 20 August 2009) by Gregg Levine:
...
Hello!
I have here on 5.25 floppy the binaries for the other DEC networking
programming, it is the one who's card which wears two discrete
connectors.(Which I've been trying to find with limited success.)
At one time I had a binary which would change that to update it to
accommodate an Ethernet card, the Racal thing. I don't suppose you
would happen, Paul, to have a copy of DECnet/DOS on floppies?
No, I don't have any DECnet bits apart from some pieces of DECnet/E.
paul
On Thu, Aug 20, 2009 at 1:56 PM, Paul Koning<Paul_Koning at dell.com> wrote:
Excerpt of message (sent 20 August 2009) by Zane H. Healy:
On Thu, 20 Aug 2009, Paul Koning wrote:
Excerpt of message (sent 20 August 2009) by Zane H. Healy:
Ditto, though last I tried Linux DECnet was in the late 90's. It's
also worth mentioning that DECnet/E seems to have trouble coexisting
with just about anything, so DECnet/Linux isn't alone. :-)
Oh really? That wasn't our experience when we built it...
paul
I suspect it is one of those "version creep" sort of things. I've noticed
that VAX/VMS V5.5-2 is much happier talking with things such as RSTS/E, and
IIRC even RSX-11M+ than say OpenVMS V8.3. Of course my secondary OS is
OpenVMS (primary is Mac OS X), so my comments are coloured a little by it.
I could believe that. Once PDP-11 support was sold off, it would make
sense for interoperability with those operating systems to suffer.
Another area I've had problems with DECnet/E is with the network hardware
itself, and software installation. It is incredibly touchy about your
network switches. I had one switch that every other OS and network stack I
through at it would work, not so DECnet/E, in fact I had to put the PDP-11
on a hub to be able to even install it, as I couldn't do the install when
attached to the switch. The other installation problem was that the
distribution kit doesn't like living on a 4mm DAT. You can install RSTS/E
from 4mm DAT, but as near as I can tell, DECnet/E needs to live on a TK50
(or I assume 9-Track).
I can't understand that. RSTS just installs from plain old tape.
Some kits are backupsets (ANSI labeled), there may be some DOS labeled
tapes (meaning the drive you have must be able to handle 14 byte
blocks) and the RSTS bootable OS install table is a mixed format tape
(first DOS then ANSI).
As for touchy about network switches, in what way? RSTS -- probably
like most PDP-11 systems -- doesn't have much memory for network
buffers, so if your switch bunches the traffic together then that
might cause trouble. But apart from that it's just plain old
Ethernet. The only OS I ever heard of having Ethernet issues was
DECnet/DOS when used with a 3C901 NIC -- which has only a single
buffer so it would croak on back to back packets. (The solution to
that was "buy a real NIC".)
It has been several years since I've been able to play with it much, has
anyone managed to install DECnet/E on an emulated system? About 6 years ago
it refused to install on either E11, or SIMH for me (of course at that point
SIMH networking code was very primitive). IIRC, that is long enough ago I
was using a different switch than the one that gave me so many problems.
Apart from my stint in RSTS development, which by now is almost 25
years ago, I've mostly run RSTS and DECnet/E on E11. It's been a
while since I did that, but it certainly worked in the past; that's
how I did the interop testing with DECnet/Linux. I also at one time
got DECnet/E running on a Pro-380, DDCMP only unfortunately. Some day
I may write a DECNA driver... :-(
paul
Hello!
I have here on 5.25 floppy the binaries for the other DEC networking
programming, it is the one who's card which wears two discrete
connectors.(Which I've been trying to find with limited success.)
At one time I had a binary which would change that to update it to
accommodate an Ethernet card, the Racal thing. I don't suppose you
would happen, Paul, to have a copy of DECnet/DOS on floppies?
--
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature was once found posting rude
messages in English in the Moscow subway."
Phase III. Ethernet support was added in RSTS V9.4, or thereabouts.
That was Phase IV, end node and level 1 routing only.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Thursday, August 20, 2009 6:29 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Who's emulating?
Yeah. WIth RSTS/E V8, asynch DDCMP is out of the quesion.
Does it support ethernet?
Hmm, what phase is it?
Johnny
Mark Abene wrote:
Unfortunately, given my preference to using RSTS/E v8, I must use
DECnet/E v2.0. Those DECnet drivers only support a DMC or DMR
device
(seen as "XM" in RSTS), or a DMP or DMV device (seen as "XD" in
RSTS).
Based on what you're saying, the patch would not solve this problem?
Paul Koning wrote:
Excerpt of message (sent 20 August 2009) by Mark Abene:
Serious? Are you actually emulating a DMC11? I'm intrigued...
Yes.
Or rather, the terminal driver contains an implementation of the
DDCMP
protocol. So it can talk to async DDCMP devices -- just as RSX did
for years. Until V10, DECnet/E only did DMC/DMR type DDCMP
devices.
On a Pro, which has a USART (not UART) console port, it even speaks
sync DDCMP if you want so it can talk to a DMC or DMR (and that
works,
I tested it). On other PDP-11s it will use any of the async lines
and
speak async DDCMP.
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
The async DDCMP driver is a whole new driver, and it depends on the
terminal driver structure that exists in the later versions of RSTS. I
don't remember when that was put in place, but I'm pretty sure it wasn't
there in V8.0. I did the original work for RSTS V9.6, but that was just
a private prototype.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Mark Abene
Sent: Thursday, August 20, 2009 6:05 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Who's emulating?
Unfortunately, given my preference to using RSTS/E v8, I must use
DECnet/E v2.0. Those DECnet drivers only support a DMC or DMR device
(seen as "XM" in RSTS), or a DMP or DMV device (seen as "XD" in RSTS).
Based on what you're saying, the patch would not solve this problem?
Paul Koning wrote:
Excerpt of message (sent 20 August 2009) by Mark Abene:
Serious? Are you actually emulating a DMC11? I'm intrigued...
Yes.
Or rather, the terminal driver contains an implementation of the
DDCMP
protocol. So it can talk to async DDCMP devices -- just as RSX did
for years. Until V10, DECnet/E only did DMC/DMR type DDCMP devices.
On a Pro, which has a USART (not UART) console port, it even speaks
sync DDCMP if you want so it can talk to a DMC or DMR (and that
works,
I tested it). On other PDP-11s it will use any of the async lines
and
speak async DDCMP.
paul
I seem to remember ethernet not being added until v10.
Johnny Billquist wrote:
Yeah. WIth RSTS/E V8, asynch DDCMP is out of the quesion.
Does it support ethernet?
Hmm, what phase is it?
Johnny
Mark Abene wrote:
Unfortunately, given my preference to using RSTS/E v8, I must use
DECnet/E v2.0. Those DECnet drivers only support a DMC or DMR device
(seen as "XM" in RSTS), or a DMP or DMV device (seen as "XD" in RSTS).
Based on what you're saying, the patch would not solve this problem?
Paul Koning wrote:
Excerpt of message (sent 20 August 2009) by Mark Abene:
Serious? Are you actually emulating a DMC11? I'm intrigued...
Yes.
Or rather, the terminal driver contains an implementation of the DDCMP
protocol. So it can talk to async DDCMP devices -- just as RSX did
for years. Until V10, DECnet/E only did DMC/DMR type DDCMP devices.
On a Pro, which has a USART (not UART) console port, it even speaks
sync DDCMP if you want so it can talk to a DMC or DMR (and that works,
I tested it). On other PDP-11s it will use any of the async lines and
speak async DDCMP.
paul
Yeah. WIth RSTS/E V8, asynch DDCMP is out of the quesion.
Does it support ethernet?
Hmm, what phase is it?
Johnny
Mark Abene wrote:
Unfortunately, given my preference to using RSTS/E v8, I must use
DECnet/E v2.0. Those DECnet drivers only support a DMC or DMR device
(seen as "XM" in RSTS), or a DMP or DMV device (seen as "XD" in RSTS).
Based on what you're saying, the patch would not solve this problem?
Paul Koning wrote:
Excerpt of message (sent 20 August 2009) by Mark Abene:
Serious? Are you actually emulating a DMC11? I'm intrigued...
Yes.
Or rather, the terminal driver contains an implementation of the DDCMP
protocol. So it can talk to async DDCMP devices -- just as RSX did
for years. Until V10, DECnet/E only did DMC/DMR type DDCMP devices.
On a Pro, which has a USART (not UART) console port, it even speaks
sync DDCMP if you want so it can talk to a DMC or DMR (and that works,
I tested it). On other PDP-11s it will use any of the async lines and
speak async DDCMP.
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Jason's "patch" is actually playing ethernet for you. So, even without any separate machine with the bridge program on, or even without a real ethernet port on your machine, your simh can have a simulated ethernet, which hooks into my bridge program, making the simh machine appear to be on the virtual ethernet segment created by the bridge program.
Johnny
Mark Abene wrote:
Serious? Are you actually emulating a DMC11? I'm intrigued...
Jason Stevens wrote:
I had a patch somewhere for SIMH to talk directly into hecnet.. So it'd
clear your first hurdle, although there isn't much I could do about the
2nd....
On Thu, Aug 20, 2009 at 5:23 PM, Mark Abene <phiber at phiber.com> wrote:
While I have been running three public access emulated systems for a few
years now (TOPS-20 on KLH10, RSTS/E v8 and 2.11BSD on SIMH), there are
several problems with me getting on HECnet. First, my host server is
FreeBSD, and FreeBSD doesn't support multicast on tap network
interfaces, nor have I heard about any plans to. Which means no DECnet.
At some point I plan to migrate my emulators over to a beefy linux
server, and linux does have the necessary support. Second problem, is
that SIMH doesn't support any DDCMP-aware network devices, which means
that even if I solve the first problem (it'll allow me to get TOPS-20 on
DECnet), I don't have any way via SIMH to get DECnet/E working on my
RSTS system. Call me crazy, but I just don't think I'll be paying 4,000
dollars for E11/linux. So that's out.
-Mark
Marc Chametzky wrote:
The recent downtime thread has sparked much discussion about a variety
of DEC (and perhaps some Compaq) hardware, but who among us is living in
HECnet lives in software?
I have two systems nominally connected to HECnet, both emulated. I have
the SIMH VAX emulator running VMS (DUSTY) and I have Mark Crispin's
Panda system running TOPS-20 (CALHAN). Both of these are running as part
of virtual Unix systems (one Linux, one Solaris) on a single ESXi box.
I've also played with a couple Alpha emulators from Stromasys
(CHARON-AXP on Windows and CHARON-AXP NCE on Linux), but I've not set up
a more permanent virtual Alpha system.
I'd set up a virtual PDP-11 to play with as well, perhaps running
RSTS/E, but it's been far too long since I've used a PDP-11 to remember
how to set it up and maintain it. Same thing with VM/370 or z/VM on
Hercules. It's sad how much I've forgotten over the years.
--Marc
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Unfortunately, given my preference to using RSTS/E v8, I must use
DECnet/E v2.0. Those DECnet drivers only support a DMC or DMR device
(seen as "XM" in RSTS), or a DMP or DMV device (seen as "XD" in RSTS).
Based on what you're saying, the patch would not solve this problem?
Paul Koning wrote:
Excerpt of message (sent 20 August 2009) by Mark Abene:
Serious? Are you actually emulating a DMC11? I'm intrigued...
Yes.
Or rather, the terminal driver contains an implementation of the DDCMP
protocol. So it can talk to async DDCMP devices -- just as RSX did
for years. Until V10, DECnet/E only did DMC/DMR type DDCMP devices.
On a Pro, which has a USART (not UART) console port, it even speaks
sync DDCMP if you want so it can talk to a DMC or DMR (and that works,
I tested it). On other PDP-11s it will use any of the async lines and
speak async DDCMP.
paul
Excerpt of message (sent 20 August 2009) by Mark Abene:
Serious? Are you actually emulating a DMC11? I'm intrigued...
Yes.
Or rather, the terminal driver contains an implementation of the DDCMP
protocol. So it can talk to async DDCMP devices -- just as RSX did
for years. Until V10, DECnet/E only did DMC/DMR type DDCMP devices.
On a Pro, which has a USART (not UART) console port, it even speaks
sync DDCMP if you want so it can talk to a DMC or DMR (and that works,
I tested it). On other PDP-11s it will use any of the async lines and
speak async DDCMP.
paul
