17 Aug
2015
17 Aug
'15
2:43 p.m.
Now that I (hopefully) have my PDP 11/23 running (it passes CPU and memory
tests, anyway), I've been messing with my RLV11 so I can use my RL02.
For a first step, I'm trying to run the VRLBC0 diskless diagnostic to check
the controller. I checked that the address and vector switches are set to
the defaults according to he manual, and also verified them with a
multimeter.
The manual says the default vector address is 330, though the diagnostics
default to 160. I tried it both ways with the same result, though I should
be on 330.
I'm not actually sure what "BR LEVEL" refers to, so I left that at the
default.
This is a PDP 11/23 with an H-9273 backplane. I have the M8186, M8067,
M8043, then the two RLV11 boards, M8013 and M8014, then an M8012.
Here's a sample run. It appears to start, but never does anything else. If
I give it a bad address it does complain, so I think I have the switches
correct.
Does anyone know what I might try next? Thanks!
.R VRLBC0
VRLBC0.BIC
DRSSM-G2
CVRLB-C-0
RLV12 DISKLESS
UNIT IS RLV12, RLV11, OR RL11
RSTRT ADR 145702
DR>START
CHANGE HW (L) ? Y
# UNITS (D) ? 1
UNIT 0
RLV12 (L) Y ? N
RLV11 (L) Y ? Y
CSR ADDRESS (O) 174400 ?
VECTOR (O) 160 ? 330
BR LEVEL (O) 4 ?
CHANGE SW (L) ? Y
ERROR LIMIT FOR AUTO-DROP (D) 0 ?
ALL REMAINING QUERIES ARE FOR OPTIONAL (MANUFACTURING)
G5388 TEST-LOOP-MODULE SET-UP. USE <^Z> TO BYPASS.
G5388 TLM INSTALLED (L) N ? N
MMU AVAILABLE
MEMORY SIZE 124 KW
18 BIT ADDRESSING
--
Ben Sinclair
ben at bensinclair.com
17 Aug
17 Aug
7:48 p.m.
BR level is the bus request level for an Interrupt. BR 4 is typical.
The RLV11 apparently asserts BIRQ L, pin AL2 - which on the 11/23 would
be BIRQ4 L. I don't think the RLV11 offers any other choice.
The RLV11 print set (bitsavers) has the switch settings on page 4 of the
PDF.
The RLV11 controller manual can be found at:
http://www.bitsavers.org/pdf/dec/qbus/EK-RLV11-TD-001_RLV11_Controller_Tech…
The RLV11 was developed for the original LSI Bus. I'd expect it to be
Q-Bus compatible, but others here probably have more recent exposure.
It has been a while since I worked with an 11/23.
Have you tried manually examining the CSR to see what it shows? Does it
make sense?
Have you tried a CSR of 774400, which might be its address on your machine?
JRJ
On 8/17/2015 4:43 PM, Ben Sinclair wrote:
Now that I (hopefully) have my PDP 11/23 running (it
passes CPU and memory
tests, anyway), I've been messing with my RLV11 so I can use my RL02.
For a first step, I'm trying to run the VRLBC0 diskless diagnostic to check
the controller. I checked that the address and vector switches are set to
the defaults according to he manual, and also verified them with a
multimeter.
The manual says the default vector address is 330, though the diagnostics
default to 160. I tried it both ways with the same result, though I should
be on 330.
I'm not actually sure what "BR LEVEL" refers to, so I left that at the
default.
This is a PDP 11/23 with an H-9273 backplane. I have the M8186, M8067,
M8043, then the two RLV11 boards, M8013 and M8014, then an M8012.
Here's a sample run. It appears to start, but never does anything else. If
I give it a bad address it does complain, so I think I have the switches
correct.
Does anyone know what I might try next? Thanks!
.R VRLBC0
VRLBC0.BIC
DRSSM-G2
CVRLB-C-0
RLV12 DISKLESS
UNIT IS RLV12, RLV11, OR RL11
RSTRT ADR 145702
DR>START
CHANGE HW (L) ? Y
# UNITS (D) ? 1
UNIT 0
RLV12 (L) Y ? N
RLV11 (L) Y ? Y
CSR ADDRESS (O) 174400 ?
VECTOR (O) 160 ? 330
BR LEVEL (O) 4 ?
CHANGE SW (L) ? Y
ERROR LIMIT FOR AUTO-DROP (D) 0 ?
ALL REMAINING QUERIES ARE FOR OPTIONAL (MANUFACTURING)
G5388 TEST-LOOP-MODULE SET-UP. USE <^Z> TO BYPASS.
G5388 TLM INSTALLED (L) N ? N
MMU AVAILABLE
MEMORY SIZE 124 KW
18 BIT ADDRESSING
8:04 p.m.
On Mon, Aug 17, 2015 at 10:48 PM, Jay Jaeger <cube1 at charter.net> wrote:
The RLV11 was developed for the original LSI Bus.
I'd expect it to be
Q-Bus compatible, but others here probably have more recent exposure.
It has been a while since I worked with an 11/23.
In 1987, all I could afford was a used 11/23 ($300 for BA11-N, CPU,
256K of RAM, DLV11J 4-line serial, LPV11 line printer interface, and
BDV11 bootstrap and terminator) so for disk, I picked up an RLV11
($100) and borrowed an RL01 off of my PDP-8/a. I used that for
(RT-11) work for 2 years. Worked great! There should be no problems
in an 18-bit backplane. If you want 22-bit, that's the RLV12, which
works in everything Qbus including MicroVAXen.
I never ran the diags... I just plugged in a drive with "0" plug in
it, and booted it up. I may have borrowed an RL02 from my boss and
booted it from that first and copied the OS to my RL01 and swapped
drive plugs. Once it was running, I had 5MB for the OS and my
development environment, and 10MB for customer data (and to transfer
deliverables to the customer site - the target was a $20,000 11/73
with 4MB of RAM and a Fujitsu Eagle disk and a few other expensive
extras (RLV12 + RL02...). I always got a kick out of developing for a
machine that cost 50X what I paid for mine).
-ethan
18 Aug
18 Aug
5:46 a.m.
On Aug 17, 2015, at 10:48 PM, Jay Jaeger <cube1 at
charter.net> wrote:
BR level is the bus request level for an Interrupt. BR 4 is typical.
On Unibus machines, more of the BR levels were used. The rule of thumb was BR4 for slow
devices (like terminals and printers), BR5 for fast devices (disks and tapes), BR6 for
real time critical devices (clock, also DECtape because you had to respond to a ?read
block number? interrupt fast enough to start reading the block before it passed over the
heads). BR7 could in theory be used by devices but I don?t believe it ever was in
practice.
paul
6:09 a.m.
On 8/18/2015 7:46 AM, Paul Koning wrote:
Yes, but this discussion regards an RLV11.
JRJ
On Aug 17, 2015, at 10:48 PM, Jay Jaeger
<cube1 at charter.net> wrote:
BR level is the bus request level for an Interrupt. BR 4 is typical.
On Unibus machines, more of the BR levels were used. The rule of thumb was BR4 for slow
devices (like terminals and printers), BR5 for fast devices (disks and tapes), BR6 for
real time critical devices (clock, also DECtape because you had to respond to a ?read
block number? interrupt fast enough to start reading the block before it passed over the
heads). BR7 could in theory be used by devices but I don?t believe it ever was in
practice.
paul
9:33 a.m.
On 2015-08-18 15:09, Jay Jaeger wrote:
On 8/18/2015 7:46 AM, Paul Koning wrote:
Yes, but this discussion regards an RLV11.
It was possible to use several BR levels on a Qbus as well, but in
practice it was not done.
And I suspect the diagnostics wants to know so that they can set the PSW
correctly on interrupts. Just using the default number should be good
enough in the common case.
Johnny
On Aug 17, 2015, at 10:48 PM, Jay Jaeger
<cube1 at charter.net> wrote:
BR level is the bus request level for an Interrupt. BR 4 is typical.
On Unibus machines, more of the BR levels were used. The rule of thumb was BR4 for slow
devices (like terminals and printers), BR5 for fast devices (disks and tapes), BR6 for
real time critical devices (clock, also DECtape because you had to respond to a ?read
block number? interrupt fast enough to start reading the block before it passed over the
heads). BR7 could in theory be used by devices but I don?t believe it ever was in
practice.
paul
10:26 a.m.
On 8/18/2015 11:33 AM, Johnny Billquist wrote:
On 2015-08-18 15:09, Jay Jaeger wrote:
Yes, but from what I could tell from its manual, the RLV11 could ONLY
use BR4 - had no jumpers to do anything else - it was designed in the
days of the LSI bus, the QBus precursor, which only had the one signal.
JRJ
On 8/18/2015 7:46 AM, Paul Koning wrote:
Yes, but this discussion regards an RLV11.
It was possible to use several BR levels on a Qbus as well, but in
practice it was not done.
And I suspect the diagnostics wants to know so that they can set the PSW
correctly on interrupts. Just using the default number should be good
enough in the common case.
Johnny On Aug 17, 2015, at 10:48 PM, Jay Jaeger
<cube1 at charter.net> wrote:
BR level is the bus request level for an Interrupt. BR 4 is typical.
On Unibus machines, more of the BR levels were used. The rule of
thumb was BR4 for slow devices (like terminals and printers), BR5 for
fast devices (disks and tapes), BR6 for real time critical devices
(clock, also DECtape because you had to respond to a ?read block
number? interrupt fast enough to start reading the block before it
passed over the heads). BR7 could in theory be used by devices but I
don?t believe it ever was in practice.
paul
9:30 a.m.
On 2015-08-18 14:46, Paul Koning wrote:
To put things another way. Think of BR level as "interrupt priority". A
bit coarse, since position on the bus further refined interrupt priority
within a BR level. (Closer to the CPU -> higher priority than farther
On Aug 17, 2015, at 10:48 PM, Jay Jaeger
<cube1 at charter.net> wrote:
BR level is the bus request level for an Interrupt. BR 4 is typical.
On Unibus machines, more of the BR levels were used. The rule of thumb was BR4 for slow
devices (like terminals and printers), BR5 for fast devices (disks and tapes), BR6 for
real time critical devices (clock, also DECtape because you had to respond to a ?read
block number? interrupt fast enough to start reading the block before it passed over the
heads). BR7 could in theory be used by devices but I don?t believe it ever was in
practice. from the CPU, for devices on the same BR level.)
And then the CPU could choose to block all interrupts at a specific BR
level and lower.
Johnny
8:24 a.m.
Well, I tried a few things, including reading the CSR, which doesn't
appear to be what I expect.
I ended up removing the RLV11 and making sure my system was still
passing the other tests, and I've found that I can no longer run
JKDBD0 to test the CPU, which was working before. It never prints any
of its starting messages, and the run light turns off.
So I'm apparently back to just trying to get the basic system running.
I have no idea why this system is so flaky. One day it works great,
the next it doesn't. Maybe it's just cursed!
On Mon, Aug 17, 2015 at 4:43 PM, Ben Sinclair <bensinc at gmail.com> wrote:
Now that I (hopefully) have my PDP 11/23 running (it
passes CPU and memory
tests, anyway), I've been messing with my RLV11 so I can use my RL02.
For a first step, I'm trying to run the VRLBC0 diskless diagnostic to check
the controller. I checked that the address and vector switches are set to
the defaults according to he manual, and also verified them with a
multimeter.
The manual says the default vector address is 330, though the diagnostics
default to 160. I tried it both ways with the same result, though I should
be on 330.
I'm not actually sure what "BR LEVEL" refers to, so I left that at the
default.
This is a PDP 11/23 with an H-9273 backplane. I have the M8186, M8067,
M8043, then the two RLV11 boards, M8013 and M8014, then an M8012.
Here's a sample run. It appears to start, but never does anything else. If
I give it a bad address it does complain, so I think I have the switches
correct.
Does anyone know what I might try next? Thanks!
.R VRLBC0
VRLBC0.BIC
DRSSM-G2
CVRLB-C-0
RLV12 DISKLESS
UNIT IS RLV12, RLV11, OR RL11
RSTRT ADR 145702
DR>START
CHANGE HW (L) ? Y
# UNITS (D) ? 1
UNIT 0
RLV12 (L) Y ? N
RLV11 (L) Y ? Y
CSR ADDRESS (O) 174400 ?
VECTOR (O) 160 ? 330
BR LEVEL (O) 4 ?
CHANGE SW (L) ? Y
ERROR LIMIT FOR AUTO-DROP (D) 0 ?
ALL REMAINING QUERIES ARE FOR OPTIONAL (MANUFACTURING)
G5388 TEST-LOOP-MODULE SET-UP. USE <^Z> TO BYPASS.
G5388 TLM INSTALLED (L) N ? N
MMU AVAILABLE
MEMORY SIZE 124 KW
18 BIT ADDRESSING
--
Ben Sinclair
ben at bensinclair.com
--
Ben Sinclair
ben at bensinclair.com
9:06 a.m.
On 08/18/2015 10:24 AM, Ben Sinclair wrote:
So I'm apparently back to just trying to get the
basic system running.
I have no idea why this system is so flaky. One day it works great,
the next it doesn't. Maybe it's just cursed!
I ran a MicroVAX-II at home for 21 years, from 1986 to about
2007. I added stuff to it for some time, had 3 tape drives,
several disks, several generations of graphics systems,
etc. Some time around 1999 or so, it started to get flaky,
and once a month or so it would hang. The fix was to power
off, reseat all the cards and it would usually come up for
another month or two. Cleaning the card cage connectors by
vacuuming first, then wiping with alcohol-soaked towel
helped it a bit more. I've finally retired the system and
given most of the peripheral boards away. The CPU still
works, but the disk I had used for a long time died.
So, cleaning the card edge connectors and backplane
connectors may help.
Jon
3365
days inactive
3366
days old
9 comments
7 participants
participants (7)
-
ben＠bensinclair.com -
bensinc＠gmail.com -
bqt＠update.uu.se -
cube1＠charter.net -
elson＠pico-systems.com -
ethan.dicks＠gmail.com -
paulkoning＠comcast.net