On 2015-08-18 19:05, Jon Elson wrote:
On 08/18/2015 10:48 AM, Holm Tiffe wrote:
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.

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.

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

Reply via email to