Post by Hittner, David T (IS)I do agree that 10/20 networking would be a desirable goal.
We did have the KMC/DUP working in SimH for both the -10 and -20 a
couple of years ago - there were some loose ends between the KMC
emulation and the DUP emulator that were open when I was diverted. It
isn't a simple device, and it was emulated using a hybrid model of a KMC
with private APIs into the DUPs. It knows it's talking DDCMP.
Using a VAX (or an -11) as a way station provides a path to the IP world.
Post by Hittner, David T (IS)You could modify an existing SIMH device of one of the DECNET-supported point-to-point network device interfaces already supported by TOPS to 'fake' the point-to point link over Ethernet by wrapping the data in an Ethernet packet and filtering the Ethernet traffic down so that it looks like a point-to-point link.
Wrapping ethernet onto a point-to-point link won't work well.
point-to-point links and broadcast links are quite different; DECnet
knows the difference at the circuit and routing layers. It would be a
LOT less effort to finish & debug UNASER. (Speaking as the author of
UNASER, the person who made TOPS-10 support DECnet Phase IV & someone
who has debugged every level of the DECnet protocol stack.)
Adding LAT support to DEUNA is easy - once one has DECnet Phase IV.
TOPS-10 already has a LAT driver, and it knows how to talk to NML and
the DECnet circuit interfaces. Except for the small matter of running
out of exec memory in 7.04. 7.03 would be easier, as I had DECnet code
in a pseudo-section then.
The good news is that finishing UNASER means there are no timing loops
to worry about; that is, considering what all else needs to be fixed,
any of those bugs would be lost in the wash.
IP would not be trivial. DEC had no TOPS-10 protocol stack for that,
and no utilities. It could be done in user mode with a UUO interface to
the circuit. But I'd stop at DECnet (+maybe ANF-ethernet & LAT). It's
easy enough to use a VAX as a waystation to IP... In fact, one could
adapt the Phase III PMR library on VAX to proxy connections to IP. Just
a small matter of translating DAP to FTP; NRT to Telnet etc on the fly ...
Trying to port TCP utilities to the -10 would be non-trivial. Somewhere
there IS a C compiler for the -10. But 36-bit words; 6, 7, 8 & 9 bit
chars; location 0 being a valid AC address and a few other endearing
attributes of the -10 do not make porting easy. (Although the C
language in theory can deal with it.) That compiler did not generate
very good code, and there wasn't much of an RTL. You don't want to go
there. Really. You could go thru the -20 utilities - yes, there was
mail, FTP, telnet, DNS - and convert all the command JSYS to GLXLIB and
all the IO JSYSs to UUOs. (MS mail would be easy as DECnet/ANF version
was ported to the -10; the others, projects.) You're talking a serious
project here.
IP for TOPS-20 would be easier - except that there was no ethernet
support in Phase III. And the KS TOPS-20 stopped there. One could
emulate an AN22, which is yet another KMC-11 + microcode. Doc for that
is surprisingly hard to come by. It's not a simple device.
I really was on the the easiest path when I started UNASER....t'wasn't a
random choice.
This communication may not represent my employer's views,
if any, on the matters discussed.
Post by Hittner, David T (IS)As the original writer of the SIMH DEUNA device, I concur with Tim. If there had been a TOPS 10/20 DEUNA driver, I would have tried to test it during the SIMH DEUNA device development, but Tim, Zane Healy, Fred van Kempen, and others indicated that a production DEUNA driver did not exist, only a few partially-tested hacks. :-(
I do agree that 10/20 networking would be a desirable goal.
1) You can add a DEUNA driver to the TOPS OS to use the existing capability of the SIMH DEUNA Ethernet device
Pros: Could support protocols other than DECNET (IP, LAT, etc.), better performance, more 'standard' implementation
Cons: driver may not be easy portable to other 10/20 OS's, simultaneous driver/device debugging, custom driver must be added to each 10/20 OS install
or
2) You could modify an existing SIMH device of one of the DECNET-supported point-to-point network device interfaces already supported by TOPS to 'fake' the point-to point link over Ethernet by wrapping the data in an Ethernet packet and filtering the Ethernet traffic down so that it looks like a point-to-point link. Theoretically, no OS debugging would be required, but in practice SIMH device debugging tends to require walking the OS code to see the simulated device interactions. You might need to add some data buffering in the SIMH device so that the TOPS OS doesn't lose data due to service timing loops - Ethernet can be wicked fast compared to the speed of the old timing loops.
Pros: no changes required to existing 10/20 OS drivers for DECNET III/IV, single device to debug
Cons: possible timing loop data loss issues, more complex SIMH device behavior, not easily expanded for non-DECNET network protocols
If you're interested in pursuing the latter, remember to debug the Ethernet connections on a hard wire; wireless Ethernet has many implementation subtleties that make it difficult for non-IP protocols like DECNET. I might even be able to provide some midnight project help with either of these, although like Tim, I can't promise how much time might be available.
Dave
-----Original Message-----
Sent: Sunday, April 26, 2015 6:32 AM
Subject: EXT :Re: [Simh] PDP-10 simulation: DEUNA support help needed
Although I started to write a TOPS-10 DEUNA driver as a midnight project, I never finished it. So far as I know no one else did, although the configuration support did find its way into the monitor.
Sadly, there were (and are) only so many midnights, but the supply of projects is infinite.
DECnet-10 supports ethernet on the KL, but the code for broadcast devices (ethernet) is not conditionally assembled. So in theory, it should be possible to write a (or complete my) driver. That's on my list of projects - unfortunately, quite far down the list. It would be very nice to have. Note also that there is code to support ANF-10 over ethernet; that also needs to be hooked in. Besides the driver proper, there are also tables that should be setup for NML. The KDP/DMR didn't
- but they have out-of-band monitoring and are much simpler to debug.
SimH provides the hardware, but obviously that has never been tested.
As it works on the PDP-11/VAX, I don't expect issues on the -10. You should be able to set an address via SimH - for the real hardware, I picked something convenient (but I don't remember what it is). The -10 doesn't autoconfigure its Unibus (although SimH has code to do so); all addresses are fixed. You'd put the address assignment (on UBA3) in pdp10_defs.h & see that it finds its way to the DIB - see auto_tab in pdp10_ksio.c. Or just use set address.
The bottom line is that any support that you see in the monitor is illusory; either you wait for real support to find its way up to the top of my (or someone else's) project list, or take it on yourself :-)
Sorry.
P.S. Before someone asks: TOPS-20 never had DEUNA support, and I never started that project. Early DECnet Phase IV development was on TOPS-20. It did use a 3COM ethernet board on the KS (this before DEUNA was available & long before the KLNIA). That driver was discarded before the first TOPS-20 release of Phase IV, as the -20 group decided not to support the KS. There was never a -20 DEUNA driver.
This communication may not represent my employer's views, if any, on the matters discussed.
Post by Cory SmeloskyHello,
I'm (attempting) to get DEUNA support operating in the KS10 simulation
(likely incorrectly).
I'm running in to some TOPS-10 issues assembling a monitor...does
anyone have a pre-genned TOPS-10 disk set up for DECnet on a KS10 with
ethernet I can use to test...if I even get that far?
* Shows up in SHOW DEV
* Has a vector
* Links correctly
* Can be enabled and attach to a host device
...and that's about all I have managed. Doesn't have an actual UNIBUS
address which is a LITTLE BIT OF AN ISSUE.
