On 18-Mar-15 20:34, Rich Alderson wrote: > At several points in the discussion, the KL-10 has come up as an > example of a system with a PDP-11 front end processor. Reference > has been made to "shared memory" between the -11 and the PDP-10 > engine which is the main reason for the existence of the system. > > The PDP-11/40 front end and the PDP-10 engine do not share memory. > Data transfer takes place over a Unibus device (from the -11 side) > which resides in the I/O bay of the -10, called a DTE-20. This is > a very simple device which ties into the interrupt systems of the > -10 and -11 with a "doorbell"; depending upon who is ringing whose > bell, data moves between the -11's memory and the -10's, but neither > side knows the address(es) in the other processor. > > Note that the front end software is special, as well. Both of the > loader programs, the older KLDCP which is retained by the diagnostic > package and the later RSX-20F[1,2,3], expect to deal with 18-bit > data on disk, not 16. > > I'm not saying that a KL-10 emulation would not be interesting, just > pointing out that it has nothing in common with the Unichannel on > the PDP-15/76. > > Rich This is more or less correct, except that the DTE20 is not a 'simple' device. I had to learn more about it than I ever wanted to, and the lessons were sufficiently painful that I remember (most of) them a few decades later.
The -11 can read and write -10 memory. The primary DTE can access anything, but the queued protocol used when the OS is running uses 'protected' reads and writes that are limited to a 10-defined window. However, even in that mode, other communication happens via fixed locations in the EPT and low memory. Including console I/O when eddt or the bootstraps are running. The primary DTE also can access the diagnostic bus, SBus & microcode. (Actually, any of them can, but software complains if more than one is privileged - it's a toggle switch on the panel of each DTE.) This includes microcode loading, and on the fly error recovery. The KL10 microcode handles some DTE20 functions. The other DTEs are restricted to the queued protocol, and can be either 11/40s or 11/34s. DECnet or ANF-10. The -10 has an electronic finger and can reboot any of the -11s - even the primary. The -10 and -11 have mutual keep-alive counters and reboot each-other. The -11 does hardware initialization, power-fail restart and other obscure, barely documented stuff. The -10 has no access to -11 memory, though the electronic finger triggers a boot ROM, and includes a few bits specifying where it starts. The DEC ROMs all had an entry point for dumping -11 memory as well as loading it. But this is a software function. There is a tech manual that has unpublished errata. There's a copy at http://www.36bit.org/dec/manual/ek-dte20-ud-003.pdf > [1] Developed mostly from RSX-11M, with a few nods to RSX-11D, at > least as far as the doc writers were concerned. -11M, but -11D device drivers and a heavy dependence on event flags. No memory mapping; it was a stripped-down environment. 1 RP04/6 disk dual ported; the 11 driver had to deal with 18-bit (576 byte) formatted sectors. The queued protocol provided access to unibus peripherals, including async lines, card reader, LPT and (my secret contribution, a battery-backed-up TOY). This wasn't pure pass-thru; the 11 did a lot of the low-level control and presented abstracted devices. > [2] If you boot an RSX-20F floppy on an 11/40 without a DTE-20, you > will immediately receive a message on the console telling you > that the DTE-20 is not found and the system will halt. > [3] NB: The primary front end must be an 11/40. There are up to 4 > DTE-20s in a KL-10, and the secondary systems can also be 11/34's, Yes, but which one is 'primary' is controlled by the toggle switch that I mentioned. The test is for one that doesn't have the 'restricted mode' bit. > I believe, but I don't think they run RSX-20F, just special loads > like DECnet or HASP/RJE software. ANF-10, DECnet, and IBM E/T (HASP/RJE and other IBM OSs. The DN20 wasn't the only adapter for IBM E/T.) This is a fairly high-level description. The details are quite involved.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
