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.
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.was Unibus space really that scarce?
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.JohnnyThis 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. JohnnyAdding DMR support was on my list, but I haven't done it yet. I'll seeif 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:[email protected]] Sent: 13 April 2013 22:40 To: [email protected] Cc: Rob Jarratt; 'Johnny Eriksson'; [email protected] 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 HWproblems and lack of time. --JohnnyIf 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 animpossibleWhoever provided that information was correct for the DMC, but not forconfiguration as the DMC11 would have been in the PDP11 front end.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 seeif 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 onTOPS10, which is in the distributed OS sources. The DMC is useless onthe 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 [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
