QUOTE(ldotsfan @ Jul 5 2008, 07:45 AM)
Precisely because FATX support depends on XDK API hence it's not going to be easy when you change the standard partition sizes to fit 1GB. You can't depend on the XDK anymore - you have to write your own filesystem code - that's what I was trying to say.
There's no way the Xbox can't support a filesystem smaller than 1GB: The C partition, out of the box, is only 500MB long. The XDK code doesn't know or care how the disk is layed out: if it did, then nothing would work on the debug xboxen, and for games to run off the F drive, every game manufacturer in existence would have to have written in support for every conceivable size the F drive might be (and to run off the G drive, they'd have had to have predicted the future invention of LBA48).
The FATX driver manipulates filesystems not on the raw disk, but on block devices provided by the kernel; to change the size of the partition, you just need to change the size of the block device. Just modify the BIOS to map the block devices onto the disk differently, and you'll have differently-sized filesystems (assuming you format them; otherwise you'll have differently-sized partitions full of bollocks). Because the FATX driver is the only thing that sees any changes, you don't need to make any changes to anything at a higher level than it: the only thing you have to do is modify the partition table, and format the partitions. No changes are needed in userland, barring obvious things like not trying to use space you don't have.
And you don't even need to hack any BIOS: the work's already been done. Just flash an LBA48v2 BIOS, fire up XBpartitioner, make partition 2 500MB, partition 1 250MB, and partitions 3-5 50MB each. Reboot, format, job done.
Even in the highly unlikely event that you're right about FATX not working on partitions smaller than the ones the xbox ships with, it
still makes no difference to your ability to use XBMC: there's plenty room to install it on the C drive, and
the C drive is the exact same size as on a standard Xbox. There's no way that can't work.*
Hell, if you used a 2BG card you could play games: make partition 2 500MB, partition 1 250MB, and partitions 3-5 750MB and overlapping each other. As far as the Xbox is concerned, the X, Y and Z drives are all valid, and just happen to have the same data on them. As long as you never write to more than one at a time (which you won't, unless you explicitly try to), you won't corrupt the FS, and even if you do, so what? It's just a disk cache. You'd probably need to blow away localcache00.bin on every boot, but that's a trivial modification.
QUOTE(ldotsfan @ Jul 5 2008, 07:45 AM)
I don't think you will find direct references to scratch partitions in the XBMC code - it's probably created by the API calls during execution - but I could be wrong.
IIRC, XBMC does mess around with the mounts while it's loading (mostly to move the D drive to be the Q drive, but also to mount the userprofile to a drive), but it is very likely that it does just use the scratch partition it's been assigned. Most straightforward hack would be to remap it onto somewhere on the E drive when the rest of the drive letters are getting remapped.
