Re: DL10 documentation

[Noel Chiappa via cctalk]

> From: Phil Budne

> FWIW, Found these bits
> ...
> Those bits and others can be found

Excellent archaeology! With these, and the ITS sources (for which we have both
the -10 and -11 sides), the register definitions in the early PDP-10 CPU
manual, and the prints, it should be possible to write a programming manual
for the DL10, to replace the one that's now lost. (If it ever existed - does
anyone know?)

Any chance I could convince you to enter all this stuff on the CHWiki DL10
article:

  http://gunkies.org/wiki/DL10

Lars (mostly) and I have added a little bit, but there's still a long way to
go!

Noel

Re: DL10 documentation

[Lars Brinkhoff via cctalk]

Phil Budne wrote:
>   DL.11I= B15 ; BIT 15 - 11 INT(INTERRUPTS IF 11-INT-ENB SET)
>   DL.11C= B14 ; BIT 14 - CLEAR 11 INT
>   DL.10I= B13 ; BIT 13 - 10 INT
>   DL.10C= B12 ; BIT 12 - CLEAR 10 INT
>   DL.NXM= B11 ; BIT 11 - NXM(INTERRUPTS IF ERR ENB SET)
>   DL.CNX= B10 ; BIT 10 - CLEAR NXM
>   DL.PAR= B9  ; BIT 09 - PAR ERR(INTERRUPTS IF ERR ENB SET)
>   DL.CPE= B8  ; BIT 08 - CLEAR PAR ERR
>   DL.WCO= B7  ; BIT 07 - WCOV(INTERRUPTS IF ERR ENB SET)
>   DL.CWC= B6  ; BIT 06 - CLEAR WCOV
>   DL.PEN= B5  ; BIT 05 - PORT ENABLE
>   DLPENB= DL.PEN  ; 
>   DL.B04= B4  ; BIT 04 - (GUESS !)
>   DL.ERE= B3  ; BIT 03 - ERR ENABLE
>   DL.INE= B2  ; BIT 02 - 11 INT ENB
>   DL.B01= B1  ; BITS 00 & 01 - PIA
>   DL.B00= B0  ; 

Thanks, good find!

I linked to your message from the GitHub issue.

Re: DL10 documentation

[Phil Budne via cctalk]

FWIW, Found these bits in the TOPS-10 7.04 sources:

http://pdp-10.trailing-edge.com/tops10_704_monitoranf_bb-x140c-sb/01/10,7/anf10/chk11.p11.html

Search for ";DETERMINE THE DL10 BASE ADDRESS"

Which tries setting the following bit pattern:
DL.CNX!DL.CPE!DL.CWC!DL.11C

Those bits and others can be found in:
http://pdp-10.trailing-edge.com/tops10_703_distr_bb-x140b-sb/02/10,7/703anf/s.p11.html


.SBTTL  DL10 HARDWARE BITS
; 
; DL10 - UNIBUS TO DECSYSTEM-10 MEMORY BUS INTERFACE
; 
.IIF NDF DL.VEC,DL.VEC= 170 ; VECTOR ADR FOR DL10
DL.LVL= 4   ; CHANNEL FIVE

DL.11I= B15 ; BIT 15 - 11 INT(INTERRUPTS IF 11-INT-ENB SET)
DL.11C= B14 ; BIT 14 - CLEAR 11 INT
DL.10I= B13 ; BIT 13 - 10 INT
DL.10C= B12 ; BIT 12 - CLEAR 10 INT
DL.NXM= B11 ; BIT 11 - NXM(INTERRUPTS IF ERR ENB SET)
DL.CNX= B10 ; BIT 10 - CLEAR NXM
DL.PAR= B9  ; BIT 09 - PAR ERR(INTERRUPTS IF ERR ENB SET)
DL.CPE= B8  ; BIT 08 - CLEAR PAR ERR
DL.WCO= B7  ; BIT 07 - WCOV(INTERRUPTS IF ERR ENB SET)
DL.CWC= B6  ; BIT 06 - CLEAR WCOV
DL.PEN= B5  ; BIT 05 - PORT ENABLE
DLPENB= DL.PEN  ; 
DL.B04= B4  ; BIT 04 - (GUESS !)
DL.ERE= B3  ; BIT 03 - ERR ENABLE
DL.INE= B2  ; BIT 02 - 11 INT ENB
DL.B01= B1  ; BITS 00 & 01 - PIA
DL.B00= B0  ; 

The (11 side) driver code for the DL10 is in:

http://pdp-10.trailing-edge.com/tops10_704_monitoranf_bb-x140c-sb/01/10,7/anf10/dndl10.p11.html

.SBTTL  DNDL10 - PDP-10/PDP-11 INTERFACE  21 JUL 82

and defines a memory window (I'm assuming only the "STS" word contains
the above bits, and the rest is shared memory) using a window pointer
determinted by chk11 (see above):

.SBTTL DL10 WINDOW

BLOCK   DL  ;THIS IS THE DL-10 WINDOW

X   STS ;DL10 STATUS REGISTER
X   ,2  ;UNUSED
X   NAM ;PROGRAM NAME BYTE POINTER (SIXBIT)
X   ,1  ;NOT USED
X   11A ;PDP-11 ALIVE INDICATOR. INCREMENTED BY
;  BY THE TEN ONCE/SECOND, SET TO 0 BY
;  THE 11.  IF <2 THEN 11 IS ALIVE.
X   STP ;STOP CODE (FOR WHEN -11 DIES)
X   DWN ;3 STATE SWITCH
;  1 => UP AND RUNNING
;  0 => DOWN, COMPLAIN TO THE OPERATOR
; -1 => DOWN BUT DON'T COMPLAIN
X   UPT ;NOT USED?
X   STA ;GLOBAL STATE WORD
DLS.DP=1;DEPOSIT 11 CORE
DLS.EX=2;EXAMIN 11 CORE
GBADDR=4; DL.ADR IS BAD
GHOLD=10; HOLD EVERYTHING

X   ADR ;ADDRESS FOR EXAMINE/DEPOSITE IN 11 MEMORY
X   DAT ;CONTENTS OF THE EXAMINE/DEPOSITE
X   RLN ;MAXIMUM MESSAGE LENGTH 11 WILL ACCEPT
X   MOD ;DL-10 MODIFICATION NUMBER
WINVER=1;WINDOW VERSION NUMVER
X   10A ;PDP-10 ALIVE INDICATOR.  INCREMEMTED BY
;  THE 11 ONCE/SECOND, SET -1 BY THE 10.
;  IF <= 1, THE 10 IS ALIVE
X   10S ;STATUS OF THE 10
;  0 => INITIAL VALUE.  NOTHING GOING ON
;  1 => STARTED INITIALIZATION
; -1 => UP AND RUNNING
X   11S ;STATUS OF THE 11.
;  0 => INITIAL VALUE.  NOTHING GOING ON
;  1 => STARTED INITIALIZATION
; -1 => UP AND RUNNING
X   IST ;INPUT STATUS FLABS
;  B1 = FIRST PART
;  B2 = SECOND PART
X   ICT ;INPUT COUNT (10'S POINT OF VIEW)
X   IDT ;INPUT DATA APPEARS HERE
X   ,1  ;SECOND INPUT POINTER'S COUNT
X   ,1  ;SECOND INPUT POINTER'S DATA


X   OST ;OUTPUT FLAGS
;  B0 SAYS OUTPUT READY TO TO
;  B1-B4 SPECIFY THE CONVERSION
;  1 => LPT COMPRESSION
;  2 => BINARY (12 BIT) CONVERSION
X   OCT ;FIRST OUTPUT BUFFER'S LENGTH
X   ODT ;FIRST OUTPUT BUFFER'S DATA
X   ,1  ;SECOND BUFFERS COUNT
X   ,1  

Re: DL10 documentation

[Lars Brinkhoff via cctalk]

Noel Chiappa wrote:
> Well The "decsystem10 System Reference Manual (DEC-10-XSRMA-A-D) -
> available online:
>
>   
> http://bitsavers.org/www.computer.museum.uq.edu.au/pdf/DEC-10-XSRMA-A-D%20DECsystem10%20System%20Reference%20Manual.pdf
>
> has a definition for the -10 side of the interface on pages C-21 and
> following (page 365 of the PDF).

I have taken a quick look at this, and also the Rubin 10-11 interface
that was used on MIT-AI.  So far they look similar.  Was there a chance
one inspired the other?

Re: DL10 documentation

[Fred Cisin via cctalk]

   > I had a major WTF moment at that. The actress had a prior or parallel
   > career as an engineer?


Is Rhea Jo Perlman (1948-)the same person as Radia Joy Perlman (1951-)?

They don't look much alike, . . .

Re: DL10 documentation

[Paul Koning via cctalk]

> On Jan 11, 2018, at 9:47 AM, Noel Chiappa via cctalk  
> wrote:
> ...
> Like I said, we did 'borrow' some idea from IS-IS, in particular the sequence
> number thing - but that may have come direct from Radia's paper:
> 
>  Radia Perlman, "Fault-Tolerant Broadcast of Routing Information", Computer
>Networks, Dec. 1983

Yes, that documents work she did at DEC early on, while developing the original 
link state routing proposal that was intended to be Phase IV but was set aside 
as "too complicated".

> I don't recall where the concept of a designated router stuff came from, if
> IS-IS was any influence there or not.

Designated router was part of DECnet Phase IV, so early 1980s.  OSPF does it in 
a fundamentally different way: DECnet aimed to be deterministic, OSPF aims to 
be stable.  The consequence is that in DECnet a given topology always has the 
same designated router no matter the sequence in which things came together, 
while in OSPF the designated router depends the order in which things happened. 
 There are arguments for either approach; in routers it doesn't matter much.

paul

Re: DL10 documentation

[Liam Proven via cctalk]

On 11 January 2018 at 19:03, Noel Chiappa via cctalk
 wrote:
> > From: Liam Proven
>
> > I had a major WTF moment at that. The actress had a prior or parallel
> > career as an engineer?
>
> Why not? Hedy Lamarr:
>
>   https://en.wikipedia.org/wiki/Hedy_Lamarr
>
> invented spread spectrum communications! :-)

True!

I wasn't saying it was impossible or anything, merely that I thought I
might have heard about that, as I had heard about Ms Lamarr.

British TV comedians Graeme Garden and Harry Hill were both medical
doctors before their media careers, for instance. It does happen.

-- 
Liam Proven • Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk • Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven • Skype/LinkedIn: liamproven
UK: +44 7939-087884 • ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: DL10 documentation

[Noel Chiappa via cctalk]

> From: Liam Proven

> I had a major WTF moment at that. The actress had a prior or parallel
> career as an engineer?

Why not? Hedy Lamarr:

  https://en.wikipedia.org/wiki/Hedy_Lamarr

invented spread spectrum communications! :-)


> From: Dave Mitton

> I could ask John Shriver  ;^)

Sure, not a bad idea. He was on the edge of that (he wasn't really part of
the IETF world), but perhaps he has some memory that would bear.

Noel

Re: DL10 documentation

[Liam Proven via cctalk]

On 10 January 2018 at 01:56, Phil Budne via cctalk
 wrote:

>
> DECnet Phase V encompassed ISO, and might have included IS-IS,
> which Rhea Perlman had a hand in (while at DEC?).

I had a major WTF moment at that. The actress had a prior or parallel
career as an engineer?

Some Googling revealed that you have your R Perlmans muddled. It's
Radia Perlman, designer of Spanning Tree.


-- 
Liam Proven • Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk • Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven • Skype/LinkedIn: liamproven
UK: +44 7939-087884 • ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: DL10 documentation

[Noel Chiappa via cctalk]

> I'm to[o] busy right now to dig back through my ancient records (paper
> and email) to find details

So while I didn't have time to do either of these (my Proteon email, if I
still even have it, will be on a magtape I'd have to get Chuck to read; and
the paper records are mixed in with a giant pile of other stuff - I was on the
IESG while I was at Proteon, and it's all mixed in together), I did take a
quick look online to see if I could locate anything from that time period -
knowing how bad human memory really is, I wanted to make sure my memory wasn't
playing me false.

I didn't have high hopes, since stuff from the late 80's is hard to find
online, and I my expectations weren't disappointed (at least, in the brief
time I could put into it), but I did happen to turn up this:

  John T. Moy, "OSPF: Anatomy of an Internet Routing Protocol"

which I'd vaguely heard about, but don't have (although I have everyone else's
books; I'll have to get a copy), wherein one may find (pg. 303) this:

  "OSPF considered, but did not use, IS-IS as a starting point."

which seems fairly definitive, and straight from the horse's mouth.


I do wish I had access to more contemporary documents to, to give it a bit
more detail. As I recall the circumstances, I had previously wanted to do a
link-state replacement for EGP (to be called FGP) but Dave Clark (who was at
that time on the Proteon board) shot it down (IIRC, in part because he thought
it was too big a job for John - and John was not sanguine either; whereas I
had already seen enough of John to know he was quite capable of it).

That part I remember clearly, but from here on out it gets hazy (I was so busy
with goings-on in the IETF, juggling so many things with that, Proteon, etc),
alas; and it's been too many years since those memories were refreshed by use.
I do recall that we also needed a better IGP, as RIP was not really that good,
and Proteon decided they could do that - and John and I would have agreed that
a link-state design was the only way to go.

It started out as a Proteon-specific thing, for Proteon's customers, but like
SGMP (which started in similar circumstances, before morphing into SNMP), it
soon turned into an 'open' effort, in the IETF. I don't recall how (i.e. why)
that happened, but I assume it was a similar set of reasoning as with
SGMP/SNMP. It might be that if the IETF email archives from that period can be
found, they'd have some useful coverage of that.

My vague memory is that our biggest design influence was the ARPANET work, and
especially the later version which added area support (described in:

  Josh Seeger and Atul Khanna, "Reducing Routing Overhead in a Growing DDN",
MILCOMM '86, IEEE, 1986

which I have in hardcopy somewhere, which I saw on the top of a pile recently,
so I can scan it if someone's interested), and also the subject of a memorable
briefing to the proto-IETF by Linda Seamonson, which I remember clearly - not
the technical details, alas, just at how good a presentation it was! :-) I
remember in particular they had a very elegant/clever method for defining the
area boundaries.

Like I said, we did 'borrow' some idea from IS-IS, in particular the sequence
number thing - but that may have come direct from Radia's paper:

  Radia Perlman, "Fault-Tolerant Broadcast of Routing Information", Computer
Networks, Dec. 1983

I don't recall where the concept of a designated router stuff came from, if
IS-IS was any influence there or not.

I did interact with John quite a bit in the very early design stages (I'd been
making a deep study of routing for quite a few years, so I was really the only
person there who was steeped in routing he could talk to), but as the work
prgressed - particularly once it moved to the IETF - I got out of the loop, as
I was too busy with other things, and he clearly had things in hand. I also
seem to vaguely recall disagreeing with him about some design points, but I
can't remember what.


Anyway, probably the wrong list for this. (Internet-history would have been
better.) Sorry, I didn't mean to get into a long thing, thought I was just
correcting a bit of nth-hand 'telephone-game' type garbling of a minor point.>

Noel

Re: DL10 documentation

[Dave Mitton via cctalk]

>  From: j...@mercury.lcs.mit.edu (Noel Chiappa)

  >> From: Paul Koning
  >> That may be the story, but I don't believe it.

>> Was anyone from whom you have heard differently _at Proteon_? If not...

I could ask John Shriver  ;^)

Dave.

Sent from Mail for Windows 10



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

RE: DL10 documentation

[Rich Alderson via cctalk]

From: Noel Chiappa
Sent: Wednesday, January 10, 2018 5:07 AM

> From: Phil Budne

>> 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

> MC, on the other hand, ran KLDCP ('KL Diagnostic Console Program') until the
> end. (The sources of DEC KLDCP version 7 are still available from the MC
> dumps, if anyone wants them, along with the MIT-modified version.) The
> console -11 on MC ran a 'combination' of IOELEV and KLDCP - the two remained
> pretty much separate, just cooperated to share the machine:

>   KLDCP does JSR PC, [to 03000] when it has nothing to do and 10 is
>   running. IOELEV should INIT if it hasn't already, then go into its main
>   loop. It should CLC, RTS PC if the 10 goes down; KLDCP will print
>   appropriate message. To go into temporary KLDCP command mode, SEC, RTS PC.

> I get the impression from the IOELEV source that it ran on the -11 connected
> to the DL10 first (stand-alone, by itself), and was later adapted to share the
> console -11 with KLDCP.

> Amusing comment in the KLDCP source:

>   WE HAVE GONE TO CONSIDERABLE DIFFICULTY AND EXPENSE TO ASSEMBLE A STAFF OF
>   SORCERERS, SHAMANS, CONJURERS AND LAWYERS TO VISIT NETTLESOME AND MYSTIFING
>   DISCOMFORTS ON ANY NINNY WHO ENDEAVORS TO REPRODUCE OR USE THIS PROGRAM IN
>   ANY FORM OR BY ANY MEANS, ELECTRONIC OR OTHERWISE, INCLUDING COMPUTERS AND
>   INFORMATION SYSTEMS, WITHOUT PERMISSION FROM THE DEVELOPER. WATCH YOURSELF!

The original KL-10 running WAITS in the SAIL tri-processor system was a 1080 as
well, and used a locally extended version of KLDCP for the front end rather
than a second program such as IOELEV.  This version of KLDCP includes Ethernet
support for the 3Mbit Xerox board, which provides PUP networking to WAITS.

We are looking at adding code to this version of KLDCP to allow setting the TOY
clock, a TCU-150.  (SAIL used a TCU-100 and a hack to get years from 1976-1991;
the TCU-150 provides a YEAR field in the date register.)  I find it interesting
that the SAIL folks never saw the need to do that. :-)

Sources for both the original and the WAITS variant are available for perusal
at SAILDART.org (Bruce Baumgart's site), and will be visible on our WAITS
system once we have IP networking going.

Rich

Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computers: Museum + Labs
2245 1st Avenue S
Seattle, WA 98134

mailto:ri...@livingcomputers.org

http://www.LivingComputers.org/

Re: DL10 documentation

[Noel Chiappa via cctalk]

> From: Paul Koning

> That may be the story, but I don't believe it.

Well, I was right there - I was the chief architect of the Proteon router
product, for which John Moy worked, and was the person who pushed John into
doing OSPF (he didn't think he knew enough).

I'm to busy right now to dig back through my ancient records (paper and email)
to find details, but I can assure you we did not 'base' OSPF on IS-IS.

Was anyone from whom you have heard differently _at Proteon_? If not...

 Noel

Re: DL10 documentation

[Paul Koning via cctalk]

> On Jan 9, 2018, at 7:56 PM, Phil Budne via cctalk  
> wrote:
>...
>DC44TYPESET-10 front end (PDP-11) for PTR (PA611R), PTP (PA611P), CAT? 
> photocomposition machine (LPC11)

That takes me back a while... 6 channel paper tape equipment, for communicating 
with typesetting machinery of that era.

Which reminds me:

> ...(*) "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; 

I don't know anything about ANF-10.  But while routing appeared in DECnet with 
phase 3, that was not the first time DEC did routing.  Earlier (late 1977, I 
think -- certainly by summer 1978), Typeset-11 did link state routing.  It had 
a primitive kind of cluster that operated by passing work around as files, via 
a proprietary protocol over DMC-11 links, with link state routing.  It was 
pretty transparent: terminals were connected to any of the nodes, and could 
edit work and pass it around (to other people or to processing components such 
as typesetting back ends) independent of the location of those other resources.

paul

Re: DL10 documentation

[Paul Koning via cctalk]

> On Jan 10, 2018, at 10:52 AM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Paul Koning
> 
>> That was then adopted by OSI as IS-IS, and further tweaked to become
>> OSPF.
> 
> Err, no. OSPF was not a descendant of IS-IS - it was a separate development,
> based mainly on the ARPANET's original link state routing. (I can't recall if
> John Moy and I took a lot from the later 'area' version of the ARPANET link
> state, although we knew of it.) I think we became aware of IS-IS as OSPF
> progressed, and IIRC John 'borrowed' a few ideas (maybe the sequence number
> thing).

That may be the story, but I don't believe it.  Contemporary accounts have it 
that he started from a draft IS-IS spec.

paul

Re: DL10 documentation

[Noel Chiappa via cctalk]

> From: Paul Koning

> That was then adopted by OSI as IS-IS, and further tweaked to become
> OSPF.

Err, no. OSPF was not a descendant of IS-IS - it was a separate development,
based mainly on the ARPANET's original link state routing. (I can't recall if
John Moy and I took a lot from the later 'area' version of the ARPANET link
state, although we knew of it.) I think we became aware of IS-IS as OSPF
progressed, and IIRC John 'borrowed' a few ideas (maybe the sequence number
thing).

IS-IS was later evolved to handle both OSI and IP addresses (and has, I
assume, since been extended to handle IPv6 too).

Noel

Re: DL10 documentation

[Paul Koning via cctalk]

> On Jan 9, 2018, at 7:56 PM, Phil Budne via cctalk  
> wrote:
> 
> ...
> (*) "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 1 was point to point, usually described as RSX only though there 
is a DECnet-8 document that describes it.  

DECnet phase 2 is also point to point except for "intercept" nodes which do 
routing (by node name -- not number).  As I understand it, intercept was 
intended for PDP-10/20 systems where the front end would be the intercept, but 
that may be a misunderstanding on my part.  I worked on DECnet/E, which neither 
asked for nor offered intercept.  An intercept node is more than a router, 
actually; it keeps connection state (NSP state) so it can disconnect 
connections whose destination has gone away.  Note that Phase 2 NSP doesn't do 
timeout and retransmit, because it works on a "reliable" datalink (DDCMP).

DECnet phase 3 adds distance vector routing, NSP now has timeout and 
retransmit.  255 nodes max, no hierarchy.  Still only point to point (X.25 was 
added).

DECnet phase 4 adds hierarchy, Ethernet support.  This is where the infamous 
"high order MAC address" hack was concocted.  And yes, areas are not subnets, 
for that matter addresses are node addresses, not interface addresses, in all 
versions of DECnet.  That made a bunch of things much cleaner while 
complicating a few others.  Phase 4 is still distance vector, now with two 
instances: one for routing within the area, one for routing among areas.  The 
latter is present only in area routers.  And yes, in the within-area routing 
table, node number 0 is the alias for "any destination outside this area".

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

Phase 5 adopted OSI ES-IS (network layer) and TP-4 (transport layer).  ISO 
didn't have a routing protocol; their theory was that the world is X.25-ish 
stuff where telcos do the routing in a proprietary way.  That was obviously 
nonsense, so the DECnet architecture team created a link state routing protocol 
inspired by earlier IP work, with a lot of fixes to deal with failures.  That 
was then adopted by OSI as IS-IS, and further tweaked to become OSPF.

A bit of obscure history: When she first arrived at DEC (1981?), Radia proposed 
a link state routing protocol for what would be phase 4.  That wasn't adopted 
because it was considered too complicated by the VMS team; instead "phase 3e (3 
extended)" was created by a straightforward hack of phase 3, and that is what 
we now know as phase 4.  But the packet headers in Radia's proposal were 
retained for the Eternet case, which is where the "long headers" come from with 
a whole pile of fields with strange names that are for practical purposes 
simply reserved values.  When we outgrew phase 4 and link state was dusted off 
again, OSI had become relevant so a new design was created on that basis.  So 
the link state algorithm is in IS-IS but the packet formats and addressing are 
entirely different from the previous "long header" Ethernet stuff.

All DECnet versions from phase 3 onward were one phase backward compatible.  
Phase 2 wasn't backward compatible with phase 1; the packet formats are rather 
different.  I'm not sure why this wasn't done; perhaps no one thought it would 
be interesting.  No DEC product that I know of was multiple-phase backward 
compatible and no spec says how to do that, but it isn't actually hard; my 
Python based router does so.

paul

Re: DL10 documentation

[Noel Chiappa via cctalk]

> From: Phil Budne

> ISTR the DTE was a DMA interface, not memory mapping like the DL10

I don't know either; I could probably work it out from looking at the DTE
documentation, which I'm too lazy/busy to do... :-)

> 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

Yup, that's what it was.

> 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

MC, on the other hand, ran KLDCP ('KL Diagnostic Console Program') until the
end. (The sources of DEC KLDCP version 7 are still available from the MC
dumps, if anyone wants them, along with the MIT-modified version.) The console
-11 on MC ran a 'combination' of IOELEV and KLDCP - the two remained pretty
much separate, just cooperated to share the machine:

  KLDCP does JSR PC, [to 03000] when it has nothing to do and 10 is
  running. IOELEV should INIT if it hasn't already, then go into its main
  loop. It should CLC, RTS PC if the 10 goes down; KLDCP will print
  appropriate message. To go into temporary KLDCP command mode, SEC, RTS PC.

I get the impression from the IOELEV source that it ran on the -11 connected
to the DL10 first (stand-alone, by itself), and was later adapted to share the
console -11 with KLDCP.

Amusing comment in the KLDCP source:

  WE HAVE GONE TO CONSIDERABLE DIFFICULTY AND EXPENSE TO ASSEMBLE A STAFF OF
  SORCERERS, SHAMANS, CONJURERS AND LAWYERS TO VISIT NETTLESOME AND MYSTIFING
  DISCOMFORTS ON ANY NINNY WHO ENDEAVORS TO REPRODUCE OR USE THIS PROGRAM IN
  ANY FORM OR BY ANY MEANS, ELECTRONIC OR OTHERWISE, INCLUDING COMPUTERS AND
  INFORMATION SYSTEMS, WITHOUT PERMISSION FROM THE DEVELOPER. WATCH YOURSELF!

   > diagnostic KLINIC (sp?) line).

KLINIK, according to KLDCP stuff.

Noel

Re: DL10 documentation

[Phil Budne via cctalk]

> 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
...
DC44TYPESET-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
DC71ANF10 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
DC75sync (PDP-11/15 & DS11's via DL10) DN8x code base! (cf DAS85?)
DC76communications (PDP-11/40 via DL10) upto 128 async lines 
(50-9600bps)
DC76F   16 async lines on DC76 (DH11 + DM11?)
...
DN20sync/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
DN22ANF10 remote station (11/04) (DMC11,DZ11,!KG11) w/ MOP ROM
DN61TOPS-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
DN62DN61 with HASP support
DN62S   DN62 via DTE
DN64TOPS-20 Bisync; PDP-11/34 via DTE; 2780/3780 RJE stations or 
emulated 2780/3780 RJE stations
DN65DN64 with HASP support
DN71remote station (PDP-8/I) (c.f. DC71?)
DN72remote station (PDP-8/E) (c.f. DC72?)
DN80ANF10 remote station (11/40) w/ DQ11; CDR, LPT, CTY
DN81ANF10 remote station (11/40) w/ DQ11; 32 TTYs
DN82ANF10 remote station (11/40) w/ DQ11; 32 TTYs, CDR, LPT, CTY (cf 
DAS82)
DN85ANF10 sync (11/40 via DL10) (cf DAS85?)
DN87ANF10 sync/async (11/40 via DL10) front end 
DN87S   ANF10 sync/async (11/40 via DTE) front end 
(DL11,DH11,DM11,DN11,DQ11)
DN92ANF10 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 

Re: DL10 documentation

[Noel Chiappa via cctalk]

> From: Phil Budne

> simulating the DL10 so you can run TVs would REALLY be bringing back a
> lost artifact!!

The Knight TV's were connected through the Rubin 10-11 interface, not a DL10.

> I'm pretty sure DN87S was a DN87 front end attached to a (KL) DTE
> (Ten/Eleven) interface instead of a DL10 (or POSSIBLY visa versa).

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! :-)

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?

Noel

Re: DL10 documentation

[Lars Brinkhoff via cctalk]

Phil Budne wrote:
> ITS speaks TCP (over an IMP interface, which is simulated in KLH10),
> so it hardly seems worth jumping thru hoops to get hardwired dumb
> terminals.

Right, SUPDUP is really the best way to talk to ITS.  But I'm can't set
Richard's priorities.  Maybe I can pitch in myself.

Chaosnet is another option.

> Now, simulating the DL10 so you can run TVs would REALLY be bringing
> back a lost artifact!!

It's on the radar.  Need more volunteers.

I have extracted the TV font, so you can use that with your favourite
terminal emulator.

Re: DL10 documentation

[Phil Budne via cctalk]

I wrote:
> Now, simulating the DL10 so you can run TVs would REALLY be bringing
> back a lost artifact!!

https://github.com/PDP-10/its/issues/279
says:

 larsbrinkhoff commented on Mar 31, 2017

 I think the number of PDP-11s connected were limited by the address space of 
the Rubin IO-11 interface. It occupied one of AI's four mobies. One moby can 
address 16 64k spaces, but somehow I recall seeing the number 8 as the maximum.

Re: DL10 documentation

[Phil Budne via cctalk]

Lars Brinkhoff wrote:
> Richard has DE10 working already, but that's not supported by ITS.
> Adding that support is not out of the question, but we want to give the
> DL10/DC76 a go.

ITS speaks TCP (over an IMP interface, which is simulated in KLH10),
so it hardly seems worth jumping thru hoops to get hardwired dumb
terminals.

Now, simulating the DL10 so you can run TVs would REALLY be bringing
back a lost artifact!!

> > The DL10 was used in two DEC system products, the DC76 Asynchronous
> > Communication System, and the DN87 and DN87S Universal Communication System
> > Front Ends. I couldn't find any documentation on the former

I'm pretty sure DN87S was a DN87 front end attached to a (KL) DTE
(Ten/Eleven) interface instead of a DL10 (or POSSIBLY visa versa).

phil

BUDD@AI
KL1026::[31,5732]
BUDNE@KL2137 & MRFORT

Re: DL10 documentation

[Noel Chiappa via cctalk]

> From: Lars Brinkhoff

> Specifically, the DC76 supported by ITS.

>> The DL10 was used in two DEC system products, the DC76 Asynchronous
>> Communication System, and the DN87 and DN87S Universal Communication
>> System Front Ends. I couldn't find any documentation on the former

> Ouch, it's the former we want.

Eh, no problem. The DL10 part is the same, and the PDP-11 devices in the DC76
were almost certainly standard DEC PDP-11 stuff.

ITS ran its own code in the PDP-11 attached to the DL10, anyway - looking at
IOELEV (in the MX-DL section), it only supported DL11's and DH11's. Those are
very well documented.

Noel

Re: DL10 documentation

[Lars Brinkhoff via cctalk]

I wrote:
>> Richard Cornwell wants to implement DL10 for his KA10/KI10 simulator,
>> but he doesn't have any documentation for it.  Any leads?

Johnny Eriksson wrote:
> First question is: since the DL10 is a DMA device for a handful of
> PDP11s, what is intended at the other (unibus) end of it?
> If the idea is to get more terminal lines, maybe a DC10 scanner would
> be an easier starting point.

Right, it's for terminals.  Specifically, the DC76 supported by ITS.
ITS doesn't have many options for terminal scanners.  TK10 anyone?
Morton box?  Knight kludge?

Richard has DE10 working already, but that's not supported by ITS.
Adding that support is not out of the question, but we want to give the
DL10/DC76 a go.

Noel Chiappa wrote:
> http://bitsavers.org/www.computer.museum.uq.edu.au/pdf/DEC-10-XSRMA-A-D%20DECsystem10%20System%20Reference%20Manual.pdf
> has a definition for the -10 side of the interface on pages C-21 and
> following (page 365 of the PDF). It just specifies the I/O instructions and
> bits, there's no description of how it works.

Thanks!

> The DL10 was used in two DEC system products, the DC76 Asynchronous
> Communication System, and the DN87 and DN87S Universal Communication System
> Front Ends. I couldn't find any documentation on the former

Ouch, it's the former we want.

Re: DL10 documentation

[Noel Chiappa via cctalk]

> From: Lars Brinkhoff

> Richard Cornwell wants to implement DL10 for his KA10/KI10 simulator,
> but he doesn't have any documentation for it.  Any leads?

Well The "decsystem10 System Reference Manual (DEC-10-XSRMA-A-D) -
available online:

  
http://bitsavers.org/www.computer.museum.uq.edu.au/pdf/DEC-10-XSRMA-A-D%20DECsystem10%20System%20Reference%20Manual.pdf

has a definition for the -10 side of the interface on pages C-21 and
following (page 365 of the PDF). It just specifies the I/O instructions and
bits, there's no description of how it works.

Still, that will help understand code that uses it; the complete ITS code is
available.

I couldn't find anything on the PDP-11 side of the interface; ITS' IOELEV >
does define a "DLXCSR", and the bits in it, but ... it seems to be a memory
location, not a register?


The DL10 was used in two DEC system products, the DC76 Asynchronous
Communication System, and the DN87 and DN87S Universal Communication System
Front Ends. I couldn't find any documentation on the former, but complete
prints for the latter are available:

  
http://www.bitsavers.org/pdf/dec/pdp10/periph/MP00068_DN87_Universal_Comm_System_Front_End_Jan76.pdf
  
http://www.bitsavers.org/pdf/dec/pdp10/periph/MP00109_DN87S_Universal_Comm_System_Front_End_Sep78.pdf

It includes a complete set of prints for the DL10. From this, and also from:

  http://pdp-10.trailing-edge.com/bb-d549g-sb/01/boot11.mem.html

it appears that the PDP-11's connected to the DL10 have a special console
which has a cable which goes to the DL10 which allows the PDP-10 to start and
stop the PDP-11; the PDP-11's UNIBUS runs into the DL10 and is plugged into
the DL10.


Anyway, it's going to be some hard work to create a DL10 programming manual
from those dribs and drabs, but there is enough info there that it can be
done.

Noel

Re: DL10 documentation

[Johnny Eriksson via cctalk]

Lars Brinkhoff  wrote:

> Hello,
> 
> Richard Cornwell wants to implement DL10 for his KA10/KI10 simulator,
> but he doesn't have any documentation for it.  Any leads?

First question is: since the DL10 is a DMA device for a handful of PDP11s,
what is intended at the other (unibus) end of it?

I have found that

  
http://bitsavers.trailing-edge.com/pdf/dec/pdp10/periph/MP00068_DN87_Universal_Comm_System_Front_End_Jan76.pdf

contains the engineering drawings for the DL10.

Also, the tops-10 source file D85INT.MAC (from the unsmon directory)
contains the driver for it.

If the idea is to get more terminal lines, maybe a DC10 scanner would
be an easier starting point.

--Johnny