Crusader_Decomp/docs/psx/psx.md

Crusader: No Remorse (PlayStation) Recon

Scope

• Target disc tree: E:\emu\psx\Crusader - No Remorse
• Goal of this pass: identify the boot executable, separate likely code from content, and find the most practical first extraction routes for PS1 assets.

Function Coverage Census

Current live census for the active Ghidra SLUS_002.68 session:

• Raw function table: 1428 total, 1070 named, 358 still anonymous (74.93% named)
• Local executable code only (0x800... addresses): 1274 total, 917 named, 357 still anonymous (71.98% named, 28.02% anonymous)

Method used:

• queried the live MCP list_functions endpoint against the active PSX program
• counted FUN_ and nullfn_ names as anonymous placeholders
• treated the 0x800... address range as the practical coverage metric so imported/system helpers in other spaces do not distort the remaining-work count

Current hottest anonymous local windows by 0x1000 page are:

• 0x8002exxx: 21
• 0x80030xxx: 21
• 0x80049xxx: 21
• 0x80031xxx: 17
• 0x80040xxx: 14
• 0x8002bxxx: 14
• 0x8003axxx: 13
• 0x80020xxx: 13
• 0x80048xxx: 13
• 0x80046xxx: 11

Practical read:

• the PSX database is well past the early blind-mapping stage; roughly seven tenths of the local code already has non-placeholder names
• the remaining anonymous mass clusters in a few rendering, world-update, and resource-heavy windows rather than being evenly spread
• 0x80040xxx remaining hot is still consistent with the current map-rendering blocker, because that window contains late projection and presentation helpers rather than only loader-side code

Immediate Conclusions

• SYSTEM.CNF is the disc boot file and points directly at cdrom:\SLUS_002.68;1.
• SLUS_002.68 is the main game executable. It begins with a valid PS-X EXE header.
• No other top-level file currently looks like a second normal PS1 executable.
• Disc content is dominated by standard PS1 media (.STR, .XA) plus a large number of game-specific .WDL blobs.
• FMV.BIN looks like movie-playback support data or a resource blob, not a bootable executable.
• ZZZ.ZZZ looks much more like media/container data than code, and its size exactly matches MOVIES/FMV3.STR.

Disc Boot Evidence

SYSTEM.CNF contents:

BOOT = cdrom:\SLUS_002.68;1
TCB = 4
EVENT = 10
STACK = 801FFFFC

SLUS_002.68 header evidence:

• Magic: PS-X EXE
• Initial PC: 0x8004BD90
• Load address: 0x80010000
• Image size: 0x000A4800 (675,840 bytes)

This is the clearest Ghidra import candidate for code analysis.

Top-Level File Classification

Top-level items:

• SLUS_002.68
• SYSTEM.CNF
• FMV.BIN
• ZZZ.ZZZ
• SPEC_A.WDL
• LEGAL.SCR
• LICENSEA.DAT
• AUDIO/
• MOVIES/
• MENUS/
• LSET1/ through LSET7/

Recursive extension summary from the extracted disc tree:

Extension	Count	Total bytes	Current classification
.STR	33	415,027,744	PS1 movie streams
.XA	2	91,897,856	PS1 XA audio
.WDL	66	76,198,860	custom game asset/level blobs
.ZZZ	1	26,148,984	likely media/container data
.68	1	675,840	main PS1 executable
.SCR	1	153,600	data asset
.BIN	1	90,812	support/resource blob
.DAT	1	28,032	data asset
.CNF	1	70	boot config

File Family Findings

1. SLUS_002.68

• This is the boot target from SYSTEM.CNF.
• It has a normal PS1 executable header.
• It should be the first import into Ghidra.
• Current working assumption: this is the only primary native code binary on the disc.

2. AUDIO/*.XA

• Files found:
  • AUDIO/MULTI8.XA
  • AUDIO/TALK1.XA
• These are standard PS1 XA audio files.
• MULTI8.XA is divisible by both 2352 and 2048, which is consistent with sector-oriented media data.
• TALK1.XA is divisible by 2048 but not exactly by 2352.
• Most practical extraction route: use standard PS1/XA tooling rather than custom RE first.

3. MOVIES/*.STR

• Files found: FMV0.STR through FMV32.STR.
• These are the strongest candidates for standard PS1 video streams.
• The raw headers look consistent with sectorized PS1 stream data rather than executable code.
• Most practical extraction route: treat them as PS1 STR video and run them through PS1 media tooling first.

4. FMV.BIN

This file does not look like a normal executable.

First bytes begin with:

\MOVIES\FMV%d.STR
MDEC_rest:bad option(%d)
MDEC_in_sync
MDEC_out_sync
DMA=(%d,%d), ADDR=(0x%08x->0x%08x)
FIFO=(%d,%d),BUSY=%d,DREQ=(%d,%d),RGB24=%d,STP=%d

Current best read:

• FMV.BIN is movie-related support data, code tables, or debug/resource text for the MDEC/FMVs.
• It clearly references the external movie path pattern \MOVIES\FMV%d.STR.
• It is worth a secondary Ghidra import only if the goal is to understand the movie subsystem specifically.
• It is not the disc boot executable.

5. ZZZ.ZZZ

Key findings:

• Size: 26,148,984 bytes
• That size exactly matches MOVIES/FMV3.STR.
• The file begins with stream-like binary data rather than an executable header.
• It also yielded movie-adjacent string evidence such as MDEC.

Current best read:

• ZZZ.ZZZ is probably not code.
• It is a strong candidate for either:
  • a renamed movie stream, or
  • a duplicate/alternate copy of FMV3.STR

Most practical next check:

1. compare a few sectors or hashes against MOVIES/FMV3.STR
2. try opening ZZZ.ZZZ directly in PS1 STR-capable tooling

6. LSET*/L*.WDL

These are the most important unknown asset family for content extraction.

Representative level sample: LSET1/L0.WDL

• Size: 1,312,624 bytes
• Header starts with structured values, not raw pixels:

0x00000034 0x00006FDC 0x0000376C 0x00001000
0x00000160 0x00000498 0x0000025C 0x00000FE0
0x00000070 0x00072EC4 0x00034B6C 0x00007448
0x0007407C 0x00010824 0x00000002 0x00000000

• This does not behave like a flat framebuffer dump.
• It looks more like a custom structured level/container blob with internal offsets, lengths, or section pointers.
• Additional offset targets inside the file, such as 0x376C, 0x6FDC, and 0x10824, land on repeating structured records rather than code.

Strict TIM-style scan results for L0.WDL found plausible embedded PS1 image headers at:

• 0xE7A84
• 0x117DEC
• 0x12CECC
• 0x135F18
• 0x1369F4
• 0x136B38
• 0x136C40

Current best read:

• LSET*.WDL likely holds mixed level resources.
• At least some of those resources may include standard embedded PS1 TIM-like image blocks.
• These files are the strongest current target for a custom extractor.

Executable-guided extraction status:

• lset_level_bundle_load in the imported PSX executable now confirms the executable builds \LSETn\Lx.WDL paths directly and treats those files as the live level-bundle format.
• The same loader reads a small level header blob first, then a large SPU/audio blob, then dispatches the remaining level resource stream through psx_stream_install_type_runtime_banks.
• image_resource_bind_vram_slot and image_bundle_load_to_vram show that resource types 4 and 5 are image/sprite-oriented resources: they resolve VRAM placement and upload image data through LoadImage.
• sprite_rle_decode_rows is now confirmed as the row-based decompressor used when a type-5 frame record has its compressed bit set.
• Current consequence: sprite extraction now has a real executable-backed path, while map extraction has a reliable raw-carving path even though the full tile/object semantics are not decoded yet.

7. MENUS/*.WDL and SPEC_A.WDL

Representative menu sample: MENUS/M13.WDL

• Size: 1,475,928 bytes
• Starts with dense repeating values like:

0x9D499D29 0x9D299D29 0x9D4A9D4A 0xA14A9D4A
0x9D49A14A 0x9D299D29 0x9D4A9D4A 0xA14A9D4A

Representative special sample: SPEC_A.WDL

• Size: 545,424 bytes
• Starts with the same raw-looking pattern as M13.WDL.

Current best read:

• These do not begin with obvious pointer tables.
• They look more like raw or lightly wrapped image/screen asset data than like level containers.
• M13.WDL had no strict TIM hits in the quick scan.
• SPEC_A.WDL did have a few plausible stricter TIM-style hits at:
  • 0x449A8
  • 0x80ED8

So the .WDL family probably is not one single uniform format. Current evidence supports at least two subfamilies:

• structured level/resource blobs (LSET*/*.WDL)
• raw-looking menu/special screen blobs (MENUS/*.WDL, SPEC_A.WDL)

Executable-guided extraction status:

• SPEC_A.WDL does not behave like the LSET*.WDL container family.
• The executable-backed extractor work currently treats it as a raw blob with embedded image candidates rather than as a contiguous section table.
• A validated carve on SPEC_A.WDL currently finds strict TIM-style hits at 0x1B5CC and 0x80ED8.

Executable-Backed Extraction Model

These findings are now grounded in both file inspection and the imported SLUS_002.68 executable.

Level bundles: LSET*/*.WDL

Validated current extraction model for LSET1/L0.WDL:

• top-level header size: 0x34
• immediately following blob: 0x6FDC bytes
• post-audio resource area starts at: 0x7010
• high-confidence internal boundaries recovered from the header and validated with the extractor:
  • 0x7448
  • 0x34B6C
  • 0x72EC4
  • 0x7407C

Current carved regions from L0.WDL:

Region	Offset	Size	Current interpretation
audio_or_spu_blob	0x34	0x6FDC	SPU/sequence data loaded by the audio init path
post_audio_region_00	0x7010	0x438	small table/directory block
post_audio_region_01	0x7448	0x2D724	strong map/placement candidate
post_audio_region_02	0x34B6C	0x3E358	strong map/placement candidate
post_audio_region_03	0x72EC4	0x11B8	small control/index block
post_audio_region_04	0x7407C	0xCC6F4	strongest current sprite/graphics bank candidate

Important consequence:

• for map work, the best current extraction targets are post_audio_region_01 and post_audio_region_02
• for sprite/graphics work, the best current extraction target is post_audio_region_04

Important correction from the next executable pass:

• a previously suspected text-like block in the broader PSX resource system is now confirmed separately in executable analysis as a menu/prompt text resource, not map data
• a heavily used level-side table is also now confirmed as a per-type flag/behavior table used by collision/order logic, not a raw map grid
• so the late-level extraction focus stays on LSET*.WDL post-audio regions, not on every large runtime table seen in the executable

The validated strict TIM carver currently finds one confirmed embedded TIM block in L0.WDL at:

• 0xBBA54

That hit lands inside post_audio_region_04, which supports treating the late large region as the current best graphics bank candidate.

The same structure now reproduces on LSET1/L1.WDL too:

• header size: 0x34
• audio blob: 0x3244
• post-audio start: 0x3278
• high-confidence boundaries: 0x6F48, 0x334D8, 0x602C4, 0x732D4
• late graphics candidate region: 0x732D4 .. EOF
• current strict TIM hit: 0xB4DC8

So the current working model is no longer based on just one level file: LSET bundles appear to share a stable pattern of:

1. fixed 0x34 header
2. SPU/audio blob
3. several map/meta candidate regions
4. one large late graphics-oriented region

What is still not stable yet:

• the internal semantics of post_audio_region_01 and post_audio_region_02 are still unresolved
• L0.WDL starts with rows that look structured when viewed as u16x6, but L1.WDL does not preserve the same obvious interpretation at the same region boundary
• current safest reading is that these are still raw candidate map/meta payloads, not yet a decoded placement format

Menu / special blobs: SPEC_A.WDL, MENUS/*.WDL

These currently behave like raw image-oriented blobs, not like the structured LSET family.

Validated current extraction model for SPEC_A.WDL:

• whole-file raw blob fallback works cleanly
• strict TIM hits currently validate at:
  • 0x1B5CC
  • 0x80ED8

Representative secondary check on MENUS/M13.WDL:

• whole-file raw blob fallback also works cleanly there
• current strict TIM hit validates at:
  • 0x493EC

This keeps menus/special screens as a secondary image-carving problem instead of a map/container problem.

Working Extractor

Current extractor script:

• tools/psx_extract_wdl.py

What it does right now:

• recognizes the validated LSET*.WDL top-level layout
• carves the audio blob and header-directed post-audio regions
• scans the whole file for strict TIM blocks and extracts them
• falls back to raw-blob carving for SPEC_A.WDL / menu-like files
• emits an exploratory u16x6 CSV view for the first post-audio LSET candidate region so raw row patterns can be inspected without claiming final semantics
• scans the large late LSET graphics region for type-5 sprite bundle headers
• decodes row-RLE compressed sprite frames and writes raw frame payloads plus grayscale preview images
• writes carved output under out/psx_wdl/<stem>/

Current practical usage:

c:/Users/Maddo/.PYENV/PYENV-WIN/versions/3.14.3/python.exe tools/psx_extract_wdl.py "E:/emu/psx/Crusader - No Remorse/LSET1/L0.WDL"
c:/Users/Maddo/.PYENV/PYENV-WIN/versions/3.14.3/python.exe tools/psx_extract_wdl.py "E:/emu/psx/Crusader - No Remorse/SPEC_A.WDL"

This is enough to start extracting:

• raw map-candidate blocks from level bundles
• strict TIM sprite/image blocks from both level and menu/special blobs
• exploratory raw row exports for the first LSET post-audio candidate region
• actual extracted sprite frames from at least some type-5 bundles inside the late LSET graphics region

Current caution:

• the u16x6 export is only a raw inspection aid
• L0.WDL gives structured-looking rows such as 0041,177B,0F7F,0000,0002,0020, but L1.WDL shows very different values at the same relative region
• so this export should be treated as evidence-gathering for map decoding, not as a solved object-placement parser yet

Confirmed Sprite Extraction

The extractor now produces actual sprite-frame outputs from at least part of the late LSET graphics bank.

The late-graphics scan is now widened beyond the original first-32-bundle probe. Current L0.WDL extraction finds 159 candidate bundles in post_audio_region_04, and the larger-first overview now clearly includes not just floor/wall tiles but also several object/UI-like assets such as framed panels, cabinets, a portrait, a hand-shaped sprite, a bone, and other small pickup-like art.

Confirmed current example from LSET1/L0.WDL:

• graphics-region-relative bundle offset: 0xE5B8
• whole-file bundle offset: 0x82634
• mode: 2 (current best read: 4bpp indexed)
• frame count: 3
• first extracted frame dimensions: 40 x 66
• runtime default bundle palette index: 12

Confirmed output files:

• raw frame bytes: out/psx_wdl/L0/sprite_bundles/bundle_0000E5B8/frame_000.bin
• preview image: out/psx_wdl/L0/sprite_bundles/bundle_0000E5B8/frame_000.png
• colored preview image: out/psx_wdl/L0/sprite_bundles/bundle_0000E5B8/frame_000_color.png
• colored sprite atlas: out/psx_wdl/L0/sprite_bundles/bundle_0000E5B8/atlas_color.png
• bundle metadata: out/psx_wdl/L0/sprite_bundles/bundle_0000E5B8/bundle.json
• palette metadata: out/psx_wdl/L0/sprite_bundles/bundle_0000E5B8/palette.json

Current result:

• this is no longer just a graphics-bank hypothesis
• the workflow can now extract actual sprite/image frame payloads and render preview images from at least some LSET graphics bundles
• the workflow can now also render colored previews and a proper per-bundle RGBA atlas using the bundle default palette index recovered from the PSX executable
• widened grayscale overviews now confirm that the late graphics bank contains recognizable object and UI art, not just texture/noise candidates

Current palette model:

• the executable-backed palette source for LSET*.WDL is the first 0x1000 bytes loaded into DAT_800676d8 by lset_level_bundle_load
• level_palette_upload_cluts uploads that 0x1000 block as 8 x 16 raw 16-color CLUTs and then caches the raw CLUT handles in DAT_800a9f48
• level_palette_expand_5bit_to_16color separately builds a second 0x1000 grayscale-expanded table, but DAT_800a9f48 is populated only from the first 8 raw rows
• the bundle header field at +0x14 is the default palette-table index used when no override is supplied at draw time
• the remaining blocker is not locating the raw CLUT block anymore; it is recovering the per-placement palette override metadata that can replace the bundle default during map/tile rendering

Current color blocker:

• both main texture draw helpers (FUN_80044bdc and FUN_80044e9c) fall back to the bundle default palette index only when no override is present
• the important caller path at FUN_80041458 ORs in a high-byte palette override from object/tile metadata pointed to by object field +0xa0
• that +0xa0 pointer is now tighter too: both object constructors store the original authored source-record pointer there, so the override is not coming from a hidden runtime side table. For current solved families the draw helper reads the override straight from the authored record bytes:
  • type 0x003e..0x00ab: high byte of source word at record +0x06
  • type >= 0x00ac: high byte of source word at record +0x0c
• that means standalone bundle previews can still be wrong even when the bundle parser and raw CLUT table are both correct
• the extractor now emits wider u16x12 raw CSV views for post_audio_region_01 and post_audio_region_02 because the relevant override state appears to live beyond the first 6 words of those candidate placement records
• the current top-ranked portrait bundle (bundle_00064478, default palette index 106) is a useful color-validation anchor because the grayscale frame is obviously correct while all raw-palette candidates remain visibly wrong
• another important unresolved issue is the exact on-disk location of the second-stage runtime header after the initial 0x3520 front image block. The loader assembly proves the runtime sequence is: 0x3520 front block -> 12-byte header -> palette blob -> audio blob -> 4-byte stream count, but the raw file bytes at offset 0x3520 do not yet reconcile cleanly with those expected sizes.
• cd_file_read itself does not transform or decompress bytes; it performs sector-based buffered CD reads. So the remaining palette-source problem is now narrowed to file-layout interpretation rather than hidden read-time decoding.

Runtime Dump Grounding: cabinet console bundle

The new RAM/VRAM dump pair was used to ground the known-colored cabinet console bundle against live runtime state instead of continuing static palette guessing.

Verified cabinet anchor:

• bundle: out/psx_wdl/L0/sprite_bundles/bundle_000A1B04
• mode: 1
• frame 0: 56 x 68
• default bundle palette index: 0

Verified live-texture result from binary/Crusader - No Remorse (USA) GPU RAM.bin:

• the frame payload from bundle_000A1B04/frame_000.bin exists in live VRAM as one exact 8bpp texture match
• exact match location: texel x=258, y=256
• texture page: (1,1)
• in-page offset: (2,0)
• no flipped exact match was found

This is a strong confirmation that the current mode 1 pixel decode is correct. The remaining problem is CLUT selection, not texture extraction.

Verified CLUT result from the same dump:

• the active CLUT band used by level_palette_upload_cluts still sits at rows 0xF0..0xF7
• the important successful step was simpler than the later screen-match ranking pass: in live_vram_clut_atlas.png, the very first candidate at the top-left corner is the correct formula for this visible cabinet family
• that top-left candidate is the contiguous 256-entry palette taken directly from live GPU row 0xF0 at x=0
• in other words, current best read for this mode 1 family is: byte value -> direct index into the 256-word slice [row 0xF0, x 0..255]
• equivalently, this behaves like 16 adjacent live 16-color CLUTs flattened into one 256-entry lookup table for the sprite byte stream
• the later numeric ranking pass that preferred handle 64 / row 0xF4 was misleading for this case and should not be treated as the correct palette formula

Important consequence:

• the dump-grounded success case is not bundle default row 0 from L0.WDL and not the later row 0xF4 ranking result
• the working palette source is the live VRAM CLUT row 0xF0, x=0, treated as one contiguous 256-entry table
• this means the current extractor problem for mode 1 bundles is better described as recover the runtime CLUT-row formula rather than pick one cached CLUT handle index
• for the visible wall-console bundle, that runtime formula now has a concrete verified answer even though the higher-level metadata path that selects it is still unresolved

Wider decode result using the corrected formula:

• a focused batch renderer was run over the detected mode 1 bundles in LSET1/L0.WDL post-audio graphics region 04
• using the same live palette source row 0xF0 / x=0, the pass rendered 92 mode 1 bundles with plausible colored output instead of only the single cabinet proof case
• the strongest batch proof is the generated overview:
  • out/psx_wdl/L0/mode1_live_clut_row_f0_x0/overview_live_row_f0_x0.png
• per-bundle outputs and summary metadata now live under:
  • out/psx_wdl/L0/mode1_live_clut_row_f0_x0/
  • out/psx_wdl/L0/mode1_live_clut_row_f0_x0/summary.json
• that wider pass now shows many object-like assets decoding plausibly under the same rule: cabinets, panels, tanks, wall fixtures, floor markers, weapons, pickups, and small machinery props

Generated runtime-grounded artifacts:

• binary/psx_framebuffer_left.png
• binary/psx_framebuffer_console_crop.png
• out/psx_wdl/L0/sprite_bundles/bundle_000A1B04/live_vram_clut_atlas.png
• out/psx_wdl/L0/sprite_bundles/bundle_000A1B04/live_vram_clut_top_matches.png
• out/psx_wdl/L0/sprite_bundles/bundle_000A1B04/live_vram_clut_best.png
• out/psx_wdl/L0/sprite_bundles/bundle_000A1B04/live_vram_clut_rank.txt
• out/psx_wdl/L0/mode1_live_clut_row_f0_x0/overview_live_row_f0_x0.png
• out/psx_wdl/L0/mode1_live_clut_row_f0_x0/summary.json

One important caveat from the dump-grounded pass:

• none of the 8 raw 256-color palette blocks carved from LSET1/L0.WDL matched the live CLUT rows byte-for-byte in this dump
• that means either the dump was captured from a different loaded level/resource set, or the active runtime palette source for this on-screen console is not the raw L0.WDL palette blob currently being tested

Palette follow-up note:

• most extracted PSX sprite data is now structurally correct, but palette selection is still only partially solved
• the current exporter should therefore be treated as good enough to continue map work, not as a final automatic color pipeline
• we need a later pass to recover the runtime palette-selection rule well enough to assign the correct palette automatically for every bundle family instead of relying on the currently verified mode 1 rule plus heuristics

PSX Map Decode Plan

Current objective:

• decode the PSX LSET*.WDL map/resource layout well enough to render PSX maps through the existing public map renderer pipeline instead of building a one-off viewer

Current working split:

• post_audio_region_01 is now the first high-confidence map-placement candidate
• post_audio_region_02 still looks more like compressed or mixed resource payload than directly renderable placement rows
• post_audio_region_04 remains the late graphics bank and should be treated as the PSX art source for any eventual renderer integration

Immediate working hypothesis:

• post_audio_region_01 is a fixed-row authored layout stream
• the raw u16x12 view is already showing that each 24-byte row behaves like two adjacent 6-word records with similar field structure
• the strongest early evidence is that neighboring left/right halves carry similar value ranges and repeat the same small control words in the tail fields, which is what we would expect from paired cell/object placements rather than opaque compressed data

Practical renderer goal:

• adapt the PSX decode into the same broad source model the public renderer already uses for PC fixed maps: coordinates, shape/frame identity, and a few raw metadata bytes/words kept for inspection
• do not block on fully naming every field before producing a first renderer-fed PSX map source

Planned work order:

1. Lock down post_audio_region_01 row structure across more LSET files and confirm whether 24 bytes is the true authored row size.
2. Separate the two half-rows into individual candidate placement records and track stable min/max ranges for each word position.
3. Identify which words are likely coordinates by checking for bounded map-like ranges and local spatial continuity between neighboring rows.
4. Identify which words are likely tile/object ids by checking whether the same values recur in ways that match repeated wall/floor/object motifs.
5. Correlate the placement stream against post_audio_region_04 bundle offsets or bundle-local ids to recover the art linkage.
6. Determine whether post_audio_region_02 is a secondary map layer, a lookup table for region 01, or a different compressed resource class entirely.
7. Prototype a PSX map-source exporter that emits JSON in a renderer-friendly form even if some fields are still labeled as raw words.
8. Add a PSX-specific loader path to the existing map renderer instead of creating a separate PSX viewer.
9. Once the first map renders, iterate on field naming, layer semantics, and art binding rather than trying to solve the whole format up front.

Current evidence-backed next step:

• the extractor now needs to keep emitting a paired-record export for post_audio_region_01 so the candidate row model can be checked quickly across multiple maps without reinterpreting the CSV by hand each time

Current renderer-compatibility result:

• the old Python/site real-art probe remains useful as discarded negative evidence, but it is no longer the active viewer workflow
• the active integration path now lives inside k:\ghidra\crusader_map_viewer\map_renderer and builds live data into .cache from STATIC_PSX
• active renderer-local scripts:
  • src/build-psx-cache.js
  • src/lib/psx-cache.js
• build entrypoint:
  • npm run build-psx-cache
• current generated live-cache outputs:
  • k:\ghidra\crusader_map_viewer\map_renderer\.cache\psx\catalog.json
  • k:\ghidra\crusader_map_viewer\map_renderer\.cache\reference-data\psx-remorse\reference-data.json
  • per-map scene files under k:\ghidra\crusader_map_viewer\map_renderer\.cache\scene-cache\psx-remorse\map-*\<fingerprint>\scene.json
  • k:\ghidra\crusader_map_viewer\map_renderer\Catalogs\psx_shape_catalog_remorse.csv
• current processed-cache characteristics from the verified build:
  • source: k:\ghidra\crusader_map_viewer\map_renderer\STATIC_PSX
  • scene format version: psx-region01-provisional-art-probe-v2
  • processed maps: 23
  • shared shape definitions: 313
  • shared atlases: 313
  • largest currently useful placement-heavy maps: LSET1/L0 (1050 items), LSET4/L33 (942 items), LSET5/L48 (851 items), LSET6/L51 (463 items), LSET7/L63 (315 items)

Current art-binding hypothesis used by this probe:

• region-01 u0 is treated as a provisional direct bundle index into the extracted sprite_bundles/ set
• region-01 u4 was originally treated as a provisional frame index within that bundle, but that interpretation is now considered wrong; the constructor chain instead points to u4 as a state/script selector candidate
• this is evidence-backed enough to render real PSX art in the existing map renderer, but not strong enough yet to call the binding solved
• the strongest negative check so far is that the region-01 u5 values (0x20, 0x22, 0x30) do not match the bundle default palette indexes, so the palette-selection/control path is still missing

Current invalidation result:

• this direct u0 -> bundle index mapping is now considered invalid for real renderer output
• the produced scene repeats a small set of obviously wrong assets, including portrait/UI-like art, in places that do not make spatial sense for the map
• executable-side tracing shows that art selection is type-driven through DAT_800758cc/d0/d4/d8 resource tables loaded by psx_stream_install_type_runtime_banks, not by directly indexing the raw post_audio_region_04 bundle scan

New loader/data evidence from this pass:

• post_audio_region_00 now has dedicated extractor diagnostics:
  • out/psx_wdl/L0/post_audio_region_00_00007010_u16x6.csv
  • out/psx_wdl/L0/post_audio_region_00_00007010_u16x12.csv
  • out/psx_wdl/L0/post_audio_region_00_00007010_u32x5.csv
  • out/psx_wdl/L0/post_audio_region_00_00007010_stream_probe.json
• the new raw probe confirms that post_audio_region_00 begins with a little-endian count value 0x20
• after an initial short header/preamble, the bytes from about 0x3c onward look like tightly packed 12-byte records in the same broad shape family as the old candidate placement rows:
  • example bytes at 0x3c: 4a 00 03 16 e7 0e 00 00 01 00 20 00
  • little-endian words: 0x004A, 0x1603, 0x0EE7, 0x0000, 0x0001, 0x0020
• that record family is a better next target than the invalidated direct bundle probe because it already exposes a small type-like word (0x004A) plus coordinate-like words without forcing an arbitrary raw-bundle index

What this renderer pass means now:

• the live renderer can expose PSX as an optional game only after the processed cache exists; it is no longer tied to ad hoc site exports
• the current active output is now a provisional real-art probe rather than a placeholder-only type/lane scene
• the processed-cache path is now compatible with the existing shared reference-data pipeline and PC-style catalog grouping, which keeps PSX integration inside the normal viewer architecture instead of forking it
• the old real-art probe is still valuable as negative evidence because it proved that direct raw bundle ordering produces obviously wrong scene content

New renderer-grounded improvement from this pass:

• src/lib/psx-cache.js now scans post_audio_region_04 directly from STATIC_PSX, parses bundle headers in JavaScript, colorizes the extracted frames with the currently available default/heuristic palette path, and writes per-map bundle atlases into .cache/reference-data/psx-remorse
• the live cache no longer uses only synthetic placeholder shapes for map 0; the current LSET1/L0.WDL scene references 49 real atlases and 62 real sprite frames under the still-provisional direct u0 -> bundle index hypothesis
• extracted bundle origins are now sanitized on import so bad 0xFFFF offsets do not blow out the scene bounds; LSET1/L0.WDL is back to a sane 3896 x 8431 footprint instead of the broken 67k-pixel-wide intermediate result
• PSX shape definitions now use a 1x1x1 footprint and the scene items synthesize viewer-compatible world.x/world.y/world.z from the final screen anchors; this keeps bounding-box and preview overlays aligned with the PSX art probe instead of projecting nonsense from the raw u1/u2/u3 words

Current app compatibility notes:

• the public renderer app was updated so non-FIXED.DAT map sources do not advertise a bogus binary export path
• for the PSX probe scene, Download Map Binary is intentionally disabled while Download PNG, Download Map JSON, and Download Atlas PNG remain available
• the static app successfully loads the PSX LSET1/L0 Region 01 Art Probe catalog entry and currently fits it at about 8% zoom instead of the earlier collapsed 2% fit

Immediate implications for the next decode pass:

• the public renderer integration path is now proven enough to use as a live debug target for PSX map-format work
• the next priority is to replace the invalidated u0 -> bundle index hypothesis with a real type/resource lookup recovered from psx_stream_install_type_runtime_banks
• post_audio_region_00 is now a top-tier candidate for that work because its new diagnostics expose a count-prefixed preamble plus compact typed records that look more loader-compatible than the old region-01 art probe
• the palette override path is now partially landed in the viewer/exporter too: the cache builder applies the executable-backed authored override byte when the source record exposes the proven +0x06 / +0x0c lane, so the remaining blocker is the cases where the runtime first picks a different object/variant/state than the current export model
• once the bundle key and palette control path are recovered, the same scene-export path can graduate from real-art probe to actual PSX map rendering

PSX Provisional Real-Art Probe

The live renderer now prefers a smaller loader-backed record family when it can normalize that family into structured placement rows, while still preserving the older dense region-01 probe as a fallback/debugging strategy.

What changed in this pass:

• the temporary Python probe established the scene structure, but the active implementation is now renderer-local JavaScript rather than a standalone exporter
• src/lib/psx-cache.js now reads STATIC_PSX, parses LSET*.WDL, prefers normalized post_audio_region_00 count-prefixed records when they pass the existing structured-candidate filter, falls back to post_audio_region_01 otherwise, scans post_audio_region_04 for sprite bundles, and emits per-map atlases built from the extracted PSX frame data
• src/build-psx-cache.js writes the resulting processed data into the live cache tree:
  • k:\ghidra\crusader_map_viewer\map_renderer\.cache\psx\catalog.json
  • k:\ghidra\crusader_map_viewer\map_renderer\.cache\reference-data\psx-remorse\reference-data.json
  • per-map scenes under k:\ghidra\crusader_map_viewer\map_renderer\.cache\scene-cache\psx-remorse\...
  • k:\ghidra\crusader_map_viewer\map_renderer\Catalogs\psx_shape_catalog_remorse.csv
• the viewer now detects psx-remorse from the processed manifest instead of from a fake PC-style source-file heuristic
• scene items now keep the candidate PSX x/y words directly in world, use the executable-backed projection basis screen_x = y - x, screen_y = 2*z - (x + y)/2 with provisional z = 0, and keep 1x1x1 shape footprints so overlay boxes remain usable without pretending the old PC-style world export is solved

Current verified processed-cache result:

• scene format version: psx-runtime-record-probe-v1
• processed maps: 61
• atlas-backed shapes: 1112
• atlases: 1112
• LSET1/L0.WDL preferred source family: post_audio_region_00
• LSET1/L0.WDL rendered items from the preferred family: 59
• LSET1/L0.WDL still has 1050 dense fallback post_audio_region_01 records preserved in scene metadata for comparison
• LSET1/L0.WDL resolved real-art atlases for the preferred family: 18
• LSET1/L0.WDL resolved sprite frames for the preferred family: 26
• LSET1/L0.WDL unique u0 types in the preferred family: 18
• lane split:
  • 0x0020: 26
  • 0x0022: 21
  • 0x0030: 12
• LSET1/L0.WDL current scene bounds after the runtime-record pass: 1313 x 438
• LSET1/L0.WDL currently resolves all 59 preferred-family records to real extracted bundles with 0 placeholder fallbacks, but still clamps 15 frame requests down to the highest available extracted frame index
• one visible viewer mismatch is now separated from the remaining map-format problem: PSX sprites already draw from authored item.screen, but the old highlight/bounding overlay path was still recomputing DOS-style wireframes from provisional item.world; scene-presentation.js now falls back to authored screen rectangles for PSX items instead of drawing those incorrect projected boxes

Why this matters:

• this is the first live viewer path that prefers a loader-compatible, count-prefixed record family instead of treating the huge dense region-01 stream as the only scene source
• it keeps the strongest current working assumption narrower and more explicit:
  • normalized post_audio_region_00 rows are now the preferred placement family when they satisfy the same structural checks as the older region-01 records
  • post_audio_region_01 remains a dense fallback evidence source instead of being silently discarded
  • the art lookup is still unresolved and must be recovered from the real runtime resource tables rather than inferred from raw bundle ordering
• it also moves the viewer one step closer to the executable model by applying the recovered PSX projection basis directly in the cache builder instead of plotting raw u1/u2 values on a pseudo-screen plane

Immediate next consequence:

• the next map-format batch should treat the processed .cache runtime-record probe as the baseline renderer target and focus on proving exactly how the normalized post_audio_region_00 words line up with the constructor-fed x/y/z fields
• the old dense region-01 path should stay available as evidence, but it should no longer be the default scene family unless the loader-backed family fails to normalize on a given map
• that means the remaining visual corruption should now be treated primarily as a placement/schema problem again, not as a box-overlay problem; the next pass needs to recover the authoritative height lane and the exact constructor-fed field mapping instead of spending more time on DOS-style overlay math

PSX Map-System Correction

The current live viewer export was built on the wrong premise. The ~45..59 records currently exported per PSX map are not enough to represent a whole Crusader level, and executable tracing now shows why.

What the loader actually does:

• wdl_resource_bundle_load_by_index reads the selected LSET*.WDL into multiple section pointers, not one flat placement stream.
• the per-level file header is now structurally tighter too: after the initial 0x38 read, the loader treats the first nine dwords as contiguous section sizes, allocates a separate 0x50 runtime-header block at DAT_80067794, and later reads one more independently allocated compressed source blob before the optional FUN_8003b00c(..., 0x3e00, 0x3e00) inflate.
• The first runtime section is a top-level table at DAT_800678f4 whose record stride is 0x18 bytes.
• The second runtime section at DAT_80067720 is also 0x18-stride, but it is not just a duplicate alias of the first pointer. The loader assigns the contiguous level sections in this order:
  • DAT_800678f4 = section[0] root dispatch table
  • DAT_80067720 = section[1] secondary 0x18-stride control/placement table
  • DAT_800678f0 = section[2]
  • DAT_80067938 = section[3]
  • DAT_80067838 = section[5]
  • DAT_800675f8 = section[6]
  • DAT_8006754c = section[7]
  • DAT_80067840 = section[8]
  • DAT_800676d8 = section[9] palette block loaded just before level_palette_header_apply
• The skipped header slot is not dead space. The loader allocates it separately as DAT_8006767c, then feeds it to FUN_80040768; that lane stays distinct from the contiguous section pack and from the later DAT_8006b5d8 -> DAT_8006769c decompression path.
• The loader iterates that first section with:
  • for each 0x18-byte top-level record
  • type = record[+0x08]
  • dispatch through PTR_PTR_80063118[type]
• Those dispatch handlers do not behave like a terrain-tile walker. They construct one runtime object or a tiny object cluster at a time through FUN_800249f4, FUN_80024eec, FUN_8003c314, FUN_8003c714, and FUN_8003cc08.
• The current 0x0042 result now fits that same generic-object model more tightly than before: psx_type_descriptor_table[0x0042] at 0x80063220 points to the shared row 0x800626f8, so both constructor-placement and root-dispatch 0x0042 still enter the same generic create/update/release family rather than a unique descriptor fork.
• The selector side is tighter too: type 0x0042 now has a dedicated transition helper, psx_type42_transition_selector_tick, that can dispatch low turning selectors 3/4 before the +0x94-style runtime latch copy. So unresolved 0x0042 presentation is no longer best framed as only a missing descriptor-table or raw-selector decode problem; part of the remaining gap is that the live turn/reseat path can be ahead of the currently latched script word.

Why the current export is incoherent:

• the current region00-first exporter is effectively treating that small top-level descriptor family as if it were the whole level
• those records are only the root nodes of the level bundle's object/resource system
• they are too few because the bulk level content lives elsewhere in the loaded bundle state

New executable-backed evidence for the missing bulk content:

• psx_stream_install_type_runtime_banks and FUN_8003917c populate the typed runtime resource tables rooted at DAT_800758cc/d0/d4/d8
• DAT_80067720 is a small top-level 0x18 record list used by object/event-style helpers such as FUN_80031044 and FUN_8002b1a8; it is not a whole-map terrain stream
• during bundle load, FUN_8003b00c(DAT_8006769c, &DAT_8006b5d8, 0x3e00, 0x3e00) inflates a separate compressed blob into a dedicated level buffer
• that decompressed buffer is carried through save/load helpers (FUN_8003a0f4, FUN_80049890) independently of the tiny top-level descriptor list, which is exactly what a real map substrate would do
• the two DAT_80067720 helpers are now clearer about role too:
  • FUN_80031044 scans the 0x18-stride rows for 0xAAAA-tagged entries and low-6-bit selector matches, then caches a pointer to the matched row payload
  • FUN_8002b1a8 mutates matching rows by type/id and flag bits in place
  • both behaviors fit a small event/marker/control list and do not look like whole-map geometry submission
• the decompressed lane is more clearly persistent substrate/state than before:
  • FUN_8003a0f4 hands DAT_8006769c plus DAT_80067528 to the save helper path
  • FUN_80049890 repacks the DAT_8006b5d8 / 0x3e00 state lane into the 0x4000 memory-card save block
  • this strengthens the read that DAT_8006769c is the saved/restored map-state substrate while DAT_80067720 stays the tiny top-level control list

Current safest read:

• the ~59 exported records are top-level WDL nodes, not the entire PSX map
• the real PSX level is split across:
  • a small top-level descriptor stream
  • typed subordinate resource tables
  • at least one separate decompressed level-state blob
• the viewer looks nonsensical because it is rendering only one small layer of that system and mistaking it for the full map

Immediate consequence for the exporter:

• stop treating post_audio_region_00 as the default whole-map scene source
• keep post_audio_region_00 and post_audio_region_01 as evidence sources, but pivot the next decode pass toward the multi-section WDL model recovered from the executable
• the next map-export target must include the decompressed bundle state and/or the subordinate placement/tile resources behind the top-level 0x18 records, not just the root records themselves

Exporter status after the next renderer pass:

• the earlier five-region post-audio carve was still wrong for visible-map recovery. The corrected loader-sized section probe shows that the first post-audio section already contains both the count-prefixed top-level descriptor rows and the dense 24-byte bulk placement rows that the flat maps were missing.
• map_renderer/src/lib/psx-cache.js now recovers visible families from loader-sized post_audio_section_00 instead of treating the old guessed post_audio_region_01 carve as the default bulk source.
• the exported scene metadata now records those visible families under executable-backed names instead of the old provisional labels:
  • section0_dispatch_roots for the top-level dispatch/root records
  • section0_constructor_placements for the dense constructor-fed placement records
• a verified full rebuild now exports all 62 PSX maps with large scene volumes and non-flat z stats. LSET1/L0.WDL now emits 1189 items, LSET1/L1.WDL jumps from 53 items to 754, and the rebuilt catalog reports 62/62 maps with section0_dispatch_roots + section0_constructor_placements coverage and uniqueZCount > 1.
• the renderer-side reference payload no longer emits one atlas per resolved PSX shape. The new packed-atlas pass reduces the shared PSX reference cache from the old 4032 one-shape atlases to 1925 shared packed atlases across the same 4032 shape definitions, and a spot-check on LSET1/L0.WDL now exports the map scene itself with atlasCount = 1 instead of a long per-bundle atlas list.
• the cache export now carries more than the parsed DAT_800758d8 candidate section. In the current psx-runtime-record-probe-v6 scene path, map_renderer/src/lib/psx-cache.js serializes DAT_800758cc, DAT_800758d0, DAT_800758d4, and the offline FUN_8003b00c decode candidate for DAT_8006b5d8 -> DAT_8006769c into stateLayers, and the scene writer preserves those layers in both scene metadata and mapSource.
• the new typed-section-16 discovery path is also broader than the earlier section-start probe: when no parsed-section candidate wins, the cache builder now falls back to an absolute-file scan, which is why the late compound-bank blobs can now land in the export even when their serialized source does not start exactly at a pre-labeled section boundary.
• the file-side header block now separates more cleanly too: FUN_80039c40 allocates a 0x50 level runtime-header block at DAT_80067794, and psx_apply_level_runtime_header_block copies that block into globals such as DAT_80078ab0, DAT_80078a88, DAT_80078a8c, DAT_80078a4c, and DAT_80067354 before calling FUN_80042ec4. So the first visible/root sections are not the only authoritative level metadata; the loader also applies a dedicated 0x50 per-level runtime header after the optional 0x3e00 decode succeeds.
• this still does not mean the PSX map decode is fully solved: the viewer now has enough volume to represent whole-level candidates across the disc, but the remaining blocker is semantic decoding of the subordinate runtime banks and the separate decompressed 0x3e00 buffer, not record-count starvation.
• the type-to-art path is only partially improved. The cache builder now scans the parsed per-type art-template payloads for bundle references, and the renderer no longer treats the disproven scan-order u0 -> bundle mapping as trustworthy visible art. Unverified types now stay on placeholder art instead of surfacing known-bad portrait/talk bundles as map geometry.
• the scan-order fallback is now known to be wrong at the root, not merely incomplete. In the live .cache output, section0_dispatch_roots types 0x0042 and 0x0049 repeatedly bind to portrait/talk-animation bundles such as map 0 type 0042 -> offset 0x000B2970 and map 0 type 0049 -> offset 0x000D84F4, with the same failure pattern continuing through early maps. Those portrait bundles are useful negative evidence: they show the top-level dispatch rows are generic object/state descriptors, not a direct map-graphics stream that can be paired to bundle order.

Next decoded runtime layers from the constructor pass:

• DAT_800758d8 is the per-type active-art-header bank, not the missing whole-map substrate. wdl_resource_bundle_load_by_index feeds it from two distinct late art-facing sections per WDL pass: an earlier build/install lane and a later 8-byte header-only override lane. The later override is what leaves raw 0x58-byte active headers in DAT_800758d8, and both constructors consume that final state before deciding whether to reuse DAT_800758c8 or call FUN_80044434.
• DAT_800758d0 is a per-type companion/component bank for the simpler constructor family. FUN_800249f4 copies the resolved pointer from that bank into the local object payload at obj->8->[0,4], so this looks like a per-type component/template block rather than a top-level placement stream.
• DAT_800758cc is a per-type offset-table bank for the compound constructor family. FUN_80024eec stores it at obj+0x88, and FUN_800260e8 later indexes it with the placement byte at record+0x08 to resolve a state/offset subrecord into obj+0x8c/0x90.
• DAT_800758d4 is another per-type companion bank for the compound constructor family. FUN_80024eec stores it at obj+0x84, and FUN_8002841c queries it later using the object's +0x94 selector, so it behaves like a variant table or companion lookup rather than raw map geometry.
• The raw-file provenance for those banks is tighter now too. Inside wdl_resource_bundle_load_by_index, psx_load_type_state_banks is called four times total: twice before the selected LSET*.WDL opens and twice again after the level-local section pack and palette/header lanes are loaded. The standalone 8-byte descriptor-table read that assigns DAT_800758d8 sits between the second pair of psx_load_type_state_banks calls. Current best read:
  • one common/shared bank pair loads before the map-local WDL opens
  • one map-local override pair loads after the level-local header and palette lanes
  • DAT_800758d8 definitely comes from its own late descriptor stream
  • DAT_800758d0 plus DAT_800758cc/d4 are loaded through the adjacent psx_load_type_state_banks blobs rather than from the root section tables or the decompressed 0x3e00 state buffer
• The key functions in that chain are now renamed in the live PSX Ghidra database:
  • FUN_800249f4 -> psx_object_create_simple_record
  • FUN_80024eec -> psx_object_create_compound_record
  • FUN_80025ce8 -> psx_reset_type_runtime_banks_from
  • FUN_80025d68 -> psx_object_advance_state_script
  • FUN_800260e8 -> psx_object_select_state_script
  • FUN_8002841c -> psx_object_lookup_variant_entry
  • FUN_8003917c -> psx_load_type_state_banks
  • FUN_80044434 -> psx_create_image_resource_from_descriptor
  • FUN_80045ffc -> psx_cache_type_art_descriptor
• the constructor/runtime chain is now clearer too:
  • psx_reset_type_runtime_banks_from is a bank reset helper used during init/recycle paths; it clears DAT_800758c4/c8/cc/d0/d4/d8 from the requested type index upward and is not the state interpreter itself.
  • psx_object_create_simple_record and psx_object_create_compound_record are two placement constructors for different section-0 row layouts, but both index the same per-type runtime banks by type id before any final render-facing selection is made.
  • psx_create_image_resource_from_descriptor turns the DAT_800758d8 per-type descriptor into a renderable resource/header object; this is why DAT_800758d8 should be read as an art/template descriptor bank, not as a whole-map tile layer.
  • psx_object_select_state_script selects a state or animation subrecord from DAT_800758cc using a placement byte (record+0x08 in the compound family), storing the resolved script/state pointer at obj+0x8c/0x90 and the selector at obj+0x9e.
  • psx_object_advance_state_script then interprets the active state script with sentinel/control values such as 0xffff, 0xfffe, 0xfffd, 0xfffc, and 0xfffb, so the visible frame path is explicitly state-driven rather than just "type id -> one bundle".
  • psx_object_lookup_variant_entry is not only a constructor-time helper. Its call graph now shows three direct consumers: psx_object_create_simple_record, psx_object_create_compound_record, and psx_object_advance_state_script. That means unresolved families cannot be modeled as one spawn-time type -> variant choice; the visible companion bytes can be recomputed after state-script control flow advances.
  • The current renderer-side consequence is important: section-0 word u4 is no longer treated as a verified sprite-frame index. It is now carried forward as a state-selector candidate in exported scene metadata until the DAT_800758cc/d4 path is decoded far enough to pick the right animation frame from executable evidence.
  • Current strongest sentinel read:
    • 0xfffe dispatches psx_script_dispatch_audio_event, which is an audio/effect helper rather than a visible-frame selector.
    • 0xfffd is an in-script jump/re-anchor control that rewrites obj+0x90 relative to the current script base.
    • 0xfffc resolves a fresh subsidiary script base from the table rooted at obj+0x88, then immediately swaps both obj+0x8c and obj+0x90 to that destination before continuing from the first record there.
    • 0xfffb also resolves a subsidiary script from the same table, but first walks the current script forward until it finds an in-band 0xfffd marker and then uses that marker's selector word to choose the destination entry.
  • Current best read of those sentinels:
    • 0xffff marks a terminal or restart control that re-anchors the script at obj+0x8c and raises object-state flags.
    • 0xfffe dispatches a side-effect helper (psx_script_dispatch_audio_event) using the following word as a parameter before advancing.
    • 0xfffd is the direct indexed jump control within the current script family.
    • 0xfffc and 0xfffb are both subsidiary-script switches through the DAT_800758cc offset table rooted at obj+0x88, but 0xfffb is specifically the scan-forward variant that consumes the next in-band 0xfffd selector.
    • because psx_object_advance_state_script calls psx_object_lookup_variant_entry after those control-flow steps, the visible art choice for unresolved types may depend on post-jump script state rather than on the placement selector byte alone.
  • psx_object_lookup_variant_entry finally uses obj+0x94 to look up a companion entry in DAT_800758d4, which means even after construction the art-facing choice is still mediated by per-type variant/state tables.
• This means the next PSX layers are now at least structurally separated:
  • visible root descriptors (section0_dispatch_roots, legacy alias region00)
  • visible bulk placement candidates (section0_constructor_placements, legacy alias region01)
  • per-type art/template descriptors (DAT_800758d8)
  • per-type simple-object component blocks (DAT_800758d0)
  • per-type compound state-offset tables (DAT_800758cc)
  • per-type compound variant tables (DAT_800758d4)
  • the still-separate decompressed 0x3e00 level-state buffer (DAT_8006769c)
• The current renderer pass now records those banks explicitly as exported scene/state layers, while still only rendering the first two as visible scene items.
• The live viewer now keeps those heavyweight bank dumps out of the hot interactive scene state after load: stateLayers and decodedRuntimeLayers are preserved for exported scene JSON, but the runtime pan/zoom/editor path uses a trimmed scene object so normal navigation does not keep dragging the full PSX research blobs through the controller.
• The renderer-side state parser is also stronger than the earlier flat selector map. buildTypeStateFrameMaps now reads the exported DAT_800758cc layer and follows the currently verified control-flow sentinels (0xfffe, 0xfffd, 0xfffc, 0xfffb) instead of just taking the first word of each selector entry. That does not fully close type 0x0042 or 0x0049, but it does mean the viewer can now distinguish more fallback states from real script structure rather than from a blind selector -> first frame heuristic.
• The live cache now tightens the selector provenance too. In exported PSX scene items, the state_selector=... label is written directly from raw word u4, while the trailing lane=... label is raw word u5; this is not a post-hoc heuristic. A full scan of the built psx-remorse scene cache found 3944 visible type=0x0042 placeholders across 61 maps, and the observed selectors track u4 exactly (0 -> 0x0000, 1 -> 0x0001, 2 -> 0x0002, 3 -> 0x0003, 4 -> 0x0004).
• The executable-side handoff is narrower than that label might suggest. psx_object_select_state_script stores the authored selector byte in obj+0x9e and uses it only to choose the initial DAT_800758cc script base at obj+0x8c/0x90; psx_object_lookup_variant_entry does not index DAT_800758d4 by obj+0x9e. It indexes by obj+0x94, which psx_object_advance_state_script refreshes from the current script entry after control-flow handling.
• Immediate map-viewer consequence: the current fallback art probe should be treated only as a diagnostic overlay for candidate bundle families. A workable renderer will need to recover the per-type DAT_800758d8 descriptor mapping and the downstream DAT_800758cc/d4 state+variant selection path before it can decide whether a section-0 placement should show world geometry, an animated object, or something non-map-facing like a portrait/talk asset.
• Current status note: even with the recovered placement/projection path and the first subset of real bundle-backed types, the live PSX map output is still unreadable as a practical map because most section-0 placements still miss the executable's final state/variant-driven art binding and therefore collapse back to placeholders.
• The next loader-side correction is now verified in the live cache too: the effective late LSET*.WDL DAT_800758d8 candidate is not the earlier small-section heuristic, but a large late section whose working descriptor stream begins at an embedded +0x38 offset. On retail map 9 that correction alone lifts bundleMappedItemCount from 0 to 111, which is enough to restore real bundle-backed art for a first subset of types without reintroducing the disproven scan-order fallback. The still-unresolved root-dispatch families remain instructive rather than contradictory. 0x0042 and 0x0049 still stay on placeholders after the bank-selection fix, but the same pass now decodes their DAT_800758cc state rows more cleanly: type 0x0042 carries three selector-targeted scripts (0, 1, 2) that all terminate through 0xffff, while type 0x0049 carries a single selector-0 script. The built scene cache shows that this is still not the whole art-facing discriminator: type=0x0042 placeholders now appear with selectors 0..4, and the higher selectors 3 and 4 are real exported cases rather than parser noise. Verified maps with 0x0042 selectors above 2 include map-4, map-5, map-8, map-45, map-69, and map-85. Two runtime reselection paths now explain how those higher selectors can arise without contradicting the earlier three-script file read. psx_object_reselect_state_from_target_vector and psx_type4_reselect_motion_state both recompute the active script with psx_object_select_state_script(obj, psx_object_quantize_motion_heading16(obj) >> 2 & 0xf), where psx_object_quantize_motion_heading16 quantizes the object's current motion vector at obj+0x60/+0x64 through psx_quantize_vector_heading16 into a 16-way heading bucket. So cache-visible 0x0042 selectors 3 and 4 can come from runtime heading/state reselection, not only from the original placement byte. That cache sweep also separates selector from lane more clearly than before. 0x0042 appears heavily on lanes 0x0020 and 0x0022, and there are also map-local lane=0x0030 cases (for example large clusters on map-108) that still export state_selector=0. So the unresolved bridge is narrower now: the visible-art rule cannot be modeled as just u5 or just the initial DAT_800758cc selector parse. The remaining unknown is the downstream interaction between u4/obj+0x9e, the active state-script pointer at obj+0x8c/0x90, and the DAT_800758d4 companion lookup that reruns after state-script advancement. A first renderer-safe bridge landed even with that exporter gap still open: the verified 0x0050 state-script mapping (selector 0..3 -> frame 0..3) is now applied as a narrow fallback in the cache builder, and the rebuilt live map-9 scene now shows type=80 state_selector=1 chosen_frame=1 instead of the old forced chosen_frame=0. Unresolved fallback placeholders are also now clamped to opacity=0.45 in live scene output so the still-missing families stop visually overpowering the recovered real art. This remains intentionally scoped: the fallback frame map only covers the one family with direct executable-backed frame evidence, and the opacity clamp is diagnostic relief rather than a decoding claim. The current draw split is clearer too. FUN_80041378 is a three-stage render pass:
  • stage 2: a second special-visible list drawn by FUN_80041144
  • stage 3: HUD/overlay/icon primitives from FUN_800416cc
• That split matters for the map-viewer target: stages 1 and 2 remain relevant to missing world-facing content, while stage 3 is mostly front-end or overlay material and should not be mistaken for the missing half of the map.
• Stage 2 is now materially better understood and is no longer just a read-side observation:
  • FUN_80040f78 is the queue-builder for that pass. It projects an object with the same fixed-point world-to-screen math as FUN_80040d44, writes the final screen rectangle to +0x20..+0x2e, then appends the object to DAT_80078b70 and increments DAT_80067472.
  • FUN_80041144 consumes that queue directly, iterating DAT_80078b70[0 .. DAT_80067472) and submitting sprite primitives through the same texture draw helpers as the main object pass.
  • FUN_80044fec resets the queue each frame by clearing DAT_80067472 after the top-level draw pass.
  • So the stage-2 list is not UI/HUD noise and not a duplicate of the main clipped visible list. It is a distinct world-facing queued-object lane, which is now a concrete candidate explanation for part of the still-missing map content in the viewer.
• The immediate caller-side consequence matters too:
  • FUN_80040d44 remains the main clipped visible-list toggle, calling the stage-1 add/remove helpers when an object enters or leaves the screen.
  • The recovered post-state-advance updater family now splits into five visible call sites: 0x80012b44, 0x80013524, 0x80013564, 0x80013650, and 0x80013778 all call psx_object_advance_state_script.
  • Three of those sites then feed the main stage-1 projector path through FUN_80040d44 (0x80012b60, 0x8001357c, 0x800136d4), while two feed the stage-2 queue-builder path through FUN_80040f78 (0x8001352c, 0x80013780).
  • That exact 3 versus 2 split matters because it tightens the earlier claim: stage-2 membership is tied to a narrower runtime object/state branch after state advance, not to the decompressed substrate buffer alone and not to all state-advanced objects indiscriminately.
• One state-script sentinel is now functionally closed too: 0xfffe dispatches psx_script_dispatch_audio_event, which is an audio/effect helper rather than a visible-frame selector. That shrinks the unknown sentinel set for the remaining DAT_800758cc script work.
• The main visible-list helpers are now also separated cleanly enough to stop treating them as a blocker:
  • FUN_8002d240 adds an object to the stage-1 DAT_8006ad5c visible-list array.
  • FUN_8002d35c removes an object from that same array.
  • FUN_8002d59c returns the sorted slice that FUN_80041378 iterates for the stage-1 world-object pass.
  • FUN_8002d6f8 and FUN_8002d778 act as refresh/rebucket/sort helpers over that main list.
• This is an important scope reduction for renderer work: the remaining missing world content is now less likely to be caused by misunderstanding the main stage-1 visibility array itself, and more likely to live in the separate stage-2 queued-object pass plus the still-unresolved DAT_800758cc/d4 state-to-art path.

Recovered next visible layer from the bulk placement family:

• The structured section0_constructor_placements rows are no longer height-agnostic. The FUN_80024eec constructor reads its authored elevation from byte +0x06 of the input record, which corresponds to the low byte of the current exported u3 word for the accepted bulk-placement records.
• That byte is not just random payload on the accepted rows. Under the corrected section-0 scan, the same ladder generalizes across the whole rebuilt catalog instead of only the earlier L0 subset. LSET1/L0.WDL still collapses to 11 distinct height values (0, 2, 4, 10, 12, 14, 18, 20, 22, 24, 26), and LSET1/L1.WDL now exposes 9 distinct levels with a z range of 0..32.
• The PSX cache builder now uses that recovered z byte for section0_constructor_placements projection instead of forcing the whole bulk layer onto z = 0, while the top-level section0_dispatch_roots descriptor stream stays at z = 0 until its own constructor-backed height source is proven.
• This is now the first PSX export pass in the viewer pipeline that produces visibly multi-layer whole-map candidates across the rebuilt retail catalog from executable-backed height data rather than from a single flattened candidate layer.

Additional constructor-backed coordinate grounding from the current pass:

• the current constructor split is now precise enough to state both authored row layouts at once:
  • psx_object_create_compound_record reads type from record+0x00, x/y from u16 words at +0x02/+0x04, authored elevation from byte +0x06, flags from +0x0a, and the initial state selector from byte +0x08.
  • psx_object_create_simple_record reads type from record+0x04, x/y from u16 words at +0x08/+0x0a, authored elevation from byte +0x0c, and the initial state selector from byte +0x0e.
• both constructors write the original authored source-record pointer to object field +0xa0, which keeps the later palette-override and state-selection paths tied to raw placement bytes rather than to a hidden runtime copy.
• both constructors also resolve the same per-type banks before any render pass runs:
  • DAT_800758d8 -> art/template descriptor
  • DAT_800758cc -> state-script offset table
  • DAT_800758d4 -> companion variant lookup
  • DAT_800758d0 -> simple-record-only component payload
• this strengthens the viewer/exporter rule again: the two visible section-0 row families are constructor inputs, not already-final render primitives. Any direct type -> bundle/frame export path still has to respect the later state-script and variant lookups.

Recovered per-level runtime-header lane:

• FUN_80039c40 is now confirmed as a pure 0x50 allocator for DAT_80067794, and psx_apply_level_runtime_header_block is the matching applier for that block.
• psx_apply_level_runtime_header_block copies fixed fields from DAT_80067794 into the active level globals, including camera/runtime anchor values and several per-level mode bytes, then calls FUN_80042ec4 to refresh dependent runtime state.
• The downstream call graph narrows that lane further: psx_apply_level_runtime_header_block is the only loader-side caller that feeds those values from WDL data, while FUN_80042ec4 is also reused by psx_input_device_init, memory_card_menu_tick, and one additional front-end/system path. Current safest read: DAT_80067794 is shared per-level runtime mode or presentation state rather than hidden bulk map geometry.
• Practical exporter consequence: keep the DAT_80067794 fields as a first-class raw metadata lane, but do not treat them as a missing placement stream. They are more likely to affect camera/runtime modes, screen-space behavior, or level-global toggles than to supply extra map cells directly.
• The higher-level level lifecycle is now readable too. psx_level_session_loop is the outer level-session loop: it loads the selected WDL through wdl_resource_bundle_load_by_index, applies shared overlay/resource setup through FUN_800388a8, resets a small per-level step-flag block with FUN_8003a498, and then runs psx_world_frame_tick as the per-frame world loop until the current level session exits.
• wdl_resource_bundle_load_by_index is now mapped tightly enough for viewer work. Its effective order is: load SPEC_A.WDL and shared type art/state banks; open the selected LSET*.WDL; read the 0x38 section-size header; lay out the contiguous per-level section pack at DAT_800678f4, DAT_80067720, DAT_800678f0, DAT_80067938, DAT_80067838, DAT_800675f8, DAT_8006754c, DAT_80067840, and DAT_800676d8; load the detached DAT_8006767c blob; optionally inflate DAT_8006b5d8 into DAT_8006769c; apply the runtime header at DAT_80067794; then dispatch the 0x18-stride root records at DAT_800678f4 through the per-type function table in PTR_PTR_80063118.
• The per-frame world loop in psx_world_frame_tick is now split clearly enough for renderer planning. In the normal in-level branch it ticks existing live objects through psx_run_live_object_type_updates, instantiates or refreshes nearby authored records through psx_dispatch_section0_dispatch_roots and psx_dispatch_section0_constructor_placements, runs per-object behavior callbacks through psx_run_live_object_behavior_callbacks, integrates world/player motion and active-object state through psx_update_motion_and_nearby_interactions, updates queued transient resources through the still-structural FUN_8002aed0 queue-drain helper, and only then submits the draw pass through FUN_80041378.
• The two authored record-family passes now line up directly with the viewer exporter model:
  • psx_dispatch_section0_dispatch_roots walks the DAT_80067720 0x18-stride family plus the fixed-size entries at DAT_80067658, culls them to roughly a +/-0x140 neighborhood around the current focus object, and dispatches their per-type handlers. This is the closest executable match for the current section0_dispatch_roots viewer family.
  • psx_dispatch_section0_constructor_placements walks the DAT_800678f0 0x0c-stride family with the same neighborhood cull and per-type dispatch. This is the closest executable match for the current section0_constructor_placements viewer family.
• The already-instantiated-object passes are separated too:
  • psx_run_live_object_type_updates iterates the linked live object list at DAT_800675ac and calls the per-type update callback (type_vtable+8) for active in-world objects.
  • psx_run_live_object_behavior_callbacks then runs each live object's callback stored at obj+0x98 / obj[0x26], which is the later object-specific behavior/update pass.
• One adjacent control family in the same world/update lane is now tighter too:
  • psx_object_run_control_opcode (0x80023c54) executes one opcode from the object-local control stream at owner +0x20.
  • psx_control_move_player_to_point (0x80023efc) is control opcode case 1 for the player path: it lazily seeds a target point from the opcode payload, steers toward it through the heading solver, and completes once the player reaches that point.
  • psx_control_move_object_to_point (0x80024070) is the non-player version of the same case 1 path, using the object movement-state helper to keep facing and locomotion aligned while the object advances toward the opcode target.
  • psx_queue_deferred_control_command (0x800241f4) appends deferred control-command entries into the small queue rooted at DAT_8008f608 / DAT_8008ef90 with count DAT_80067730.
  • psx_control_wait_ticks (0x80024290) is control opcode case 3: a one-shot timed wait gate that snapshots DAT_80078a28 on first entry and completes only after the opcode's tick count has elapsed.
  • psx_control_configure_fixed_camera_anchor (0x800242f0) is the shared control opcode case 4/5 helper: one branch projects an opcode-provided point into the shared camera basis and seeds a fixed anchor through DAT_80078a2c, while the other branch clears that anchor and restores normal camera-follow behavior.
  • psx_spawn_object_compound_effect_variant3 (0x800184e8) is the direct effect spawner used by control opcode case 8: it builds a type-2 compound record at the current object position, forces variant 3, and triggers audio event 0x2c.
  • psx_flush_deferred_control_queue (0x8002aed0) drains that queue once per world tick, applying each entry through psx_apply_deferred_control_command.
  • psx_apply_deferred_control_command fans one deferred entry out into both psx_apply_deferred_control_to_dispatch_roots and psx_apply_deferred_control_to_live_objects, which is the clearest current evidence that this queue is a small deferred world/control mutation lane rather than a render queue.
  • psx_control_set_facing_direction (0x80024438) is control opcode case 9: it forces an explicit facing token and immediately refreshes the player or object movement-state around that heading.
  • The remaining neighboring helper at 0x800243b8 is still intentionally unnamed for now; it looks like a short delay gate around psx_spawn_object_compound_effect_variant3, but it still needs stronger subsystem evidence before it should get a behavioral name.
• psx_update_motion_and_nearby_interactions is the broad world-motion and nearby-interaction integrator that sits between behavior updates and draw submission. For viewer purposes, this is the runtime bridge between authored map placement and the motion/state values that later feed heading-based state reselection and projection.
• The cull-to-draw bridge is now closed too. psx_authored_record_in_view_bounds is the authored-record screen-space gate used by the two section-0 dispatch passes, while psx_world_point_in_view_bounds is the corresponding gate for already-instantiated live objects. Both use the same isometric camera basis around DAT_800678d4, which means the viewer can treat the record-family export as feeding the same projection space as the later live object list instead of as a separate map coordinate model.
• The main world-object draw helper is now grounded more tightly as well. FUN_80041458 builds the final sprite primitive from the authored screen rectangle at obj+0x20..+0x2e, then ORs in a palette override read from the original source-record pointer at obj+0xa0: for types 0x003e..0x00ab it uses the high byte of source word +0x06, and for types >= 0x00ac it uses the high byte of source word +0x0c. That means the remaining viewer mismatch is not where the override comes from, but when the runtime chooses a different object/variant/state before draw.
• The stage split is tighter too. psx_project_object_special_visible_queue (0x80040f78) feeds a distinct world-facing stage-2 queue, and FUN_80041144 consumes that queue with the same projected screen rectangle fields and the same resource-specific draw helpers used by the stage-1 visible list. So the unreadable output is not explained by one missing HUD lane; the dominant gap is still the unresolved final art-binding path, with the stage-2 queue as a secondary world-object lane the viewer must eventually model.
• The next high-value executable target is now partly closed. psx_type4_reselect_motion_state (0x8002906c) is now named, and the surrounding interaction cluster is finally concrete enough to describe instead of leaving it as a black box:
  • psx_type4_update_delayed_interaction (0x80029c20) is the type-4-only delayed wrapper. It probes ahead, stores the hit object at the controller-local +0x38 slot, seeds a countdown from distance and speed, and dispatches to psx_type4_reselect_motion_state when that delay matures.
  • psx_type4_reselect_motion_state (0x8002906c) is the post-construction reselection path for those delayed type-4 interactions. Depending on target flags it either hands off to the older psx_object_reselect_state_from_target_vector (0x80028c94) helper or flips the object's motion components against the target bounds, then reseats the live state script through psx_object_select_state_script(obj, psx_object_quantize_motion_heading16(obj) >> 2 & 0xf) before registering bilateral contact.
  • psx_object_update_nearby_interactions (0x80029478) is the broad nearby-object sweep that feeds most of the non-type-4 collision and interaction bookkeeping. It walks the active object set, culls locally, performs overlap checks, updates directional contact/block flags, and registers contact pairs.
  • psx_object_test_overlap_3d (0x80028298) is the box-overlap predicate used by that sweep, and psx_object_update_contact_block_flags (0x800289f0) is the direction-sensitive flag updater that writes the contact/block bits on the active object.
  • psx_object_register_contact_pair (0x8002845c) is the bilateral contact queue helper used by both the broad sweep and the type-4 delayed path, which means the interaction lane is no longer speculative glue around the art/state system. It is a verified runtime bridge that can directly reseat the live script before the later DAT_800758d4 companion lookup.
• The motion-heading side of that bridge is now closed one step further too:
  • psx_object_reselect_state_from_target_vector (0x80028c94) is the older target-relative reselection helper used by psx_type4_reselect_motion_state. It builds a motion vector either from a target-relative offset or from a normalized target-to-player vector, writes that vector to obj+0x60/+0x64/+0x68, and reseats the live state script from the resulting heading bucket.
  • psx_object_quantize_motion_heading16 (0x8003bc1c) is the thin wrapper that feeds the current object motion vector into psx_quantize_vector_heading16.
  • psx_quantize_vector_heading16 (0x8003b980) is the actual 16-way heading quantizer. It classifies the current x/y vector against the threshold table at DAT_80064990, which is why the runtime reselection callers consistently reduce its result with >> 2 & 0xf before indexing the DAT_800758cc script table.
• The local post-advance render wrappers are also no longer anonymous labels:
  • psx_spawn_compound_record_advance_state_once (0x80013618) creates one compound-record object, forces its script countdown to 1, immediately runs psx_object_advance_state_script, and then marks the object with obj+0x1e |= 0x20. This is the cleanest currently recovered example of a constructor wrapper that intentionally advances into a non-initial live state before the object joins the normal update/render flow.
  • psx_spawn_simple_record_set_active_flag (0x8001372c) is the simpler sibling for the simple-record constructor: create the object, then immediately set the low active flag in obj+0x1e.
  • psx_object_refresh_main_visible_and_cleanup (0x80013688) is the compact stage-1 handoff wrapper. When the object still has a drawable resource and the 0x20 flag is set, it feeds the object through psx_project_object_main_visible; if the object is not in the obj+0x1c & 1 hold state but does carry obj+0x1e & 0x10, it then queues the object into the nearby-interaction active set through psx_nearby_interaction_list_add.
  • psx_object_advance_state_and_queue_special_visible (0x80013758) is the compact stage-2 handoff wrapper. If the object still has a drawable resource, it advances the active script and immediately queues the object through psx_project_object_special_visible_queue, then applies a small sentinel cleanup block that clears world coordinates and selected flags for specific type/selector cases.
• The owner above those wrappers is now named too: psx_object_integrate_motion_and_route_visible (0x800131a8). It is the per-object bridge between movement state and rendering: it integrates position/velocity fields, refreshes the local visible/on-screen flags, handles the controlled-object side path, then advances the live state script and routes the object either into psx_project_object_special_visible_queue for the type-4/special-visible branch or into psx_project_object_main_visible for the normal drawable branch before the usual nearby-interaction enqueue step. This is the clearest recovered owner-level proof that state advancement and render-lane routing belong to the same runtime step.
• Those wrappers matter because they close one more gap between psx_object_advance_state_script and the render split. The stage-1/stage-2 divergence is not only visible in larger caller bodies such as the 0x80013524 / 0x80013564 branches; it also exists as small dedicated wrappers that either project through the main visible list after state work or advance-and-queue directly into the special-visible pass. That makes the renderer problem look even less like a missing flat table and more like a true runtime pipeline with multiple post-script routing paths.
• The render-side leaf chain is now close to end-to-end:
  • psx_project_object_main_visible and psx_project_object_special_visible_queue both use the current script word at obj+0x94 as the frame selector they pass into the frame-metric helpers.
  • psx_resource_frame_origin_x (0x8004513c), psx_resource_frame_origin_y (0x800451d0), psx_resource_frame_width (0x80045014), and psx_resource_frame_height (0x800450a8) read per-frame rectangle metadata from the current drawable resource at obj+0x10 using that same live frame index.
  • psx_draw_world_visible_passes (0x80041378) is the top-level world-facing draw orchestrator: stage 1 draws the sorted main visible list through psx_draw_main_visible_object (0x80041458), stage 2 draws the queued special-visible list through psx_draw_special_visible_queue (0x80041144), and stage 3 is the non-world HUD/overlay pass.
  • psx_draw_main_visible_object and psx_draw_special_visible_queue then dispatch to one of two final frame submitters depending on resource kind: psx_sprite_resource_submit_frame (0x80044bdc) handles the streamed/VRAM-backed sprite resource path, while psx_image_table_submit_frame (0x80044e9c) handles the table-backed image resource path. Both receive the live frame index from obj+0x94, not the original authored selector.
  • The stage-1 visible list manager is now named end to end too: psx_main_visible_list_add, psx_main_visible_list_remove, psx_main_visible_list_rebucket_object, psx_main_visible_list_refresh_from_live_chain, psx_main_visible_list_sort_range, and psx_main_visible_list_get_sorted_slice cover membership, rebucketing, refresh, dependency/tie-break sorting, and final slice retrieval for the main world-object draw pass.
• The constructor/resource side closes the remaining resource-pointer handoff. psx_create_image_resource_from_descriptor is now confirmed as the builder used by both constructors: type-4 descriptors bind a single indexed image resource through image_resource_bind_vram_slot, while type-5 descriptors allocate and upload a multi-frame bundle through image_bundle_load_to_vram. Both psx_object_create_simple_record and psx_object_create_compound_record resolve the per-type art bank before any draw pass runs, store the resulting drawable resource on the object at obj+0x10, store the per-type variant bank at obj+0x84, store the per-type state-script bank at obj+0x88, and only then call psx_object_select_state_script. So the current strongest end-to-end model is now:
  • authored record type -> per-type art/state/variant banks
  • constructor seeds obj+0x10 drawable resource plus obj+0x88/0x84
  • psx_object_select_state_script seeds the initial script from DAT_800758cc
  • runtime reselection / psx_object_advance_state_script updates the live script word at obj+0x94
  • psx_object_lookup_variant_entry maps that live script word through DAT_800758d4
  • the projectors and final draw submitters use the same live obj+0x94 frame index against the drawable resource at obj+0x10
• The newly traced consumer side changes the export diagnosis in an important way. psx_object_advance_state_script does not treat the DAT_800758d4 lookup result as a resource id or replacement frame index; it sign-extends the returned three bytes into obj+0x30/+0x34/+0x38, and the verified downstream consumers are all in the overlap/contact lane. psx_object_test_overlap_3d uses those fields as box extents against obj+0x54/+0x58/+0x5c, psx_object_update_contact_block_flags uses the same extents while updating directional block bits, and the reselection helpers read target-object +0x30/+0x34/+0x38 as target bounds. By contrast, the visible projectors and both stage-1/stage-2 draw helpers still only use obj+0x10 plus live obj+0x94 for visible presentation.
• The renderer/exporter path now preserves that distinction too. The PSX cache builder decodes DAT_800758d4 as a count + packed signed xyz-extents table, carries the decoded per-state tuples in the exported state layer, and writes the resolved companionExtents tuple onto each scene item and mapSource row for the chosen live state when a matching entry exists. So the viewer now keeps the newly verified bounds evidence explicitly instead of flattening it back into the old placeholder-art bucket.
• That is not yet the full remaining answer for unresolved placeholder-heavy families, but the missing piece is narrower again now. The DAT_800758d4 bytes are no longer the best candidate for the final art table; they are acting like per-state companion extents used by collision/contact logic. So the remaining gap sits inside the family-specific live resource/frame presentation path after script reselection, not in projection, placement decoding, draw-lane discovery, or generic DAT_800758d4 consumption.
• The latest dispatch-table trace also removes one remaining false lead for 0x0042 and 0x0049. Their type-table slots do not point to unique family handlers; both currently resolve to the same generic descriptor used across 0x003e..0x0050, whose callback slots are psx_spawn_compound_record_advance_state_once, psx_object_refresh_main_visible_and_cleanup, and psx_object_release_to_free_list. So the unresolved art rule for those types is not hiding in a dedicated per-type descriptor fork; it still appears to live later in generic object state/resource handling.
• The state/art split is therefore even sharper than the earlier constructor notes implied. psx_object_select_state_script only chooses the current script base from DAT_800758cc and stores the authored selector at obj+0x9e, but both psx_object_reselect_state_from_target_vector and psx_type4_reselect_motion_state can later overwrite that live script choice from runtime motion state. psx_object_advance_state_script then refreshes obj+0x94 from the current script word and reruns psx_object_lookup_variant_entry, and that lookup indexes DAT_800758d4 by obj+0x94, not by the original obj+0x9e selector byte.
• That changes the exporter diagnosis in a useful way. The unreadable map output is still real, but the remaining gap is narrower than before: it is not just that DAT_800758cc exists, but that runtime interaction and heading-state paths can overwrite the live script after spawn. Any renderer-safe state-to-art rule for unresolved families such as 0x0042 has to account for those post-spawn reselection paths instead of assuming the authored selector byte is final.
• that means the PSX level load now has four distinct evidence-backed layers instead of the earlier two-way split:
  • root dispatch records at DAT_800678f4
  • secondary 0x18-stride records at DAT_80067720
  • per-type runtime banks at DAT_800758d8/d0/cc/d4
  • a dedicated 0x50 level runtime-header block at DAT_80067794
  • plus the separately loaded compressed source at DAT_8006767c and its optional DAT_8006b5d8 -> DAT_8006769c decoded 0x3e00 state buffer

PSX Coordinate Model From Executable

The current coordinate problem is no longer a renderer-only guess. The executable now closes the last projection step well enough to treat PSX placement as its own map-space model instead of as a PC-style direct world export.

Key function evidence:

• FUN_800249f4 and FUN_80024eec are constructor paths that load authored coordinates into object fields +0x3c, +0x40, and +0x44 as 16.16 fixed-point values.
• For the first family, the source record shape is now strong enough to describe directly:
  • u16 word at record +0x08 -> object +0x3c as value << 16
  • u16 word at record +0x0a -> object +0x40 as value << 16
  • u8 byte at record +0x0c -> object +0x44 as value << 16
• FUN_80040d44 and FUN_80040f78 are the projection helpers that turn those fixed-point object coordinates into the per-object screen rectangle stored at +0x20..+0x2e.
• FUN_80041458 and FUN_80041144 then consume that already-built rectangle directly during draw submission; they do not derive screen position on the fly.

Recovered projection model:

• +0x3e and +0x42 are not separate authored fields. They are the high 16-bit halves of the fixed-point x and y values stored at +0x3c and +0x40.
• The runtime builds an intermediate screen anchor in fixed-point at +0x78/+0x7c from those world coordinates:
  • screen_anchor_x = y - x
  • screen_anchor_y = 2 * z - (x + y) / 2
• FUN_80040d44 computes that anchor with the exact writes:
  • obj+0x78 = ((y_hi - x_hi) << 16)
  • obj+0x7c = (obj_z * 2) - ((x_hi + y_hi) << 15)
• The projection helper then subtracts the current camera anchor from DAT_800678d4 + 0x3c/+0x40, subtracts sprite-frame origin/size metadata from FUN_8004513c, FUN_800451d0, FUN_80045014, and FUN_800450a8, and writes the final visible rectangle into +0x20..+0x2e.

What this means for the viewer:

• the PSX map does not want the PC viewer's current synthetic world.x/world.y/world.z guess based directly on raw candidate words
• the most defensible renderer-side export target is now the runtime's own projected anchor or the equivalent fixed-point world tuple that reproduces the same screen_anchor_x/screen_anchor_y formulas
• any importer that treats the raw authored coordinates as if they were already PC-style isometric world coordinates will bunch objects together or smear them across the map because PSX uses a different projection basis
• the current cache builder no longer synthesizes PC-style world coordinates from final screen anchors; it now keeps the candidate PSX x/y words directly in exported scene items and applies the runtime projection basis separately during anchor generation

Open parts that still matter:

• this closes the final world-to-screen math, but it does not yet prove which raw post_audio_region_01 or post_audio_region_00 record family feeds each constructor path
• it also does not close the type/resource lookup that selects the correct bundle/frame through DAT_800758cc/d0/d4/d8
• palette override is no longer wholly unresolved in the viewer path, but the >= 0x00ac source-base semantics and the runtime's later variant reselection still leave some color choices provisional

Immediate consequence for the next pass:

• the next executable-guided decode step should map candidate authored record words directly onto constructor inputs, not onto PC-style scene coordinates
• once the correct record family is tied to FUN_800249f4 or FUN_80024eec, the renderer can export either:
  • the raw fixed-point PSX world tuple, plus a viewer-side reproduction of the runtime projection, or
  • the runtime-equivalent projected anchor/rectangle directly for debug rendering
• the cache builder now uses the recovered projection basis and prefers the loader-backed record family, but the exact record-to-constructor link and the authoritative height lane still need proof before this can be called a solved map export

PSX Script / Usecode Equivalent

Current status:

• there is no evidence yet that the PSX build carries the exact same external USECODE/EUSECODE.FLX style asset pipeline used by the DOS version
• the current PSX executable-backed work has mostly exposed compiled resource loaders, animation/audio handlers, and image upload/decode paths rather than a separate obvious bytecode container

Current working question:

• the likely PSX equivalent, if one exists, may be either:
  • compiled gameplay logic directly inside SLUS_002.68, or
  • a separate embedded event/script resource format inside the LSET/other disc blobs that is not yet isolated

Immediate plan:

1. scan the PSX executable and current renamed function set for script/event-dispatch terminology or obvious VM-style control loops
2. compare any candidate dispatch path against the DOS usecode model only at the behavioral level, not by assuming the asset format is shared
3. keep this as a secondary track while map decoding takes priority

Practical Extraction Paths

Standard media first

The easiest wins are the standard PS1 media formats:

• MOVIES/*.STR: treat as PS1 video streams
• AUDIO/*.XA: treat as XA audio
• ZZZ.ZZZ: try as a movie stream too, especially against FMV3.STR

This does not need custom reverse engineering first.

Custom .WDL extraction second

The .WDL files are the main custom-content frontier.

Current executable-backed extraction order:

1. run tools/psx_extract_wdl.py over representative LSET*.WDL files
2. treat post_audio_region_01 and post_audio_region_02 as the current best map-data extraction targets
3. treat post_audio_region_04 as the current best sprite/graphics extraction target
4. carve any strict TIM blocks first, because those now have executable support via the type 4 / type 5 image handlers
5. separately carve SPEC_A.WDL / MENUS/*.WDL as raw image-oriented blobs

The level files and menu/special files should not be assumed to share one parser until that is proven.

Recommended Ghidra Import Candidates

Primary

1. E:\emu\psx\Crusader - No Remorse\SLUS_002.68

Reason:

• confirmed by SYSTEM.CNF
• valid PS-X EXE
• main native code image

Secondary, only if useful for subsystem RE

2. E:\emu\psx\Crusader - No Remorse\FMV.BIN

Reason:

• clearly tied to FMV playback
• contains path and MDEC-related strings
• could be worth importing as a raw binary/data blob if the movie subsystem becomes a target

Not primary code imports

These currently look like content, not executables:

• E:\emu\psx\Crusader - No Remorse\ZZZ.ZZZ
• E:\emu\psx\Crusader - No Remorse\SPEC_A.WDL
• E:\emu\psx\Crusader - No Remorse\LSET1\L0.WDL
• E:\emu\psx\Crusader - No Remorse\MENUS\M13.WDL

They may still be worth loading as raw binaries later for format RE, but they are not first-choice code imports.

Current Working Model

• SLUS_002.68 = main PS1 executable
• FMV.BIN = FMV helper/support blob
• MOVIES/*.STR = standard movie streams
• AUDIO/*.XA = standard XA audio
• ZZZ.ZZZ = likely renamed or duplicated movie stream data
• LSET*.WDL = structured level/resource containers
• MENUS/*.WDL and SPEC_A.WDL = raw-looking screen/menu resource blobs, possibly with some embedded standard PS1 image content

Executable Catalog Findings

This batch focused on the imported SLUS_002.68 executable as a catalog source rather than on the raw WDL bundles alone.

Map inventory and mission-facing structure

Current executable-backed map findings:

• wdl_resource_bundle_load_by_index now has a direct string-backed proof for the shipped folder layout. The loader copies one of seven hardcoded path prefixes \LSET1\L through \LSET7\L based on map-index thresholds 10, 20, 30, 40, 50, and 60, then formats the final .WDL path.
• The extracted disc tree currently ships 62 level bundles total:
  • LSET1: L0 through L9
  • LSET2: L10 through L19
  • LSET3: L20 through L29
  • LSET4: L30 through L39
  • LSET5: L40 through L49
  • LSET6: L50 through L58
  • LSET7: L62 through L64
• So the shipped PSX map-bundle range is L0..L64 with a real on-disc gap at L59..L61.
• The executable also preserves only 15 plain-text Mission Briefing ^Mission N strings, for Mission 1 through Mission 15.

Current safest read:

• the PSX disc contains 62 shipped map/resource bundles used by the LSET loader
• the player-facing campaign/briefing flow exposed by the executable is 15 numbered missions
• any extra bundle coverage beyond that mission-facing set is currently better treated as lower-level map/resource inventory, not automatically as 15 == all shipped WDLs

Per-bundle shipped inventory from the extracted disc tree:

Bundle range	Folder	Count	Size range (bytes)
L0..L9	LSET1	10	987,932 .. 1,312,624
L10..L19	LSET2	10	1,107,380 .. 1,314,992
L20..L29	LSET3	10	904,384 .. 1,221,556
L30..L39	LSET4	10	1,104,316 .. 1,321,656
L40..L49	LSET5	10	1,120,084 .. 1,303,732
L50..L58	LSET6	9	1,012,956 .. 1,341,684
L62..L64	LSET7	3	965,072 .. 1,150,428

Passcodes and password-screen cheat status

Follow-up: the hidden passcode compare lane is now materially tighter in docs/psx/jl-9-investigation.md. The recovered decoder at 0x8003ec8c is table-driven rather than plain ASCII, and its special hidden rows now give the strongest current code-backed support for public PSX folklore that L0SR is the cheat-mode password candidate while XXXX routes into a separate hidden branch.

Current executable-backed passcode findings:

• The mission-complete passcode display path at 80022cd4 and 80022f1c synthesizes a 4-character code from generated indexes.
• Those indexes are mapped through the hardcoded alphabet at 80063ef0:

BCDFGHJKLMNPQRSTVWXZ0123456789

• The resulting 4 characters are written into the temporary display buffer at 80063f6e..80063f71, null-terminated at 80063f72, and shown through the completion message at 80063f10:

^Congratulations!^ You have completed your mission.^^The passcode for the next mission is:^   

• So PSX mission passcodes are definitely real executable-generated 4-character values, not just external manual text.

Current best password-screen cheat list from public PSX references:

• XXXX = hidden pictures
• L0SR or L0SER = cheat-mode password reported by public sources; the conflicting transcription is almost certainly a 0 vs O issue and is not yet closed directly from the executable

Important executable-side caveat:

• none of the known public PSX mission passwords checked in this pass (FWQP, HWQP, LRTN) appear as plain ASCII strings inside SLUS_002.68
• the same is true for the public cheat-password candidates XXXX, L0SR, and L0SER
• current safest read is therefore password entry and/or validation is numeric or transformed, not a plain embedded string table of passcodes
• this pass closed the visible generation/display side, but it did not yet directly close the hidden cheat-password compare path

Weapons and items

The executable does preserve user-facing text tables for equipment.

Recovered ammo names:

• INVALID AMMO
• JL-2 AMMO
• AR-7 AMMO
• GL-303 AMMO
• RP-22 AMMO
• SG-A1 AMMO

Recovered item names:

• NULL ITEM
• INHIBITOR
• CREDITS
• SCI PLANS
• BLAST PAC
• DET PAC
• DATA LINK
• LAND MINE
• SPIDER BOMB
• MEDICAL KIT
• ENERGY CUBE
• FUSION PAC
• CHEMICAL BATTERY
• FISSION BATTERY
• FUSION BATTERY
• GRAVITON GENERATOR
• IONIC GENERATOR
• PLASMA GENERATOR

Recovered weapon names:

• RP-16
• RP-22
• RP-32
• SG-A1
• AC-88
• PA-31
• EM-4
• PL-1
• UV-9
• GL-303
• AR-7
• JL-2
• JL-9

Current safest read:

• these are real executable-backed display-name tables, not guessed carryovers from the DOS build
• the PSX build still uses a recognizable Crusader equipment taxonomy even where some item labels differ from the more familiar DOS-side vocabulary

JL-2 / JL-9 follow-up:

• neither JL-2 nor JL-9 appears in the known DOS Weapon_GetNameForShapeNo tables already extracted in this repo for retail Remorse or Regret; those tables stop at the older DOS weapon families such as BA-40, BA-41, PA-21, EM-4, SG-A1, RP-22, RP-32, AR-7, GL-303, PA-31, PL-1, AC-88, UV-9, and the Regret-only additions BK-16, LNR-81, XP-5
• that makes JL-2 and JL-9 strong PSX-only naming additions rather than inherited PC names
• JL-2 is also the only one of the two with an explicit PSX ammo label (JL-2 AMMO) in the nearby executable text table, while no matching JL-9 AMMO string has been recovered
• the focused follow-up in docs/psx/jl-9-investigation.md now closes one important part of the question: JL-9 is a real executable-backed final weapon-definition row rather than just a stray PSX-only string, and the strongest current acquisition route is a hidden passcode -> debug gate -> bulk weapon unlock path that likely reaches the extra late weapon channel
• that same focused follow-up now tightens the disambiguation further: the extra hidden-passcode/L0SR-adjacent non-PC weapon is now directly identified as JL-9 (0x0d), while JL-2 is the neighboring ordinary lane (0x0c)
• exact sprite identity and exact level placement for JL-9 remain open and still need runtime or asset-side correlation

Enemies

This pass did not recover a comparable plain-text enemy-name table from SLUS_002.68.

What is closed:

• the PSX executable has clean user-facing text for mission briefings, passcode UI, ammo, items, and weapons
• the same executable does not expose an equally obvious plain-text enemy catalog in its main printable-string regions

Current safest read:

• enemy identities in the PSX build are probably carried primarily as numeric resource/type ids, spawn tables, or script/resource references rather than as a direct display-name list
• the next enemy-focused pass should start from enemy spawn/type dispatch or resource-stream type tables, not from more blind string hunting

Highest-Value Next Steps

1. Run tools/psx_extract_wdl.py over more LSET*.WDL samples and compare whether the high-offset region pattern stays stable across level sets.
2. Recover the password-entry validation path directly so the hidden PSX cheat-password compare logic can be proven from code instead of only cross-referenced from public password lists.
3. Focus map decoding on post_audio_region_01 and post_audio_region_02, starting with table structures, coordinate ranges, and repeated record widths.
4. Focus sprite/graphics decoding on post_audio_region_04, including more aggressive TIM validation and possible packed-image expansion.
5. Recover the exact type IDs consumed by psx_stream_install_type_runtime_banks so the sprite/image resource records can be labeled more precisely.
6. Compare carved post_audio_region_04 image assets against on-screen level graphics to separate sprite sheets from tiles.
7. Run the raw-blob fallback across MENUS/*.WDL to identify which menu files contain usable embedded TIM data and which are likely packed 15-bit images.