On Wed, 17 Nov 2004, Michael wrote:

> Stupid typo alert - I meant an I2C bus, not I2O.

	That's a little bit different :) First off, are you certain that
you're dealing with I2C directly and not with a higher level protocol? I
spent a few years with a Personal DECstation 5000/25 which implemented the
DEC Desktop.Bus protocol which later became Access.Bus which later became
SMbus, and the basis for USB. If you're dealing with access bus like
protocol, all devices initialize to a default powerup address and then
wait for you to initialize them one by one. They may be hardwired down to
an individual address. i.e. the DECstations PROM would initialize the
keyboard and mouse to one address for console IO, then you had to reset
the controller and assign the desired addresses when you loaded the kernel
of whatever operating system you were using.

I think the basic procedure goes something like this:

- Make the power up address device the master
- relinquish the bus since the host controller is the master
- issue a GETCAP request to get the capabilities structure
- assign the device a bus address (i.e. 0x7c)
- become the master
- repeat
- keep going until all devices have been assigned an address.

The Access Bus protocol is pretty well documented. I can dig up the DEC
documentation on it that I found on gatekeeper and the net for helping the
NetBSD/pmax port with a keyboard and mouse driver if you'd like.

If you are dealing with I2C directly, I have two 650+ page manuals from
Philips (who wrote the protocol) I can loan you entitled:

IC12a - I2C-Bus compatible ICs Types MAB84X1 Family to PCF8579
IC12b - I2C-Bus compatible ICs Types PCF8582A to UMA 1010T

There should be a wealth of information on the net as well. Let me know if
any of this would be of use.