Xbox Controller Memory card

[rderooy]

The readme does not mention it, but is this meant to be able to mount an XBox controller memory card via USB?

Using an Xbox to USB cable, I was able to format a USB stick on the Xbox. But when I try to mount it with fatx, I just get an error "failed to initialize the filesystem".

I was able to use fatx to format the USB stick, and transfer save files to it, but the XBox does not seem to really like that. The save file is showing on the XBox, but as "Unknown Title" (but with the correct icon) with the only option to "Delete" (yes, after selecting the actual save file). Possibly because it is not expecting partitions on the memory card?

sudo ./fatxfs/fatxfs /dev/sdc /mnt --format=retail --destroy-all-existing-data

[dekay]

Yes, the issue is that the XMU is not partitioned and FATX currently can't deal with that. Having this capability would be very useful. There is code in this xemu pull request that might be adaptable to adding to FATX.

Some relevant discussion on the xemu discord.

[djholt]

A bit more observation on this: if I attempt mounting a raw image of an XMU that reads/writes properly from the Microsoft Xbox Dashboard, fatx will successfully mount the image by using --offset=0 and --size=N, the image size. However, filesystem contents are not accessible. Either the mount point displays empty contents, or "Device not configured" is displayed when attempting any file operations (on macOS).

I would think using --offset and --size explicitly should bypass the fact that the XMU structure has no partition table, so perhaps something else is the issue. I can provide a raw image if it's helpful, but in short, the structure is nearly identical to a normal FATX partition allocation, beginning with chars FATX, but with one notable difference I've observed:

The 4-byte int starting at offset 0x8, which typically contains the cluster size in units of sectors (0x20 for cluster size 16KB), always seems to contain the value 0x4 regardless of the size of the memory unit. Nevertheless, it seems a 16KB cluster size is still used.

I hope that helps if and when someone attacks this. :)

[djholt]

Carrying the observation forward, if --sector-size=4096 is specified, this aligns with 4 sectors per cluster and a cluster size of 16KB, and the image reads successfully. I hadn't realized we might encounter a 4096 sector size, but it makes sense, and I was happy to see a command-line argument for it.

In conclusion, to mount and read/write an XMU device or image, give these options a try:

--sector-size=4096 --offset=0 --size=XMU_SIZE_IN_BYTES

p.s. big thanks @mborgerson for the excellent work on this!