I agree with a logical interface to the devices in the OS API but if we're talking about the computer's internal bus (which will be used only for the central 8052 to communicate with the video 8052, the audio 8052, and the I/O 8052) why would we want to have the OS support both parallel and serial I2C mode? I can see the benefit of the I/O 8052 having an I2C capability to be able to talk to I2C devices that might be hooked to it, but I'm not sure I see the benefit of the internal bus supporting both I2C and parallel.



I agree with all of that. But, assuming we're all in some agreement with the idea of having 4 8052s (central 8052, audio 8052, video 8052, and I/O 8052), the communication between each of those 4 8052s ought to be parallel, don't you think? Each of the individual 8052s can connect to other external devices with any protocol it wants--but we have to have a set standard that allows the 4 8052s to talk to each other. And I'm still not understanding why we'd want to go with a serial approach if we have the I/O lines available to do it a byte at a time.



I agree with you there. We have an interesting situation where we have to do define an OS API for hardware that hasn't been defined yet, and we need to define hardware that may receive some of its definition based on the needs of the OS API.

Regards,
Craig Steiner