DL10 documentation

Phil Budne phil at ultimate.com
Tue Jan 9 18:56:55 CST 2018


> Ah, right you are: I just assumed from the name (without checking!) that it
> was some kind of variant on the DN87 - which I guess it is, just a more major
> one than I thought! :-)

The later-day TOPS-10 front-end ecosystem which included the DN87 was
called "ANF-10" (*) and included both local (DL10/DTE) interfaced
systems as well a remote nodes (both 8's and 11's) connected via
(DDCMP) sync lines.

I'm pretty sure the ANF-10 software was modular, and that the
configured devices/drivers were determined by a compile time config
file.  The DNxx designations might have been more a matter of
supported configurations and catalog designations.  I hesitate to use
the term "off the shelf" since my usual way in to my cubicle on the
second floor of "MR2" at DEC Marlborugh was thru the third floor,
which was manufacturing, and you could see entire hardware
configurations set up for test before delivery, so EVERYTHING was hand
constructed, and I don't know where the group that boxed up a
separately purchased ANF10 node was located (in Marlborough, or
somewhere else), and it's entirely possible that each and every
front-end sold ran hand configured software.

from http://www.ultimate.com/phil/pdp10/10periphs

    DAS78	IBM bisync support (up to 16 360, 370, and/or 2780's) (PDP-11 via DL10)
    DAS82	11/40 remote station via KG11(DQ11?) 9600 sync, CR11 300CPM CDR, LP11 250LPM LPT, 2xDH11 32 async lines (c.f. DN82)
    DAS85	11/40 via DL10 upto 16 DQ11 sync lines at 9600 (max 50kb agregate) c.f. DN85
    ...
    DC44    TYPESET-10 front end (PDP-11) for PTR (PA611R), PTP (PA611P), CAT? photocomposition machine (LPC11)
    DC68A   PDP-8(/I) 680(/I) communications system (via DA10): PDP-8/I-D w/ 4K memory
    DC71    ANF10 PDP-8/I remote station: CTY, DP01 sync, CR08 CDR, LP08 140LPM 64-char LPT, upto 16xDC02F async lines
    DC72A   ANF10 PDP-8/E remote station: DP8E sync, CDR, 170LPM 96-char LPT, upto 2xDC72L
    DC72B   ANF10 PDP-8/E remote station: DP8E sync, CDR, 240LPM 64-char LPT, upto 2xDC72L
    DC72C   ANF10 PDP-8/E remote station: DP8E sync, CDR,  53LPM 64-char LPT, upto 2xDC72L
    DC72L   8 FDX async lines on DC72A/B/C
    DC75    sync (PDP-11/15 & DS11's via DL10) DN8x code base! (cf DAS85?)
    DC76    communications (PDP-11/40 via DL10) upto 128 async lines (50-9600bps)
    DC76F   16 async lines on DC76 (DH11 + DM11?)
    ...
    DN20    sync/async (11/34 via DTE) front end [ie; DECnet MCB] (KMC11,DUP11,DMC11,DZ11,LP20,!KG11)
    DN200   ANF10 remote station (11/34) (Updated DN82) *or* DECnet remote station
    DN22    ANF10 remote station (11/04) (DMC11,DZ11,!KG11) w/ MOP ROM
    DN61    TOPS-10 Bisync; PDP-11/40 via DL10; 12 2780/3780 RJE stations or emulated 2780/3780 RJE stations
    DN61S   TOPS-10 Bisync; PDP-11/40 via DTE; 2780/3780 RJE stations or emulated 2780/3780 RJE stations
    DN62    DN61 with HASP support
    DN62S   DN62 via DTE
    DN64    TOPS-20 Bisync; PDP-11/34 via DTE; 2780/3780 RJE stations or emulated 2780/3780 RJE stations
    DN65    DN64 with HASP support
    DN71    remote station (PDP-8/I) (c.f. DC71?)
    DN72    remote station (PDP-8/E) (c.f. DC72?)
    DN80    ANF10 remote station (11/40) w/ DQ11; CDR, LPT, CTY
    DN81    ANF10 remote station (11/40) w/ DQ11; 32 TTYs
    DN82    ANF10 remote station (11/40) w/ DQ11; 32 TTYs, CDR, LPT, CTY (cf DAS82)
    DN85    ANF10 sync (11/40 via DL10) (cf DAS85?)
    DN87    ANF10 sync/async (11/40 via DL10) front end 
    DN87S   ANF10 sync/async (11/40 via DTE) front end (DL11,DH11,DM11,DN11,DQ11)
    DN92    ANF10 remote station (PDP-8/A); (Updated DC72)

My recall is that (some of) the front end software started in a group
that did custom engineering, and was later productized, and that the
designations "DAS" were from the former, and "DN" were the latter.

I'm not sure where the "DC" designations fall, my notes (below)
indicate the DC75 was built from the same code base as DN8x, and
possibly based on DAS85 (unclear if this refers to code or just
hardware), or how, or whether a DC68 differs from a "680".

ISTR the hardware in the 680 configuration used "bit-banging" to
implement async lines!!

I think Tim Litt could speak more authoritatively about ALL this, and
ISTR I've seen him speak up on the SIMH list, if not here.  Perhaps
writing these words will summon him?

> I wonder why DEC sold MIT a KL with a DL10 for the second PDP-11 front end?
> (The Console-11 was connected via a DTE.) Maybe it was so early in the
> product run that the DN87S didn't exist yet?

Could very well be.  MC was DEFINITELY an early system (see below).
ISTR the DTE was a DMA interface, not memory mapping like the DL10, so
that might have factored in as well.  For all I know at the point MC
was sold, noone had ever connected more than one 11 to a DTE, or more
than one DTE to a KL.

I collected the following KL serial numbers in the 80's
(when I worked for DEC in Marlborough and was an ITS tourist):

1026 one half of TOPS-10 development/time-sharing SMP system
1038 MC
1031 Hardware Development (rans TOPS-20?)
1042 second half of TOPS-10 development/time-sharing SMP system

I also seem to recall that MC was designated as a "1080" which the
above URL says means "Model A, External channels only, tall cabs,
DECtapes", while a 1090 is a "Model B" system (new backplane, expanded
microcode space, capable of running extended addressing microcode, and
could have "internal" (RH20) massbus channels).  MC's (Model A)
microcode would not run on a Model B CPU.

I remember finding documentation on MC for "KLDCP" the original DEC
front-end software (suitably defaced) which DEC later replaced with a
modified version of RSX-11, which allowed the KL to use the front end
to speak to character devices (other than the console and diagnostic
KLINIC (sp?) line).

Some more excessive rambling:

    TOPS-20 didn't speak to ANF-10 front ends, and ALL character
    devices (printers, cards, terminals, (paper tape??)) were
    connected to the RSX-20F front end 11/40.

    TOPS-10 would run on any KL sold for TOPS-20 (see 1091 below) But
    if you had a 1090 that normally ran TOPS-10, you might boot
    TOPS-20 on it (if you put the system pack on a drive that was dual
    ported to the console front-end and an RH20 channel), but you
    could only use RH20 connected disk drives, and serial lines
    connected to the console front-end (which might only be the
    console and KLINIC (sp?) ports)

    Machines sold for TOPS-20 were designated 20x0, (and GENERALLY had no
    PDP-10 I/O bus adaptor, internal (MOS) memory instead on an external
    memory bus, only internal channels, UNLESS they were sold to ARPAnet
    sites) came in low, orange cabinets, with RX01 floppies instead of
    DECtapes on the front-end 11, and had serial numbers above 2100 (2102
    was the TOPS-20 development system, BB&N had 2105).  ISTR ARPAnet
    systems (despite the fact that they might end up running TOPS-20) were
    sold as 1091T (a 1091 was a blue, low-cabinet system sold to run
    TOPS-10), due to the fact that they had an external I/O bus for the
    IMP interface).

    ISTR there was an orange system in Marlborugh that sometimes was
    used for TOPS-20AN (ARPAnet) development, and was also sometimes
    used by the TOPS-10 group for tri-CPU SMP configurations (2136?)
    but maybe I'm conflating two systems.

    It seemed like powers of two were used for PDP-10 CPU serial number
    boundaries: The dual KI-10 system in Marlborough (gone before I
    started work there, but I saw it on a visit) had CPUs 514 and 546.
    The TOPS-10 Development system (TWINKY-- the command to switch your
    ANF-10 front-end connected terminal from one ANF-10 host to another
    was "SET HOST(ESS)") was S/N 4096, and the TOPS-20 group had 4097.

(*) "A Network For 10s?" possibly based on a VERY early spec for
DECnet.  It may have used link-state routing.  I don't think routing
in DECnet appeared before Phase III; Between Phase II systems you
needed to use a passthru service, and ended up hand specifying routes,
like in the UUCP world: A::B::C:: -- DECnet routing (at least up to
Phase IV) was distance vector (within an area, I think node zero was
designated to be a route to an inter-area router).  The ONE nice thing
I remember about Phase IV is that an area could span multiple Ethernet
links, so you didn't have to waste a "network number" on each Ether
segment the way you had to use a Class-C in TCP/IP before subnetting.
I've wondered how much longer the IPv4 address space might have lasted
if there hadn't been a constraint that each network link have its own
network number (and each interface be uniquely addressable).

DECnet Phase V encompassed ISO, and might have included IS-IS,
which Rhea Perlman had a hand in (while at DEC?).  XNS (and hence
Netware) had 32-bits network number (host/node address was 48 bits
(ethernet address) and might also have had longer legs for global
use.

But I'm using IPv4 to type this, so it's not dead yet!


More information about the cctalk mailing list