Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Address of second TMSCP controller

Thanks to you all for the input.

Unfortunately, the drive for my second TMSCP controller is kaput - another thing to add to my ever-increasing hardware fixit list!

Tusen takk til Tom for informasjonen



Amateur Radio, the origin of the open-source concept!
Skype:  TILBURY2591 nw.johnson%ieee.org@localhost

On 2021-03-20 9:14 a.m., Johnny Billquist wrote:
On 2021-03-20 13:43, Tom Ivar Helbekkmo wrote:
Johnny Billquist <bqt%update.uu.se@localhost> writes:

The whole point of the DEC defined floating CSR configuration rules
was in order to reliably identify each controller type. But it
requires a rather more intelligent contextual probing of the address
space instead of the NetBSD rules based matching system.

I just noticed this discussion thread...  The probing algorithm is quite
simple, and data driven.  I wrote a tool that mimics the CONFIG part of
VMS SYSGEN, in order to configure my Q-bus systems according to DEC
rules.  By far most of the work was in copying out the tables of device
specifications from the Grey Wall.  :)

A write-up, and the tool, are at https://www.hamartun.priv.no/sysgen.html

This got to have been a couple of years ago at least... :-)

The algorithm is definitely not complicated. However, it basically means that CSR addresses and vectors are not defined in the config anymore, if you are to follow it. Which is where it is rather different than the NetBSD configuration system, which builds up a config at compile time, and at boot it tries to probe through that configuration (now talking about the VAX bits here, not sure about how it works on other architectures).

The floating address assignment system defined by DEC certainly is nice in that it means you can reliably figure out what the actual hardware looks like on a system. But it requires that people always correctly update everything whenever any controller is added or removed.

This was a bit of a hassle, and so most people and systems didn't adhere to the convention that strictly. This was not only a NetBSD thing. On PDP-11s, RSX definitely did not care about it either. Instead, similar to NetBSD, you define at compile time where different things are located in the address space, and it just gets probed at boot time, if the hardware is actually present. If things were added, and hardware should shift to other addresses because of this, then RSX wouldn't find it anymore. Same with NetBSD.

Now, with simulators, it is sortof easier to move controllers around. No need to pull cards, flip switches and/or cut resistors or wires (or add them). But on the other hand, have stable addresses for controllers makes it easier to know what is where, and what is going on.

So I'm not fully convinced you really would want to have a system that goes by the DEC floating address conventions. Not to mention if someone change a configuration, and does the slightest bit wrong, then things will not work well at all.


Home | Main Index | Thread Index | Old Index