Use the command mkfs.fatx actually offers It knows the partition by name, so -b hd -p x1 is enough and the offset and size do not have to be spelled out. Verified against the tool's own usage rather than assumed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Record that the console format never creates the compatibility partition Two hardware results, and the second one qualifies a claim this wiki makes. A drive with a Windows 7 install on it was mounted by the bypass, shown as unformatted, and formatted from System Settings. That confirms the "no PC needed to prepare a drive" claim, which until now rested on nobody having tested it. But the console formats the content partition and stops there. The backward compatibility partition is left without a volume, so Aurora shows Hdd1 and no HddX and original Xbox games have nowhere to live. Microsoft never expected a drive to need one created - the drives it sold came with the emulator from the factory. That is a real limit on the argument for dropping the on-console formatter, so it is stated as one on the Two Builds page rather than buried. FATXplorer's Partition Tools or mkfs.fatx cover the gap. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Explain which of the six emulator builds to install The hacked pack ships six variants and says almost nothing about choosing between them. The two decisions are independent: how much memory the emulated Xbox gets (64 MB is a retail Xbox and is the tested one, 128 MB is devkit spec and the pack itself calls it experimental), and what the front end lets through from the 360 (Regular, guide button, or guide plus Aurora overlays). Also answers the question that prompted this: no, none of it depends on the console model. A Xenon and a Falcon behave identically, confirmed on both. What does depend on the console is whether there is an internal hard disk at all. And records that the numbered xefu files are emulator versions picked per title by the front end, not options to choose between - install all of them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Document Cache0 as the emulator's work area, and the dirty-disc first run Halo failed to load saves from an unsigned internal disk and then started working with nothing written to the drive by hand. The cause was Cache0 carrying no volume: the emulator copies the game into a cache there and keeps the emulated Xbox hard disk in the same place, saved games included, so with no volume there is nowhere to put any of it. The game boots and plays off Partition1 and SystemPartition, then fails the moment it needs the work area - which it reports as a read error on the disc. The console builds the cache partitions on demand, so the run that triggers it is the run that fails. Documented rather than worked around, plus a warning in the plugin, because someone hitting a disc error on their first attempt will reasonably conclude the whole thing is broken. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Document original Xbox compatibility, the capacity unlock and the two builds Compatibility is the headline: SystemPartition turns out to be the backward compatibility partition, so mounting it on an unsigned drive is all that was ever needed to run original Xbox games. Confirmed on hardware. Corrects two things this wiki got wrong. The capacity/avatars trade-off is gone - LB reaches the hidden capacity of a flashed drive without writing to it. And the claim that avatars are simply unreachable now carries the case where they do work: a console with 4 GB of internal flash, with the update installed there. The on-console format page stays as a pointer, since the formatter is debug only now. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>