Hello,

> > Stupid typo alert - I meant an I2C bus, not I2O.
> 
> 	That's a little bit different :)
Yeah, and since I never dealt with any of them I keep confusing the abbreviations.

> First off, are you certain that you're dealing with I2C directly and not with a higher level protocol?
Yes. All the ZR36057 offers is a register to read or write SDA and SCL, there's no support for higher level stuff in the chip and the SAA7110 wants to be configured this way.

> 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.
Ok, so I'll just probe. Since device addresses are usually only one byte that should be reasonably fast ( ok, there's an extension for 10 bit addresses but I'm not (yet) sure any device that could possibly sit on a video board would use it.

> 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.
So far I found a site that describes the basic protocol ( like, how to send a START, address devices and so on ) I guess probing would simply involve sending START, send an address, look for an ACK, send a STOP, increment address, repeat until I got all addresses.
... which raises another (stupid) question - are there any timing constraints? No docs I saw so far mentioned any. But I'd think that I can't toggle the clock line as fast as I'd like to, so - how long do I need to keep the clock line up or down for a device to react?

have fun
Michael