TFX Research archive

Previously unidentified TFX resources

The resource audit now includes the identification evidence and auditions below. Machine-readable findings 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 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 Parser Editor V2.3: a minimal launcher declaring miss_num and executing MISS %miss_num.
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 and audit viewer.

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.

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
samples/29.sam 41520003 31,060 “AWACS confirms inbound hostiles, you have permission to fire” Play/download WAV
samples/30.sam 49431601 6,978 “Change heading” Play/download 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 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 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. 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 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.

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.

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.