pdp11/84 PMI memory: What is the problem with Q bus?
cz at alembic.crystel.com
Tue Apr 21 15:17:07 CDT 2020
Thanks Mark! Actually this was just the boards from the 11/84 (no idea
what happened to the chassis, drat) so it's an 11/84 CPU (18mhz, FPP
chip installed), 2 PMI boards (one old 2mb, one new 1mb) a console board
of some sort and the Unibus map.
I popped this into my BA23 to speed things up a bit in place of my quad
height 11/73 CPU with 2mb memory. So far it seems to work, and with the
CA memory in the PMI slot managed to boot RSX11M 4.2 and compile up EMPIRE.
My guess is the 11/84's Unibus talks directly to the PMI bus and
orchestrates the data transfers, but there is something wrong when the
PMI memory is accessed on the true Q bus. That would not happen on an
11/84 (CPU and Map use PMI only) but when you have a Q bus DMA device it
probably manifests at random. It's possible the MTI card is throttling
the DMA to single mode instead of hog mode, wonder if I want to screw up
my disk to verify this....
Drat. On the positive side it's chock full of 256k chips, which I could
pull off and put on the EA board to bring it up to 2mb memory. I have
air heat tools and a pre-heater so getting the chips off should be
pretty basic. Getting them on the new board though could be a pain since
all the holes are soldered over....
No way to reprogram or fix it I assume?
On 4/21/2020 11:48 AM, Mark Matlock via cctalk wrote:
>> Date: Sun, 19 Apr 2020 15:29:44 -0400
>> From: Chris Zach <cz at alembic.crystel.com>
>> To: CCTalk mailing list <cctalk at classiccmp.org>
>> Subject: pdp11/84 PMI memory: What is the problem with Q bus?
>> Message-ID: <3efa4105-3d3d-bb98-0358-8c46fca0fdcf at alembic.crystel.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>> So I picked up an 11/84 CPU, 3mb of memory, and a 11/84 Unibus card on
>> Ebay. Goal is to speed up my fastest 11 here
>> For boot time, the diagnostics run in 13 seconds (from when it starts to
>> prompt) on the 11/73 board I have and 13 seconds on the 11/84 board.
>> This is with a camintonn 2mb half height memory board.
>> Put in the first PMI module above the 11/84 CPU and tried it out. This
>> is a CA rev board which apparently only works in a Unibus pdp11 and not
>> a Q-bus one. Apparently it does work.
>> So what exactly was the bug with the older PMI memory? Block mode DMA,
>> I'm using an MTI ESDI controller which can do 16 word block DMA on Q
>> Bus. Something else?
> Congrats on the PDP-11/84! I also have a PDP-11/84 that uses one of Joerg’s Hoppe’s
> UniBone devices to simultaneously emulate MSCP disks, RL02 disks (including the
> RL02 Load/Ready/WriteProtect/ and fault lights) and a DL11.
> I have a question about something you said above, that you are using a MTI
> ESDI disk controller and then you mention Qbus block mode DMA. Are you able to use a
> Qbus MTI controller in the 11/84’s Qbus section of the backplane? This is something
> I’ve often wondered about but never tried.
> Also, you mention putting the PMI memory above the 11/84 CPU. In the 11/83
> Qbus backplane this is of course determines whether the M8637 memory is accessed via
> Q22 or PMI. In the 11/84 System Maintenance Guide Figure 2-8 shows the
> CPU card above the memory which if you were to do this in the 11/83 would mean
> that the memory will be accessed via Q22 and essentially become an 11/73.
> In my 11/83 I have run both configurations to understand and measure the benefit of PMI.
> As has been mentioned the 11/84 can use any of the M8637 memory boards but the
> 11/83 can only use the M8637-D or -E versions. For anyone who is curious about what
> Happens when a M8637-C version board is used as PMI memory in an 11/83 I can speak
> From experience. This was running RSX11M+ and it boots fine but after a few minutes if
> The system is active, the console starts to report that various installed tasks are corrupted
> And the system will XDT a bit later. After this the disk is corrupted and you will need to restore
> the system disk from backups after you get the correct PMI memory boards.
> I’m not completely sure how the write DMA operations put bad data through the disk controller
> (I was using an Emulex UC07 with a SCSI2SD) into the disks but that is what happens.
> Mark Matlock
More information about the cctalk