# `orig/` developer-artifact notes

This pass focuses on the small set of bundled retail files that still look like build outputs, generated sources, backup headers, or other developer-facing leftovers. These are different from normal runtime assets: they preserve original names, generated code structure, or symbol labels that can be reused directly during decompilation.

## Tool

- `python tools/orig/developer_artifacts.py`
  - Catalogs the generated `*.c.new` boot-text sources under `files/Boot` and `files/gametext/Boot`.
  - Summarizes the MusyX symbol header preserved in `files/audio/starfox.h.bak`.
  - Reports the module leftovers in `files/modules/`.
  - Scans `sys/apploader.img` for preserved source-file names.

## High-value findings

### 1. `Boot/*.c.new` and `gametext/Boot/*.c.new` are real generated C source files

These files are not vague text dumps. They preserve:

- original internal paths such as `D:\binary/Boot/English.c.new`
- the include `GameTextData.h`
- generated symbol names such as `Boot_English_characters` and `Boot_English_texts`
- per-string arrays such as `English_825_0`

That is enough structure to scaffold plausible original source or generated-source wrappers around the boot text pipeline instead of treating those assets as anonymous blobs.

The shared structure is stable:

- all listed languages use the same `7` boot text IDs: `825`, `826`, `827`, `828`, `829`, `830`, `1381`
- all variants define one `Boot_<Language>_characters[]` table and one `Boot_<Language>_texts[]` table
- every file still points back at `GameTextData.h`

The copies are not all the same, though:

- `files/Boot/English.c.new` and `files/gametext/Boot/English.c.new` are the same file after normalizing the header path
- the French, German, Italian, and Spanish pairs are **not** exact duplicates
  - French preserves different disc-cover / insert-disc wording
  - German changes both glyph coverage and text content
  - Italian and Spanish show split or revised strings and slightly different glyph tables
- `files/gametext/Boot/Japanese.c.new` exists, but there is no matching `files/Boot/Japanese.c.new`

This is useful because it shows that the repo contains multiple revisions of the boot text generator output, not just redundant copies.

### 2. `audio/starfox.h.bak` preserves a generated MusyX symbol header

`orig/*/files/audio/starfox.h.bak` is byte-identical across EN/PAL/JP and still contains:

- `Generated by DolphinExport 13:22:28 7/25/2002`
- `57` `GRP*` group defines
- `113` `SNG*` song defines
- `828` `SFX*` effect defines

Examples from the header:

- groups: `GRPcloudrunner_fortress`, `GRPworld_map`, `GRPfront_end`
- songs: `SNGKrazoa_Shrine`, `SNGCRF_Treasure`, `SNGDIM_Mines`
- effects: `SFXstaff_rocket_boost`, `SFXmenu_pause_up`, `SFXswapstone_move_long`, `SFXdrak_roar2`

This is direct naming evidence for the audio subsystem. It can seed real enums, debug-name tables, and MusyX-facing symbol names without inventing placeholders.

### 3. `files/modules/` still contains a stable module testcase

The module leftovers are unchanged across all three bundled regions:

- `files/modules/dino.str` -> `baddies/testmod.plf`
- `files/modules/testmod.rel` -> `569` bytes

This is already small enough to use as a compact REL/parser testcase. The important part here is the preserved path string: it ties the module sample back to the original content pipeline naming.

For deeper REL details, pair this with [modules.md](/C:/Projects/SFA-Decomp/docs/orig/modules.md).

### 4. `sys/apploader.img` still leaks SDK source filenames

The EN/PAL/JP apploader image is byte-identical and still exposes:

- `BS2Mach.c`
- `CRCMain.c`
- `dvd.c`

That is useful for SDK matching. These names are not game-specific, but they are a concrete clue for identifying the exact apploader family and avoiding guesswork while matching Nintendo/Dolphin code.

## Practical use

- Use `python tools/orig/developer_artifacts.py --search GameTextData Boot_English_texts` when scaffolding boot text or generated text source.
- Use `python tools/orig/developer_artifacts.py --search SNG SFX` before introducing audio enums or symbol tables.
- Use `python tools/orig/audio_symbols.py 0x23 menu_pause --kind SFX` to query the preserved MusyX names without committing the generated header into `src/`.
- Use `python tools/orig/developer_artifacts.py --search testmod plf` when working on REL/module parsing.
- Use `python tools/orig/developer_artifacts.py --search dvd.c CRCMain.c` when matching apploader or SDK code.

## Why this matters

These artifacts are unusually strong evidence because they are not reverse-engineered guesses:

- the boot files preserve original generated source structure
- the audio header preserves original symbolic names
- the module leftovers preserve an original asset path
- the apploader preserves SDK source names

That makes them better naming/scaffolding anchors than most ordinary retail asset blobs.
