TFX engine-build comparison

The bundled Inferno cinematic preview uses a different early TFX-engine build, retaining player flight code, three TFX aircraft presets, 3D rendering, sound-effect definitions and the default high-score roster. It is not a copy of the September 2.05 executable. Its supplied presentation assets make the preview non-interactive; that does not mean the executable contains only a movie player. This is not evidence that it is the final released Inferno engine.

Machine-readable comparison records source hashes, section layouts, routine matches, relocated strings, all sampled-effect descriptors and complete native flight-preset data writes. The original executable files remain untouched.

Builds

The March and September CDs also have a separate root-level TFX.DAT, byte-identical between the two discs and different from their installed engines. It is included as its own build, using the September file as the canonical source. Its data allocation is 236,064 bytes; the additional allocation is not assigned a purpose here.

There are 137 unique qualifying signatures among the 178 annotated 2.05 entry points. Matches retain instruction bytes while masking relocated addresses and branch destinations. They identify shared routine prefixes, not complete function equivalence or a percentage of the whole engine. Failure to match is not proof of absence. All three retained CDs carry the same preview engine SHA-256: 2d8b69e562b774a8869d92e858a8e82f76e127eda988c74e058429b41bac2da3.

Retained gameplay and renderer code

The preview also retains TFX aircraft labels, mission-file diagnostics, autopilot and landing-system messages, weapon data and flight-realism settings. There is no supplied gameplay dataset in the preview archive, and its trash4.par script does not launch a mission. Retained code is not proof that every TFX gameplay path can run successfully with that archive.

Native flight-preset comparison

All three preset routines have been located from their original aircraft-selection dispatcher and executed in each of the eight relocated images: 24 native calls. The September calls also match the previously captured 95-field preset study.

The preview and November floppy presets produce identical ordered values and write sizes in all 885 events. Their field addresses differ: 306 destination locations map consistently one-to-one between the two builds. Addresses are retained separately rather than discarded or claimed identical. This is strong evidence for the early TFX branch; it does not establish identical complete flight behaviour.

The JSON groups exact preset value/write-size streams across all eight builds. These groups include ordinary state/flag initialisation; they are not automatically distinct aerodynamic models. Units and physical meanings are not assigned to unnamed fields.

PC Plus playable demo

The playable demo has the same ordered preset values/write sizes as March retail and September 2.05 for all three aircraft. Its native loader adds a sixth early executable to the relocation checks. This establishes matching aircraft initialisation under the isolated capture conditions, not identical complete in-flight simulation.

The demo is a distinct engine build despite its configuration program reporting 2.01. In particular, it reads 17-byte presentation text settings, while March/root-CD/September use the retained 16-byte layout. Its save-path construction also shares DID-prefixed forms with the floppy and root-CD families. See the detailed demo/retail comparison for native instruction evidence, configuration differences and the Gravis helper study.

Sound and embedded data

All eight executables retain the same 103 sampled-effect names, rates and cooldowns, including the descriptor whose x10 resource is missing from the reference archive. No 25, 29 or 30 descriptor appears in any of these builds. That supports the unused-recording interpretation across more than just 2.05, without proving that no dynamically constructed loading path exists.

All eight also contain the same ten-entry default high-score roster. Referenced strings unique to the preview among these builds include DID=F: at file 0xb7d52, referenced at 0x739f5 inside the MSCDEX-initialisation area. It is not evidence that the cinematic requires TFX resources on drive F. The JSON preserves that reference and the other earlier-build string differences.

Early executable loader

The six early executables use a small DOS/4G-hosted LE bootstrap. The real program is in three uncompressed sections, described by a 52-byte footer at EOF; it is not a compressed executable needing an unpacker. The bootstrap reads three (relocation pages, file offset, allocation size) triples, a stack offset, an entry offset, and the relocation-stream offset and length. The data section has a larger allocation than its stored extent. Analysis bases are chosen allocations, not recovered fixed load addresses.

The relocation stream starts with the total page count. For each section page, three groups contain a 16-bit count and 16-bit page-relative offsets, one group for each target section. Each pointed-to 32-bit word receives the corresponding runtime allocation base. Page-crossing sites are preserved. Two bootstrap layouts store their temporary section bases at different offsets; the native checks discover those fields from the original instructions.

All 175,476 relocation sites in the six early builds were checked against execution of the original loader helpers, comparing 4,039,828 allocated section bytes. File reads, DOS allocation and complete program startup are outside that isolated test; uninitialised memory is zero-filled for the research calls. September 2.05 instead exposes its real sections through ordinary LE objects.

python3 tools/compare_engine_builds.py

inspect_did_executable.py provides the shared early-image reader. compare_engine_builds.py generates this comparison and performs the native checks. The full Inferno game and further extraction of its cinematic assets remain a separate project.