18 Aug
2015
18 Aug
'15
8:55 p.m.
On Aug 18, 2015, at 3:48 PM, Johnny Billquist <bqt
at update.uu.se> wrote:
On 2015-08-18 21:29, Paul Koning wrote:
Ideally yes. However, at least RSX I think fails on that. As device vectors are detected.
they are installed. So the vector detection code does not get called for the second device
using the same vector, but instead you get a spurious interrupt in the autoconfiguration.
Ok. RSTS does indeed check for duplicate vectors. It also checks for devices
interrupting at too high a priority.
It?s pretty neat code. Back in 1977 or so when that came out, it may have been one of the
first autoconfig systems, at least in DEC. It could probe almost all devices supported by
RSTS (and some not supported); the exceptions being card readers and the DT07 bus switch.
But it would do hairy things like the KMC-11 and DMC-11, for example.
Also, for disks it would discover all units and their types.
paul
On Aug 18, 2015, at 2:00 PM, Johnny Billquist
<bqt at Update.UU.SE> wrote:
On 2015-08-18 19:05, Jon Elson wrote:
...
Typically that would be detected as a configuration error ? two devices whose
autodetected vector matches. One of the offending devices (the one seen later,
presumably) would end up disabled. 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.