Clearpoint QED1 4MB Qbus PMI Memory

[pbirkel@gmail.com]

Thanks! Also remember everyone that the 11/84 versions of the DEC PMI have a bug where they will drop data and screw up transactions from Burst mode/Block mode DMA transfers to the J11 cache. This will corrupt your RSX11 disk at random times and is nasty.

Yes, that is something to consider on the MSV11-J! The last two etch revisions (-D for 1 MB, -E for 2 MB) are not affected, but earlier revisions (-B and -C, I've never seen a -A) are.

I'm trying to square these two statements with these comments from Pete Turnbull: https://classiccmp.org/pipermail/cctech/2018-July/033089.html

"
> The DEC PMI memories are the MSV11-J and (I think) the MSV11-R. The latter is
> rare, but the -J's can be found.

Correct, but bear in mind that there are 4 versions of the MSV11-J; the
-JB and -JC versions have different ASICs and don't support QBus CPUs.
Specifically, they don't support block-mode transfers and don't work
properly even as PMI memory except in an 11/84, while the -JE and JD
versions support everything. Bill would want the -JD (2MB) version (the
-JE version is 4MB so too big).

--
Pete
Pete Turnbull
"

@czunit appears to state that there is a problem in 11/84 PMI rather than a problem in the memory implementation of the MSV11-J. @glitch appears to state that the (only?) problem is in early revs of the MSV11-J and he's agnostic about where the module is employed. Pete states that 11/84 PMI works in the early revs of the MSV11-J as well as the later ones, which seems to contradict @czunit. Arrgh!

Why would PMI fail in an 11/84 backplane -- which is a Qbus -- but not in a regular Qbus backplane? Or vice versa? I infer that the problem originates with a device controller which wouldn't be located directly on the Qbus in an 11/84 backplane (it would be interfaced via the UBA). Gunkies appears to clarify this understanding with the following statement:

"Although it can function in QBUS-only mode (but see the note below about the -JB and -JC versions), it is really intended for use with a PMI-capable CPU, such as the KDJ11-B. In systems such as the PDP-11/83, where the primary I/O bus is the QBUS, the card 'speaks' PMI to the CPU, and QBUS to the devices. In the PDP-11/84, PMI is used for communication with both the CPU and the devices (via the KTJ11-B UNIBUS adapter)."

Now ... for the early revs Pete states that only the 11/84 worked properly whereas @czunit states that only the 11/84 fails. Gunkies appears to agree with Pete:

"The -JB and -JC are earlier versions, which contain an error which prevents them working properly as QBUS memories (i.e. in the PDP-11/83); they are only usable in the PDP-11/84."

Elided seems to be a statement to the effect that the early-rev problem lies in "speaking QBUS to the devices" (while PMI to the CPU). Am I understanding the issue here correctly?

FWIW all of the photos of 11/84 module configurations that I've seen have the CPU installed _ahead_ of one or two MSV11-J; I've never seen the MSV11-J installed upstream in a traditional PMI configuration. AFAICS from the 11/84 documentation PMI is active with the MSV11-J installed downstream of the CPU, although it can apparently be deactivated under software control. I infer that the (relatively) anomalous module order in the 11/84 is because the UBA requires PMI access and therefore C/D _always_ operates as a PMI bus.

I need to reread EK-1184E-TM-001_Dec87.pdf a few more times regarding how this all works in practice!

 

[glitch]

It's my understanding that the PDP-11/84 (I don't have one) is a special case due to the KTJ11-B, and the interaction is why the MSV11-JB and -JC work there but not on the all-QBus systems. Again, this is my understanding from digging through technical manuals, micronotes, diagnostic listings, etc. -- I don't actually own a PDP-11/84. From the notes, I would suspect Pete Turnbull's remark about the lack of block mode support is the root of the issue. This may indeed be limited to non-PMI bus masters, but that's effectively total breakage on QBus unless you're doing something weird like running a PDP-11/83 with PMI memory and only using a DLV11 to emulate TU58 for storage! (that is the only non-DMA block storage device on QBus I could think of offhand that works on Q22)

I would agree that the -JB and -JC revisions are effectively faulty designs, and that there is not a problem with PDP-11/84 PMI.

PMI passes through on the CD interconnect from board to board. The PDP-11/84 QBus section is wired special, probably necessary due to the KTJ11-B having to be between Unibus and QBus slots. On all other standard QBus backplanes, you should have to have the PMI boards ahead of the CPU to make PMI work -- the PMI signals are only on the component side of the KDJ11-B (you can easily confirm this with a visual inspection). If you place the PMI memory boards after the CPU, they function as standard QBus memory as long as they're in a Q/CD slot. If you place a MSV11-J in a Q/Q slot, it will be damaged.

There is probably also the caveat that the MSV11-J needs to be in a Q/CD slot with nothing incompatible below it...I'm thinking of a dumb situation like putting half of a RLV11 below a MSV11-J. I bet it's at least not happy, if not damaged.

TL;DR: PDP-11/84 is a special case, and the only normal use case for MSV11-JB and -JC.

 

[czunit]

It's my understanding that the PDP-11/84 (I don't have one) is a special case due to the KTJ11-B, and the interaction is why the MSV11-JB and -JC work there but not on the all-QBus systems. Again, this is my understanding from digging through technical manuals, micronotes, diagnostic listings, etc. -- I don't actually own a PDP-11/84. From the notes, I would suspect Pete Turnbull's remark about the lack of block mode support is the root of the issue. This may indeed be limited to non-PMI bus masters, but that's effectively total breakage on QBus unless you're doing something weird like running a PDP-11/83 with PMI memory and only using a DLV11 to emulate TU58 for storage! (that is the only non-DMA block storage device on QBus I could think of offhand that works on Q22)

Well, an RXV11 would work just fine. However the bigger problem is that block mode DMA appears to cause a cache coherency issue on an 11/83 class system but it is very intermittent. So every once in awhile your write to disk will be a corrupted block, which will total the system over time.

I spent a while a few years ago fuzzing this out with my MTI ESDI disk controller. It's a really fast controller, and it does have in the MTI console the ability to turn on and off all sorts of features including burst mode DMA and block mode DMA. I think the problem was block mode: That's where the Q-bus sends a starting address, then just clocks data on the lines over and over and the memory increments the address it should go. Brings Q Bus speed up to full Unibus (where the address/data lines are all together) but can confuse the cache on the CPU.

I believe they worked fine when I set the board to not do burst mode DMA, but the performance sucked more than just running a Q/Q memory so there you go.

Otherwise you have to do DMA the "old" way we did with earlier memories where each DMA cycle required one bus cycle to specify address and the second to specify the data word, then the next an address.... 50% slower and part of the reason the Q Bus was always the "slow" bus in the days of the 11/03 and 11/23.

The 11/84 doesn't have this problem because of the way the Unibus map does transfers to PMI memory. They built the 11/84 first, sold a bunch, sold a bunch of 11/83 systems and promptly found the problem. Requires a different ASIC mask, so old boards were flagged to only run on 11/84 and new boards would work on 11/83 or 11/84.

I think this is also why the 11/84 can't run multiple Q bus devices (they would do the transfer using Q-Bus mode instead of speedy PMI mode) but there is another issue.

The C/D bus on the 11/84 is a true "bus". On the BA11/S and BA23 the C/D bus goes from one device to the one below and above it, but they are not all connected. Thus you could have two separate RLV11's (for example) in a single BA11/S without them interfering with each other. However on the 11/84 the wires are bussed through to all boards, this is why the CPU can be slot 1 and memory slot 2/3 but with an 11/83 the CPU is at the "bottom" and its' top wires connect to the memory board above it.

Weird stuff.

I would agree that the -JB and -JC revisions are effectively faulty designs, and that there is not a problem with PDP-11/84 PMI.

PMI passes through on the CD interconnect from board to board. The PDP-11/84 QBus section is wired special, probably necessary due to the KTJ11-B having to be between Unibus and QBus slots. On all other standard QBus backplanes, you should have to have the PMI boards ahead of the CPU to make PMI work -- the PMI signals are only on the component side of the KDJ11-B (you can easily confirm this with a visual inspection). If you place the PMI memory boards after the CPU, they function as standard QBus memory as long as they're in a Q/CD slot. If you place a MSV11-J in a Q/Q slot, it will be damaged.

There is probably also the caveat that the MSV11-J needs to be in a Q/CD slot with nothing incompatible below it...I'm thinking of a dumb situation like putting half of a RLV11 below a MSV11-J. I bet it's at least not happy, if not damaged.

TL;DR: PDP-11/84 is a special case, and the only normal use case for MSV11-JB and -JC.

 

[glitch]

Thanks for the thorough explanation on the peculiarities of the PDP-11/84! Your experimenting clears up a lot of questions, it seems.

 

[pbirkel@gmail.com]

The C/D bus on the 11/84 is a true "bus". On the BA11/S and BA23 the C/D bus goes from one device to the one below and above it, but they are not all connected. Thus you could have two separate RLV11's (for example) in a single BA11/S without them interfering with each other. However on the 11/84 the wires are bussed through to all boards, this is why the CPU can be slot 1 and memory slot 2/3 but with an 11/83 the CPU is at the "bottom" and its' top wires connect to the memory board above it.

Thanks for the answers guys! It turns out that the UBA article on gunkies makes this point as well: https://gunkies.org/wiki/KTJ11-B_UNIBUS_adapter Other relevant information there too.

 

[Steve Toner]

To get things back on track:

I noticed at power-up, my QED1's lights go G->R->G->Y. This is running w/jumpers set for 4MB. If I set the jumpers for 2MB, the lights go G->R->G
Pressing Restart gives the same pattern a couple of times, but then doesn't flash red after that (i.e., in 2MB configuration, just stays green).
Removing the top right (fingers pointing down, handles on top) chip gives G->Y & passes POST. VMJAB0 reports "PROGRAM CSR COULD NOT BE DETERMINED" but runs anyway and reports no errors on pass 1.

Switching back to 4MB, removing the lower left RAM chip results in a memory error:
Expected = 177776
Bad = 155157
Address = 12000000

This is weird.

Replacing that chip & removing from row 4, 7th chip from right (easiest to access for removal) gives a memory error:
Expected = 125252
Bad = 125052
Address = 12310104

OK, that seems more like it. A single bit error when removing a single chip.

I don't have a way to test individual RAM chips right now, but I'll play around with removing individual chips some more and see what happens...

 

[Steve Toner]

...and by pulling the RAM chips one by one & running the power on test, I was able to find a bad one. No bent pins, just bad. Replaced it and now I have a solid green light when configured for 4MB!

The bad news is that the power switch on my BA-11S now refuses to latch in the ON position. It was always (since I got the box) somewhat flaky, but I seem to have worn it out with all these power cycles

 

[Terri Kennedy]

Why would PMI fail in an 11/84 backplane -- which is a Qbus -- but not in a regular Qbus backplane? Or vice versa? I infer that the problem originates with a device controller which wouldn't be located directly on the Qbus in an 11/84 backplane (it would be interfaced via the UBA).

This is just more of the bugs / glitches / errors that the KDJ11 CPU and its relatives were infested with. We're probably all familiar with the several rounds of "This CPU won't work with that FPA" stuff. Even after that was fixed, Harris did a multiple sets of new masks for both the DC334 and DC335 parts. To qualify as a DCJ11-AE (18MHz crystal, works with FPJ11) the DC334 revision has to be 1 and the DC335 revision has to be 11. Yet Harris went to DC334 revision 4 and DC335 revision 16. Not even DEC knew what the changes were.

The gate arrays used on the 11/73 and /83 CPU boards got flaky above 18MHz, which is why DEC never pushed Harris too hard to meet the original 20MHz crystal spec. The 11/93 and various J11-based Mentec boards didn't use those gate arrays, and I have an 11/93 that's solid at 22MHz. I actually have some of the last DCJ11's produced (mid-1998 date codes, Harris logo on the white ceramic carrier) and I should probably try for 24MHz at some point.

The DCJ11 lost its CIS option (an early version of the J-11 Programmer's Reference says "J-11 CIS performance equal to the 11/44.") early on.

The PMI memory boards were yet another botch. The Unibus adapter in the 11/84 did not generate the type of bus cycles that caused the bad boards to corrupt data, so they were sold for use in the 11/84 only instead of being reworked or scrapped.

Bob Supnik said that the J-11 was intended to "Put a capstone on the PDP-11". IMHO, it came close to being a tombstone.

 

[Hunta]

The gate arrays used on the 11/73 and /83 CPU boards got flaky above 18MHz

https://forum.vcfed.org/index.php?threads/my-kdj11-b.1204310/

 

[Terri Kennedy]

https://forum.vcfed.org/index.php?threads/my-kdj11-b.1204310/

You'll note that a number of the posts in that thread were by me.

As the fabrication process matured, DEC probably got higher wafer yields and higher-binning parts. Since DEC never offered a J-11 based system running faster than 18MHz, there was no need for them to pick combinations of parts that would work at the higher speeds. It was probably luck of the draw, aided by later production dates.

 

[glitch]

...and by pulling the RAM chips one by one & running the power on test, I was able to find a bad one. No bent pins, just bad. Replaced it and now I have a solid green light when configured for 4MB!

Excellent! One of mine had three dead RAM chips, found by pulling all the RAM and testing in an Intel AboveBoard 286 in an IBM 5170 PC/AT. Before that, I'd get a yellow light part of the way through the 9-step test, and never had an error during many rounds of `VMJAB0`. I think at this point we can definitively say a yellow light is a problem.

The bad news is that the power switch on my BA-11S now refuses to latch in the ON position. It was always (since I got the box) somewhat flaky, but I seem to have worn it out with all these power cycles

The good news about the bad news is that's a standard switch that's still made! I had to replace one a few years ago that was mushy and intermittent when I got it. If you can't find a part # I can check our PO system to see if we still have record of it. While you have the supply open, you might as well recap, if you are comfortable doing it and it hasn't been serviced in a long time/ever.

 

[glitch]

I got in contact with Noel and got an account set up on Gunkies, I am planning on condensing this thread down into an article on the QED1. Does anyone here object to me using their information/pictures and giving credit on it?

 

[shirsch]

As far as my posts go, have at it!

 

[czunit]

Feel free to. One of these days I should do a Gunkies account, but I've got other things going. Glad to see boards work!

 

[Steve Toner]

I got in contact with Noel and got an account set up on Gunkies, I am planning on condensing this thread down into an article on the QED1. Does anyone here object to me using their information/pictures and giving credit on it?

No objections here. Please share.

Interestingly, Noel himself was looking for documentation on these boards six years ago (!)
Apparently nobody ever came up with it, but I have a hard time believing that all copies of the documentation have been discarded. Somebody, somewhere, has to have one...

I think at this point we can definitively say a yellow light is a problem.

Yes, a yellow light seems to indicate that a correctable error exists. Most likely (based on our common experience) one or more bad RAM chips. There's still some magic voodoo going on that allows the board to detect a bad RAM chip and apparently map one of those 4 extra chips in its place...

 

[shirsch]

Not even Dave McGuire has a copy of the docs. I suspect that one or both of Keyways or VARx has them, but I've been hesitant to ask.

 

[Steve Toner]

The good news about the bad news is that's a standard switch that's still made! I had to replace one a few years ago that was mushy and intermittent when I got it. If you can't find a part # I can check our PO system to see if we still have record of it. While you have the supply open, you might as well recap, if you are comfortable doing it and it hasn't been serviced in a long time/ever.

Yes, a part number would be wonderful. Meanwhile, here's my workaround:

DEC conveniently provided a stud next to the switch, so a .275" spacer (I used nylon), an 8-32 hex nut and a scrap of PC board clamps the switch in the ON position

 

[Steve Toner]

Not even Dave McGuire has a copy of the docs. I suspect that one or both of Keyways or VARx has them, but I've been hesitant to ask.

Or, it's possible that the CHM has a copy, but hasn't taken the time to do a full inventory:
Mark Ellson collection of brochures and product specifications

 

[Terri Kennedy]

Not even Dave McGuire has a copy of the docs. I suspect that one or both of Keyways or VARx has them, but I've been hesitant to ask.

I'd say go ahead and ask Ron at VARx. He's been very supportive of the hobbyist community.

Note that he moved some years ago and has downsized his inventory a bit, but he still has quite a few rarities.

 

[Steve Toner]

The good news about the bad news is that's a standard switch that's still made! I had to replace one a few years ago that was mushy and intermittent when I got it. If you can't find a part # I can check our PO system to see if we still have record of it. While you have the supply open, you might as well recap, if you are comfortable doing it and it hasn't been serviced in a long time/ever.

BA11-S Field Maintenance Print Set shows it as a 7A 250V Circuit Breaker, DEC Part #121862-00

Can't find a cross-reference for that part number - Is it a Schurter 4435.004 (TA35-CBDWF070C0)? Looks pretty close, but I'm not sure the cutout dimensions are correct...