In reply to:

Now can you detail how an interface box might actually allow a USB slave port to magically behave like a USB master port?



That is the the thing that is simple in my head, but I am sure will be an absolute bu66er when I come to actually implement it. I will assume everyone knows a little about how USB works (anyone who doesn't speak up, and I may try to simplify it from the specs) and the main problem is that a USB device cannot TX on the USB cable unless it is answering a request from a host (don't use master/slave, USB went to a lot of trouble not to).
So my idea is to have a small microcontroller to act as a limited function host with about as much inteligence to enumerate the connected device (the empeg in this case), and set a configuration that has one pipe/endpoint, the micro then sends requests for data to be sent to the other device to the Empeg down the open pipe, the Empeg responds, and the micro just forward the data to the connected device, any response gets forwarded back to the Empeg. This continues until the devices are unplugged or the Empeg stops sending commands.

This should move the processing of the USB stack to the empeg (as it has a little more processing power than a micro), and may even allow us to use existing Linux class drivers.

For me at the moment the main question is how is the Empegs USB port represented on the player, and how easy will it be for us to bind to an endpoint.

In my mind the USB CD-ROM is the current leader, as I can get my hands on one pretty easily, but I am still listening if anyone has a particular preferance for something else.

Mark
20GB MKII 090000916
_________________________
Mark. [blue]MKI, MKII & MKIIa, all Blue, and all Mine![/blue]