maddo/Crusader_Decomp
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add Ghidra MCP server update workflow instructions and various binary files; enhance segment coverage ledger and mid-project plan with detailed analysis notes

Browse source
This commit is contained in:
MaddoScientisto 2026-03-21 19:29:57 +01:00
commit 8847708d41
10 changed files with 248 additions and 18 deletions
Download patch file Download diff file Expand all files Collapse all files

17
plan-mid.md
View file

@ -20,20 +20,25 @@ The estimates below are intentionally conservative. They measure verified behavi
- Priority 0 has started: `crusader_segment_coverage_ledger.csv` exists and contains a first-pass 145-row ledger.
- The currently seeded ledger rows are conservative and strongest around seg001, seg004, seg021, seg043, seg080, seg082/083/085, seg091, seg094, and seg095.
- Priority 1 has started on the cache/backend cluster: the seg082 allocator mechanics are now materially recovered (`allocator_head_try_alloc_block`, `allocator_head_free_block`, `allocator_free_block_by_ptr`), and the next unresolved clue is that `0x4588` behaves like a runtime-installed callback/dispatch object used by `entity_conditional_render_dispatch` plus a one-shot teardown path.
- The `0x4588` blocker is tighter than before: no-function windows now confirm a direct install at `000a:493e`, repeated clear paths in seg004, and additional vtable `+0x0c` callbacks from unresolved `000a:` and `000d:` callers, but the concrete subsystem name is still unresolved.
- Priority 1 has started on the cache/backend cluster: the seg082 allocator mechanics are now materially recovered (`allocator_head_try_alloc_block`, `allocator_head_free_block`, `allocator_free_block_by_ptr`), and the `0x4588` path now has named lifecycle helpers (`runtime_callback_object_init_once`, `runtime_callback_object_teardown_once`, `runtime_callback_object_phase_finalize`).
- The `0x4588` blocker is tighter than before: `000a:b988` boundary repair now includes both callback sync callsites (`000a:b9e5` / `000a:ba66`) inside one real function body, `000d:9d5e` / `000d:a3b7` are confirmed inside `entity_cleanup_resources_and_dispatch`, and adjacent helpers are now clarified as `allocator_head_finalize_sweep` (`0009:a961`), `video_bios_state_snapshot` (`000a:4a1f`), and `video_mode_set_and_record_state` (`000a:4972`). Concrete subsystem identity is still unresolved.
- A larger MCP rename batch completed for cleanup callees: `palette_buffer_alloc_and_init_256` (`0009:7853`), `file_handle_alloc_init_and_open` (`0009:1c3a`), `file_handle_open_with_mode` (`0009:1d6a`), `surface_release_internal` (`0009:8d7b`), `surface_release_and_maybe_free` (`0009:8e0a`), and `sprite_redraw_global_if_active` (`000d:9231`). This reduces `entity_cleanup_resources_and_dispatch` ambiguity on file/surface/palette teardown paths.
- The previously missing `000d:7e00` function object is now recovered and named `entity_dispatch_entry_init_runtime_state`, with paired destructor `entity_dispatch_entry_release_runtime_state` at `000d:8078`. Adjacent missing helpers `0003:a880` and `0003:b8e2` were also recovered, with `0003:b8e2` promoted to `far_buffer_alloc_with_mode_flags`.
- Additional helper stabilization now covers seg061/064/076: `vga_palette_read` (`0009:6ec7`) is confirmed alongside existing palette write/free paths, `timer_entity_enable_wrapper` (`0008:d3ba`) is named, and seg064 one-shot gate helpers around `0x3b72/0x3b73` are documented with conservative comments while keeping speculative naming deferred.
- Constructor-lane semantics tightened further: `entity_set_update_period_and_reschedule` (`0008:d27e`) and `palette_buffer_alloc_copy_from_source` (`0009:7905`) are now named, and both `0x4588` callback emit callsites (`000d:9d5e`, `000d:a3b7`) now have explicit payload-pair annotations in disassembly.
### Current Focus
1. Finish Priority 0 refinement by promoting more exact segment rows where notes already support a verified foothold.
2. Continue the Priority 1 pass by tracing the remaining caller-side `0x4588` / `0009:b1c3` object-role evidence rather than the already-recovered allocator mechanics.
2. Continue the Priority 1 pass by tracing remaining caller-side `0x4588` / `0009:b1c3` object-role evidence now that the `000d:7e00` constructor/destructor path is readable.
### Next Resume Point
1. Update the ledger for any additional exact segment anchors found in the reset/cache or render-path notes.
2. Recover or classify the still-unbounded callback callers around `000a:b9e5` / `000a:ba66` and `000d:9d5e` / `000d:a3b7`; they now look like the best remaining cheap wins on the `0x4588` path.
3. Revisit the nearby install/lifecycle gap around `000a:493e` / `000a:4a56` only if those caller windows need a stronger object-owner model.
4. Continue `ASYLUM.24` only after the `0x4588` path has no further cheap wins.
2. Continue caller-role classification inside `entity_cleanup_resources_and_dispatch` (contains both `000d:9d5e` and `000d:a3b7`) and map how it relates to `runtime_callback_object_phase_finalize` + `allocator_head_finalize_sweep`.
3. Promote additional field-level names inside `entity_cleanup_resources_and_dispatch` and `entity_dispatch_entry_init_runtime_state` now that update-period/palette-copy helpers are named.
4. Classify remaining callback-role semantics for the `0x4588` object (especially vtable `+0x08` vs `+0x0c` intent and phase/event meaning) using the confirmed payload pairs `+0x12d/+0x12f` and `+0x74f/+0x751`.
5. Continue `ASYLUM.24` only after the `0x4588` path has no further cheap wins.
### Headline Estimate