18 Aug
2015
18 Aug
'15
7 p.m.
On 2015-08-18 19:05, Jon Elson wrote:
On 08/18/2015 10:48 AM, Holm Tiffe wrote:
The floating address space was pretty much there from the start for the
Unibus, even before you had "large" systems. For most controllers, only
the first one has a fixed address, and all others were assigned from the
floating space. Makes sense, as it was just too costly to statically
assign space in the I/O page for all possibly configurations you could
imagine.
Understand my quandary: I have changed not a
single bit on the
hardware while cleaning and repairing it and besides that DHU11-DHV11
Switch the board was in the published factory setting!
DEC went to this floating
address/vector scheme back in the PDP-11 days,
when they started building large systems like the 11/70 and using
PDP-11's as the console for DECsystem 20's. They'd put a huge number of
I/O boards in such systems. A choice of 3 pre-assigned CSR addresses
and interrupt vectors just would not cut it in such systems.
They had a utility you could run (at least on VAX) where you input the
number of instances of each device, and it would print out a table of
all the CSR and vectors to set them to. So, the situation is that changing the number of one
kind of board could
alter the addresses of many OTHER boards!
Indeed.
Most likely, some board was added or removed from the
system before you
got it, and it caused the vector to now be wrong.
The vector is usually not the first victim. The CSR address is, which
cause all access to the controller to fail. But the vector often also
move, causing the more obscure errors. However, most DEC OSes actually
autodetected the vetor, and did not care about the actual floating
assignment rules for the vectors.
The thing is, all you need is to trigger an interrupt on the device, and
then notice at what vector it came in, and then you go with that. This
only fails when several devices happen to use the same vector.
In some cases, you had to force a device to be at a
non-standard
address, possibly because a 3rd party device could not be configured at
the address the DEC enumeration scheme wanted to put it at. This was
pretty easy to do in later VMS systems.
Very easy to do in RSX-11M-PLUS as well. A simple one line command,
which can be done on the running system.
Unfortunately, this type of misconfiguration is fairly
hard to detect
with software. Later devices (MSCP) had an autoconfiguration scheme
where the OS would assign the CSR and vector at boot time.
Well, half correct anyway.
The CSR is never autoassigned. It always is configured by switches or
jumpers on the board. Some of the more modern controllers, like MSCP
controllers, setup the vector through software.
CSR misconfigurations are pretty much impossible to fix, but most of the
time easy to detect. If nothing is responding on the CSR address, the
controller simple is not there.
Vector misonfigurations can either be handled fine by the OS, or cause
spurious interrupts for another driver. A bit harder to detect
sometimes. Depends on the driver. Some actually log unexpected interrupts.
Johnny