Re: DL10 documentation
> 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
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
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
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
> 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
> 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
On 11 January 2018 at 19:03, Noel Chiappa via cctalkwrote: > > 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
> 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
On 10 January 2018 at 01:56, Phil Budne via cctalkwrote: > > 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
> 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
> 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
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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
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
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
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
> 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
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
> 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
Lars Brinkhoffwrote: > 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