22 Apr
2020
22 Apr
'20
10:17 p.m.
Date: Tue, 21 Apr 2020 16:17:07 -0400
From: Chris Zach <cz at alembic.crystel.com>
To: cctalk at classiccmp.org
Subject: Re: pdp11/84 PMI memory: What is the problem with Q bus?
Message-ID: <27647f0e-19d4-b484-d288-e9f3bb715363 at alembic.crystel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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.
Chris,
I understand now. I also have a PDP-11/83 in a BA123 box and the CPU and
PMI memory (M8637-E) can move from the Qbus box to the 11/84 box and work fine
In either. I spent a good bit of time tinkering with the 11/84 power supply which did not
Work until I put a M7556 minimum load module in it. Basically the +/- 12 Volts needs a
Load or you get a hung bus error. Also, with the Unibus you have to pay attention to
The NPR/NPG grant jumpers.
For disks on the QBus systems I used the UC07 and SCSI2SD. The UC07 can be
can be configured for block mode transfers and I think it is doing it. I guess I?d need
to hook up a logic analyzer to know for sure.
The 11/84 uses a UniBone and when it is emulating a MSCP disk, it can do 150
I/Os a second (using IOX on RSX11M+) The 11/83 using the UC07 and a SCSI2SD
Does about 60 I/Os per second. I think the UC07 could go faster but is limited by the
SDcard interface. I need to put a fast real SCSI disk on it sometime and see what it can
do.
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?.
What is the model # for your MTI disk controller?
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?.
Moving the RAM chips sounds a bit tedious but would certainly be possible.
No way to reprogram or fix it I assume?
Are you asking about making the M8637-B or -C into the -D or -E? If so I?ve
never seen any reference to doing that. I was very fortunate that the person
Who sold me the M8637-C was willing to trade it for a -E.
Mark
23 Apr
23 Apr
5:51 p.m.
Oh I'm using an MTI MQD13 card as my disk controller. It is a MCSP
controller that can interface up to 4 ESDI drives to Q Bus. Pretty fast.
Just checked the configuration and block mode DMA *is* off. Wonder what
happens if I turn it on...
It does have a lot of knobs to fiddle with, so maybe I can figure out
what works and what does not for these memory boards. Experimentation!
C
DMA CHARACTERISTICS: DRIVE 2... ESDI
BLOCKMODE............ OFF FIRST LOGICAL...... 002
BURST LENGTH (WORDS). 16 SECOND LOGICAL..... 006
THROTTLE............. ON DRIVE 3... ESDI
DWELL us............. 1.6 FIRST LOGICAL...... 003
SECOND LOGICAL..... 007
SEEK MODE................ OVERLAPPED
SEEK OPTIMIZATION.... ELEVATOR COMMAND QUEUE.......... 008
FAIRNESS VALUE....... 016
On 4/23/2020 1:17 AM, Mark Matlock via cctech wrote:
Date: Tue, 21
Apr 2020 16:17:07 -0400
From: Chris Zach<cz at alembic.crystel.com>
To:cctalk at classiccmp.org
Subject: Re: pdp11/84 PMI memory: What is the problem with Q bus?
Message-ID:<27647f0e-19d4-b484-d288-e9f3bb715363 at alembic.crystel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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.
Chris,
I understand now. I also have a PDP-11/83 in a BA123 box and the CPU and
PMI memory (M8637-E) can move from the Qbus box to the 11/84 box and work fine
In either. I spent a good bit of time tinkering with the 11/84 power supply which did
not
Work until I put a M7556 minimum load module in it. Basically the ? 12 Volts needs a
Load or you get a hung bus error. Also, with the Unibus you have to pay attention to
The NPR/NPG grant jumpers.
For disks on the QBus systems I used the UC07 and SCSI2SD. The UC07 can be
can be configured for block mode transfers and I think it is doing it. I guess I?d
need
to hook up a logic analyzer to know for sure.
The 11/84 uses a UniBone and when it is emulating a MSCP disk, it can do 150
I/Os a second (using IOX on RSX11M+) The 11/83 using the UC07 and a SCSI2SD
Does about 60 I/Os per second. I think the UC07 could go faster but is limited by the
SDcard interface. I need to put a fast real SCSI disk on it sometime and see what it can
do.
6:35 p.m.
Well I turned on block mode DMA on my MTI controller, booted RT11 5.5,
did an init on VM0: and tried to copy a .dsk file of 2500 blocks in size
with 2mb of PMI memory from an 11/84 (CA, bad memory for Q Bus).
First time was not good:
.copy dungeo.dsk vm:
Files copied:
?PIP-F-Input error DK:DUNGEO.DSK
.dir dungeo.dsk
DUNGEO.DSK 2500P
1 Files, 2500 Blocks
34488 Free blocks
Second time was better, took ~4 seconds.
.copy dungeo.dsk vm:
Files copied:
DK:DUNGEO.DSK to VM:DUNGEO.DSK
Switched off block mode and tried again:
Takes 5 seconds.
Changed burst length from 16 words to 2:
Took 25 seconds.
4: 23 seconds
16: 5 seconds
Turning off the throttle mode (which requires Block mode and 16 word
transfers) and it took 4 seconds. No speed increase.
Then I decided to try using 2mb of crummy Q bus memory:
16: 5 seconds
8: 15 seconds
2: 26 seconds
Didn't do 4.
So it looks like what really speeds things up is having a large burst of
Q busy transfers, going from 2 word transfers to 16 speeds things up by
a factor of five. Makes sense, controller is spending less time setting
up the transfer. Somewhat interesting that PMI doesn't really help, I
understand that the controller is talking to PMI at normal Q bus speeds,
but I would expect something for the CPU to manage the VM: driver.
Unless the CPU just says "Oh, VM:? Point your data right into memory and
be done with it".
Moral: PMI memory does not really speed up disk to memory performance.
Good to know. Anyone know a good benchmark to see if PMI is worth
anything in terms of performance? Maybe the unibus map interfacing
directly to PMI speeds things up a lot by allowing full hog mode DMA
(which in theory could mean that an 11/84 could run a RH11-C controller
and keep up with disks like the RM02 and RM05)
Thinking along those lines, was the 11/70's MASSBUS channels nothing
more than RH11-C's attached to the old FASTBUS on the 11/45 cpu core
(which is what an 11/70 really is, with cache) or did they port right to
the memory box?
C
1703
days inactive
1704
days old
2 comments
2 participants
participants (2)
-
cz＠alembic.crystel.com -
mark＠matlockfamily.com