# Previously unidentified TFX resources

The [resource audit](unresolved/index.html) now includes the identification evidence and auditions below. [Machine-readable findings](unresolved/investigation.json) preserve hashes, exact comparisons and the remaining qualifications. The Inferno demo is excluded.

## Recovered parser-editor sources

The three `unresolved/*.txt` files are UTF-8 reading copies of original DOS
CP437 authoring text, with DOS end-of-file markers removed. The original
archive payloads remain unchanged. They are classified as `presentation_source`,
separately from the eight still-unclassified binaries; the audit includes both
unresolved resources and recovered editor material.

| Text export | Contents |
|---|---|
| [66cebd1a.txt](unresolved/66cebd1a.txt) | Parser Editor V2.4: a 1,628-line front-end/game-flow draft covering the introduction, training, simulation menus, campaign scaffolding, enrolment and outcome handling. Extracted under the candidate name `waytxt/dpop.lst`. |
| [70e6ab2a.txt](unresolved/70e6ab2a.txt) | Parser Editor V2.3: a minimal launcher declaring `miss_num` and executing `MISS %miss_num`. |
| [a450a156.txt](unresolved/a450a156.txt) | Parser Editor V2.4: a small result-script example calling `MISS 9999`, then selecting success or retry text using `miss_val`. |

All three headers credit Dave at Digital Image Design, with a 1992/93 copyright
notice. The large draft retains placeholder text, empty strips and duplicate
variable declarations. These are authoring leftovers, rather than an established
textual source for the shipped binary `.par` programs; normal retail use of
these particular source files has not been established. See also the
[presentation-format notes](media-and-presentations.md#parser-editor-source-leftovers)
and [audit viewer](unresolved/index.html#66cebd1a).

## Breathing recordings

Three waveform buffers match the filename candidates `samples/breath1.sam`, `breath2.sam` and `breath3.sam`. Their relationship to the native `breath1q`, `breath2q` and `breath3q` effects is unusually clear: after skipping four source bytes, each signed amplitude is halved with truncation towards zero.

```text
q[i] = 128 + trunc((original[i + 4] - 128) / 2)
```

All 12,140 and 10,254 samples match for the first two files. The third matches except its final output sample: the transformation predicts 153, while the stored `q` file ends in 178. These are quieter versions of the same recordings, not missing instruments or new compositions.

`breath3` is also **byte-identical to the used `breathin` sample**, including all four initial bytes. Its native descriptor specifies 7,500 Hz, so the audit reuses that existing WAV. Auditions of the other two originals are labelled **7,500 Hz inferred**: the used `q` descriptors supply that rate and the conversion preserves sample positions. No separate native descriptor for the unattenuated names has been established. The first four bytes are not asserted to be a file header; the native `breathin` path plays that identical buffer in full.

These three buffers are now classified as `sample_variant`, reducing the unclassified family from eleven to eight. Their native source payloads and extraction paths remain unchanged.

## Numerical sample candidates

The remaining waveform-like files match the numeric filename candidates `samples/25.sam`, `samples/29.sam` and `samples/30.sam`. In particular, the older `spanish/23.dav` guess collides with `samples/29.sam`; the numerical sample candidate fits the bytes and neighbouring numbered effects better, but remains a candidate.

| Candidate | Resource | Bytes | Heard in audition | Audition at assumed 7,500 Hz |
|---|---|---:|---|---|
| `samples/25.sam` | `4d4a1803` | 7,450 | “Talk to me, Goose” | [Play/download WAV](unresolved/25-7500hz-assumed.wav) |
| `samples/29.sam` | `41520003` | 31,060 | “AWACS confirms inbound hostiles, you have permission to fire” | [Play/download WAV](unresolved/29-7500hz-assumed.wav) |
| `samples/30.sam` | `49431601` | 6,978 | “Change heading” | [Play/download WAV](unresolved/30-7500hz-assumed.wav) |

The WAVs preserve every source byte as unsigned 8-bit mono PCM. **7,500 Hz is an audition assumption**, chosen because all 21 used numbered samples have that native rate. No descriptor establishes it for these three files. The [resource viewer](unresolved/index.html#4d4a1803) lets you change the audition rate, including the corresponding pitch change, without producing duplicate recordings.

All 103 recovered effects descriptors were checked. An additional search through every LE relocation found no pointer to an exact `29` or `30` filename string. The sole pointer to `25`, at executable file `0x8b924`, belongs to HUD text: the instruction at `0x8b923` supplies it to the mini-HUD writer `0x87154`, called at `0x8b930`. That is not an audio descriptor. This narrows the known reference executable's evidence; it does not prove the clips were unused by every version or every dynamically constructed filename path. The transcriptions above were supplied by the user after listening; the AWACS line’s attribution to `29.sam` was explicitly confirmed. Audible content is established, while the original filename, native playback rate and runtime trigger remain separate questions.

Each buffer is byte-identical across the December 1993, March 1994 and September 1994 CDs. They are not later-CD additions. The subsequent [eight-build engine comparison](engine-builds.md#sound-and-embedded-data) finds the same 103 sound definitions in every engine, including the early floppy and Inferno-preview executables, with no descriptor for `25`, `29` or `30` in any of them.

## Terrain editor stamp candidates

All seven `.sta` files contain a count followed by 27-byte records: a little-endian tag word and a **5×5 pattern of tag bytes**. There are 250 records in total. Every nonzero pattern byte belongs to that table's tag-word vocabulary. Patterns include solid fills, a filled 3×3 centre, dotted crosses and narrow connections. Repeated tag words are preserved as separate records.

The tags also occur in the nine-value metadata attached to scenery tiles in the matching `.asc` authoring files. For six of seven files, every nonzero ASC tag has a corresponding stamp; some stamps are unused in that particular ASC. `colum_d` is the exception: its stamp table lacks eighteen nonzero tags used by its ASC, another concrete inconsistency in that retained authoring set.

This supports interpreting the resources as **terrain-editor stamps or classification patterns**, rather than height samples. An active native reader, orientation, placement rules and the meaning of zero remain unverified. The audit renders the 5×5 patterns with diagnostic colours to make the structures inspectable; those colours do not claim to reproduce a game palette or schematic.

## Four buffers containing DOS memory snapshots

The old sixteen-by-twenty-byte partition of the four 324-byte files was misleading. Their actual recognisable region begins at **byte 68** and occupies the final **256 bytes**: real-mode memory `0000:0000` through `0000:00ff`, containing the first 64 interrupt-vector slots. The first 68 bytes remain unidentified.

Three files — `9af21b6b`, `9d0a9b6b` and `9f9a9b6b` — are byte-identical. Their vectors include nine fixed BIOS entries, including `F000:FF54` for Print Screen, `F000:F84D` for the equipment list, `F000:F841` for memory size, `F000:E82E` for the keyboard and `F000:FE6E` for the clock. These addresses agree with the fixed entry-point table in [Intel's CSM specification, section 5.2](https://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/efi-compatibility-support-module-specification-v098.pdf). DOS services point to `D03C:0AB2`, and the mouse entry to `C97E:042D`.

Resource `90221b6b` contains a different session's table: DOS services are at `D529:0AB2`, the mouse entry is at `D771:042D`, and the BIOS entries are redirected. It differs from the other files in 161 bytes: byte 13 of the prefix, plus 160 bytes of the interrupt-table region.

Both versions also preserve DOS's **inline far jump at physical address `0xC0`**, rather than an ordinary INT 30h vector. In the files it is at byte 260 (`68 + 0xC0`):

| Snapshot | Bytes | Decoded instruction |
|---|---|---|
| Three identical files | `EA D0 10 23 01` | `JMP FAR 0123:10D0` |
| `90221b6b` | `EA 28 00 02 01` | `JMP FAR 0102:0028` |

The fifth byte overlaps the nominal INT 31h slot. This is a particularly useful check that these are genuine low-memory snapshots, rather than merely arrays containing pointer-like numbers. The viewer retains those slots' raw words but marks them as compatibility code, not handler addresses. [DOSBox-X's DOS initialisation](https://dosbox-x.com/doxygen/html/dos_8cpp_source.html) independently documents and implements the same five-byte arrangement.

INT 34h–3Bh share a handler, with separate handlers at 3Ch and 3Dh. This resembles the x87 software-emulation interrupt convention used by several DOS language runtimes. It does **not** identify a unique compiler or prove that the retail TFX engine used that runtime; see the interfaces described in the [GoFast emulator vendor's guide](https://www.smxrtos.com/doc/ussw/gofast/gofast86.pdf).

The three identical snapshots already appear in the December CD and floppy data. The different snapshot appears in the March and September CDs. A tool could have deliberately saved a machine context or accidentally appended bytes read through a null pointer. Neither explanation is proven: the writer, original filenames, prefix fields and native consumers remain unknown. The files stay unclassified as a whole, while their low-memory contents are now decoded.

## Big-endian record table

Resource `862db179` has big-endian header words **20, 200**, then twenty ten-byte records. Each record contains `[3330 × index, 28, 8, 37, 370]`, followed by 1,064 zero bytes. The second header word equals the 200-byte record extent. Its progression could represent angular placement or time, but no filename or native consumer establishes either interpretation.

The complete 1,268-byte buffer is identical across all three CDs and the floppy data. Its archive IDs change with the archive's directory/extension tables: December `83233379`, March `81053179`, September `862db179`. Searching only for September's ID in earlier archives would incorrectly suggest that the table was absent. A filename-hash match alone remains insufficient: searches produce collisions that do not match the same content across the versions.

No additional model or image format has been established in these eight files. The three recordings, four snapshot-containing buffers and single table remain explicitly qualified in the catalogue; recognising the contents of part of a file is not the same as recovering its original purpose.

```sh
python3 tools/investigate_resources.py
python3 tools/catalog_resources.py
python3 tools/audit_remaining_resources.py
python3 tools/build_resource_browser.py
```

The investigation checks the complete PCM transformations, the native-identical alias, source hashes, all terrain extents and tag vocabularies, the exact big-endian record pattern, the DOS snapshots and cross-version content matches before generating its report. The catalogue independently checks the PCM relationship when assigning `sample_variant`.

The completion pass also tested filename candidates drawn from recovered resource names, authoring text and executable strings across the remaining buffers. No additional name was established. Their bytes are already fully extracted; what remains unknown is their original purpose or consumer. This is distinct from an archive entry that cannot be decompressed.