[Simh] DECnet for TOPS-10
Timothe Litt
litt at ieee.org
Sun Apr 14 10:11:09 EDT 2013
> don't think it was production ready, but I seem to remember he did it
> sponsored by DEC.
To my knowledge, DEC engineering did not sponsor V5 on the KS. It's
vaguely possible that a field office did on a consulting basis for some
customer, or that marketing asked for an outside feasibility study. But
it would not have been viable.
> was Unibus space really that scarce?
The KS has one BA11 drawer for UBA3. The RH11 for tape was required.
The LP20 was more-or-less required, as was at least one DZ11. That's 2
of the 5 system units (though the RH has a couple of SPC slots; the
DEUNA needs full Hex slots.) KDP was optional. There were a couple of
slots left in most systems, as few had the max config of all
peripherals. The engineering system was pretty full. You COULD install
a DEUNA if you had/made the space (I did, but I never finished a driver
for it.) I'm not sure what DEUNA availability was when the DECnet-36
implementation started; that may also have been an issue. In any case,
the 3Com device was used.
In theory, one could have daisy-chained another BA11 off the UBA3 box,
but the KS was intentionally constrained to maintain a balanced system
(and product positioning in the DEC product line.)
See
http://bitsavers.trailing-edge.com/pdf/dec/pdp10/lcg_catalog/Large_Systems_Product_Summary_Jul79.pdf
for the basic configuration rules.
Systems that had UBA2 added another BA11 (in another cabinet).
> Wasn't it that the KS actually have KL style extended sections, but
> there are only two sections on the KS?
The KS has KL or KI page tables. (Initially both in one ucode; I split
it into multiple loads to make room for other stuff.)
However, the KS only supports a single section with KL page tables.
(Section 0/1). You can't separate sections 0 & 1 due to the way
extended addressing is defined. Sections >1 would have required
hardware changes; it couldn't be done only in microcode.
> But it don't sound unreasonable that he'd use what you had already done.
I didn't do the internal work for TOPS20 V4.2/5.x on the KS. Some
people in the support and internal services groups did. MRC would have
started with the monitor source tapes.
> Phase III nodes can't directly talk with nodes in the same area
> either, if the other node have an address > 255.
Depends on the Phase III implementation, but yes, 255 or less.
Directly. What I said: Phase III nodes don't get any Phase IV
capabilities by virtue of being connected to one. PMR gets around this;
the DEC network used this extensively. (PMR = 'Poor Man's Routing' =
node::node::... syntax; this allowed symbolic connection forwarding via
FAL, circumventing the numeric limits on node and/or area number.)
With respect to the email you dug up about MRC's work - he reports what
I said - barely possible to even fit 4.1 + phase IV into the exec
address space. And he even had to reduce KDP buffer size. 5.[0,1] was
even more marginal.
Mark H's suggestion that the KS used the DMC interface is simply wrong.
No (DEC) OS supported the DMC on the KS. (I can't speak for ITS.) The
DMC WAS one of the communications boards used in the DN20 and DN200
communications front ends, though under other part numbers. DUP was
also used for low-speed lines, and for IBM communications (which
required bit-stuffing support.)
In any case, this has gone far afield of the simh issue of getting the
DMR/KDP into the PDP10 simulator. So I'm returning to the regularly
scheduled programming.
This communication may not represent my employer's views,
if any, on the matters discussed.
On 14-Apr-13 08:31, Johnny Billquist wrote:
> On 2013-04-14 02:18, Timothe Litt wrote:
>>> Did I remember wrong in that I thought I had seen something from MRC
>>> in the past where he said he had managed to get phase IV for TOPS-20
>>> running on a KS?
>> MRC may well have reconstructed a V5 monitor for the KS from the
>> sources, but that's not DEC product. And unless he did a lot of work,
>> it would have been an interesting toy, but not product quality.
>
> I don't think it was production ready, but I seem to remember he did
> it sponsored by DEC. But it never got shipped. Cancelled in the end,
> for one reason or other. But I think it was running just fine.
> But this is all from memory, and I might very well have things wrong.
>
>> Support for TOPS-20 on the KS ended with V4.1 (Phase III). The most
>> pervasive changes in Phase-IV were a consequence of supporting broadcast
>> media. DECnet Phase IV was initially developed on a KS with a 3-Com
>> ethernet card, as the DEUNA took too many slots, and the KLNIA wasn't
>> ready. (The DECnet, LAT and SCA modules were ported to TOPS-10; some of
>> the TOPS-10 changes went back into the DECnet group's sources.) As the
>> DECnet code grew, more modules were moved into extended sections,
>> including the SCA (CI) and cluster drivers. It was barely possible to
>> boot V5 on the KS if you cut back on a lot of configuration parameters,
>> but DEC never shipped it because there wasn't enough exec address space
>> left over (or resources) for a reasonably configured/responsive system.
>> It was held together to support DECnet development for quite a while,
>> but over time the dependencies on extended addressing grew. Once the
>> KLNIA was stable, the DECnet group abandoned the KS, as did the monitor
>> group.
>
> Interesting stuff. I admit to not having opened a KS that many times,
> but was Unibus space really that scarce? I mean, the DEUNA is just two
> cards after all. (Using two slots.)
>
>> TOPS-20 development decided to stabilize the KS at 4.1 rather than
>> invest in making 5.0 production quality on the KS. Since support was in
>> another group, they didn't bear the costs. A few people in the support
>> group had 5.1 running on the KS as a support tool (didn't want to get
>> rid of their KS system, as it was a lot cheaper in floor space, power,
>> and maintenance than buying/running another KL.) But that was
>> scaled-down & not product quality. I don't recall them succeeding (or
>> even putting much effort) at later versions of TOPS-20. The leftover
>> tracks in the sources would probably be the basis of MRC's work.
>
> I know that TOPS-20 never went beyond 4.1 on the KS. Sad, but probably
> understandable. Wasn't it that the KS actually have KL style extended
> sections, but there are only two sections on the KS?
>
> I don't know when MRC did his work, or what he had available. But it
> don't sound unreasonable that he'd use what you had already done.
>
>> I made a different call for TOPS-10. I updated the KS microcode to
>> support the version of KL paging that TOPS-10 used (but still a single
>> section), and made Phase IV work. JMF & I then came up with the
>> slight-of-hand to create an alternate address space for DECnet, allowing
>> TOPS-10 to also support a reasonable number of users. Presented with a
>> fait-accompli, product management saw the benefits and allowed us to
>> ship it. Happy customers. And we only had to support one version of
>> the monitor through end-of-life of the 36-bit product line.
>
> Yeah. I even used Tops-10 V7.02 on a KS. Thanks. :-)
> (Don't think I used 7.03 though.)
>
>>>> TOPS-20 can participate in a modern network.
>>> More or less. There are some restrictions.
>> Yes, but in this context, they're not significant. TOPS-20 Phase-III
>> will talk to a Phase IV system. Routing is different; the Phase-III
>> node doesn't know about areas, and (obviously) anything new in Phase-IV
>> doesn't magically appear in the Phase III implementation. But Phase-III
>> routers and end nodes can happily co-exist with Phase-IV on serial
>> links. NCP works. And PMR can be used to allow the Phase III nodes to
>> communicate across areas.
>
> Phase III nodes can't directly talk with nodes in the same area
> either, if the other node have an address > 255.
>
> Johnny
>
>>
>> This communication may not represent my employer's views,
>> if any, on the matters discussed.
>>
>> On 13-Apr-13 19:05, Johnny Billquist wrote:
>>> On 2013-04-14 00:39, Timothe Litt wrote:
>>>>> That sounds like we can get DECnet on TOPS-20 on SIMH, if so that
>>>>> would be
>>>>> really great!
>>>> Yes.
>>>>> Which phase(s) does TOPS-20 DECnet support on the KS?
>>>> Phase III. Because it was so large, Phase IV used extended sections
>>>> (addressing), which the KS doesn't support. I used slight-of-hand to
>>>> make Phase IV fit into TOPS-10 on the KS10.
>>>
>>> Did I remember wrong in that I thought I had seen something from MRC
>>> in the past where he said he had managed to get phase IV for TOPS-20
>>> running on a KS?
>>>
>>>> But Phase III will connect to a Phase IV node, so TOPS-20 can
>>>> participate in a modern network.
>>>
>>> More or less. There are some restrictions.
>>>
>>> Johnny
>>>
>>>>> Adding DMR support was on my list, but I haven't done it yet. I'll
>>>>> see
>>>>> if I
>>>>> can get the KMC/DUP code in and then do DMR, but it may be a while
>>>>> before I
>>>>> get time.
>>>> That would be super. It looked like your code has some hooks for DMR,
>>>> but is incomplete. Given that you don't actually do DDCMP, the
>>>> differences should be small.
>>>>
>>>> --
>>>> This communication may not represent my employer's views,
>>>> if any, on the matters discussed.
>>>>
>>>> On 13-Apr-13 18:25, Rob Jarratt wrote:
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Timothe Litt [mailto:litt at ieee.org]
>>>>>> Sent: 13 April 2013 22:40
>>>>>> To: r.jarratt at computer.org
>>>>>> Cc: Rob Jarratt; 'Johnny Eriksson'; simh at trailing-edge.com
>>>>>> Subject: Re: [Simh] DECnet for TOPS-10
>>>>>>
>>>>>> On 13-Apr-13 17:00, Rob Jarratt wrote:
>>>>>>> I wrote support for the KMC/DUP combo a long time ago, for simh
>>>>>>> v2.9.
>>>>>>>
>>>>>>> Works just fine, both for ANF and DECnet. Sources are (still) at
>>>>>>> ftp://ftp.stacken.kth.se/pub/pdp10/v29upd if anyone is interested.
>>>>>>>
>>>>>>> I do not have any system up at the moment, due to a combination
>>>>>>> of HW
>>>>>>> problems and lack of time.
>>>>>>>
>>>>>>> --Johnny
>>>>>>>
>>>>>> If KDP (KMC/DUP) still works, it should be integrated into the PDP10
>>>>>> simulator. TOPS-10 (ANF-10 and DECnet) supports the device, and
>>>>>> TOPS-20
>>>>>> (DECnet) supports it. Both on the KS10.
>>>>>
>>>>> That sounds like we can get DECnet on TOPS-20 on SIMH, if so that
>>>>> would be
>>>>> really great!
>>>>>
>>>>>
>>>>>>> It went into the PDP10 emulation for a while but was later
>>>>>>> removed when we were informed that it would have represented an
>>>>>> impossible
>>>>>>> configuration as the DMC11 would have been in the PDP11 front end.
>>>>>> Whoever provided that information was correct for the DMC, but
>>>>>> not for
>>>>>> the DMR.
>>>>>>
>>>>>> For the KL, yes, the DECnet serial line adapters were in the PDP11
>>>>>> front
>>>>>> end. Ethernet was on an internal channel.
>>>>>>
>>>>>> If the DMC can be configured as a DMR, it should go into the PDP10
>>>>>> simulator.
>>>>>
>>>>>
>>>>> Adding DMR support was on my list, but I haven't done it yet. I'll
>>>>> see
>>>>> if I
>>>>> can get the KMC/DUP code in and then do DMR, but it may be a while
>>>>> before I
>>>>> get time.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> As I said, I wrote a KS10 (Unibus) driver for the DMR on
>>>>>> TOPS10, which is in the distributed OS sources. The DMC is
>>>>>> useless on
>>>>>> the KS10. As I noted, the DMR uses fixed addresses in TOPS-10, not
>>>>>> the
>>>>>> usual Unibus floating addresses.
>>>>>>
>>>>>> Either device would allow TOPS-10 networking to work under simh.
>>>>>> TOPS-10
>>>>>> can be configured for either or both devices. TOPS-10 DECnet will
>>>>>> work
>>>>>> as either a Phase III or Phase IV end-node on the KS10. (I did the
>>>>>> Phase IV implementation for the KS.)
>>>>>
>>>>> Which phase(s) does TOPS-20 DECnet support on the KS?
>>>>>
>>>>>
>>>>>> I was a developer for TOPS-10, and supported TOPS-20 (among other
>>>>>> things), so this is authoritative.
>>>>>>
>>>>>> This communication may not represent my employer's views,
>>>>>> if any, on the matters discussed.
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Simh mailing list
>>>> Simh at trailing-edge.com
>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>>>
>>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130414/1b66287d/attachment-0002.bin>
More information about the Simh
mailing list