| QUOTE |
| Plug and Play is a technology developed for the PCI bus, so that devices on the bus get their memory regions, I/O ports and IRQ lines assigned dynamically. This way, there will most probably be no I/O resource conflicts, no matter what you plug into the PCI slots. On a Plug and Play enabled IBM-PC, either the BIOS or the PnP OS (such as Windows 95/98/ME or Windows 2000/XP, but not Linux) assigns the I/O resources to the PCI devices. In case of Linux, the BIOS does all the work, and Linux can then query the assigned addresses from the PCI bus. The Xbox makes use of the PCI bus, too, but the Xbox kernel, unlike the Windows 2000 kernel it is derived from, is not Plug and Play aware. It expects certain hardware at predefined addresses, for instance the SMBus controller can always be accessed through the I/O port addresses beginning at 0xC000. So unlike Linux, it does not query the PCI hardware to get the correct resources, but it expects the code that has been run before the Xbox kernel to assign constant addresses and I/O lines for the different devices. For Linux on the Xbox, this has two implications: If we run the Linux kernel from within the Xbox kernel environment, we can read the resource allocation from the PCI configuration, just as on a PC, because the Xbox kernel bootloader has already assigned the resources of all devices. Our clean-room ROM replacement will either have to assign the same resources to the PCI devices as the original initialization code, or contain real Plug and Play resource assignment code. Any way, there will have to be some hardware initialization code. The PCI bus on the Xbox can be accessed as on any PC/AT through the ports at 0xCF8/0xCFC. Look at arch/i386/kernel/pci-pc.c in the Linux kernel for details. |
| QUOTE |
| OHCI USB Controller, IDE Controller These devices are compatible to standard PC devices and require no additional code |
| QUOTE |
| I'm enjoying talking to myself here, hopefuly someone else will read some of this and be able to contribute. As I'm finding out more I am posting it so all can see it without having look that up first and duplicate any effort. Doesn't look like you could plug a memory card directly into a port on the front, at least not for use with anything written using the SDK. To mount a memory card requires the slot ID, XDEVICE_TOP_SLOT or XDEVICE_BOTTOM_SLOT. I had assumed that along with XDEVICE_NO_SLOT these would map to 0, 1 & 2 (not in that order) to represent the port numbers on the integrated hub. However these constants turn out to be 0, 0 & 1, so the extra 1 is obviously added in the library for the two slots (giving 0, 1 & 2), and so we are not able to get down to the first port on the hub (real 0) for the to access a momory card there. Unless we can put a value of -1 to get back upto 0. That wouldn't work either, the xbox assigns a drive letter to the memory card (just like a pen drive under windows, then you use it like a normal disk drive). The letter assigned is apparently predetermined by the slot the card is in, so the library wouldn't know what letter to issue if we got it to plug in to the first port on the hub. rab. |
| QUOTE |
| Went out and bought a memory card to test my theory (didn't get the genuine MS one, got an InterAct authorised accessory one, which came with an extra "break-away" cable, which was handy to connect my keyboard to the box at the same time as my controller). Connected a USB lead to it, like so:(no picture) Plugged it into the PC and it shows up a an unknown USB device, under Windows XP. It shouldn't need drivers for a standard USB storage device, so it must be a bit different. To test a bit of other USB thinksings I plugged the memory card into the back om keyboard hub, and plugged the keyboard into the xbox, and the box can access the memory unit as expected. rab. |
| QUOTE |
| Finally got my final year project done, and so had time to play with this a bit more. Plugged the memory card into the PC under linux to get some info from it. T: Bus=02 Lev=03 Prnt=03 Port=01 Cnt=02 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs= 1 P: Vendor=05fd ProdID=1316 Rev= 1.00 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 60mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=42 Prot=50 Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms As you can see it is a mass storage device (0x08), but it has a subclass of 0x42, which in the spec is listed as reserved for future use. Has this been implemented now? If so what is it? Haven't been able to find much about it. rab. |
| QUOTE |
| I suspect it would be possible to write a driver, though I don't know how easy it would be. The subclass of 0x42 is not an official one as far as I can tell. This defines block message format used to comunicate with the device, so you would need to understand it to write a driver. I suspect MS made up a new, non-standard, one so they could licence the info, and prevent just anyone making them. |
| QUOTE (BenJeremy @ Nov 28 2002, 05:58 AM) |
| Try a search of the forums next time.... been there, done that, as they say. USB drives show up as memory cards on the Xbox, apparently. |
| QUOTE (BenJeremy @ Nov 28 2002, 04:58 AM) |
| USB drives show up as memory cards on the Xbox, apparently. |
| QUOTE (BenJeremy @ Nov 28 2002, 04:58 AM) |
| Try a search of the forums next time.... been there, done that, as they say. USB drives show up as memory cards on the Xbox, apparently. |