# Build provenance and source-organization clues

The strongest current inference is **substantial handwritten 16-bit x86
assembly**, including the flight logic, not just hardware-facing routines.
This is an inference from recovered executable behavior, not a recovered source
credit. No particular assembler, linker, C compiler or other host language has
been identified. An entirely assembly-written game remains plausible, but is
not established for every component.

Evidence in the inspected core:

- State lives inside immediate instruction operands. Flight inputs, energy
  reserves, callback parameters and deadlines are read and written at addresses
  inside instructions, rather than only in separate variable storage.
- Call interfaces are tailored to individual routines: registers carry several
  inputs/results, BP commonly points into an SS-resident object, and flags can
  carry results. These are not the conventional stack-frame interfaces one
  would use to recognize ordinary compiler output. A register convention alone
  would not prove assembly; the combined patterns are much stronger evidence.
- Control flow deliberately repurposes return addresses. `7EAD` pops its return
  address into the object's callback slot and jumps to it, turning the remainder
  of its caller into the next update state.
- Helpers share tails and enter one another at intermediate labels. The flight
  code uses byte halves, carry propagation, shifts and register exchanges to
  implement fixed-point arithmetic with very little abstraction overhead.
- The renderer patches instruction operands in its vertex machinery. Startup
  also replaces a CPU-dependent copy sequence and later reuses startup-code
  space for the extended sine table.

These patterns imply intentional assembly-level organization, or explicit
assembly embedded in another build, rather than merely aggressive optimization
of conventional C. They do not distinguish assembler brands: the resulting
instruction encodings and private register conventions are not a tool signature.
The MZ container and recovered relocation entries establish DOS loading details,
not a particular linker or source memory-model declaration.

The layout gives useful subsystem boundaries: drawing/geometry machinery,
flight input and movement, resource loading, and mission-script interpretation
form recognizable clusters. Objects have update callbacks; flight, landing and
transitional states replace those callbacks. Keyboard events and mission
commands use handler tables. These structures can guide a modern module layout,
but do not recover original filenames, procedure names, macros or include files.

There are also **domain-specific interpreted formats**: geometry command streams
and mission/scene scripts. Those are evidence of an authored data pipeline and
custom interpreters, not evidence of a particular language used for the engine
or its offline tools. Their original authoring syntax remains unknown.

Sound Images Generation 2 is independently identified in the external audio
drivers. Its provenance must be kept separate from the game's main code; the
whole product need not have used a single programming language or toolchain.

See [unpacking](executable-unpacking.md), [flight logic](flight-physics-and-charging.md),
[model bytecode](model-bytecode.md), and [audio investigation](audio-investigation.md).