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, flight logic, model bytecode, and audio investigation.