David Riley wrote: The M8189 is a quad-height 11/23-plus card which includes bootstrap, LTC, SLUs, etc and there wouldn't normally be a BDV11 in the same system. The M8186 is the dual-height 11/23 card, and that would normally have a BDV11 in the system. The original 11/23-plus bootstrap ROMs are modified versions of the BDV11 boot ROMs and have the same boot options -- no MSCP. Those ROMs would be labelled 23-339-01E2 and 23-340-01E2 (or sometimes 23-339E2 and 23-340E2). That's not quite right. The early 11/23 cards (M8186 dual-height) are only 18-bit but all Rev.C and later 11/23 cards are 22-bit. All M8189 are 11/23-plus cards and are 22-bit. The only difference between different M8189 cards (apart from inconsequential etch revisions) are the boot ROMS. The original release -BA are 2K ROMs equivalent to BDV11 boot ROMs and they were used in PDP-11/23-plus systems (BA11S box). Later ones such as -BE and onwards that support MSCP were made specifically for microPDP-11/23+ systems (BA23 box). No, the oldest versions can't. Only the ones intended for microPDP-11/23+ system have MSCP support (-BE and later). -- Pete Peter Turnbull Network Manager University of York

Glen Slick wrote: 23-339E2 and 23-340E2 are 2K devices. There's a typo in the listing (corrected now!), but if you look at the files you'll see they're 2Kx8, and of course the E2 suffix means 2Kx8. Or modify the sockets. I don't think there's quite enough room to replace the 24-pin sockets with 28-pin on a KDF11-B card, but it can be done with a carrier. For KDF11-A systems, there's room to do it on a BDV11, and I have one that's been so modified. Of course with a BDV11 you can also re-jumper it to spread the 8K across 4 pairs of sockets. -- Pete Peter Turnbull Network Manager University of York

On Fri, Jan 6, 2012 at 12:25 PM, David Riley <fraveydank at gmail.com> wrote: Just KDF11-A vs KDF11-B... KDF11-A may or may not be 22-bit (only Rev A is 18-bit). All -B are 22-bit. Dual-height CPU only vs Quad-height CPU plus dual SLU plus on-board Boot ROMs. If you are building a system from scratch and have an up-rev KDF11-A plus a couple of serial ports (like half of a DLV11-J) plus a Bootstap/terminator board then compare that to a /23+ system, the effective difference is that the /23+ system will have fewer boards to do the same thing and more open slots. No effective difference from a software standpoint. One can also assemble a KDF11-A system in one of the oddball narrow backplanes that originally shipped with the LSI-11/2 where a KDF11-B won't fit, but that's still just packaging. A minimal /23+ system could be as little as 2 modules - KDF11-B plus memory - use the second SLU for a TU58 or TU58 emulator and you could boot RT-11. A /23 system will have more boards. -ethan

On Jan 6, 2012, at 1:12 PM, Glen Slick wrote: They're documented in the KDF11-B CPU System Maintenance manual (EK-245AA-MG-001). At least the DUn ones are. - Dave

On Jan 6, 2012, at 2:13 PM, Glen Slick wrote: I think I found it searching for the switch settings some months ago, so there you go. :-) It certainly explained why the ROM displays listed in the KDF11-BA manual were somewhat different from what I was seeing on mine. :-) Glad that whomever I bought the board from saw fit to upgrade it (they're clearly a retrofit; the EPROM windows are covered with bits of floppy disk label). - Dave

On 06/01/12 9:05 PM, Chris Elmquist wrote: That should work, bugs notwithstanding. --Toby

On Jan 6, 2012 6:09 PM, "Chris Elmquist" <chrise at pobox.com> wrote: If you just use the BOOT command or configure for auto boot there are probably restrictions on how the CSR addresses and device unit numbers are configured for the MSCP controllers. If necessary both the KDF11-B and KDJ11-B firmware should let you specify a non-standard CSR address using the BOOT command with the /A option as documented in the manuals. I haven't had any problems booting from Dilog and CMD SCSI SCSI controllers and Dilog and Emulex ESDI controllers using the standard KDF11-B and KDJ11-B firmware MSCP boot. -Glen

Glen Slick wrote: It doesn't exist. The list is published in more than one of the manuals, for example it's in the Micro PDP-11 Maintenance Manual. Here's the list Roger Wallace posted to vmsnet.pdp11 many years ago. It's valid for all the -BE to -BJ versions, with the caveats that the TMSCP boot is only present in the last versions, older versions don't support later hard drives, -BE doesn't support TSV05/TK25 or the MSCP sniffer boot. If S1-1 to S1-6 are all open, autoboot is disabled; if they're all closed, the self-test loops (and does not autoboot, of course). The MSCP sniffer boot first tries all removable-media MSCP devices, then all fixed MSCP devices, and boots from the first it finds with a valid bootstrap. ====================================== S1-8: Console Select -- ON = ANSI CRT (e.g. VT-100) OFF = NOT ANSI CRT (Hard copy TTY) S1-7: Memory Diagnostic -- ON = Run Quick Memory Diagnostics (But the system seems to run this anyway, even with the switch OFF) S1-1 through S1-6: Select Boot Device as follows (0=Open/1=Closed): S1 6 5 4 3 2 1 *** Device *** 0 0 0 0 0 1 TSV05 Unit0 (TK25) 0 0 0 0 1 0 TU58 Drive 0 0 0 0 0 1 1 TU58 Drive 1 0 0 0 1 0 0 RX01 Drive 0 0 0 0 1 0 1 RX01 Drive 1 0 0 0 1 1 0 RX02 Drive 0 0 0 0 1 1 1 RX02 Drive 1 0 0 1 0 0 0 DU0: 0 0 1 0 0 1 DU1: 0 0 1 0 1 0 DU2: 0 0 1 0 1 1 DU4: 0 0 1 1 0 1 DU5: 0 0 1 1 1 0 DU6: 0 0 1 1 1 1 DU: "Sniffer Boot" 0 1 0 0 0 0 DL0: 0 1 0 0 0 1 DL1: 0 1 0 0 1 0 DL2: 0 1 0 0 1 1 DL3: 0 1 0 1 0 0 DEQNA / Unit 0 0 1 0 1 0 1 DEQNA / Unit 1 0 1 1 0 0 0 TK50 0 0 0 0 0 0 Inhibit Autoboot 1 1 1 0 0 0 DECNET / DUV11 1 1 1 0 0 1 DECNET / DLV11-E 1 1 1 0 1 0 DECNET / DLV11-F Other possible combinations are "reserved" or "unused". With luck 8-} , I copied these correctly from by KDF11BJ ROM upgrade kit manual. The DU: "Sniffer Boot" was the default for DEC Micro-11 systems; it tests _removable_ MSCP devices, then _fixed_ MSCP devices, in numerical order and boots the system from the first bootable device found. -- Pete Peter Turnbull Network Manager University of York

On Fri, Jan 6, 2012 at 3:35 PM, Pete Turnbull <pete at dunnington.plus.com> wrote: Aren't there some OS restrictions when using an MXV11-B? Something like you can't run RSTS/E because the MXV11-B on-board memory is non-parity memory and parity memory is required for RSTS/E?

On Fri, Jan 6, 2012 at 6:35 PM, Pete Turnbull <pete at dunnington.plus.com> wrote: Yes. That too. Ah, yes. Good point. I rarely remember the MXV11-B, mostly I think because I mostly worked with systems that had one or more boards of "real" memory and either a DLV11J (in BA-11s) or some type of quad-height quad serial card (in BA-23s). My own first PDP-11/23 was a customer-returned "HASPBOX" from the pre-COMBOARD days of Software Results Corp. It was shipped with 100% DEC hardware and 100% SRC software to be a bisync serial I/O front-end processor for a larger RSTS machine, probably a PDP-11/70. When the customer decommissioned their RSTS box, they didn't know what to do with the little BA11N hanging off of it, so they read the sticker and sent it back to us. I bought it for peanuts... in 1985, $300 got me a KDF11-A, four 32K memory cards (MSV11-D?), an LPV11, a DLV11J, some flavor of DEC sync serial board with a COM5025 USART, and a BDV11. I think I had to buy my own RXV21, and I know I had to buy my own RLV11 ($100 at the time since the RLV12 was just out and didn't need a CD-interconnect backplane, so was very popular). I borrowed a VT100, an RL01, and an LA180 from my PDP-8/a and ran RT-11 V5.0 on it. I made my living for a couple of years on that box. At one point, I even ran the extra backplane wires to manually upgrade it to 22-bit, then upgraded the dual-height memory card that was half-full of 4164 DRAMs, from 128K to 256K IIRC. Lots of soldering. Took three passes to find all the dry joints, but I did get it working with no strange crashes (just crashes caused by my buggy MACRO-11 code. ;-) Fun times. I'm still happy I found someone to pay me to build and program PDP-11s. Great job. No budget for MSCP disks, though. My experience with that came (two years?) later once low-end MicroPDPs were starting to go for cheap. -ethan

Allison wrote: Yep, that's what I used to do on my original 11/23. Bob Schor posted the MSCP boot to vmsnet.pdp11 a long time ago, and I expect copies are floating around the net. But to save exercising Google too hard, here's part of Bob's post from 1994. As Allison says, it's not short. =============================================================== The following is MSCP.MAC, the code for the toggle-in bootstrap for DU0 as listed (almost) in the RT-11 5.6 manuals. When this is assembled, the .SAV image at 76000 will match that of the boot. The first set of comments on the right are the (octal) location and contents of the bootstrap, should you actually need to toggle it in. I am indebted to Jim Crapuchettes for deducing the missing word in the manual listing, and for providing the comments as to what the code is doing. [MSCP is a pretty mysterious protocol. Suffice to say that you build instruction packets in PDP-11 memory, then tell the controller to execute them.] Note that I have used this code, as ODT instructions, to "ram" the bootstrap over a serial line to an 11/73 which had no DU boot. The 11/73 came up in ODT, so all I had to do was to fire up VTCOM and send the ODT-like instructions over the serial line (ending, of course, with 76000G). To my surprise, it worked! ;------------------------------------------------------------------------------ ;This is the MSCP bootstrap as listed in the RT-11 5.6 INS manual ... ; along with its disassembly (by hand!). Additional comments and ; attempts to make "nicer" assembly by ; Bob Schor bschor at vms.cis.pitt.edu (412) 647-2116 (w) ; ;Missing word (at 76102) and most of the explanation supplied by ; Jim Crapuchettes jimc at netcom.com 408-732-0569 ; .asect . = 42 .word 1000 ;-; Set stack pointer for RT-11 - don't "toggle" in . = 76000 ; The contents of R0 must be the MSCP unit number. Although it is set to 0 ; below, it could be manually set to some other value and then execution ; started at 76002. start: clr r0 ;76000/5000 ;; Preset register to 0 (unit) mov #172150, r1 ;76002/12701 ;; Point to IP register ;76004/172150 1$: mov #itabl, r4 ;76006/12704 ;; Point to init/cmd params ;76010/76156 mov #4000, r5 ;76012/12705 ;; Set init step to 1 ;76014/4000 ; Do 4-step controller initialization. Begin by writing any value to IP to ; reset the controller; all the rest of initialization is done through SA. mov r1, r2 ;76016/10102 ;; Copy IP address, write to mov r0, (r2)+ ;76020/10022 ;; IP to init & bump to SA 2$: tst (r2) ;76022/5712 ;; Test for error bit in SA bmi 1$ ;76024/100770 ;; Error = start init again bit (r2), r5 ;76026/31205 ;; Test step bit in SA br 3$ ;76030/401 ;; ????, appears to skip next bic (r1)+, (r5)+ ;76032/42125 ;; ????, seems to be skipped 3$: beq 2$ ;76034/1772 ;; Wait for next step ready mov -(r4),(r2) ;76036/14412 ;; Next init param to SA asl r5 ;76040/6305 ;; Move to next init step bpl 2$ ;76042/100367 ;; Loop thru 4 steps ; Bring unit on-line, read bootstrap (block 0) from the disk and start it up. 4$: tstb -(r4) ;76044/105744 ;; Point to next cmd byte bne 5$ ;76046/1002 ;; Loop thru commands mov pc, r4 ;76050/10704 ;; Point r4 to "clr pc" and clr pc ;76052/5007 ;; go start at location 0 5$: clr r2 ;76054/5002 ;; Init for clearing memory 6$: clr (r2)+ ;76056/5022 ;; Clear memory from loc 0 cmp r2, #17204 ;76060/20227 ;; thru loc 17202 ;76062/17204 blo 6$ ;76064/103774 ;; Loop until done incb @#17101 ;76066/105237 ;; Packet length = 400 bytes ;76070/17101 mov r0, @#17110 ;76072/10037 ;; Set unit number = 0 ;76074/17110 movb (r4), @#17114 ;76076/111437 ;; Move command to cmd pkt ;76100/17114 movb -(r4), @#17121 ;76102/114437 ;; Set parameter from table ;76104/17121 mov #17004, (r2)+ ;76106/12722 ;; Set response packet de- ;76110/17004 ;; scriptor: low 16 address mov r5, (r2)+ ;76112/10522 ;; bits & PortOwn bit mov #17104, (r2)+ ;76114/12722 ;; Set command packet de- ;76116/17104 ;; scriptor: low 16 address mov r5, (r2) ;76120/10512 ;; bits & PortOwn bit cmp -(r2),-(r2) ;76122/24242 ;; Point back to resp desc tst (r1) ;76124/5711 ;; Poll controller to start 7$: tst (r2) ;76126/5712 ;; Wait for resp desc PO bit bmi 7$ ;76130/100776 ;; => 0 == response received tst @#17016 ;76132/5737 ;; Status byte = success (0)? ;76134/17016 beq 4$ ;76136/1742 ;; Yes, go to next command stop: halt ;76140/0 ;; No, stop here... ; NOTE: This table MUST be - immediately preceeded by a zero byte (the HALT ; instruction) because it is the "end-of-table" marker; and immediately ; precede the Initialization Step Parameter table since a single register ; points first to the IStep Params (1 word each) and then to the commands ; (1 byte for the command, 1 byte for the parameter), passing through them ; in reverse. .byte 2 ;; Set byte count to 1000 for OP.RD .byte 41 ;; OP.RD = ReaD .byte 0 ;; 0 parameter for OP.ONL .byte 11 ;; OP.ONL = ON Line ;; .word 20402 ;76142/20402 ;; .word 4400 ;76144/4400 .word 1 ;76146/1 ;; IS4: GO bit .word 0 ;76150/0 ;; IS3: Ring base high address .word 17204 ;76152/17204 ;; IS2: Ring base low address .word 100000 ;76154/100000 ;; IS1: bits- ;; [15] = 1, [14] (WR) = 0, [13:11] (cmd ring ;; size) = 0, [10:8] (resp ring size) = 0, [7] ;; (IE) = 0, [6:0] (int vect/4) = 0 :: command ;; and response rings = 1 element, no inter- ;; rupts and no interrupt vector. itabl =: . ;need pointer to end of table ;76000g to start ODT .end stop ;For RT-11 only, don't "toggle" in -- Pete Peter Turnbull Network Manager University of York