OXOS v0.2.0

Big disks and exFAT. The Xbox hard disk no longer has to be a Microsoft FATX disk.

• Format a drive of any size as exFAT on your PC (Windows, macOS or Linux).
• Copy the dashboard, your apps and your saves onto it as ordinary files.
• Put it in the Xbox.

OXOS also uses the whole disk now, not just the first 128 GiB.

Download: bios_v0.2.0.bin (1 MB, SHA-256 93fa5833cbb1ef6fce4c8f325ae7fe5cdae55936b6cc9f3ff70e69f39666e67f)

Big hard disks: 48-bit addressing (LBA48)

• The original kernel uses 28-bit sector numbers, so it can only reach the first 128 GiB of a disk. OXOS now uses the drive's 48-bit commands, which reach 128 PiB.
• Tested in xemu on a 2 TB disk: every test sector landed at the right place, including the ones just past the old 128 GiB limit.
• Disks up to 128 GiB get exactly the original commands, and existing FATX disks keep working unchanged.

exFAT hard disks

• Formatted on any computer. Use one exFAT partition on a GPT disk (or MBR, up to 2 TiB). The default settings of Windows Disk Management, macOS Disk Utility, or Linux gdisk + mkfs.exfat all work. You don't need FATX tools or Xbox-specific partitioning.

• Folders are the Xbox drives:

  Folder	Drive	What goes there
  C	C:	the dashboard
  E	E:	saves and game data (TDATA, UDATA)
  F	F:	your extra drive: apps, homebrew, anything
  X, Y, Z	X:, Y:, Z:	game caches, created automatically

• Copy data any time. Put the drive in a PC: saves, apps and the dashboard are plain files. You can back up, restore and add apps with the file manager you already use.

• One shared pool of space. There are no fixed partition sizes: C, E and F can each use the whole disk.

  • Games see C: and E: as at most 2 TB, because some older software miscounts larger numbers.
  • F: shows the full size.
  • The cache drives X/Y/Z show 750 MB each, as on a retail disk. Games format them as they always did, and OXOS empties the folder instead.

Size limits:

• Disk: no practical limit with GPT; tested with 256 GB and 500 GB disks. MBR partitions stop at 2 TiB.
• Files: the PC can store files of any size on the disk. Xbox games and apps only see files under 4 GB, because the Xbox file API is 32-bit; larger files are hidden from them.
• Names: Xbox software sees names of up to 42 characters (the Xbox rule). Longer names, and names with characters outside Latin-1, are hidden from it and left untouched.

Setting up a drive:

1. Format it as exFAT: one GPT partition starting at 1 MiB (the default everywhere).
2. Create the folders C, E and F.
3. Copy your dashboard files into C (for example from your old drive's C:), and your saves into E if you have them.
4. Put apps into F, e.g. F\apps\myapp\default.xbe.

For xemu users

Make an exFAT disk image on Linux:

qemu-img create -f qcow2 hdd.qcow2 500G
sudo modprobe nbd max_part=8 && sudo qemu-nbd --connect=/dev/nbd0 hdd.qcow2
sudo sgdisk -n 1:2048:0 -t 1:0700 /dev/nbd0 && sudo mkfs.exfat /dev/nbd0p1
sudo mount /dev/nbd0p1 /mnt && sudo mkdir /mnt/C /mnt/E /mnt/F   # copy your files in
sudo umount /mnt && sudo qemu-nbd --disconnect /dev/nbd0

• Set the image as xemu's hard disk.
• Mount it again whenever you want to copy files. Unmount it before starting xemu: the PC and the console must never have the disk open at the same time.
• From a source checkout, python3 tests/exfat.py --from-fatx old.qcow2 new.qcow2 --size 500G converts an existing FATX image.

New for developers (in the repository)

• make run-xbe XBE='F:\apps\demo\default.xbe' runs an XBE from the hard disk. A small launcher disc (tools/xbe-launcher) starts it the way a dashboard does. make run-trace-xbe does the same with the serial log and kernel call tracer.
• New tests:
  • make test-lba48 runs the self-tests on a 2 TB disk.
  • make test-exfat runs them on an exFAT disk and checks the disk afterwards.
  • tests/exfat.py builds and checks exFAT disk images.
• Designs: spec/oxos-internal/ (LBA48, the exFAT storage layout, the exFAT driver).

Known limitations

• Not tested on a real console yet. Large disks need a drive, or an IDE adapter, that passes 48-bit commands through.
• Memory units are still FATX only; exFAT memory units are planned.
• Disk layout:
  • The first data partition on the disk must be the exFAT one.
  • The disk must use 512-byte sectors, the normal case for drives used with IDE adapters.
• No certificate key: stock saves and System Link with stock consoles won't work.

Checked in xemu

• All make test phases, make test-exfat and make test-lba48 pass, and make test-dash boots this exact image to the dashboard.
• A disk prepared only with standard Linux tools (a 500 GB disk; sgdisk, mkfs.exfat, files copied through the Linux exFAT driver):
  • the Microsoft dashboard boots from it;
  • Halo formats its cache, loads a level and writes its cache files;
  • afterwards Linux's fsck.exfat reports the disk clean.
• On an exFAT disk, Halo was played, the profile saved, and the game continued after a reboot.

Using it in xemu

1. Open Machine → Settings → System.
2. Set Flash (BIOS) File to bios_v0.2.0.bin and leave MCPX Boot ROM File empty.

Sources (GPL-2.0)

• This repository at tag v0.2.0.
• XboxDev/cromwell at 86f547387184d1001d377cce97d3756c8acf91cc for the X-codes and EEPROM key states.
• Contains no Microsoft code. Not affiliated with or endorsed by Microsoft.

OXOS v0.1.6

LATEST UPDATES: discs loaded at the ms dashboard are now recognised (previously you had to reset afer loading a disc)

Biggest updates was to the source repo - If you are a developer, this version also adds developer tools to the repository (source-level debugging of the kernel and nxdk titles, a serial debug log and a kernel call tracer); they're built only by their own make targets and are not part of this BIOS image.

Kernel debugging in VS Code: the OXOS kernel stopped at a breakpoint in XepLoadImage while loading the dashboard, with its call stack, locals, the loaded title's name and path in watches, and the kernel's boot log in the terminal.

Download: bios_v0.1.6.bin (1 MB, SHA-256 9e9e16dad78a299f9def09699ead645b19adf5b06f28f35c69ee00f2cf4da040)

What changed in the BIOS

• Discs loaded at the dashboard are recognised. Inserting a disc while the Microsoft dashboard was running showed "unrecognised disc" until a reset. The kernel now mounts discs in the same order as the original kernel (XDVDFS, then UDF), and retries the drive's "medium changed" and "becoming ready" answers the way the original does.

New for developers (in the repository, not in the BIOS image)

• Source-level, real-time debugging with gdb or VS Code. This covers the OXOS kernel and any nxdk app or game, in one session:

  • set breakpoints, step over and into code, and inspect variables, watches and the call stack;
  • step from your app straight into a kernel call and back.

  make run-gdb builds a debug kernel and starts xemu paused with its GDB server.

  • The kernel in VS Code: open the OXOS folder, set a breakpoint and press F5 (the screenshot above).
  • Your nxdk app in VS Code: copy tools/vscode/ into the app's .vscode/ folder. F5 then builds the app with DEBUG=y, boots it on OXOS and stops at your first breakpoint.

• Debug serial log. The trace builds write a log to the SuperIO serial port (COM1): boot steps, DbgPrint output from the kernel and games, every title load and its result, and crashes. In xemu, make run-trace-basic prints it in the terminal. On hardware it works with an LPC SuperIO adapter or a Modxo board (spec 18). Release builds leave it out.

• Kernel call tracer. make run-trace-full records a game's last 32,768 kernel calls: function, arguments, return value and file names. They're dumped automatically when the kernel crashes and when xemu closes; make print-trace-dump prints them at any time. It runs with xemu set to 128 MB, so games get the same memory as on a release build.

• Getting started guide. The README now covers the packages to install on a fresh Ubuntu, how to install xemu, clone the repository, add a hard-disk image and do a first build. Pillow is no longer needed to build.

Known limitations

• Debugging is xemu-only. A GDB stub for real hardware (over the SuperIO serial port) is not built yet.
• gdb sees one CPU, not an app's threads. Timers stop while you're paused.
• C++ nxdk apps need CXXFLAGS += -mllvm -dwarf-linkage-names=Abstract for gdb to show function names; C apps need nothing.
• Not tested on a real console yet.
• No certificate key: stock saves and System Link with stock consoles won't work.

Checked in xemu

• All make test phases pass, and make test-dash boots this exact image to the dashboard.
• The debug kernel passes all make test phases too.
• Kernel debugging in VS Code: a breakpoint on each title load, with the title's name shown.
• nxdk app debugging, on the repository's controller-test app: breakpoints in main, stepping into nxdk code, inspecting variables.

Using it in xemu

1. Open Machine → Settings → System.
2. Set Flash (BIOS) File to bios_v0.1.6.bin and leave MCPX Boot ROM File empty.

Sources (GPL-2.0)

• This repository at tag v0.1.6.
• XboxDev/cromwell at 86f547387184d1001d377cce97d3756c8acf91cc for the X-codes and EEPROM key states.
• Contains no Microsoft code. Not affiliated with or endorsed by Microsoft.

OXOS v0.1.5

HD video release: games that use 720p or 1080i now get a picture of the right size, shown at 16:9.

Download: bios_v0.1.5.bin (1 MB, SHA-256 5ade49197eab2f95fd5d1235b55d79d8c886693a68942b9edf7ee57da04c9fd4)

What changed

• HD and VGA display modes. Until now every video mode was shown as 640×480, whatever the game asked for. The kernel now sets the right picture size for each mode:

  • 480p (640 and 720 wide)
  • 720p
  • 1080i
  • the VGA sizes 800×600 and 1024×768

  The timings come from the published video standards, and the mapping of the games' mode numbers to sizes from nxdk's public mode table.

• HD shows at 16:9. 720p and 1080i now raise the AV connector's widescreen signal, so xemu's Auto aspect ratio shows them widescreen. The original kernel keeps that signal low in HD, which made xemu squeeze HD games into 4:3. 480p still follows the game's own widescreen setting.

How we found it

Enter the Matrix crashed xemu right away under make run:

• Trigger: the dashboard settings had 720p and 1080i enabled, so the game picked an HD mode, and our kernel then programmed a 640×480 screen for it.
• Investigation: we logged the modes games request, and measured how xemu sizes its display.
• Result: our 720p now shows as 1280×720 and 1080i as 1920×1080 interlaced.

Known limitations

• Enter the Matrix in 720p or 1080i still crashes xemu at render scale 2 or more. xemu rejects one of the game's own render surfaces when scaling. At scale 1 it runs (make run SCALE=1). To play at higher scales, turn off 720p and 1080i in the dashboard's video settings.
• 1080i looks rough in xemu, whose interlaced display is unfinished. 720p looks cleaner.
• No TV-encoder tables yet, so on a real console HD output (and SD fine-tuning) is still missing. This is xemu-only for now.
• Not tested on a real console yet.
• No certificate key: stock saves and System Link with stock consoles won't work.

Checked in xemu

• All make test phases pass.
• Enter the Matrix in 720p and 1080i at scale 1, widescreen.
• The Halo 2 title screen with this exact image.

Using it in xemu

1. Open Machine → Settings → System.
2. Set Flash (BIOS) File to bios_v0.1.5.bin and leave MCPX Boot ROM File empty.

Sources (GPL-2.0)

• This repository at tag v0.1.5.
• XboxDev/cromwell at 86f547387184d1001d377cce97d3756c8acf91cc for the X-codes and EEPROM key states.
• Contains no Microsoft code. Not affiliated with or endorsed by Microsoft.

OXOS v0.1.4

Memory release: games now get at least as much memory as with the original kernel. The memory manager and file cache were rewritten to match how the original kernel works.

Download: bios_v0.1.4.bin (1 MB, SHA-256 220ad9eb5e9463da4ab0ea419427c77072a1ebde57e7c120c1d052317fe6f062)

Why the rewrite

Some games had memory-related trouble, so we measured instead of guessing:

• Measured at game start: with the original BIOS and with ours, xemu was stopped at the instant each game starts, and the free memory was counted.
  • Games: the dashboard, Halo, Halo 2 and Half-Life 2.
  • Every one had about 1.2 MB (305 pages) less with our kernel.
• Measured during play: a few minutes of real gameplay in each, recorded every 10 seconds. These games run very close to the limit:
  • Halo 2 keeps under 1 MB free.
  • Half-Life 2 dropped to about 150 KB.
  • A 1.2 MB shortfall is enough to break them.
• Re-examined the original kernel's memory manager and file cache, looking at how it tracks memory, which pages it hands out, and what it keeps for itself.
• Rewrote the specs from that (spec 09 memory manager, spec 16 file cache), then the implementation to match. Each step was checked against the measurements.

What changed

• The boot splash no longer holds memory when the game starts. It stays on screen but its memory is handed to the game, as the original kernel does with its boot animation. This alone was 1.2 MB.
• Memory bookkeeping works like the original's. Free memory is tracked inside the page tables, as the original does, with no extra tables of its own.
• Memory is handed out in the original's order. If a game asks for a fixed memory area the kernel is already using, the kernel moves its own data out of the way.
• The kernel's own memory matches the original's: the same size, the same number of thread stacks, and no extra threads.
• One file cache shared by the hard disk and DVD file systems, sized and counted like the original's: 16 pages at boot, and whatever a game or the dashboard asks for. Before, DVD directory lookups and small reads went to the drive every time.
• Memory statistics report what the original reports (game image, cache, pool and stack memory), and the debugger memory table points at structures in the original's format.

Measured result (free memory when the game starts)

Game	Original kernel	v0.1.3	v0.1.4
Dashboard	15,876 pages	15,560	15,881
Halo	15,347	15,042	15,350
Halo 2	14,880	14,575	14,883
Half-Life 2	16,166	15,861	16,169

During gameplay, memory use by type (game, graphics, pool, cache) now matches the original kernel within a few pages in all four.

Checked in xemu

• All make test phases pass, including a new test that moving memory in use keeps its contents.
• The dashboard, Halo, Halo 2 and Half-Life 2 played for several minutes each.

Using it in xemu

1. Open Machine → Settings → System.
2. Set Flash (BIOS) File to bios_v0.1.4.bin and leave MCPX Boot ROM File empty.

Known limitations

• Not tested on a real console yet.
• The power, eject and AV-cable events moved to a new code path. They pass the tests, but haven't been triggered by hand from xemu's menu yet.
• No TV-encoder tables.
• No certificate key: stock saves and System Link with stock consoles won't work.

Sources (GPL-2.0)

• This repository at tag v0.1.4.
• XboxDev/cromwell at 86f547387184d1001d377cce97d3756c8acf91cc for the X-codes and EEPROM key states.
• Contains no Microsoft code. Not affiliated with or endorsed by Microsoft.

OXOS v0.1.3

Bug-fix release: Half-Life 2 controller input now works, and the kernel keeps everything the original keeps when one game launches another.

Download: bios_v0.1.3.bin (1 MB, SHA-256 a94dded3836d76f6be31e17bfb98cb71ca3fe4031d5f92249748c61476b2add8)

Fixes

• Controller didn't work in Half-Life 2 ("Press START" ignored every button).
  • Half-Life 2 starts through a small launcher that restarts the kernel into the real game (a quick reboot).
  • XboxHardwareInfo was filled at power-on only and wiped by that restart. The game's USB code sizes its descriptor pool from those flags; with them zeroed it ran out on the second hub and never found the pad.
  • It now survives quick reboots, as in the original kernel. Any game that starts through a launcher could have hit this.
• More state kept across quick reboots, checked against everything the original kernel keeps:
  • AV cable type from power-on. Before, unplugging and replugging the same AV cable during a game started from the dashboard reset the console.
  • "Game loaded" flag for eject and tray events. An eject while the next game was loading took the before-launch path.
  • Network PHY "initialized" flag. Every networked game re-ran the link negotiation, which can take a few seconds.
• Widescreen signal. Mode changes now drive the AV connector's widescreen line (GPIO 0x80D6). With xemu's Auto aspect ratio, widescreen SD modes such as the dashboard's display at 16:9.
• The 2BL clears the 8 bytes the boot trick leaves at physical address 0, so page 0 starts zeroed as with a Microsoft BIOS.

For developers (make run)

• Keeps a persistent HDD copy and EEPROM per HDD image, so saves and settings survive. It starts from the Microsoft dashboard image when present and defaults to widescreen 1920x1080.
• ASPECT=auto|native|4x3|16x9. The original kernel sends the widescreen signal only for SD modes, so widescreen games in 480p/HD (Halo 2) need ASPECT=16x9.

Checked in xemu

• Half-Life 2: START on the title screen goes on to load the first level, as with a Microsoft BIOS.
• Halo 2 in 16:9 at 480p.
• The dashboard, Halo, Halo 2 and Brute Force as in v0.1.2.
• All make test phases and the controller test pass.

Using it in xemu

1. Open Machine → Settings → System.
2. Set Flash (BIOS) File to bios_v0.1.3.bin and leave MCPX Boot ROM File empty.

Known limitations

• Not tested on a real console yet.
• No TV-encoder tables.
• No certificate key: stock saves and System Link with stock consoles won't work.

Sources (GPL-2.0)

• This repository at tag v0.1.3.
• XboxDev/cromwell at 86f547387184d1001d377cce97d3756c8acf91cc for the X-codes and EEPROM key states.
• Contains no Microsoft code. Not affiliated with or endorsed by Microsoft.

OXOS v0.1.2

Compatibility release: Brute Force now starts in xemu and reaches its main menu.

Download: bios_v0.1.2.bin (1 MB, SHA-256 761e37ed9b1cbae51b6e6133a4c4e7006b7ccb1877c8da81d020c5fd672c11c5)

Fixes

• Brute Force quit straight back to the dashboard.
  • Games built with later XDKs check the disc themselves: the drive must report an authenticated Xbox disc, and the disc's security sector must carry a matching timestamp, hash and RSA signature.
  • xemu doesn't emulate these drive commands, and OXOS carries no Microsoft key. On a drive without them (such as xemu's), the CD-ROM driver now answers them itself. Every security sector handed to a game is signed with OXOS's own open key, which now fills XePublicKeyData.
• Stuck on "Loading" (Brute Force). The game copies files from the disc to the hard-disk cache until it gets "end of file". Disc (XDVDFS) reads rejected that last read as an invalid parameter. They now check end of file first, as the original kernel does (the same rule v0.1.1 fixed for FATX).
• Garbage menu textures (Brute Force). The game opens files as z:\dir\\name, with a doubled backslash. The original kernel's FATX driver accepts one doubled separator; ours now does too.
• CD-ROM pass-through always sends the 12-byte command block, as the original kernel does.
• KeStallExecutionProcessor uses the original kernel's fixed loop count.
• Boot splash stays up until the game draws its first frame.
• Trace builds (make run-trace) show the last CD-ROM drive requests on screen, for diagnosing disc boots.

Checked in xemu

• Brute Force: intro movie and main menu with correct textures.
• The dashboard, Halo and Halo 2 work as in v0.1.1.

Using it in xemu

1. Open Machine → Settings → System.
2. Set Flash (BIOS) File to bios_v0.1.2.bin and leave MCPX Boot ROM File empty.

Known limitations

• Not tested on a real console yet.
• No TV-encoder tables.
• No certificate key: stock saves and System Link with stock consoles won't work.
• Brute Force has only been checked as far as its main menu.

Sources (GPL-2.0)

• This repository at tag v0.1.2.
• XboxDev/cromwell at 86f547387184d1001d377cce97d3756c8acf91cc for the X-codes and EEPROM key states.
• Contains no Microsoft code. Not affiliated with or endorsed by Microsoft.

OXOS v0.1.1

Bug-fix release: the stock Microsoft dashboard now runs on OXOS (from a hard disk dumped from a real console).

Download: bios_v0.1.1.bin (1 MB, SHA-256 8d251a9d768dde72dcaa9a8be00fc477f7eabf9f3bc481ec4dbb4c8ff1c92e4c)

Fixes

• Error 21 with the stock dashboard.
  • The dashboard reads files until it gets "end of file". Our FATX driver rejected that last read as an invalid parameter, so the dashboard gave up and rebooted into error 21.
  • Reads now check end of file first, as the original kernel does.
• Memory screen showed "0 blocks". Opening C:\ through a drive letter opened the volume instead of its root directory. The hard disk now shows its real size.
• Disc reads (UDF): non-cached reads whose length isn't whole sectors are accepted, as the original kernel does. This is the same rule as the Halo 2 disc fix in v0.1.
• FATX scatter/gather reads follow the same end-of-file-first rule.
• Tests: a self-test buffer was too small for the stock xboxdash.xbe, and the quick-reboot test no longer depends on how the dashboard treats its launch data.

Checked in xemu

• The stock dashboard boots and its menu, Memory, Music and Settings work.
• The xemu HDD image's dashboard, Halo and Halo 2 work as in v0.1.

Using it in xemu

1. Open Machine → Settings → System.
2. Set Flash (BIOS) File to bios_v0.1.1.bin and leave MCPX Boot ROM File empty.

Known limitations (unchanged)

• Not tested on a real console yet.
• No TV-encoder tables.
• No certificate key: stock saves and System Link with stock consoles won't work.

Sources (GPL-2.0)

• This repository at tag v0.1.1.
• XboxDev/cromwell at 86f547387184d1001d377cce97d3756c8acf91cc for the X-codes and EEPROM key states.
• Contains no Microsoft code. Not affiliated with or endorsed by Microsoft.

OXOS v0.1

First release of OXOS: a clean-room, open-source Xbox kernel in a fully open 1 MB BIOS image.

Download: bios_v0.1.bin (1 MB, SHA-256 703fba282a052dfbff8241bf5b410a86a89a619a5a287fb13820b0c008dcfbd7)

What works (in xemu)

• The dashboard (e.g. the copyright-free xemu HDD image), Halo and Halo 2 (playable), and UDF (DVD-video) discs.
• Boots without an MCPX boot ROM file (our reset code runs the X-codes), and through the real MCPX 1.0 boot ROM.
• Stock locked hard disks unlock (EEPROM key handling from XboxDev/cromwell).
• Own boot splash.

Using it in xemu

1. Open Machine → Settings → System.
2. Set Flash (BIOS) File to bios_v0.1.bin and leave MCPX Boot ROM File empty.
3. Use an HDD image such as xemu's copyright-free one.

Known limitations

• Not tested on a real console yet. The TV-encoder mode tables are still missing, so expect no picture on real TVs.
• No certificate key.
  • Saves from a stock console do not verify under OXOS (and the other way round).
  • System Link only works between OXOS consoles.
  • Saves made under OXOS work fine among themselves.
• Targets console revisions 1.0–1.5 (MCPX 1.0/1.1).

Contents and sources (GPL-2.0)

• Kernel, 2BL and reset code: this repository at tag v0.1. Build with cd kernel && make BUILD=build-release SELFTEST=0 build-release/bios.bin.
• MCPX header, X-code table and EEPROM key states: XboxDev/cromwell at commit 86f547387184d1001d377cce97d3756c8acf91cc (GPL-2.0), fetched by the build.
• Contains no Microsoft code. Not affiliated with or endorsed by Microsoft; "Xbox" is a trademark of Microsoft Corporation.