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. 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? 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!