Describe what LB actually does now The Capacity Unlock page still described raising the partition lengths in memory, which was removed after hardware showed it cannot reach the goal - the console formats to the signed sector count regardless - and destroys data while it lasts. Rewritten around removing the flash signature, with the measurements behind it: the extra space on a flashed drive is real (no HPA, writes at 150 GiB read back), the signature offset is a load-immediate so it is identical on every drive, and clearing the content volume header alongside is what stops the console reaching E71. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Name the configuration that actually runs on a retail console The debug build shipped as `Debug`, which also defines _XDK. That switches SetMemory over to DmSetMemory - an export of xbdm.xex, the debug monitor, which exists only on development kits. The DLL then declares an import a retail console cannot resolve, so it never loads and XeUnshackle reports it as Missing. Nobody would have found that without trying to use it. Debug_Retail defines _DEBUG;_XBOX without _XDK and imports the same two libraries the normal build does. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Correct the avatar and capacity claims, and document the three format modes The power-on explanation for avatars was wrong: the updater rescans when a device appears, shown by the update menu coming up on USB insertion from inside the dashboard. The actual cause is the disk key slot 0x1001, which is write-once per boot - replaying a valid sector returns 0xC8000002 even on the drive that had just authenticated with it. The capacity-versus-avatars trade-off is also gone for a flashed drive: LT+RT+LB keeps the signature and marks the content partition, and system content lives in SystemExtPartition, which the resize never touches. Verified at 218 GiB with avatars working. On-Console Format now documents all three modes rather than LT alone, and the partition list matches what the code writes.
Document that avatars cannot work on a disk that appears after the exploit
Document formatting all four partitions for the avatar update
Document unauthenticated disk support
Initial Home page