Pete Turnbull wrote: I'm somewhat confused by this, I know how and why you need grant cards in a Unibus machine. But I thought the Qbus made away with that need, although I have read something about it being needed for certain cards and that some controllers need to be the last card. Anyway, I have mine in the order: CPU, MEM, SLU, TERM, with some space between for easier handling. The backplane is not the serpentine version, when I got it, it had a RL01 controller in it (I got two RL01 drives too) which I believe need the straight backplane. I will check the console cable, it came with the machine but is home made, it goes directly from the card (i.e. no cab kit). I'm fairly certain of the baud speed, the manual was quite clear on the jumpering on the DLVJ1 (I call it that because the pdp-11 field guide lists it as such). Thanks Pete and Ethan /Pontus.

On 12/1/09, Pontus Pihlgren <pontus at update.uu.se> wrote: The "difference" in terms of grants and slots and jumpers is that you don't have to modify your Qbus backplane to have a DMA-capable (NPR - non-processor request) card in a single slot, but you do for Unibus. The Qbus still has a grant chain for interrupts just like the Unibus. There is a Qbus grant card, M9047, that looks very similar to the Unibus G727 (and descendants) grant card, but the bridged pins are slightly different (and the handle is Magenta, not Green). When we were making Qbus and Unibus periperals, we stuffed one of our own Unibus grant cards (w/NPR jumper) in every box - I wanted to make a version that could be rejumpered to work in a Qbus backplane, but we had so many Unibus grant cards on the shelf that we never needed to order more cards. The order is fine, but unless you have no blank slots between the CPU and SLU, you might have problems. Thanks to Pete for reminding me that you can have space above the BDV-11 and it won't matter. It's been a few years since I loaded up a Qbus (all of mine are pretty well set these days). The card that really matters is the RQDX1 - you can't put things behind it because it doesn't pass grant. DEC broke their own rules there, but since they expected you to install the RQDX1 in a BA23 and the cable for the distribution board comes up from the bottom, there's little reason *not* to put the RQDX1 in last. It doesn't have to be in the bottom-most slot of the entire backplane, but it does need to be the bottom-most installed card in the backplane. That should be the "CD" backplane (can't remember the part number). I have one like that, with an RLV11 as well. Yes... dual-height cards just stack down the left edge. If you are going right into the SLU card, check that you are in the correct port (all the way left or all the way right - I'd have to go look at a machine or read the handbook to be certain), and do check the baud rates. Of course what we usually did when we weren't sure of the baud rate was to set the terminal to the most common ones and poke at it - it was faster to check 3-4 baud rates that way (300, 1200, 9600, at least) than to tear apart the machine. If that didn't work, we did it the long way and examined the hardware. Of course, as pointed out further up this thread, there are some details about the specific wiring for even a direct cable - the necessary information is in the Microcomputer Peripherals Handbook - some DEC serial connections are straight RS-232 (1488/1489 drivers), some are differential (9636/9637drivers) and may require a jumper or converter. As for the name, when it first came out in the 1970s, it was called the DLV11J, since other SLUs were the DLV11E, etc. DEC started renaming certain cards with the newer Qbus convention (RQDX1, et al.) in part, I think, to get rid of the '11' and in part to reassure the customers that this card will work in a VAX - thus DLVJ1. The renaming might have worked for other cards, but I have honestly never seen a DLV11J (or DLVJ1) in a MicroVAX, only in a PDP-11, so for me, the old name will stick. -ethan

On 12/1/09, Pontus Pihlgren <pontus at update.uu.se> wrote: Sorry for that. Your written English is quite good, but I understand that indirect and conditional expressions in English can be hard to untangle, especially for non-native speakers/readers. You should not have any spaces between CPU and memory and the SLU. It matters because you need to keep the grant chain unbroken. You can install the boards sequentially with no gaps (slot 1, slot 2, slot 3), or you can find some M9047 Qbus grant cards to place between CPU and memory and the SLU. That sentence above is complex and conditional because as Pete pointed out, you *can* have gaps in front of the BDV11 terminator - it does not require a continuous grant chain. If you are configuring a Qbus machine, you should have the Microcomputer Handbook and the Microcontroller Peripherals Handbook are not as simple to set up as modern PC hardware and have a number of issues that are well documented but not obvious to a new user. -ethan

On 03/12/2009 22:38, Pontus Pihlgren wrote: That should be fine. Then, assuming the cable really is correct (have you tried swapping Tx and Rx?), is plugged in to the correct port on the DLV11-J, and the baud rate is sensible or close to correct, either: -- the cable has a broken wire or a short -- the DLV11-J has a blown RS232 transmitter IC (unlikely, if you've tried two of them) -- port 3 isn't actually set up as a console port. It's also possible you have a damaged backplane preventing the DLV11-J description :-)) that's not plausible. Check the C1 and C2 jumpers on the DLV11-J. If you hold it component-side up with the SLU connectors at the top, they're at the lower left, just below the address jumpers. They must both have a link the three). Any other setting will prevent port 3 operating as a console. Also, the base address of the DLV11-J has to be one of 176500 (the standard base address) or 176540 or 177500, otherwise even setting C1 and C2 won't work. What you describe is exactly what you should expect. With the HALT switch up, booting the machine causes the processor to behave according to the boot mode set on its jumpers, which is commonly to start execution at the standard bootstrap address of 173000. That executes the diagnostic code in the BDV11, which (with its normal settings) does some processor and memory tests, turning LEDs off as it completes each test and sizes the memory, sends a prompt to the console ("XX<CRLF>START?", where XX is the memory size) and then waits for you to type either "Y" or a 2-character device code. With the HALT switch down, the CPU enters the halted state, without executing any of the code in the BDV11 ROMs, so all the BDV11 LEDs remain on. I thought that starting with the halt It will indeed do that. But you're not getting any serial data to the console terminal so you don't see that. -- Pete Peter Turnbull Network Manager University of York

On Fri, December 4, 2009 5:52 pm, Pontus wrote: 4K for the I/O page.. -Dave -- Dave McGuire Port Charlotte, FL

On 05/12/2009 11:46, Pontus Pihlgren wrote: They will. The MSV11-D memory and your H9273 backplane will support 18-bit addressing, and so as long as you don't try to run things as a 22-bit system, they'll work fine. A KDJ11-A or KDJ11-B will happily work as an 18-bit system if that's what they're in, just as your KDF11 does (it's also 22-bit, if it has the MMU). There's no practical way to upgrade the MSV11-D to 22-bit, but if you do want to upgrade the backplane, it's not very hard to link together the relevant pins for the additional 4 signal lines by soldering wire-wrap wire down the backplane. If you do that, the system, including the MSV11-D will still work fine as an 18-bit system so long as you don't try to put memory in the area from 256KB to 4MB. If you want to go further than 256KB, remember that your BDV11 is also only 18-bit, unless it's Revision F or later. However, there's an ECO to convert it to 22-bit if necessary. And if you want more memory than 256KB, you'll need to replace the MSV11-D with something else. Early DLV11-J boards are supposedly not compatible with even KDF11 processors, but I can't remember why. Anyway, yours works, apparently, so presumably it's not too early, and will also with with a KDJ11. -- Pete Peter Turnbull Network Manager University of York

Ethan Dicks wrote: Pontus, double check your backplane number to make sure that it truly isn't a serpentine type. If you *do* have a serpentine backplane, and you stack the boards down the AB slots only, you'll have gaps in the grant chain. In my experience DEC labeled the backplanes on the upper side of the backplane sockets, which is visible only if you remove the cage/backplane from the BN-11 box. Here are the four types that I have experience with: An 11/23PLUS in a BN-11 box that has a H9276A backplane. This *is not* serpentine. An 11/23 in a BN11-NC box that has a H9273 backplane. This *is not* serpentine. An 11/23 in an OEM box with a H9275-A backplane. This *is* serpentine. A couple of 11/03s in BA-11M boxes with the H9270 backplane. This *is* serpentine. So, as Ethen, Pete and others have suggested, check everything with the Handbook, and make sure you know which backplane you have. -- Jared

On 12/1/09, Pete Turnbull <pete at dunnington.plus.com> wrote: Very nice. Thanks for gathering all that info into one document. It reminds me that I need to check the part numbers in my "Tri-Node" - a CompuServe-built cabinet with *three* independent 9-slot DEC Qbus backplanes, three PSUs, three boot switches, etc. I got it at the curb (totally gutted) about 6 years ago when someone was cleaning out a rack at the Hilliard Data Center that started out as the replacement CompuServe headquarters but became a WorldCom facility after the split. I was contemplating loading it up with three KDF11 boards (since I have those already) and running three different OSes on it simultaneously - RT-11 on one for sure, possibly 2BSD on another, and TBD on the third. I could drop RSX-11 on the last, but ISTR RSX-11 is rather poky on an F-11 (not that RSTS is fast on a small machine). -ethan