X3 3294: observed memory layout and allocation behavior

Scope and status

This reference uses the operator-supplied standard X3 Config Live 3294 image for Xbox 1.0–1.5. The supplied v16plus image targets 1.6/1.6b and has not been qualified on xemu's Xbox 1.0 machine. Both ROM files are 1,048,576 bytes. ROM size is not resident RAM consumption.

The investigation observes public kernel calls, PE section metadata, page-table mappings and device transactions. It publishes no firmware instructions, reconstructed proprietary functions, ROM payloads or captured guest memory. Implementations remain independently authored. This is behavioral research, not a certification of personnel-separated clean-room development.

Why the original xemu launch closes

Clean fork main dcc536830deba245eec36cd009db5860ca04884c powers off early with the unchanged ROM. QMP records SHUTDOWN, guest=true, reason=guest-shutdown. The device trace confirms an SMC command 0x02/value 0x80. This is a guest-requested shutdown, rather than a demonstrated host crash.

Two missing interfaces were isolated sequentially:

1. I/O port 0xF500 reads 0xFF because the default machine has no X3 identification device. The published identification value is 0xE1.
2. Supplying that value alone reveals 21 unsuccessful SMBus word reads at address 0x50, command 0, followed by another shutdown. This settings device is separate from the ordinary Xbox EEPROM at 0x54.

The unchanged standard ROM completes the allocation/lifetime guest when both interfaces are supplied. xemu issue #350 tracks the failure; draft PR #351 adds an opt-in, one-byte identification device, without changing the default machine. Existing smbus-storage supplies the private settings fixture.

The 256-byte blank settings fixture is a tested boot configuration, not a complete specification of the physical X3 EEPROM. Flash banking, LCD, switch behavior and flashing are not implemented by this small device.

Settled public allocation checkpoint

The unchanged allocation-lifetime-probe, schema 1, runs 576 pool allocations and 40 created/joined/closed thread lifetimes. All requested pool objects were obtained; public MM/PS queries and thread lifecycle operations returned success. Its final checkpoint is used consistently below. Retained Complex and SpiritBoot results are reference captures, not newly repeated native performance campaigns.

Public measurement	Complex reference	SpiritBoot current main	X3 standard reference
Unavailable physical memory, includes probe/hardware allocations	632 KiB	1,328 KiB	1,964–1,968 KiB
Pool backing at final checkpoint	20 KiB	280 KiB	20–24 KiB
Stack backing at final checkpoint	76 KiB	148 KiB	76 KiB
Reported ordinary cache backing	64 KiB	64 KiB	64 KiB
Threads at final checkpoint	1	7	1

X3 is 1,332–1,336 KiB above Complex and 636–640 KiB above SpiritBoot in this observation. A repeated local run varied by one pool page. These totals are not a firmware-only physical ownership ledger. ImagePagesCommitted also includes title allocations and does not measure the entire kernel.

X3 does not establish a smaller overall footprint than Complex or SpiritBoot. Its useful evidence is the finer pool geometry and lower settled thread/stack population.

Public pool allocation capacities

Each row holds 32 objects concurrently, obtains the first object's usable capacity through ExQueryPoolBlockSize, then releases the entire batch. The returned size is a public capacity observation; it does not reveal private allocator structures or prove physical packing by itself.

Request bytes	Objects obtained	Reported usable bytes
1	32	24
8	32	24
16	32	24
24	32	24
32	32	56
64	32	88
128	32	152
256	32	280
512	32	536
720	32	728
1,024	32	1,048
1,664	32	1,688
2,040	32	2,040
2,048	32	2,072
2,384	32	2,392
4,096	32	4,096
4,097	32	8,192
16,384	32	16,384

A 512-byte request reports 536 usable bytes and a 1,024-byte request reports 1,048. These results support investigating finer packing in SpiritBoot. They do not justify copying a proprietary allocator or assuming a particular header layout. Measure physical backing for mixed allocation sizes and lifetimes before choosing classes.

The Windows cold boot reproduces the local final checkpoint: 15,892 available physical pages, six committed pool pages, 19 stack pages, 16 cache pages and one thread. It completes the same guest again after reset. The compiled Windows binary is 0.8.136-0-g050174b03ff6, based only on clean xemu main plus draft PR #351.

The same sequential batch procedure also records newly committed pool backing. These are additional pages relative to each batch's before checkpoint, with prior batches already executed; they are not fresh-slab packing formulas or firmware-only totals.

Request bytes, 32 simultaneous objects	SpiritBoot main additional pages	X3 additional pages
256	4	0
512	8	1
1,024	15	7
2,048	32	28
2,384	32	28

X3's zero additional pages for 256-byte objects means existing backing could serve this batch; it does not mean the objects occupy no physical memory. The measured backing deltas support a packing/lifetime investigation without assuming the private allocator's design.

After the complete allocation/thread procedure, X3 returns to 19 stack pages and five or six pool pages. Temporary eight-thread waves obtain and release their backing. This is stronger lifetime evidence than comparing nominal allocation capacities alone.

Kernel section mappings

The observed PE kernel header is at virtual 0x80010000, backed initially by physical 0x00010000. Its SizeOfImage is 0xBEAC0 / 780,992 bytes. Metadata and page-table observations at the completed probe give:

Section	Virtual content bytes	Relative virtual address	Present section pages
.text	203,136	0x2e0	50
KDCODE	13,887	0x31c60	5
.data	84,569	0x352a0	21
STICKY	10,788	0x49d00	4
IDEXPRDT	264	0x4c800	1
INIT	467,354	0x4c920	115

Section boundary pages overlap. Counting each backing page once yields 191 mapped physical pages / 764 KiB across these section ranges. Adding the individual row counts would double-count shared pages.

All 115 pages intersecting INIT remain mapped in this capture. Mapped does not prove reserved: an alias may remain after physical backing has been returned to an allocator. The current experiment does not identify X3's internal PFN ownership flags, so it cannot label those pages reclaimable, exclusively resident, or wasted. It also does not establish runtime execution from ROM. Those require a separate physical ownership/execution investigation.

What the evidence supports for SpiritBoot

• Pool geometry: evaluate classes that improve objects-per-page for actual live populations; retain independent query/free/alignment tests.
• Thread ownership: explain each of SpiritBoot's extra settled execution contexts and its stack lifetime. Do not merely lower stack limits.
• Image ownership: keep section mappings separate from the physical owner ledger, especially discardable INIT aliases.
• X3 compatibility: explicit emulated modchip hardware allows an unmodified reference BIOS to become observable. It does not make the kernel's allocation policy correct or optimal by assumption.

Qualification boundaries

The compiled optional device passes actual qtest I/O checks: default-machine behavior, identification, write protection, adjacent port, split word/dword accesses and completed reset. The local production candidate also completes the unchanged guest without debugger intervention. Native Windows production I/O, cold firmware boot and warm reset have also passed. Native utility rendering and menu navigation are verified. The operator identifies this image as loading its own BIOS loader/tool; direct retail-title boot is unqualified. Two Conker attempts remained in the utility and are not game PASS results. GitHub CI dispatch currently rejects the build because Actions is disabled; local checks do not establish an all-platform CI pass. The reference is not a claim of full X3 flash-device support or game performance improvement.

References

• Original X3 release notes: hardware revision selection and default-settings warning.
• Pinned public interoperability constants: register addresses; implementation not copied.
• Resident-Memory-Comparison, Complex-BIOS-Size-and-Layout, SpiritBoot-BIOS-Size-and-Layout: retained comparison context.

Utility launch and input distinction

With a keyboard controller connected, the observed firmware preference Autostart X3 Config Live is initially enabled. It was toggled to Disabled through the visible firmware UI during diagnosis, but retail Conker still did not reach its menu. The public allocation guest continues to complete with the configured fixture and reports the same 1,968 KiB unavailable checkpoint. Do not infer a memory-capacity failure or game compatibility from those utility screenshots.

The first diagnostic window selector could match SDL's hidden offscreen helper. Corrected selection requires the visible window with an xemu title; firmware navigation then visibly works. These input/harness corrections change no BIOS instructions or official authored benchmark procedure.

HDD dashboard cold-boot and reset clearing observations

The original nxdk fixture in SpiritBoot draft PR #150 boots as \Device\Harddisk0\partition2\xboxdash.xbe on Linux and native Windows. This dedicated diagnostic route does not change authored game benchmarks. Original ROM/HDD/EEPROM files remain intact.

Before the first CPU instruction, the host seeded all ordinary 64 MiB RAM with unique, nonzero, address-specific words and read back every byte. The early checkpoint occurs at DASH_EARLY_READY, after nxdk startup but before the fixture's framebuffer and marker-buffer allocations.

Cold-boot page class	Pages	Meaning
Retained	6,246	Entire page still matches its preboot seed.
Zero	1,450	All bytes are zero at capture.
Replaced	8,648	Changed, without a surviving marker word.
Mixed	40	Changed, with a surviving marker word.
Total	16,384	Complete 64 MiB capture.

24.398 MiB retains its exact preboot markers. A blanket full-RAM clear is not observed on this path. Zero or changed pages do not identify their writer; normal boot reuse can replace markers.

Linux and Windows early public statistics agree: 16,384 total pages, 15,898 available, one pool page, 19 stack pages, 16 cache pages, 19 title-image pages and one thread. The 486 unavailable pages (1,944 KiB) include guest and hardware allocations. This is not a firmware-only subtotal or the same checkpoint as the completed allocation/lifetime probe above.

For warm reset, three nonpersistent 64 KiB contiguous allocations receive known nonzero words only inside their owned ranges. Their recorded addresses were 0x03bd0000, 0x03be0000, and 0x03bf0000. After a completed QMP reset, the next early capture precedes new fixture buffers/framebuffer allocation. Both hosts agree: 40 of 48 pages are zero, eight replaced, and none retain the original markers. This establishes loss of these markers on this reset route, not a universal clearing or persistence rule.

The separate DVD launcher verifies the optical XBE signature before requesting launch. At ab801d8 its build and four analyzer contracts pass, but the native Conker handoff returns to the HDD dashboard. Successful access/request is not proof of game entry. Game performance, persistent allocations and 128 MiB behavior remain unqualified by this experiment. Raw ROMs, dumps and retail assets remain private; the repository holds original source and numeric results.