Files

MechaCat02 ef93a4fa14 handoff: VSync/event-wedge fixes + iterate 2.A–2.BC research notes

Source changes (dormant parity infra, retained from iterate 2.AI/2.AO):
- xenia-kernel/exports.rs: nt_create_event manual_reset polarity +
  related event wiring
- xenia-gpu/mmio_region.rs: D1MODE_VBLANK_VLINE_STATUS hardcode parity

Also lands the audit-runs/ analysis notes (.md/.txt/.json digests) for the
iterate 2.x VSync/0x10e8/0x1004 wedge investigation. Raw trace dumps
(.jsonl/.gz/.csv/.stdout) and agent worktrees (.claude/) are gitignored as
regenerable local artifacts — see memory + HANDOFF for the running findings.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-05 07:19:08 +02:00

3.1 KiB

Raw Blame History

Phase C — ground-truth reference

Third reference: the pre-extracted `.pe`

Path: /home/fabi/RE - Project Sylpheed/Project Sylpheed - Arc of Deception (USA, Europe) (En,Ja).pe
SHA-256: 9be5f5621c517c78a451245eca25d54388af741ed20e669b2f78438aaa429e72
Size: 9568256 bytes == xex_image_size
file(1): PE32 executable (XBOX) PowerPC (big-endian), for MS Windows, 14 sections

Provenance

Generated by tools/xex-extract/ (Rust tool in this workspace). The tool:

Parses the XEX2 header from the ISO's default.xex
Decrypts the encrypted body using XEX2 retail AES-128 key
Decompresses (LZX for normal-compressed XEXs)
Verifies MZ PE signature
Writes the resulting raw PE image to <stem>.pe

The tool is completely independent of both canary and ours — it is an offline XEX2 decoder with its own AES + LZX implementations. This makes the .pe file a true third reference for the post-decode XEX content.

Layout

The .pe file is a flat virtual image: byte offset N in the file corresponds to guest VA image_base + N = 0x82000000 + N. Verified by sampling:

offset 0x000000: 4d 5a 90 00 ... → MZ DOS header at image_base ✓
offset 0x150000 (= .text virtual_address): 7d 88 02 a6 ... → PPC mflr r12 function prologue ✓
offset 0x910800 (= .reloc virtual_address): 0c aa 8f f6 ... → PE base-relocation block records ✓
offset 0x144C00 (= .text raw_offset, but ≠ virtual_address): 00 00 ... 00 → padding gap (zero), confirming raw-offset is NOT the layout key in this file ✓

This means the engines' loaded image at [0x82000000, 0x82920000) should match .pe byte-for-byte modulo runtime patches (import slots, relocations).

What `.pe` represents

The .pe is the post-decode pre-patch XEX content. It contains:

PE headers (DOS+NT+section table)
Each section's raw bytes laid out at its virtual address
XEX import-record markers at the slot addresses listed in the XEX import table (record_type=0 → 4-byte u32 BE ordinal; record_type=1 → 16-byte thunk template 01 00 ord_hi ord_lo / 02 00 ord_hi ord_lo / mtspr ctr,r11 / bctr)
Base relocations in .reloc (not applied)

It does NOT contain:

Runtime import-slot patches (variable addresses, thunk shim bytes)
Applied base relocations
Any per-engine runtime state

Verification this session

Computed image_canonical_sha256 (XEX import slots masked to 0xCD) over all three:

source	canonical sha256
canary loaded image	`62c51908e2df705583fe81a084f39bd399196f9000cfa7bffd56127b41a4ab96`
ours loaded image	`62c51908e2df705583fe81a084f39bd399196f9000cfa7bffd56127b41a4ab96`
.pe pre-patch	`62c51908e2df705583fe81a084f39bd399196f9000cfa7bffd56127b41a4ab96`

All three match. This is the strongest possible evidence that:

Both engines decode the XEX2 file to the same canonical content.
The .pe reference is correctly aligned to engine-loaded virtual VA.
There is no XEX-decode bug in either engine at this layer.

Conclusion

.pe is validated as ground truth for the post-decode XEX image content at [image_base, image_base + image_size), modulo runtime patches.

3.1 KiB Raw Blame History