Captain Bible reverse-engineering

Project repository: https://github.com/peterkelly/captain-bible-re

This book records the evidence, methods, and results of reverse-engineering Captain Bible in the Dome of Darkness. The supplied copy is a DOS program whose main executable is CB.EXE. The work begins with a reproducible FreeDOS virtual machine before moving to static and dynamic analysis.

Statements in this book should distinguish direct observations from inferences. Commands and their important results are preserved in the progress log.

Current scope

The playable QEMU environment is complete. Static analysis has identified the packer and run time, reconstructed the executable, mapped startup and major support routines, and recovered the command-line, export, input, and save paths. Dynamic analysis now uses a QEMU TCG plugin to trace game-originated DOS and sound-driver calls without modifying CB.EXE, correlating file activity and runtime addresses with the reconstructed program. The resource container, graphics, scene bytecode, audio, text, saves, maps, combat, conversation, and final progression all have reproducible inspectors or archive-backed regressions.

Focused input/save traces, representative gameplay screens, and a live combat memory capture now supplement the earlier startup evidence. Remaining questions concern semantic names and branch-level behavior that the current evidence does not distinguish. Those boundaries are recorded in PLAN and in the relevant system chapters.

Environment and Running the Game

Host tools

The first inventory found:

• QEMU 11.0.2 (qemu-system-i386 and qemu-img)
• Rizin 0.9.1
• mdBook 0.5.3

The host is macOS on Apple Silicon. QEMU therefore runs the i386 guest using software emulation rather than hardware virtualization.

Guest operating system

The selected guest is the stable FreeDOS 1.4 release. The FreeDOS project recommends its LiveCD for installation in a virtual machine. Its published minimum is an Intel-compatible processor, 640 KiB of memory, and at least a 20 MB hard disk.

The repository-specific setup instructions require a noninteractive build rather than the FreeDOS installer. tools/setup_freedos_image.py downloads and verifies the official LiteUSB archive, extracts the largest image member, preserves its boot code and filesystem, and builds a new 1 GiB raw disk with a single active FAT16 LBA partition.

The base image is:

build/freedos/freedos.img

It has a 1 MiB partition offset (LBA 2048), so its mtools path is:

build/freedos/freedos.img@@1048576

The builder initially produces a clean FreeDOS base image. run.sh clones it to a separate persistent play image, copies CB/ to C:\CBDOME, installs CuteMouse from the LiteUSB package set, and replaces the clone’s boot scripts so the game starts automatically. At the user’s request, the complete game was also copied into the current base image at C:\CBDOME; rebuilding the base image will remove that additional copy.

Run the game

From the repository root:

./run.sh

The persistent play disk is build/captain-bible/captain-bible.img. Use ./run.sh --setup-only to prepare the disk without opening QEMU or ./run.sh --rebuild to replace it from the current CB/ tree. Rebuilding discards saves stored only in the old play disk.

For deterministic comparison, supply an unsigned decimal initial state from 0 through 65,535:

./run.sh --rng-seed 1

This mode never edits CB/CB.EXE. Immediately before QEMU starts, the launcher reconstructs and signature-checks the unpacked executable, installs the portable RNG, clones the persistent disk into a unique run directory below build/qemu-deterministic-rng/, injects the patched executable only into that clone, and copies it back out for a byte-for-byte check. QEMU runs the clone with -snapshot, so guest writes are discarded at exit. An existing persistent play image is unchanged unless --rebuild is also supplied; initial setup may create it. A normal launch removes the unique run directory after QEMU exits. Use ./run.sh --setup-only --rng-seed 1 to build and verify the disposable image without opening QEMU and retain its printed directory for inspection.

When booting the current base image directly instead, enter CD \CBDOME followed by CB. The normal ./run.sh path needs no DOS commands because its derived play image starts the game automatically.

The QEMU machine provides:

• a Pentium-class i386-compatible CPU with 16 MiB RAM;
• standard VGA in a visible Cocoa window with zoom-to-fit enabled on macOS;
• a PS/2 mouse served through the CuteMouse DOS driver;
• Sound Blaster 16 digital audio; and
• AdLib-compatible FM synthesis.

The supplied SOUND.1 identifies itself as a Sound Blaster 16 driver, and SOUND.2 identifies itself as a Sound Blaster Pro FM driver. These match the emulated devices.

Verification result

The base image passed a screenshot-free boot smoke test. A temporary clone wrote FREEDOS_READY to C:\BOOT.OK from both patched boot-script paths, and the marker was read with mtools after QEMU stopped. A separate bounded launch of the play image reached the Captain Bible title screen at 640×400.

The user subsequently verified the complete interactive path: keyboard and mouse input work in the visible QEMU session, and the game exits normally through its menus. This closes the environment/playability check independently of the automated boot and title-screen evidence.

Initial game requirements

The supplied MANUAL.TXT says to change to the installation directory and run CB. It reports that the game needs approximately 500 KiB of conventional memory. Its optional command-line switches and player-name prefix are now recovered from game_main and documented in the static-analysis and save-game chapters.

Reproducing the Results

This chapter provides one end-to-end path through the repository. Individual format chapters explain the evidence and field meanings; this page answers the practical question “which commands recreate and verify the results?”

The original game files remain under CB/ and are intentionally not tracked. Generated disk images, extracted resources, memory dumps, rendered media, and the HTML book remain under ignored build/ directories. The Python tools, tests, Rizin names, checked symbol catalog, and Markdown sources are tracked.

1. Check the input copy

The supplied executable and main container used for this research are:

Verify them on macOS with:

shasum -a 256 CB/CB.EXE CB/DD1.DAT

The file-inventory chapter records every supplied file, size, timestamp, hash, and current identification.

2. Build and run the DOS environment

Construct or verify the FreeDOS base and persistent play image without opening QEMU:

tools/setup_freedos_image.py
./run.sh --setup-only

Play with the required visible, zoom-to-fit Cocoa display and silent host audio:

./run.sh

Use ./run.sh --rebuild only when deliberately replacing the persistent play image and its saves. The environment chapter documents the image layout, mtools offset, boot scripts, and guest path.

To run DOS with the portable deterministic generator and seed 1:

./run.sh --rng-seed 1

The corresponding Rust launch is:

cargo run --release --manifest-path rust-engine/Cargo.toml -- \
  --data CB --rng-seed 1

The DOS command reconstructs a patched executable and injects it into an ignored disposable disk clone. It never writes the original packed executable. After normal setup, it also leaves the persistent play image unchanged unless combined with an explicit --rebuild; initial setup may create that image. Seed 1 produces the first six generator outputs 19511, 30543, 10098, 22502, 1941, 10629 in both engines.

3. Reconstruct and inspect the executable

Recover the EXEPACK-compressed load module:

tools/analyze_cb_exe.py CB/CB.EXE \
  --output build/analysis/CB_UNPACKED.EXE

When the recorded title dump is present, independently compare relocation and the live process image:

tools/analyze_cb_exe.py CB/CB.EXE \
  --output build/analysis/CB_UNPACKED.EXE \
  --memory-dump build/dumps/title-physical-1m.bin \
  --load-segment 0x627

Load recovered names and verify the checked symbol catalog:

rizin -b 16 -i analysis/cb.rz build/analysis/CB_UNPACKED.EXE
tools/inspect_symbol_map.py

Then verify every BIN dispatch target and operand-reading path against the unpacked executable, symbol catalog, decoder, and original archive:

tools/audit_bin_opcodes.py

The executable and symbol-map chapters define load offsets, file offsets, segment translation, confidence levels, and handler-address auditing. The checked per-opcode report is analysis/opcode-audit.tsv.

4. Extract the resource archive

List and expand all 369 directory entries:

tools/extract_dd1.py --list CB/DD1.DAT
tools/extract_dd1.py --extract-all build/dd1/all CB/DD1.DAT

Repeated archive names receive numeric prefixes in all-member output, so no member overwrites another. The extractor validates declared sizes, payload magic, compression boundaries, and exact input consumption.

5. Reproduce graphics results

Inspect frame descriptors, render a canvas, and regenerate the annotated full-screen gallery:

tools/render_art.py build/dd1/all/003_LOGO.ART --list
tools/render_art.py \
  build/dd1/all/003_LOGO.ART \
  --palette build/dd1/all/002_LOGO.PAL \
  --canvas --scale 2 \
  --output build/graphics/logo.png
tools/render_fullscreen_gallery.py \
  CB/DD1.DAT \
  --output build/graphics/full-screen-gallery.png

These paths cover all 143 ART members and infer scene-selected palettes from decoded BIN commands. The graphics chapter records descriptor validation and the independent QEMU framebuffer comparison.

6. Inspect scripts and gameplay systems

The general BIN decoder supports display objects, choices, animations, and actions:

tools/inspect_bin.py build/dd1/all/005_INTRO.BIN
tools/inspect_bin.py build/dd1/all/001_LOGO.BIN --objects
tools/inspect_bin.py build/dd1/all/327_BOSS.BIN --choices
tools/inspect_bin.py \
  build/dd1/all/337_COMBAT7.BIN --animations --actions

Inspect the world grid and late-game road graph with their specialized tools:

tools/inspect_map.py CB/DD1.DAT --map CE --rooms
tools/inspect_map.py CB/DD1.DAT --map CE --hall-features
tools/inspect_unibot.py build/dd1/all/315_CP2.BIN

The scene, object, conversation, combat, state, maps, and endgame chapters connect those views to executable runtime tables and progression behavior.

7. Reproduce audio and text results

Decode a sound effect, validate an XMIDI container, and join a verse index to its companion text stream:

tools/convert_abt.py \
  build/dd1/all/306_D003.ABT \
  --output build/audio/d003.wav
tools/inspect_xmi.py build/dd1/all/267_MUS001.XMI
tools/inspect_midpak_ad.py CB/SOUND.4
tools/inspect_text_resources.py \
  CB/DD1.DAT --data-dir CB \
  --translation N --bank A --record 0

The audio decoder covers all 41 ABT members; the XMI parser covers all 32 music members; and the timbre inspector validates all 181 installed OPL patches. The text inspector covers every translation and bank pairing. Their chapters record the live PCM and QEMU-export comparisons.

8. Inspect saves and mutable state

Decode the fixed label index, one state, its descriptors, and named variables:

tools/inspect_save.py CB/DDGAMES.SV0
tools/inspect_save.py CB/DDGAMES.SV3 --descriptors
tools/inspect_save.py CB/DDGAMES.SV9 --variables
tools/inspect_map.py \
  CB/DD1.DAT --map CE --compare-save CB/DDGAMES.SV3

These commands connect the 2,752-byte save layout to script state, text descriptors, and the mutable 768-byte map.

9. Repeat dynamic tracing when needed

Launch the visible QEMU session with the game-filtered DOS-call plugin:

./run.sh --trace-dos

The dynamic-analysis and sound-driver chapters document generated paths, deterministic segment assumptions, preserved startup hashes, live AX capture, and the int 16h/21h/33h/66h record formats. This is an interactive capture, not part of the fast test suite.

For a controlled scene-entry experiment, patch both scene names in a research copy of a state and inspect a subsequent physical-memory dump:

tools/patch_save_scene.py input.SVQ COMBAT1 output.SVQ
tools/patch_save_scene.py input.SVQ ROOM3 output.SVQ --coordinate 13 6
tools/inspect_runtime_tables.py memory.bin \
  --data-segment 0x14e1 \
  --bin build/dd1/all/343_COMBAT1.BIN

The combat-runtime chapter states the provenance limitation: the preserved COMBAT1 capture entered through a patched hall quick-save, not by walking to the encounter naturally. The loaded action and animation tables nonetheless match the selected BIN resource byte for byte in every compared definition. The optional coordinate pair patches variables 11 and 12 in both serialized variable blocks and was used to probe coordinate-sensitive handlers.

10. Run the complete noninteractive verification

From the repository root:

python3 -m unittest discover -s tests -v
python3 -m py_compile tools/*.py tests/*.py
tools/check_documentation.py
tools/inspect_symbol_map.py
tools/audit_bin_opcodes.py
bash -n run.sh tools/build_qemu_dos_trace.sh
mdbook build docs
test -f docs/book/index.html

The tests read original inputs directly from CB/ and do not depend on a previous extraction directory. The documentation checker requires every book chapter to appear exactly once in SUMMARY.md, validates local links and anchors, and confirms that repository commands in shell examples exist and are executable. The final HTML is written to docs/book/.

Result boundaries

The noninteractive suite proves deterministic parsing, structural invariants, known byte-level regressions, documentation integrity, and book generation. It does not claim to automate subjective gameplay checks. The completed interactive pass is recorded separately because it used a visible QEMU session, monitor input, screenshots, guest save files, and physical-memory dumps rather than the fast suite.

Executable Reconstruction

File identity

The supplied CB/CB.EXE is a 64,299-byte, 16-bit DOS MZ executable. Its SHA-256 is:

2b7726ae9cf56e0067533e4bd1c5c76685f1d9855a7d90835850388db7b07ee0

The filesystem timestamp is 1996-12-24 23:32 in the host’s +0700 time zone. The MZ header has no outer relocations and points to 0F79:0010, only 395 bytes before the end of the file. The load module’s entropy is approximately 7.004 bits per byte. These are consequences of executable compression, not evidence that the game code is encrypted.

Microsoft EXEPACK

The bytes at file offset 0xF990 are a 16-byte Microsoft EXEPACK header. The RB signature, the decompression loop, and the 22-byte Packed file is corrupt error message identify the format. Microsoft’s MS-DOS Encyclopedia describes EXEPACK as LINK’s compression of repeated byte runs and the relocation table. David Fifield’s independently maintained EXEPACK implementation documents and implements the specific header and backward decompression algorithm used here.

The packed relocation table is 118 bytes: 32 bytes of counts for 16 groups plus 43 two-byte offsets. The recovered load-module relocation offsets are:

0034c 0033c 00334 002ac 000af 000aa 034d4 034c8 035fb 0429c
04286 04275 0424f 04246 0422c 041fc 0414e 04143 0412e 04129
04115 040f0 043da 043cf 043ba 0439d 04392 0437d 04363 04335
04320 04316 042ed 05146 07615 0973a 09ae8 09e8c 0ab31 0cb67
0cbf1 12214 122a8

tools/analyze_cb_exe.py implements the relevant MZ and EXEPACK decoding with the Python standard library. It emits a 75,776-byte conventional MZ file with SHA-256:

4875f83d6d2ba9c1cc4f058e351e453010c6a5976e1b15976b676689f9747643

That output is byte-identical to the result from Fifield’s EXEPACK 1.4.0 at source revision f715ed19285565d636e78182fc19df62c0fa64b9.

QEMU memory verification

QEMU was run with the required visible Cocoa display and its monitor and GDB server enabled. Once the title screen appeared, the VM was stopped and the first MiB of physical memory was saved:

build/dumps/title-physical-1m.bin

The captured register state located the process precisely:

After adding load segment 0x0627 at all 43 MZ relocation sites, the rebuilt load module and the QEMU process memory have an identical prefix of 0x905A bytes. There are 5,612 differing bytes in the full 75,264-byte comparison; inspection shows runtime-initialized tables, loaded resource metadata, and BSS state. Known static strings occur at the predicted relocated addresses, including the Microsoft run-time banner at physical 0x14E18. This makes the QEMU snapshot a strong independent check of both decompression and relocation.

Address convention and memory model

All function addresses in this book and analysis/cb.rz are linear offsets from the DOS load-module base, not file offsets. Add 0x200 for the unpacked file offset. At the captured load segment, add physical base 0x6270 for a physical address.

The C startup sets DS to load segment plus 0x0EBA, so a source-level data reference such as DS:08DA corresponds to load offset 0xF47A. Rizin does not automatically perform this segment addition and may present such immediates as references into low code addresses.

The evidence is consistent with the Microsoft C small memory model: ordinary code and data pointers are 16-bit, all normal C calls are near within one code segment, and explicit far pointers are used for loaded resources and driver interfaces. The initialized data contains:

MS Run-Time Library - Copyright (c) 1988, Microsoft Corp

This identifies the Microsoft C run time and Microsoft LINK/EXEPACK, but does not by itself prove an exact compiler release.

Static Analysis Findings

Working with the disassembly

Generate the unpacked executable and apply the current symbol map:

tools/analyze_cb_exe.py CB/CB.EXE \
  --output build/analysis/CB_UNPACKED.EXE
rizin -b 16 -i analysis/cb.rz build/analysis/CB_UNPACKED.EXE

Rizin’s first recursive pass identifies approximately 340 candidate functions. Several large candidates cross jump tables or data and are false merges, so the names below are limited to routines whose implementation and call sites provide direct evidence.

Program entry and main

The real entry at 0xCB5C is Microsoft C startup code. It checks for DOS 2.0, resizes the process allocation, clears BSS, constructs argc, argv, and envp, and calls the near function at 0x8A82 with all three values. That function is therefore main.

The high-level static flow is:

1. If argv[0] has a drive-qualified path, 0x8A09 changes to that drive and directory.
2. main initializes resource-name buffers including LOGO, seg, and DDGAMES, then parses all remaining arguments.
3. 0x3363 verifies VGA, reads SOUND.5, loads the configured SOUND.1 through SOUND.4 drivers, opens DD1.DAT, and initializes subsystems.
4. 0x7F58 reads the save index, and 0xB818 loads RUN.ART as resource slot 253.
5. 0x7D2B creates a new session and initializes the menu/game state.
6. main repeatedly updates audio and dispatches states 0, 1, and 2 to the menu/game loop, reset path, and restore path. It has no ordinary return.

Runtime random source

Startup initialization at 0x3363 calls the clock helper at 0x02CF. That helper reads the DOS local time and returns hour * 3600 + minute * 60 + second; startup masks the low word with 0x7FFF and passes the result to the runtime seed function at 0xE954. The seed is zero-extended into the 32-bit state at DS:3968. New Game does not repeat this startup initialization.

The runtime function at 0xE966 updates that state with state * 0x000343FD + 0x00269EC3, retaining the low 32 bits, and returns (state >> 16) & 0x7FFF. Opcode 0x82 divides that result by its immediate and stores the remainder. The X text-component shuffle calls the same function twice for each of 20 swaps. Unused opcode 0x8B also shares the stream: it takes the result modulo the loaded descriptor count, scans cyclically to the next set state byte, clears it, and stores 3,000 at DS:005C.

The call-reference audit found one additional dormant consumer at 0x649F. While flag 36 and the DS:005C timer established by unused opcode 0x8B are nonzero, each status refresh subtracts the current batched timer delta, calls 0xE966, and uses the result’s low two bits as X/Y flip flags for zero-based STUFF.ART frame 27 at (10,10). The controller invokes this refresh before and after the scene VM with the same elapsed delta, so an already-active timer normally consumes two values per update. A refresh that expires the signed timer still draws, then clamps it to zero; clearing flag 36 freezes the timer and suppresses the draw. No shipped scene executes opcode 0x8B, so this path does not alter ordinary-game call ordering.

Portable deterministic replacement

The comparison launcher replaces both the self-contained DOS generator above and the two separate coordinate-indexed reads used by opcodes 8E and 91; it does not merely hold the clock seed fixed. tools/patch_deterministic_rng.py first reconstructs the verified unpacked MZ, then applies four length-preserving, signature-checked edits at load-module offsets:

The portable recurrence is:

state = (state * 0x6255 + 0x3619) modulo 2^16
value = state >> 1

Both handlers use value & 0xFF. The multiplier is one modulo four and the increment is odd, so the state period is all 65,536 values. The patch fits in place, overlaps no relocation, preserves the original calling convention, and requires no code cave. It is a deliberate comparison/reference patch rather than a claim about the original executable’s implementation.

Command-line parser

The parser in main lowercases the option letter and handles exactly the six switches described by MANUAL.TXT:

An argument without a leading hyphen replaces the DDGAMES save prefix and implements the manual’s per-player name/path option. An unknown switch calls the game’s message path with Huh?.

Text export

Function 0x5F92 opens the requested file in text-write mode. It parses the game’s record tags and writes labeled sections. Direct bit tests recover the full -gXX mask:

The routine writes the heading CAPTAIN BIBLE IN DOME OF DARKNESS, iterates the available records/buildings, and uses Microsoft C fread/write and text stream helpers. This is implementation evidence for the manual’s export feature rather than merely a string search. The text-format chapter documents the extensionless verse indexes, companion DDL* streams, loader, inspector, and complete QEMU export validation.

Save files

The default player prefix is DDGAMES; a non-option argument replaces it. The .SV0 index is nine 27-byte label buffers, normal states are .SV1 through .SV9, and F10/F9 use the independent .SVQ state. Static copy direction separates checkpoint and live fields in each fixed 2,752-byte state. The scalar fields include translation, music, effects, and checkpoint/live text-bank values; the 66 ten-byte descriptors connect exactly to the recovered text resources. The save-game format chapter gives the full 15-block layout, filename logic, supplied-file comparison, error behavior, and reproducible inspector.

Input and hardware support

0x90D4 uses BIOS video interrupt 10h functions 1A00h and 12h to classify the display adapter. Startup requires return value 2 and otherwise prints VGA not detected.

0x8E0A checks interrupt vector 33h and calls the mouse reset function. Functions at 0x8D50 and 0x8D5D show and hide the mouse cursor. 0x8D79 reads mouse motion and buttons, clamps coordinates to 320×200, and accumulates button press/release bits. The event combiner at 0x7BED merges this with the keyboard path and returns internal event codes used by 0x875D, including Escape, Enter/click, pointer movement, and the four extended arrow codes. The position belongs to this persistent input subsystem, so scene loading and New Game do not reset it.

The independent startup framebuffer comparison isolates the cursor’s exact 19 changed pixels at center (160,100): 16 palette-index-1 crosshair pixels at axis offsets 3 through 6, and a three-pixel palette-index-15 upper-right shadow. This live overlay is separate from ART resources and is drawn above scene and interface output.

The keyboard wrapper tests BIOS interrupt 16h service 01h and consumes an available word with service 00h. It therefore receives BIOS typematic entries for a held key rather than maintaining a game-specific repeat timer. Every repeated word follows the same menu or gameplay dispatcher as its initial key press.

Converter 0x0010 returns a nonzero BIOS ASCII byte directly and otherwise adds 80h to the BIOS scan byte. This preserves modifier distinctions that a host adapter cannot infer from the physical key alone: Shift+Enter is still 0Dh, Ctrl+Enter is 0Ah, Alt+Enter is extended, and Alt+Escape is extended while the plain, Shift, and Ctrl Escape forms remain 1Bh.

The executable consequently has no separate keypad dispatcher. BIOS keypad Enter produces the same Enter value; navigation-mode keypad keys produce the same Home, End, arrow, and page scan values; and numeric-mode keypad keys produce printable digits or punctuation. Shift reverses the effective Num Lock state before those BIOS values reach converter 0x0010.

The executable also contains wrappers around DOS interrupt 21h, BIOS video interrupt 10h, keyboard interrupt 16h, and a loaded-driver interface on interrupt 66h. The sound-driver chapter assigns all 34 CD 66 sites to DIGPAK or MIDPAK services and records their register contracts.

Installation lock file and sound drivers

Startup reads all four bytes of SOUND.5 into a local structure. The fields are installation policy rather than sound-hardware selection:

The supplied file is 01 00 00 00: translation value 1, forced no-mature mode, and no installation-level combat restriction. This also explains why -b, -t, and -c cannot relax installation locks: startup preserves an already selected command-line translation and ORs the two restriction flags.

The no-mature flag does not remove runtime Bible descriptors. Map loader 0x034F uses it to clear connected kinds 1 through A when either cell parameter is at least E0; exporter 0x5F92 separately skips descriptors whose selector is at least E0.

The following four files are independent driver components loaded into far memory. SETSOUND.BAT records their original configured names:

The dynamic trace confirms that load_file_into_far_memory at 0xACDA opens each file, measures it with seek calls, allocates its paragraph-rounded size, reads it in chunks, and closes it.

Main resource archive

The lookup routine at 0x99AB uppercases the requested base name and extension, scans an in-memory table in 24-byte steps, seeks the persistent DD1.DAT handle to the record’s 32-bit offset, and verifies the two-byte GC payload signature. The loader at 0x97D0 then selects either the raw far-copy path at 0x9BEF or the dictionary decoder at 0x9CA4 from the record marker.

The latter initializes 256 literal dictionary entries, reconstructs codes from groups of low bytes plus high-bit plane bytes, and expands prefix/suffix chains through 0x9D98. Static reconstruction plus extraction of every declared member establishes the full directory and compression format; see the dedicated DD1.DAT chapter.

Palette and artwork rendering

All PAL resources are raw 256-entry VGA DAC tables. The BIOS palette path at 0xA017 uses video function 1012h; the retrace-synchronized path at 0xA032 writes the same six-bit RGB triplets through ports 03C8h and 03C9h.

Every ART frame has a 12-byte descriptor containing signed X/Y origins, unsigned width/height, and a 32-bit pixel offset. The direct frame routine at 0xB99C multiplies the requested index by 12, reads width at offset 4, height at 6, and the far pixel displacement at 8. The pixel body is row-major and eight bits per pixel. Low-level blitters provide both opaque copying and an index-0 transparent path. The graphics-format chapter records validation of all 143 resources and the exact QEMU framebuffer comparison.

Scene bytecode interpreter

The 62 BIN members contain scene programs interpreted by 0x451B. The routine reads opcodes 0x01 through 0x91 and dispatches through a 145-entry table at 0x59AB, containing 134 distinct handler addresses. Shared readers at 0x3A1E, 0x3A30, and 0x3A64 consume bytes, little-endian words, and pointer-capable strings from a far resource cursor; four resource-name handlers use separate inline-only string loops. An independent control-flow audit recovers the operand layout and dispatch effect for all 145 commands. Of those, 122 occur across 25,829 decoded commands.

initialize_scene at 0x6631 appends .BIN, loads the resource, and starts the interpreter at file offset zero. update_scene_threads at 0x7997 resumes stored file offsets. Directly identified handlers load .ART and .PAL members, select XMI music, change scenes, manage timing, manipulate variables, and implement absolute jumps, calls, and returns. The dedicated scene-bytecode chapter documents the complete structural schema, startup sequence, mixed code/data regions, inspection tool, and QEMU memory check.

Unibot and final sequence

The final programs form a fully recoverable script state machine. GANTRY mirrors seven victim-rescue flags into seven crew-present flags; CP1 counts them and refuses departure until all seven are aboard. ROBOT clears the five powerups, initializes the Unibot position and heading, and enters CP2.

The 256-byte trailer of CP2.BIN stores a reciprocal 16-node road graph with four compass headings, seven pylon endpoints, one Tower endpoint, node types, and lower-right-map coordinates. Seven persistent variables record pylon rescues. An incomplete pylon encounter or premature Tower assault enters OVER; all seven allow the alternating FACE/CP3 confrontation. Its correct study response reaches KABLAM and WIN, while the wrong response sets state 9 and reaches OVER. A separate flag makes the road-network Annoy Cyber’s verse loss a one-time event. The dedicated Unibot chapter gives every table entry, variable, branch, and reproducible inspection command.

Scene display objects

Scene programs append up to 100 ten-byte display records at DS:A2AC, with the current count at DS:00E2. Direct object records contain signed X/Y, 8.8 scale, an ART-slot/visibility byte, one-based ART frame, render flags, and a type byte. Other types connect animation sequences or command threads to the same update list. The ART-slot high bit hides an object; two low bits in the separate flags byte flip its axes.

The reset function at 0x3AD2 releases every render slot and clears the count when changing scenes. The update function at 0x3AFF dispatches records by type, and 0xBCAC submits direct objects to the ART renderer. A visible, silent QEMU capture of LOGO.BIN contained 13 records whose type order and direct fields exactly match all 13 linear display definitions in the script. The dedicated scene-display-object chapter documents the layout, commands, QEMU addresses, inspector output, and boundary between display state and scripted gameplay state.

Combat animation and actions

The seven COMBAT*.BIN programs contain 214 animation definitions with 2,596 nine-byte steps and 27 selectable action targets. Animation runtime records begin at DS:6EBA with a 12-byte stride; they retain the first/current BIN step offsets, timing, linked slot, mode, and render slot. Dedicated opcodes start, link, stop, wait for, and branch on those animations.

Selectable actions use a separate ten-byte table at DS:480E. Each record contains an absolute BIN target, screen coordinates, a selector-string offset, and an active byte. The first ART resource in every combat is COMBTAGS; rendering its four frames identifies selectors .11 through .14 as ATTACK, DEFEND, RETREAT, and COMBAT. Pointer and keyboard paths search active targets and start a BIN scheduler slot at the selected target.

Random branches, the Sword and Shield flags, opcode-0x81 faith loss, and map/progression changes live in script state. Every Retreat target jumps around the victory mutation into a shared exit. Six ordinary combats mark the current map cell as kind 0xB; the exceptional guard program uses kind 0xA, copies parameter B to A, omits faith loss, and never sets the combat-active flag. COMBAT7 implements the Zapper reward by ending a meter flash at faith 10,000. No enemy-health field exists in the display or action-target records. The combat-runtime chapter documents the tables, commands, action outcomes, shared epilogue, and remaining dynamic validation boundary.

Conversation and choice flow

Scene scripts construct dialogue menus in a separate transient table. Opcode 0x45 clears the table, opcode 0x44 appends a six-byte target/text record, and opcode 0x46 presents the menu and suspends the scene thread. The record count is at DS:B428; records begin at DS:B116 and contain an absolute BIN target followed by a far pointer to the inline choice text. The generic text menu at 0x2556 returns the selected target through DS:7CBA, allowing the interpreter to resume directly at the chosen branch.

That renderer builds one 16-byte input record per wrapped row. The record’s first two words are (text_x + 72,row_y + 2), while words at offsets 8 and 10 place the SELECT sprite to the left or right of the text. Selector 0x6CE5 calls the approximate-distance helper at 0x3315, accepts the strictly nearest record at a distance no greater than 100, and rejects a nearest record whose marker byte at offset 15 is FE. The same machinery serves choices, Game Options, slot lists, and confirmation menus.

Dialogue opcodes 0x14, 0x48, and 0x4E share a presentation handler but serve distinct channels dominated by the adversary, other characters, and Captain Bible. Corpus analysis finds 40 choice definitions and 597 dialogue commands. A visible, silent QEMU capture of the five-choice BOSS.BIN menu matched every target and far text pointer from the static decode. Selecting the final row wrote target 0x095C and displayed the dialogue stored at that exact branch.

Conversation scripts also invoke the study-Bible browser. Opcode 0x7D selects a victim-conversation, paraphrase, or cyber-lie prompt, and opcode 0x49 requests the browser. A correct descriptor sets state flag 0x14; leaving without the expected match sets 0x15. The conversation-flow chapter documents the command lifecycle, runtime structures, BOSS memory correlation, study integration, and remaining boundaries.

World-map state

The archive contains 21 exact 768-byte map resources: levels A through G for Easy, Normal, and Difficult modes. Opcode 0x78 constructs their names and loads one into a mutable row-major 16×16×3-byte grid. Address calculations in the executable use 48*y + 3*x; the first cell byte contains independently used connection and location-kind nibbles, followed by two parameters.

The map screen also consults a 16-word exploration bitmap. Scene commands can process the current cell, mutate each cell field, normalize location kinds, and mark coordinates explored. The supplied SV3 and SV4 grids match CE.MAP except for four explained field changes. The dedicated world-map chapter gives the format, opcodes, save correlation, and inspection tool. It also decodes connection directions, five room classes and orientations, the seven hallway Cybers, Scripture stations, hidden Spider triggers, cleared encounters, level exits, and locked-room actions while keeping three environmental kinds explicitly unresolved.

Script state and progression

The two 200-byte save blocks are checkpoint and live copies of 100 signed script-variable words. BIN commands encode variables as even byte offsets within this block and provide copy, immediate assignment, signed comparison, branching, arithmetic, increment/decrement, and bitwise operations. Static handlers and complete-corpus validation identify 39 variables used by that core family.

Words 3 through 10 double as a 128-bit state-flag bank. Dedicated scene commands branch on, set, and clear flags. The executable rebuilds transient map flags 0x00..0x2F, while flags 0x30..0x34 are the five powerups and seven victim scenes set distinct rescue flags 0x3A..0x40. Variable 21 is faith on a 0–10,000 scale; opcode 0x81 applies difficulty-scaled loss. Separate text-descriptor state bytes connect obtained or completed text records to scene branches. The script-state chapter documents the complete recovered families and remaining semantic boundaries.

Digital effects and XMIDI music

Opcode 0x57 passes an effect number and rate to 0x417F. That routine formats D###.ABT, loads it from the archive, allocates the decoded sample count from the first word, calls the built-in decoder at 0x92E0, and submits the resulting PCM state to the DIGPAK interface on interrupt 66h.

The decoder implements absolute samples, run-length commands, and packed one-, two-, or four-bit adaptive delta blocks. Its helpers at 0x93BE, 0x94CB, and 0x956E add signed table deltas to the preceding sample and clamp to unsigned eight-bit PCM. All 41 resources decode exactly to 412,282 samples at 9,000 Hz. A QEMU breakpoint immediately before playback captured D003.ABT’s live 9,064-byte buffer; it is byte-identical to the host decoder.

Music function 0x4091 chooses MUS###.XMI or IBM###.XMI. All 32 resources are IFF/XMIDI files with FORM XDIR, one INFO sequence count, CAT XMID, and one FORM XMID containing TIMB and EVNT. The audio-format chapter documents both formats and their reproducible tools.

Startup initializes the family word at 0x76E8 to zero, then compares SOUND.2 offsets 0xD2..0xD4 with IBM at 0x35C3..0x35DE. A match changes the word to one; play_music_resource uses that word to choose the filename prefix. The supplied Sound Blaster Pro FM SOUND.2 has 00 20 02 there, so this installation selects the MUS family.

Checked symbol catalog

The complete checked map now contains 140 named functions, 26 named BIN handlers, and 9 data symbols. Each entry has its own evidence statement and a Verified or High confidence rating. The dedicated symbol-map chapter defines those levels, summarizes subsystem coverage, documents address translation, and gives commands that check the catalog against both analysis/cb.rz and Rizin’s resolved handler addresses.

Symbol and Function Map

The checked symbol catalog is analysis/symbol-map.tsv. It records every project-assigned name in analysis/cb.rz, rather than only a selected list of interesting routines. The current map contains 283 entries:

All offsets are 16-bit linear offsets from the DOS load-module base. Add 0x200 to obtain an offset in CB_UNPACKED.EXE. For the recorded QEMU load at segment 0627, add physical base 0x6270. Initialized data references also require the documented DS base translation; the executable chapter gives the complete address convention.

Confidence scale

Each catalog row has its own evidence statement and one of these confidence levels:

“Verified” does not mean source-level names were recovered: the executable has no debug symbols. It means the descriptive name has an independent check beyond recognizing the disassembly. “High” is still strong enough to load into Rizin. Unresolved candidate routines remain unnamed rather than being promoted to the catalog with speculative labels.

Coverage

The catalog groups evidence by subsystem. Counts include functions, handlers, and data symbols:

The TSV preserves one concise piece of evidence per individual entry. For example, decode_abt cites both exhaustive decoding and the live D003 PCM match, while normalize_map_cells remains High because its loop is clear but has not received an independent runtime capture.

Reproducible audit

Validate the catalog against every afn, fr, and named data flag in the Rizin script:

tools/inspect_symbol_map.py

The command rejects missing or extra names, changed function/data offsets, duplicate names, duplicate kind/offset pairs, unknown confidence labels, and empty evidence. It can also filter the readable listing:

tools/inspect_symbol_map.py --kind function
tools/inspect_symbol_map.py --confidence verified

BIN handler addresses originate in Rizin’s switch analysis, because cb.rz renames generated case flags rather than declaring those addresses directly. Regenerate and verify that final layer with:

rizin -q -b 16 -e scr.color=false -i analysis/cb.rz \
  -c fl build/analysis/CB_UNPACKED.EXE \
  > build/analysis/cb-flags.txt
tools/inspect_symbol_map.py \
  --rizin-flags build/analysis/cb-flags.txt

The current Rizin run resolves all 134 distinct handlers at the cataloged offsets and emits no script errors. Archive-backed unit tests enforce the 140/134/9 counts and exact catalog-to-script coverage. The independent opcode audit additionally reads the dispatch table and handler control-flow graph from Rizin during its dedicated test.

Boundaries

Rizin’s recursive analysis currently proposes roughly 340 functions, but several candidates cross jump tables or data. The catalog therefore does not claim that 140 functions are the whole executable. They are the complete set of names supported by the reverse-engineering evidence so far.

The 134 handler names cover every distinct implementation needed to describe all 145 opcodes. The repeated addresses are the paired scaled-object command, five no-op values, three dialogue variants, four edge-transition callbacks, and the paired palette-loading command. Unused handlers keep low-level names when shipped scripts cannot establish a more specific gameplay role.

Dynamic Analysis

QEMU tracing workflow

tools/qemu_dos_trace.c is a QEMU TCG plugin that observes BIOS keyboard interrupt 16h, DOS interrupt 21h, mouse interrupt 33h, and sound-driver interrupt 66h without changing the game executable or disk image. Build and run it through the normal launcher:

./run.sh --trace-dos

Trace mode keeps the required Cocoa display visible, uses QEMU’s silent audio backend, and creates these ignored artifacts:

build/qemu-trace/qemu_dos_trace.so
build/qemu-trace/dos-calls.log
build/qemu-trace/monitor.sock

The plugin filters on the current game code segment 0627 and remains dormant until the reconstructed entry point 0627:CB5C executes. That prevents an earlier FreeDOS program that temporarily occupies the same segment from polluting the trace. Each call record contains its exact CS:IP, physical linear address, live AX, argument registers, data segments, and an escaped pathname when the DOS API uses one. A paired return record preserves AX, the other general and segment registers, and carry.

QEMU 11.0.2 represents the first x86 register’s opaque plugin handle with value zero. The tracer tracks descriptor presence separately instead of mistaking that valid EAX handle for a missing register. It retains static MOV AH/AX inference only as a fallback for targets that do not expose EAX. Trace mode also sets one-insn-per-tb=on; without it, plugin register reads describe the beginning of a longer translation block rather than the interrupt boundary.

For a focused instruction-boundary memory probe, invoke the plugin directly with a code offset and a data-segment range:

-plugin build/qemu-trace/qemu_dos_trace.so,\
log=build/qemu-trace/probe.log,cs=0x627,start=0xCB5C,\
probe=0x5913,probe-offset=0x008A,probe-size=0x0100,calls=off

probe is an IP within the filtered code segment. probe-offset and probe-size select up to 4,096 bytes from the live data segment. Each PROBE record contains the instruction-boundary registers and a hexadecimal memory snapshot. calls=off suppresses interrupt-call tracing for faster probes; the default remains calls=on. This mode produced the exact opcode 8E and 91 DOS coordinate-indexed-object-overrun captures documented in the scene-bytecode chapter.

Preserved startup capture

The verified capture ran from process startup into the first story text. The monitor stopped at:

This independently repeats the earlier load and data segment values. The screen contains the opening narration beginning “There once was a city far from us in place and time,” establishing the visible runtime point. QEMU also saved the first MiB of physical memory to build/qemu-trace/startup-physical-1m.bin.

Comparing the captured memory with the independently unpacked and relocated load module again produces the exact 0x905A-byte static prefix and 5,612 runtime differences across 75,264 bytes, matching the earlier title capture.

The trace contains 195 completed game DOS calls. Its high-level file timeline is:

All listed returns have carry clear. The path sequence is runtime evidence, not a prediction from embedded strings.

Sound-driver correlation

SOUND.5 is read in requests of one byte and three bytes. Each driver file is then opened, queried, measured with three seek calls, allocated in DOS memory, read in chunks, and closed. The observed allocation request exactly matches the file size rounded up to a 16-byte paragraph:

This connects the static far-pointer loader at 0xACDA with the DOS API calls inside the Microsoft C low-level I/O routines. The trace supports the names libc_lowio_close (0xDA82), libc_lowio_seek (0xDAA2), libc_lowio_open (0xDB1C), libc_lowio_read (0xDCC0), and libc_lowio_write (0xDD9E).

Live decoded effect capture

For an independent codec check, launched QEMU with the same visible Cocoa display and silent audio devices, plus its GDB remote stub. A breakpoint at physical 0xA499 stopped Captain Bible at 0627:4229, after D003.ABT had been decoded and immediately before its state was submitted to interrupt 66h.

The state at DS:A0DE pointed to 5A45:0000 and declared 9,064 samples at 9,000 Hz. The 9,064-byte physical-memory dump from 0x5A450 exactly matches the independently implemented ABT decoder. Both have SHA-256 ca97ad22acf3cc39d078b619168fa026deb1606082999bfb8b9a1aac4957422b. The dedicated audio-format chapter records the codec and conversion tool.

Main container correlation

Startup first opens and closes DD1.DAT through normal stream setup, then opens it again as DOS handle 5. Subsequent resources cause seeks and reads on that handle; no DOS open is made for the static resource name RUN.ART. This is direct evidence that names such as RUN.ART refer to members indexed inside DD1.DAT, not sibling files in the DOS directory.

DDLC, by contrast, is opened as a separate DOS pathname twice during the captured interval. Later static and format analysis identifies it as tagged companion text bank C; DDLA through DDLG and DDLR use the same recovered record stream. The direct opens are therefore runtime confirmation that DDL text lives beside the main container, while the extensionless verse indexes live inside DD1.DAT. The text-format chapter documents their exact join.

Focused input and save capture

A later visible, silent QEMU run added int 16h and int 33h to the same instruction-boundary tracer. The game polls BIOS keyboard service 0101 at 0627:E9DC, mouse motion service 000B at 0627:8D8A, and mouse position/buttons service 0003 at 0627:8DCD. These sites independently match the statically named input wrappers.

Moving the monitor mouse changed the returned position from X/Y 0140:0064 to 01D0:0088, or (320, 100) to (464, 136). Holding the left button then produced repeated service-0003 returns with BX=0001 at the new position. This proves that the guest driver state reaches the game’s own polling path, not merely that QEMU accepted host events.

F10 produced BIOS scan/ASCII word 4400 first through the non-consuming service and then through service 0000. The next DOS activity opened the existing DDGAMES.SV0, then created and wrote DDGAMES.SVQ. After QEMU stopped, the quick save was exactly 2,752 bytes with SHA-256 5e329e21f32d2e6c3e564d3a3ad717ab07ad55aaedde2587725756945597e43f. The before/after .SV0 hashes were identical, confirming that quick save does not rewrite the normal-slot label index.

The normal in-game Escape/Save Game path ended name entry with BIOS word 1C0D and then rewrote the 243-byte DDGAMES.SV0 followed by the selected 2,752-byte DDGAMES.SV2. The low-level writes follow the recovered state layout: 200-byte snapshot and live blocks, 66 flags, 660 bytes of text descriptors, four 20-byte strings, five words, and two 768-byte maps. Parsing the copied slot with tools/inspect_save.py recovered the expected settings, bank C, INTRO/seg scene strings, and named script-variable state. This connects BIOS input, the menu path, write_save_state, Microsoft C low-level I/O, and the two on-disk formats in one run.

Adding more interrupt vectors exposed a tracer bookkeeping bug: an interrupt instruction inside DOS could have the same registered return callback active while a game call was pending. Return records from the affected capture are therefore not used for DOS-result claims; its call-entry paths and write arguments remain valid. The plugin now stores the pending call’s exact linear return address and ignores callbacks at every other CS:IP. A fresh bounded run recorded 119,824 paired calls—39,903 keyboard, 115 DOS, and 79,806 mouse—with no false DOS-internal return.

Representative interactive coverage

The visible Cocoa session exercised and captured these distinct paths:

Function keys were sent only after normal gameplay began; an earlier F1 during the introductory sequence advanced into the difficulty selector instead of opening the Bible. The distinction is useful evidence that the same input is routed by scene state rather than handled as an unconditional global hotkey. The combat chapter records the controlled scene-entry provenance and table dump in detail.

File Inventory

All supplied game files have the host-interpreted timestamp 1996-12-24 23:32:00 +0700. The macOS .DS_Store file is host metadata and is excluded. file(1) descriptions are heuristic; in particular, its “Arhangel archive” label for DDLE is not treated as a format identification.

Programs, data, and support files

Supplied saves

SV6 and SV8 are byte-identical. SV0 is the nine-record slot index; SV1 through SV9 use the fixed state layout documented in the save-game format chapter.

DD1.DAT Resource Container

Container directory

DD1.DAT is the game’s main named-resource archive. The supplied file is 1,866,068 bytes and has SHA-256 a395fcf9f19d655a6440b5b8ab213983eb7d34a99810b763a9c95360f98f9562. Its first little-endian word is the member count, followed immediately by fixed 24-byte records:

The file declares 369 records. Consequently, the directory occupies 2 + 369 * 24 = 0x229A bytes, exactly the offset of the first payload. Payloads are contiguous in directory order, and the last one ends exactly at the end of the container. Every payload starts with ASCII GC; lookup code at 0x99AB seeks to the recorded offset and verifies this word before returning the member.

The recovered population is:

There are 38 raw members containing 203,303 expanded bytes and 331 compressed members containing 5,340,520 expanded bytes. The complete archive expands to 5,543,823 bytes. Three names occur twice: GANTRY.PAL, HOLEA.ART, and NG. Each repeated pair also has identical extracted content, but its two directory slots are retained rather than silently deduplicated.

Representative records connect the static directory to the QEMU trace:

The startup trace’s seek to 0x24DA and its 431-byte stored and 640-byte expanded values match LOGO.BIN exactly. RUN.ART, which appears as a static name passed to the art loader, is likewise present only as archive member 82; DOS never opens it as a separate path.

Payload encodings

For marker 0, the bytes following GC are the resource verbatim. The stored size is therefore always the expanded size plus two.

Marker 1 selects the dictionary decoder at load offset 0x9CA4. It is an LZW-family scheme with an unusual byte-plane representation for code bits:

1. Dictionary codes 0 through 255 are literal bytes. Each has a prefix of -1 and a suffix equal to the byte value.
2. At the start of a dictionary pass, the decoder reads and emits one literal, stores it as the prefix of entry 0x100, and sets its code counter to 0x101.
3. It reads the next code, saves that code as the prefix for the following dictionary entry, recursively emits the referenced phrase, and saves that phrase’s first byte as the suffix of entry counter - 1. This one-slot offset implements the normal LZW special case where the current phrase can refer to the entry being completed.
4. When the counter reaches 0x1001, the dictionary pass restarts with a new literal. There is no clear code in the stream.

Codes do not form a conventional contiguous bitstream. Every group of up to eight codes stores all required high-bit planes first, followed by the eight low bytes. Bit 0 of each plane byte belongs to the first code in the group, bit 1 to the second, and so on. One plane supplies code bit 8, the next bit 9, up to four planes for the 12-bit dictionary range. The number of planes grows as the counter passes 0x100, 0x200, 0x400, and 0x800.

The implementation in tools/extract_dd1.py follows the assembly’s precise prefix/suffix update order. It also rejects truncated streams, undefined codes, dictionary cycles, over-expansion, unused compressed bytes, invalid directory padding, noncontiguous payloads, bad GC magic, and trailing container data. Regression outputs include:

Extractor usage

List the directory:

tools/extract_dd1.py --list CB/DD1.DAT

Extract one uniquely named member:

tools/extract_dd1.py \
  --extract RUN.ART \
  --output build/dd1/RUN.ART \
  CB/DD1.DAT

Extract all members with their directory indices preserved:

tools/extract_dd1.py --extract-all build/dd1/all CB/DD1.DAT

The all-members form creates names such as 082_RUN.ART; the numeric prefix prevents duplicate archive names from overwriting one another. A duplicate can also be selected explicitly with --index and --output.

Executable routines

These names refer to offsets within the unpacked load module, using the same address convention as the rest of this book.

Palette and Artwork Formats

PAL: VGA DAC entries

Every one of the 37 PAL members is exactly 768 bytes: 256 consecutive red/green/blue triplets. Each component is in the inclusive range 0 through 63, matching the VGA’s six-bit DAC. There is no header. The host renderer expands a component with bit replication, eight_bit = (six_bit << 2) | (six_bit >> 4), so both endpoints remain exact.

The executable confirms this interpretation in two independent paths:

• vga_load_palette_bios at 0xA017 invokes video BIOS function 1012h with 256 entries, start index 0, and a far pointer to the triplets.
• vga_write_palette_range at 0xA032 waits for vertical retrace through port 03DAh, writes a starting index to 03C8h, then sends three unmodified bytes per entry to 03C9h.

There are 35 unique palette payloads. The two copies of GANTRY.PAL are identical, and RICH.PAL is identical to 1.PAL. The game also changes palette ranges at runtime for fades and color cycling, so a base PAL preview does not necessarily reproduce every animated color at a particular instant.

ART: descriptors and indexed pixels

An ART member begins with one or more fixed 12-byte frame descriptors. It has no explicit descriptor count; the first descriptor’s pixel offset is also the end of the descriptor table, so the count is first_offset / 12.

Each descriptor is followed indirectly by exactly width * height bytes of row-major, eight-bit palette indices. Pixel blocks are contiguous in descriptor order and occupy the rest of the resource without padding.

This layout validates without exception across all 143 ART members:

Signed origins matter. For example, RUN.ART frame 0 has origin (-28, -5) and size 46×61; these values position a running sprite relative to an entity, not directly on the screen. LOGO.ART demonstrates a multi-piece screen:

The object renderer treats the 8.8 scale word as a divisor. It computes frame dimensions and origins as value * 256 / scale, so 0x0200 halves artwork. For a horizontal reflection it computes anchor_x - scaled_origin_x - scaled_width; it does not reuse the normal anchor_x + scaled_origin_x position. This is directly visible in LOGO.BIN, which reflects frame 3 at X=303 to form the left half of the dome.

The descriptor itself does not specify transparency. The draw-call flags choose the copy operation. blit_rect_transparent_zero at 0xA106 tests each source byte and advances the destination without writing when the index is 0. blit_rect_opaque at 0xA136 copies every byte. The fast VGA copy at 0xA0C9 copies rows into segment A000h using a 320-byte screen stride.

Layering uses the stable render slot allocated by the scene’s mixed display list, rather than controller update order. The compositor at 0xC000 walks those slots in increasing order. This lets the direct LOGO.BIN dome pieces at display indices 7 through 9 occlude the moving actor at index 4, producing the oval entry and exit mask without a dedicated ellipse-clipping routine.

STUFF.ART: font and interface labels

The game does not obtain its dialogue font from the video BIOS. Startup calls the routine at 0xAE42, which loads STUFF.ART, retains frame 0’s pixel pointer and width, and constructs a 95-entry glyph-offset table at DS:A1E8. Frame 0 is a 257-by-14 atlas containing only source values 0, 1, and 2. The first seven rows hold bytes 21h through 60h; the offset resets to atlas row 7 for byte 61h (a) and continues through byte 7Fh.

The proportional widths live in the executable at DS:3462, indexed by character minus 21h. Renderer 0xAF36 copies exactly seven scanlines and advances by the glyph width plus one. Space and control bytes advance three pixels without copying. The modal compositor later doubles each logical pixel in both axes, yielding seven-row glyphs at 640-by-400 output with a 16-output-pixel line pitch. This explains why a fixed 5-by-7 host font drawn at one horizontal pixel per source column appeared narrow and tall.

The text-object renderer at 0xBE7E remaps the atlas values through a three-palette-index style. The ten recovered triplets are:

1:  1,  7,  3    2:  1, 37,  4
3: 16, 15, 17    4: 15, 84, 84
5:  0, 64, 70    6:  0, 32, 37
7: 15, 86, 90    8: 15, 74, 69
9: 15, 32, 36   10: 15,  1,  8

The live BOSS capture confirms style 2 for normal dialogue: its glyph pixels are framebuffer indexes 1, 37, and 4. State 1 uses style 1 for unselected choice rows and style 2 for the selected row. Character and Captain Bible messages enter state 2 and use style 2; adversary messages enter state 7 and use style 7. The Computer Bible prompt above the book also uses style 7 for an L cyber lie, style 9 for a P paraphrase, and style 10 for * victim-conversation text.

Several interface captions are complete indexed sprites in the same resource, including frame 16 GET VERSE, frame 28 SELECT, frame 29 CONTINUE, frame 30 UNLOAD, and frame 31 COMPUTER OFF. Their descriptors include the signed origin used to overlap the associated panel or row. In particular, SELECT is (-12,-3,24,7) and CONTINUE is (-17,-3,35,7). These sprites include their own letters and borders and are drawn with index zero transparent. Transparent-pixel matching against the preserved VGA dumps finds one unique placement for each: CONTINUE at logical top-left (220,81) with anchor (237,84), and SELECT at (154,69) with anchor (166,72).

Frames 7 through 10 are the pointer-hover navigation arrows Up, Down, Left, and Right. Their descriptors are respectively (-5,-1,11,10), (-5,-9,11,10), (0,-5,10,11), and (-9,-5,10,11). The selector-overlay routine draws one of these transparent frames at the active target’s authored logical coordinate.

The top status row is another fixed subset of STUFF.ART. Frame 4 is the Computer Bible cross at descriptor origin (4,1), frame 32 is the Map control at (23,1), frames 22 through 26 are descending Faith-meter states at (44,3), and frames 17 through 21 are Sword, Shield, No Trap, Candle, and Flight. Frame 11 is the disk indicator at (297,1). The positive origins are already logical screen positions, so the UI draws these frames at anchor zero and uses their nontransparent bounds as pointer targets.

Zero-based frame 27 is a dormant transient-status overlay. Unused opcode 8B starts its timer; the status renderer anchors the frame at logical (10,10) and derives its X/Y flip flags from the shared random source. See Runtime random source for the controller cadence.

QEMU framebuffer validation

INTRO.ART consists of one descriptor (0, 0, 320, 200, 12). Compared its 64,000 pixel bytes directly with physical VGA memory at 0xA0000 in the preserved startup dump. Of those bytes, 63,648 are identical. Every one of the 352 differences falls in one of two known live overlays visible in the QEMU screenshot:

After excluding those rectangles, the extracted resource and live VGA memory are byte-for-byte identical. This establishes the descriptor dimensions, row-major order, one-byte pixels, and mode-13h screen placement independently of visual interpretation.

The runtime screenshot also maps each used pixel index to a consistent RGB value. Most static entries match TITLE.PAL; entries 243 through 254 differ because the opening text cycles that palette range while the story is shown.

Rendering tool

tools/render_art.py validates the complete descriptor and pixel layout and requires a separately extracted PAL for rendering. List descriptors with:

tools/render_art.py build/dd1/all/003_LOGO.ART --list

Composite all frames at their signed origins on a 320×200 canvas:

tools/render_art.py \
  build/dd1/all/003_LOGO.ART \
  --palette build/dd1/all/002_LOGO.PAL \
  --canvas --scale 2 \
  --output build/graphics/logo.png

Render one animation frame or all frames separately:

tools/render_art.py \
  build/dd1/all/082_RUN.ART \
  --palette build/dd1/all/025_TITLE.PAL \
  --frame 0 --scale 2 \
  --output build/graphics/run-0.png

tools/render_art.py \
  build/dd1/all/082_RUN.ART \
  --palette build/dd1/all/025_TITLE.PAL \
  --all-frames build/graphics/run-frames \
  --scale 2

Individual frames use index 0 as PNG transparency by default, matching the color-keyed game path. --opaque-zero preserves it as a visible palette color and selects opaque composition. --width and --height change canvas size; --scale applies nearest-neighbor integer scaling.

Full-screen gallery

Exactly 11 frames have origin (0, 0) and dimensions 320×200. The scene programs select the following palettes before loading them:

tools/render_fullscreen_gallery.py discovers those frames directly from the archive, infers each ART-to-PAL association from the resource-loading commands in the BIN scene programs, and labels every image with its archive index, resource name, frame number, and palette. Generate the native-pixel contact sheet with:

tools/render_fullscreen_gallery.py \
  CB/DD1.DAT \
  --output build/graphics/full-screen-gallery.png

Pass --scale 2 for a nearest-neighbor enlarged sheet. KABLAM1.ART appears almost black under KABLAM.PAL, but is not an empty image: it contains 16 distinct pixel indices and acts as a base for later overlay frames.

Executable routines

Offsets use the unpacked load-module convention documented elsewhere in this book.

Scene Bytecode

Overview

The 62 expanded BIN members are the game’s scene programs. Most are pure bytecode streams with no header. They select art and palettes, start music, change scenes, update variables, branch, call subroutines, and coordinate animation. The executable’s interpreter dispatches opcodes 0x01 through 0x91 through a 145-entry near-pointer table at load offset 0x59AB.

The operand layout and an evidence-based handler name have now been recovered for every dispatched opcode. Linear decoding identifies 25,829 commands in 64 code regions and uses 122 of the 145 possible opcodes. Names for commands that do not occur in the shipped scripts describe their direct engine effects rather than claiming an unobserved gameplay role.

An independent second pass reads the 145 dispatch pointers directly from the unpacked executable and finds 134 distinct implementation addresses. It walks every handler’s control-flow graph, records all operand-reader calls, and joins the results to the complete shipped corpus. The checked result is analysis/opcode-audit.tsv; tools/audit_bin_opcodes.py regenerates and verifies it.

Runtime model

initialize_scene at 0x6631 appends .BIN to a scene base name, loads that archive member into far memory, installs its base and initial cursor, resets scene-thread state, and calls execute_bin_commands at 0x451B with file offset zero. Later, update_scene_threads at 0x7997 resumes active command streams by passing their saved file offsets back to the same interpreter.

Four words in the data segment hold the current input state:

The interpreter sets its cursor to base + requested_offset, fetches one byte, converts opcode 1 to dispatch index 0, range-checks through 0x91, and calls the corresponding handler. Branch and call targets are absolute offsets within the expanded BIN member, rather than relative displacements.

Three shared operand readers make the encoding unambiguous:

Four other handlers implement their own byte-at-a-time inline string loops: opcodes 0x01, 0x0D, 0x4D, and 0x6D. Those loops do not recognize the 0xFF offset escape. Keeping the two encodings separate prevents an art, palette, or scene name beginning with CP437 byte 0xFF from being misinterpreted as a pointer.

Operand schema

The decoder records each opcode with a compact schema:

The conditional BHs form is used by opcodes 0x11, 0x12, and 0x17 through 0x1A. For example, bytes 11 01 F8 FF E6 01 contain byte 1, signed word -8, and therefore the extra word 0x01E6.

The complete machine-readable table is OPCODE_SCHEMAS in tools/inspect_bin.py. It contains one entry for every value from 0x01 through 0x91; tests extract the resources directly from CB/DD1.DAT and exercise every known code region against that table.

Top-level selector input

The main input dispatcher at 0x875D separates confirmation input from exploration actions with global action-selection word DS:004C. When it is zero, Enter (0x0D) or the primary-button event (0x7E) sets the opcode-64 latch at DS:7CC0. When it is nonzero, those events instead query render slot 0x124, require the current selector index at DS:00EE to be nonnegative, and call the selector activator at 0x851E. A press with no current selector does nothing; it does not leak into the confirmation latch.

ASCII Space reaches the cycling routine at 0x6939 only while action selection is enabled. That routine refreshes the current selector with update_action_selector_overlay, then advances through two tables. Kind zero visits the 16-byte scene-thread records at DS:7DC0; kind one visits the 10-byte opcode-3A records at DS:4810. Exhausting either table wraps into the other. An actor needs its byte at +7 set, while an action needs its byte at +8 set. Both require signed X less than 320 and signed Y less than 200. The successful record writes X and Y+4 to the logical pointer words and calls the overlay updater again.

The four extended arrow events have the same action-selection split. 0xC8, 0xD0, 0xCB, and 0xCD search for selector keys u, d, l, and r while DS:004C is nonzero. While it is zero, the branches at 0x889C, 0x88BD, 0x88F7, and 0x88D7 instead subtract or add eight to the corresponding logical pointer word.

Opcode 02 initializes the scene-thread selector X/Y fields to 30000 and its string pointer to -1; its navigation X/Y live elsewhere in the same record. Opcode 10 installs the on-screen selector anchor and string. Consequently an unlabeled navigation record such as GANTRY’s opening remains clickable through the navigation hit-test, but its untouched off-screen selector fields keep it out of proximity hover and Space cycling.

The standalone Bible routine at 0x1C88 is a blocking top-level interface. It saves action-selection state at 0x1D5F, clears DS:004C at 0x1D66, and services its own input loop before returning. The map, options, save, and status-notice dispatchers follow the same nested-interface model rather than returning to the scene controller on every host frame.

Independent audit

The second pass does not use successful linear decoding as proof of operand width. tools/audit_bin_opcodes.py instead combines five independent views:

1. the exact 145-word dispatch table at load offset 0x59AB;
2. every reachable path through the interpreter’s 1,817 Rizin instructions;
3. calls to the byte, word, and pointer-string readers, plus the four inline string loops and opcode 0x07’s direct nine-byte cursor advance;
4. the handler aliases and per-symbol evidence in analysis/cb.rz and analysis/symbol-map.tsv; and
5. all 25,829 decoded commands in all 64 known code regions.

The audit expands conditional schema BHs into both legal paths, BH and BHH. It also records the dialogue handler’s intentional no-read retry path: while a modal message is active, the command suspends without consuming its p operand; after the modal state clears, it consumes that same pointer and continues. No other handler is allowed an undeclared operand path.

Run the complete comparison with:

tools/audit_bin_opcodes.py

The report records, for every opcode value, the dispatch address, handler symbol and confidence, declared schema, independently observed read paths, script-variable operand positions, use count, resource set, and first shipped site. Twenty-three opcode values are absent from shipped code: 03, 0E, 13, 18, 1B, 2E, 30, 37, 39, 47, 4A, 4B, 4F, 50, 56, 5E, 65, 66, 6E, 6F, 8B, 8F, and 90.

Identified commands

These handler meanings have direct static support from their callees or clear control-flow behavior:

Formerly structural commands

The final unnamed-handler pass connected the remaining 51 opcode values to their consumers. Thirteen of these values never occur in the shipped command regions; their rows are marked unused and rely on static handler behavior. Ten already-named values are also absent, producing the audit’s overall total of 23 unused opcodes.

The movement opcodes share the controller recovered at 0x6F46, 0x7469, and 0x779D. Opcode 0x53 uses the same edge initializer with identical start and end nodes; opcode 0x0A therefore continues waiting until that minimum traversal completes. Opcode 0x54 first compares its operand with the retained desired node. During active interpolation a different operand only replaces that byte. The current edge, timer, pose, phase, and callbacks remain intact, and route search runs again from the reached node after its arrival callbacks. The retained byte starts at 0xFF, persists across scene changes, and is not reset by opcode 0x53.

Navigation callbacks are fresh synchronous command-stream invocations: each one runs through its first yield or return before the dispatcher examines the next matching record. A same-slot callback’s delay does not pause the outer command interpreter that synchronously invoked it; if that outer invocation later yields, its cursor replaces the nested cursor while both delay changes remain accumulated. Initial movement searches, runs the source-node and directional-edge departure callbacks in that order, and then initializes the edge. State-five continuation searches, initializes the edge, and runs the directional-edge then source-node departure callbacks. Completion makes the controller inactive for request purposes before running the directional-edge then destination-node arrival callbacks.

Opcode 0x69 was previously recorded as a one-word instruction. Its handler actually reads an immediate BIN offset and a destination-variable offset. In CP2.BIN, the second word’s low byte happened to be opcode 0x40, so all streams still decoded while eleven destination operands appeared as phantom commands. Correcting the schema reduces the corpus total from 25,840 to 25,829 without changing the set of 122 opcodes genuinely used by shipped scripts.

DOS coordinate-indexed object overrun

The operand source used by opcodes 0x8E and 0x91 is not a MAP field and is not a separately loaded 16×16 resource. Both handlers calculate 16 * map_y + map_x and read from DS:008A. The initialized object at that address contains only 80 bytes, covering rows zero through four:

92 DF 1A 72 01 83 9C E5 00 B8 A8 01 2C F7 E2 AA
64 F3 43 CA 7D 7C 6A 51 37 A3 33 7A 70 1F 8B 4F
98 EF 83 6F 65 41 A3 0F C8 93 80 3F 1F 18 90 6E
AC 5D 3E 31 46 2C 3A 40 4E B1 13 C1 E5 DB 07 CA
5C 05 1A 21 EC D6 65 46 A8 65 B1 B3 AF A1 44 62

The handlers perform no bounds check. Rows five through fifteen therefore alias the initialized data and live globals which immediately follow the 80-byte object. Those aliases explain why a literal 256-byte zero replacement removed combat variation and made every Communications room choose the same initial face during reverse engineering. They are DOS implementation details, not clean-room compatibility requirements.

The live aliases identified while explaining the DOS captures are:

The two segment words are allocator-derived. They were 42C5 in the focused fresh-load probes and 4C13 in a longer prior session, even though the resource-relative cursor behavior was identical. This is the only part of the lookup whose exact value can vary with the DOS heap history.

The clean-room engine treats this entire lookup as a DOS implementation detail. Every opcode-8E or opcode-91 execution advances the one portable runtime generator and uses the returned value’s low byte, regardless of map coordinate. Opcode 0x82, the text shuffle, unused opcode 0x8B, and the transient-status refresh started by 0x8B share that stream. The algorithm and call order are now explicit so, from the same initial state and inputs, a patched DOS run, Rust, and future implementations can replay the same branches without depending on resource addresses, selector state, or unrelated scene globals.

Instruction-boundary QEMU probes validate both consumers. COMBAT1.BIN reached 0627:5913 at map coordinate (0,4) with BX=0040, ART/display counts 6/35, and cursor 07F3, exactly one byte after its opcode-8E at 07F2. A patched ROOM3 save reached 0627:597F at coordinate (13,6) with BX=006D, ART/display counts 3/16, and cursor 169C, exactly one byte after opcode 91 at 169B.

The latter probe proves the problematic alias directly. DS:008A + 006D is DS:00F7, the high byte of the current BIN instruction pointer stored at DS:00F6; opcode 91 read 16h from the pointer value 169Ch. The deterministic DOS patch removes the whole coordinate calculation at 0x5905 and 0x5971 and routes each handler through the portable generator exactly once.

The pointer-capable p encoding is used by seven opcodes: 0x0C, 0x10, 0x14, 0x3A, 0x44, 0x48, and 0x4E. Only two shipped commands use its explicit-offset form: ROOM3.BIN at 0x181C (0x48) and 0x18CE (0x4E) both point back to string offset 0x0336. All other shipped p operands are inline strings.

Opcode 0x8D copies the same active player prefix and mutable suffix used by the save routines, then requests fopen(..., "rb"). At its only site, TITLE.BIN:0x012C, the initialized suffix is .SV0, so the constructed name is DDGAMES.SV0 with the default prefix. A failed open selects target 0x012F, which is also the next command; either result therefore reaches the same change_scene 'INTRO', 'seg'. The handler passes the returned stream to fclose after either path, including the null result on failure.

Opcode 0x7A deliberately modifies the loaded BIN buffer. Combat exits use it to replace the C in inline CHAL from the current level-letter variable; POWER.BIN replaces the digit in combat1 from the selected combat number. It is therefore a resource-name templating mechanism rather than a persistent-state write.

Opcode 0x6C calls rotate_palette_range at 0xB5A8. Its operands are inclusive minimum, inclusive maximum, signed step, and phase variable. The helper wraps the updated phase, fills the palette-index mapping across the range, and schedules a palette update. Opcode 0x7E calls start_palette_blackout at 0x1B6C; the next palette update writes an all black palette and counts down the effect state.

The suffix strings are present in the executable data segment and were also checked in the QEMU process image: .PAL at DS:0434, .ART at DS:0490, and .BIN at DS:0721. This corrects an early interpretation of bytes such as 4D 54 49 54 4C 45 00 as the string MTITLE: byte 0x4D is actually the palette opcode followed by the string TITLE.

Startup programs

The QEMU DOS trace and archive directory give this resource-load sequence:

LOGO.BIN -> LOGO.PAL -> LOGO.ART -> D003.ABT
TITLE.BIN -> TITLE.PAL -> TITLE.ART -> TITLE2.ART -> MUS001.XMI
INTRO.BIN -> INTRO.ART

The scripts involved decode completely:

INTRO.BIN begins by setting two small state values, loading TITLE.PAL, loading INTRO.ART, and drawing the opening sequence. Opcode 0x52 selects music index 1, which produces MUS001.XMI. At file offset 0x009A, opcode 0x0D carries strings dome and seg to enter the first gameplay scene.

The runtime dump contains all 184 INTRO.BIN bytes at physical address 0x4C130. The base pointer 4C13:0000 appears at physical address 0x14F0A, stored as offset word 0000 at DS:00FA and segment word 4C13 at DS:00FC. The live cursor is 4C13:004B; resource offset 0x004B begins opcode 0x42 and is exactly the boundary after the preceding return_minus_one command. This ties the static decoder’s command boundaries to live interpreter state.

Mixed code and data

Sixty members decode linearly from byte zero through end of file. Two members contain non-code regions:

• CP2.BIN has commands at 0x0000..0x1D54, followed by a 256-byte structured data trailer at 0x1D55..0x1E54. It contains a 16-node four-heading adjacency table, node types, transition values, and lower-right map coordinates. The Unibot chapter decodes every entry.
• ROOM3.BIN has command regions 0x0000..0x0336, 0x0C96..0x1754, and 0x1768..0x19DB. A 2,400-byte zero-filled block and a 20-byte zero-filled block separate them.

Opcode zero is invalid. The decoder deliberately reports it instead of guessing that arbitrary padding or embedded tables are executable commands. The later ROOM3.BIN entry points are therefore decoded explicitly rather than reached by a single linear sweep.

Inspection tool

After extracting the archive, inspect a complete stream with:

tools/inspect_bin.py build/dd1/all/005_INTRO.BIN

Use explicit bounds for embedded regions:

tools/inspect_bin.py \
  build/dd1/all/334_ROOM3.BIN --start 0x0c96 --limit 0x1754
tools/inspect_bin.py \
  build/dd1/all/334_ROOM3.BIN --start 0x1768
tools/inspect_unibot.py build/dd1/all/315_CP2.BIN

Output includes the file-offset range, opcode, current semantic name, and typed operands. Variable operands show both their word index and encoded byte offset, with recovered names such as var[21:faith]@0x002a. Other words with their high bit set are displayed in both unsigned hexadecimal and signed decimal forms. Every dispatched opcode now has a name; low-level names for unused commands deliberately describe state changes rather than inferred UI.

Add --objects to append a linear summary of commands which define display records, --choices to inventory dialogue target/text pairs, or --animations --actions to inventory animation sequences and selectable screen targets. Action summaries name the four combat selectors and the hall selectors for movement, Confront Cyber, Unlock, and Get Verse. The scene-display-object chapter documents the ten-byte runtime record, while the conversation-flow chapter documents the six-byte choice table. The combat-runtime chapter documents animation slots, action targets, and the BIN scheduler; the world-map chapter correlates the hall actions with map-cell features. These summaries warn that branches can change which definitions execute.

Executable routines

Offsets use the unpacked load-module convention documented elsewhere in this book.

Scene Display Objects

Scope and terminology

The scene runtime maintains a 100-entry display list which connects BIN commands to animation, command threads, ART frames, and the renderer. Some records visually represent characters, enemies, or props, but the structure itself is a display list. Calling every entry a gameplay entity would be misleading: the same list also contains animation-group and thread records.

The recovered model is based on the bytecode handlers, the scene update and render paths, and a live QEMU capture of LOGO.BIN.

Runtime layout

The list count is a word at DS:00E2. Records begin at DS:A2AC, have a ten-byte stride, and are addressed as A2AC + index * 10. The update routine at load offset 0x3AFF rejects counts greater than 100, establishing the capacity.

For directly rendered record types 0x03 and 0x43, the layout is:

This assignment follows the arguments passed to the renderer at 0xBCAC. That routine selects a loaded ART resource with the low seven bits of byte +6, subtracts one from the frame number, applies coordinates and scale, and derives the two flip bits from byte +8. An ART-slot byte in 0x80..0xEF, or frame zero, releases/suppresses the render slot instead of drawing it.

Visibility is therefore encoded in the ART-slot byte rather than the separate render-flags byte. The slot byte should not be modeled as a plain array index without masking or checking its high bit.

Record types

Four type values are written by the recovered scene handlers:

The update routine handles type 0x02 through the scene-thread path. Types 0x03 and 0x43 are submitted directly to the object renderer. Type 0x06 is owned by the animation-sequence path. The ten-byte fields not used by a type can contain zero or stale data and must not be interpreted as a direct object’s coordinates.

Type 0x02 records also participate in the primary pointer-target table even when no opcode 0x10 selector label was attached. The main input path around 0x87D3–0x8842 gives scene-thread targets priority over opcode-0x3A actions. Its selected-target dispatcher at 0x851E distinguishes a scene-thread target from an ordinary script action and writes the selected thread/node index into the movement controller rather than jumping to a BIN offset.

This matters in GANTRY.BIN. Navigation nodes 2 and 3 share geometry (190,70) and have no selector strings. Entry seg finishes on node 2, whereas arrival at node 3 enters CP1. The current unlabeled node is omitted from hit-testing, so table order selects node 3 when the player clicks the opening. Requiring a nonempty selector makes this scene appear locked even though its navigation graph and callback are complete. The missing label also means DOS displays no transient action arrow for this target.

The selected-target index is also what the main input path dispatches after Enter and what the Space-cycle routine uses as its starting record. These paths do not re-filter the target by selector-string presence. Consequently the unlabeled GANTRY opening is keyboard-activatable when the pointer is over it, and Space advances from rather than ignores an unlabeled current target.

Scene commands

The definition and direct frame-control commands are:

The animation step is not copied when opcode 0x07 executes. The handler advances over its nine bytes; the animation state created by opcode 0x06 retains a BIN-stream location and consumes the records later. This explains why the command decoder originally could establish the nine-byte boundary before the animation lifecycle was understood.

Six consecutive 0x07 records at CP1.BIN:0x0026..0x0062 precede the first 0x06 in that resource. The DOS handler accepts them because it only advances the BIN cursor; they are not owned by an animation definition. Treating 0x07 as an append operation that requires an already created host animation incorrectly rejects the Unibot boarding scene.

The animation slot and step layouts, lifecycle commands, and linked-transform path are now documented in the combat-runtime chapter.

Victim scenes use 0x85 and 0x86 on groups of display indices when their visual state changes. For example, NAGE.BIN hides a set of crystal-related objects in a subroutine selected by progression flags. This is evidence for display visibility, not by itself for entity death or activation state.

Lifecycle

initialize_scene calls the reset routine at 0x3AD2 before loading and executing the next BIN resource. The reset routine visits every current display index, releases its render slot, and sets the count to zero.

The offset-zero loader invocation ends at opcode 0x05 before the requested entry traversal is started. That invocation remains stopped while the actor moves between the two nodes selected by the matching 0x0C record. Only the ordinary departure or arrival callbacks start a fresh command stream afterward. The entry movement request synchronously runs its departure callbacks before initializing the selected edge; they must not share the terminating loader invocation. Keeping the loader stream runnable at the byte after 0x05 makes an arrival handler execute once as fallthrough and a second time on actual arrival. Starting a departure callback inside the loader’s 0x05 handler instead lets that return deactivate the new invocation. CP1.BIN exposes the first error as a duplicated Unibot introduction, while FIRST.BIN exposes the second as a missing beamer materialization.

During scene updates, 0x3AFF walks the current list:

• type 0x02 invokes the associated thread/update slot;
• types 0x03 and 0x43 pass the recovered ten-byte fields to 0xBCAC;
• other supported types are serviced by their dedicated animation paths.

The main frame update calls those controller paths separately, but call order is not layer order. Each path writes into the render slot reserved by its mixed display-record index. Direct rendering passes index + 1 at 0x3B72–0x3B76; animation rendering passes its saved display index plus one at 0x3D64–0x3D6B; scene-thread movement does the same at 0x763D–0x7642. The dirty-region compositor at 0xC000 then advances through the 26-byte render slots in increasing order.

This distinction supplies the opening oval mask. In LOGO.BIN, the moving RUN.ART controller is display record 4, while the direct dome and bridge pieces are records 7 through 9. The later scenery covers the character outside the oval as it enters and leaves. It is display-list occlusion rather than a separate geometric clipping primitive. Regrouping records as direct, animation, and movement passes incorrectly forces the character above the mask.

The list is runtime scene state and is reconstructed from the BIN program. It is not serialized in the save file.

QEMU validation

The game was started with the repository’s visible and silent trace mode:

./run.sh --trace-dos

At the Bridgestone logo screen, QEMU reported DS=14E1. A one-megabyte physical-memory dump therefore placed the count at physical 0x14EF2 and the record table at physical 0x1F0BC. The live count was 13.

The three directly rendered records were:

These values exactly match the three 0x43 commands at BIN offsets 0x0122, 0x012C, and 0x0136. Records 0–3 and 10 are the five animation sequences begun by opcode 0x06; records 4–6 and 11–12 are the five scene threads created by opcode 0x02. Thus all 13 definitions in the linear startup path match the live type order and count.

The dump and screen capture are retained as ignored analysis artifacts under build/qemu-trace/.

Inspector

Show the normal command listing followed by its linear display definitions:

tools/inspect_bin.py build/dd1/all/001_LOGO.BIN --objects

The summary includes source offset, type, and all definition fields known for that type. It follows linear file order; branches and calls can skip or repeat definitions at runtime, so indices outside a straight startup sequence are not guaranteed live indices.

Primary movement controller

The recursive search at 0x6DA5 and wrapper at 0x6EBD establish the route algorithm. The wrapper tries recursion limits zero through 19. At the limit, the recursive routine looks for one final direct edge, so the accepted route lengths are one through 20 edges. Every level scans the opcode-0x0B table in insertion order, testing a record’s stored first endpoint before its second. It has no visited-node set. The wrapper returns only the immediate next node and edge direction; updater 0x7469 calls it again at every intermediate node rather than retaining a complete route.

Request routine 0x779D keeps the desired destination in controller byte DS:7A45. While the interpolation count at DS:7A3A is nonnegative, another request writes only that byte. It does not restart the edge or disturb its coordinates, timing, animation phase, turn pose, or callbacks. Edge completion enters state 5, runs directional and node arrival callbacks, and performs the next search on a later controller update. This is why rapid pointer or keyboard navigation redirects Captain only after he reaches the next graph node. The byte is initialized to FFh, is not reset by opcode 0x53, and remains resident across scene replacement. Final idle resolution changes it to the current node.

Initial movement calls the source-node departure and then the directional edge departure before initializer 0x6F46. State-five continuation first initializes the selected edge, then calls its directional departure and the source-node departure. Completion makes the interpolation count negative, then calls the directional edge arrival and destination-node arrival. Handler 0x7A5C runs every matching callback synchronously as a fresh invocation through its first yield or return before scanning the next record. Arrival callbacks can therefore start and then retarget a new edge in one controller pass. The caller’s BIN cursor is saved separately, so a negative delay left by a same-slot nested callback does not prevent the outer command stream from continuing. If the outer stream later yields, its cursor replaces the nested cursor and its delay change accumulates with the callback’s.

Edge initializer 0x6F46 never resets the phase accumulator at DS:7A2C. Updater 0x7469 advances it modulo 0x0600 across intermediate edges and writes 0x0200 only in idle state 2. The initializer’s orientation table contains offsets 0, 0, 24, and 12; the four phase increments are all 28. When horizontal direction changes but that offset remains zero, a reflection change selects RUN.ART frame 20. A direct offset-12/offset-24 reversal, toward versus away, selects frame 19. Both set the transition countdown to 28 << 3, or 224 controller units. Horizontal/depth changes have no special turn pose. The raw table bytes were checked in the unpacked executable at file offsets 0xEF34 and 0xF4CA as well as through the instructions at 0x71BB..0x721E.

Opcode 0x53 at 0x5440 writes both current-node bytes, sets the previous edge index to -1, and calls 0x6F46 with identical start and end nodes. It therefore snaps to the requested geometry but remains in state 1 for a minimum same-node traversal. Its completion cannot match a directional edge callback because the edge index is -1, but it still dispatches the node-arrival callback. A following opcode 0x54 at 0x5468 merely queues its destination until this traversal finishes. An unreachable ordinary request takes the same minimum-traversal path before returning to idle. Opcode 0x53 does not replace the retained desired-node byte.

Controller timer rate

The hardware initialization at load offset 0x3600 installs the interrupt-8 handler at 0xAAE4. It programs PIT channel zero in mode 3 with divisor 0x26D7 (9,943), producing approximately 120 interrupts per second. Each interrupt increments the counter at 0x4B66. The elapsed-delta helper at 0x00B6 multiplies that counter by 24 and caps the result at 400 before the frame controller at 0x7A8D distributes it to animations, scene threads, and movement. The resulting controller rate is approximately 2,880 units per second, not one unit per millisecond.

The ordinary controller at 0x7ACB reads and resets that elapsed delta, calls the animation updater at 0x3DA8, and calls the dirty compositor at 0xC5CA before returning. The blocking input poll repeatedly invokes this controller, so under normal load each nonzero update contains one interrupt: 24 units, or about 8.33 ms, followed by one presentation.

The animation updater adds the complete controller delta to a sequence’s countdown. If more than one record became due, it catches up through those records and submits only the final resolved display slot. DOS can therefore skip an intermediate frame after a genuine stall, but its normal 24-unit cadence does not skip the explicit 30- and 40-unit sequences in COMBAT4.BIN. This distinguishes normal visual cadence from the controller’s intentional long-stall catch-up behavior.

Remaining questions

• The opcode-0x02 16-byte interactive/display record still needs names for every field and a clearer distinction from the true BIN scheduler table.
• Combat targeting uses a separate ten-byte screen-action table. No evidence yet connects direct display objects to collision or enemy health.
• The last two bytes of each 12-byte animation slot and several detailed mode transitions remain unnamed.
• A display record can visually represent a character, but no identity or gameplay-stat field exists in this ten-byte structure.

Relevant executable functions

Offsets use the unpacked load-module convention.

Combat Runtime

Architecture

Combat is implemented by seven scene programs, COMBAT1.BIN through COMBAT7.BIN. The executable supplies generic animation, selectable-action, thread, random-number, sound, and faith-loss operations; each BIN program combines those primitives into an encounter. This is a script-driven system, not a conventional enemy object with a health field in the ten-byte display record.

Every combat program loads COMBTAGS.ART, COMBAT.ART, and one or more enemy-specific ART resources:

The programs branch on script variables and progression flags, including the Sword and Shield power flags 0x30 and 0x31. They use opcode 0x81 to reduce the player’s faith. Encounter outcomes, enemy phases, and exits are therefore expressed as script control flow and persistent state changes. No separate enemy-health structure has yet been found.

Animation definitions

Opcode 0x06 begins an animation definition. Its word operand becomes the sequence interval. The immediately following opcode-0x07 commands are the steps retained in the BIN stream; executing 0x07 merely advances over its nine-byte payload.

Each step has this layout:

The runtime animation table starts at DS:6EBA, has a 12-byte stride, and is counted by the word at DS:B114. The recovered fields are:

Opcode 0x08 reads animation, mode and starts the slot with parent/link value -1. Opcode 0x5F reads animation, linked animation, mode and supplies the explicit link. Opcode 0x09 stops a slot and releases its render slot. Opcode 0x3F suspends the current BIN thread unless the animation state is 0, 5, or 6. Opcode 0x80 branches when a chosen animation’s state byte is nonzero; opcode 0x8A branches for exactly the same three finished states accepted by 0x3F.

The executable routines at 0x3B9B, 0x3D08, 0x3DA8, 0x3F59, and 0x3FDF resolve linked transforms, render one slot, update all slots, start a slot, and stop a slot respectively. The updater advances through the BIN steps in ten-byte command units and implements animation modes 1 through 10. Disassembly of 0x3F59 shows that only modes 2, 4, 6, and 10 initialize at the final step; mode 8 starts at the first step. At the boundary, 0x3DA8 backs a mode-7 overrun up by one ten-byte record, retaining the final frame and changing to mode 8. A mode-8 underrun advances by one record, retaining the first frame and changing to mode 7. The complete observed behavior is:

Selectable action targets

Opcode 0x3A appends a ten-byte action target to the table at DS:480E; the word at DS:6EA4 is its count:

Opcode 0x3B enables one record and 0x3C disables it. Opcode 0x41 enables action selection globally; 0x42 disables it and clears pending selection state. The overlay routine at 0x6A23 scans active targets, compares their coordinates with the pointer, decodes the selector string, and draws the corresponding label. The keyboard path at 0x8558 searches the same table. A selected record is dispatched through the BIN-thread start routine at 0x7A5C.

The overlay scan first checks enabled scene-thread selectors and then the ordinary action-target table. Function 0x3315 computes max(abs(dx),abs(dy)) + floor(min(abs(dx),abs(dy))/2). Candidates above 0x46 are rejected, and strict less-than replacement preserves the first candidate on a tie. The chosen label is submitted in transient render slot 0x97; that slot is released when no target qualifies. For .u, .d, .l, and .r, the executable selects one-based STUFF.ART frames 8 through 11.

The numeric path at 0x6B94 through 0x6CCE interprets a selector .XY as loaded ART slot X and one-based frame Y. It submits that resource frame using the target’s X/Y anchor and the frame’s signed descriptor origin. This is why the combat names are not drawn with the font and why .23 elsewhere can use the same generic overlay path.

The keyboard matcher at 0x8558 normally compares the character after the dot. For .1N it instead compares N, exposing combat selector keys 1 through 4. The translation routine at 0x866B, with its switch table at 0x86E8, maps A and S to 1, D to 2, R to 3, G to v, and U to x. C first searches for an ordinary .c selector and falls back to 4 only when none is active. Other letters pass through. Both keyboard and overlay scans preserve scene-thread selector priority over ordinary action records.

COMBTAGS.ART contains four label frames. Rendering all four with 019_ZAP.PAL identifies the selector mapping independently of the scripts:

The world-map chapter documents the independent hall-kind and transition evidence for these manual identities. COMBAT6.BIN is the only program without a DEFEND target. For example, COMBAT7.BIN defines:

These coordinates are screen hotspots rather than enemy bounding boxes. The same generic table can represent selectable actions elsewhere, so its runtime name is deliberately broader than “combat buttons.”

BIN threads and synchronization

The command-stream scheduler uses 16-byte slots beginning at DS:8D44; the current slot index is at DS:7DB4. The fields proven so far include the BIN cursor at +0, a delay/timer at +0x0C, an active byte at +0x0E, and a status byte at +0x0F.

Opcode 0x3E activates a selected slot at an absolute BIN target and runs it immediately. Opcode 0x61 clears a slot’s active byte. This is the mechanism used after an action target has supplied a branch destination. It is distinct from the separate 16-byte record family created by opcode 0x02, whose type 0x02 entries also participate in the scene display/update list.

The shared start routine at 0x7A5C does more than replace the cursor. It sets the active byte, writes the target, primes the delay from the negated current controller delta, clears the status byte, and immediately invokes update_scene_threads for that slot. In host terms this is a fresh, ready invocation which runs before its caller continues. Action selection uses the same routine for slot zero. Retaining the idle loop’s existing negative delay instead leaves a combat choice dormant for hundreds or thousands of logical timer units.

Opcode 0x59 waits for a digital effect to finish. With usable playback it yields and retries while the driver reports an active effect. Without usable playback it subtracts 100 from the calling scheduler slot’s delay, advances past the command, and lets the ordinary per-thread timer provide the pause. Opcode 0x82 computes a runtime pseudorandom value modulo its first operand and stores the remainder in the script variable selected by its second operand. Together with animation waits, these operations let the combat scripts sequence visual attacks, sounds, and randomized branches without embedding those policies in an enemy structure.

Action and outcome control flow

The four actions are entry points into the same encounter program, not numeric combat operations. ATTACK disables the current choices and runs an enemy-phase-specific animation path. DEFEND changes the available timing window; when Shield flag 0x31 is set, the scripts leave the attack option available longer. COMBAT uses opcode 0x82 and branches on Sword flag 0x30 and Shield flag 0x31 to choose successful, harmless, and faith-damaging sequences. The exact visual phase that makes each enemy vulnerable remains encoded in scene-local animation and counter variables.

Opcode 0x81 contains the base loss used on Normal difficulty. The seven programs contain these loss sites:

Each Retreat target is itself an unconditional jump to the common exit entry. It therefore skips the victory-only map mutation. The table records all static loss sites rather than claiming that every site executes in one fight; branches choose among them. Easy halves each immediate, Difficult multiplies it by four, and installation no-combat mode suppresses it.

COMBAT7 contains the manual’s exceptional Zapper reward directly. Its victory subroutine alternates faith between 1 and 10,000 five times, producing a visible meter flash and ending at full faith. This happens before kind 0xB is written to the defeated encounter’s map cell.

Shared encounter epilogue

Six programs set state flag 0x38 after defining their action table and clear it in the common exit. The Game Options input routine tests the same flag and disables the Automatic Combat menu target while it is set. Flag 0x38 is therefore the combat-active lock, while flag 0x37 stores the Automatic Combat setting itself. COMBAT6 is exceptional: it has no DEFEND target, never changes flag 0x38, contains no faith-loss opcode, and produces a different map transition. Its internally named GUARD encounter is the Leech Cyber covering a Scripture station: victory reveals the station and transfers its saved verse selector into the active field.

After victory or retreat, the programs clear current-cell parameter A and select a hall scene. Variable 67 chooses the literal GHALB or GHALS variants for two special cases. Otherwise opcode 0x7A patches the first byte of the inline CHAL string from variable 16, the current map-level letter, yielding the appropriate AHAL through GHAL resource name. Opcode 0x7E starts a palette blackout immediately before these scene changes.

All seven combat programs also expose a separate POWER scene-change entry. POWER.BIN is the in-combat study/power interface, not a game-over scene. On a successful selection it copies the current combat number, adds ASCII '0', patches the digit in the inline name combat1, and changes back to that encounter. The caller path into this special entry has not yet been fully recovered.

Inspection

Inspect animation definitions and action targets with:

tools/inspect_bin.py \
  build/dd1/all/337_COMBAT7.BIN --animations --actions

The summaries follow linear definition order. Calls and branches can skip or repeat definitions, and enable/disable commands determine which action targets are live at a particular moment.

Live COMBAT1 table validation

A visible, silent QEMU capture now validates the three runtime table families. The route was controlled rather than a natural walk to an encounter: a genuine hall quick-save contained snapshot/live scene names MENU/CHAL, and tools/patch_save_scene.py changed only both 20-byte scene-name fields to COMBAT1. The modified state round-tripped through the FAT image byte for byte. Loading it with F9 produced the Macho combat screen, and the A key started a visible green attack effect.

The first dump caught scene initialization between visible redraws, with counts 0 and 1, so it is not used for table comparison. A second one-MiB physical dump after the attack input had SHA-256 becc98dd2eba0bad502f1bf6b7aef4ef2638fa48d0e0e62688ad879085bc1654. QEMU reported DS=14E1; tools/inspect_runtime_tables.py therefore read the same data offsets documented above at physical base 0x14E10.

The stable capture contains four action records and 33 animation records. All four action target/X/Y/selector-offset tuples match the static COMBAT1 definitions. ATTACK, DEFEND, and RETREAT are active; the automatic COMBAT target is present but inactive. Every animation record’s first-step offset and interval matches its corresponding BIN definition, 33 of 33. Current-step, link, state, render-slot, and timing values are retained as live values rather than forced to equal their initial definitions.

The first ten 16-byte scheduler records were also saved. Current slot is zero; slots 0, 5, 7, and 8 have active byte 1. Slot 0 has cursor 0x0C35 and signed delay -824 at the sampled instant. The remaining opaque bytes are emitted in hex so later field naming will not lose evidence. The exact comparison command is:

tools/inspect_runtime_tables.py \
  build/formal-captures/combat-after-a-memory.bin \
  --data-segment 0x14e1 \
  --bin build/dd1/all/343_COMBAT1.BIN

This validates the table addresses, strides, counts, and statically comparable fields. It does not prove a natural map-to-encounter transition, nor does the controlled state preserve a normal combat outcome: the patched checkpoint had zero snapshot faith, and the run subsequently reached the “Don’t Give Up!” screen. Those provenance limits are intentional and recorded rather than being generalized to ordinary play.

Remaining questions

• Name the final two bytes of each animation slot and every mode’s exact transition rule.
• Separate the opcode-0x02 interactive/display record family from the true BIN scheduler slots field by field.
• Correlate every randomized branch with the exact enemy phase and rendered successful, harmless, or damaging sequence.

Conversation Flow

Overview

Conversations are ordinary BIN control flow layered over two reusable user interfaces: a modal dialogue box and a text-choice menu. Scene scripts supply speaker text inline, build choices as target/text pairs, and branch to the target selected by the player. The same study-Bible screen used elsewhere in the game can be opened from a conversation and returns success or failure through state flags.

This system is distinct from the scene display list. Portraits and other characters can be display objects, but conversation branches are absolute BIN offsets and their transient menu records live in a separate table.

Dialogue commands

Three commands share the handler at load offset 0x52A3. The handler chooses presentation parameters from the opcode and stores a far pointer to text in the current BIN resource. The input layer then displays the modal box and waits for Enter or a click to advance it. Escape temporarily transfers control to Game Options without accepting the message.

Here p is either inline NUL-terminated CP437 text or byte 0xFF followed by an explicit 16-bit offset in the same BIN resource. ROOM3.BIN uses the offset form twice, at commands 0x181C and 0x18CE, to reuse text beginning at 0x0336. Those are the only explicit string offsets in shipped code.

The handler has a deliberate retry path that reads no operand. If a modal dialogue is already active, it suspends the command thread at the original command offset. Once the modal state clears, re-execution consumes p and continues. This no-read path is synchronization behavior, not an optional text operand.

Opcode 0x4E is a presentation channel rather than a hard type system. A few scripts reuse it for system or caption text such as Verse loaded: & and the credit screen. The speaker names describe the dominant, independently labelled use rather than a restriction enforced by the interpreter.

The formatter at 0x224F scans the display string for &. When present, it switches to the complete index string of the currently selected text record. That record is stored as citation|verse; while copying it into the temporary display buffer, the formatter replaces | with -. Thus Verse loaded: & expands to the reference and full verse. A literal | in the display template is not a separate verse-only placeholder.

The modal dialogue state word is at DS:8934. State 1 denotes a choice menu; higher positive states select dialogue-box artwork and behavior. Function show_dialogue_message at 0x2933 renders the frame, wraps the far text, and runs the input loop while continuing to update scene animation.

The routine also creates one transient input record at DS:0248. Its anchor is the horizontal text midpoint and logical text Y plus five. Each update passes that record to the shared nearest-object selector at 0x6CE5, which uses the distance helper at 0x3315 and rejects values above 100. The click exit at 0x2ADD requires both a selected record and the primary-button latch. A click outside that proximity region therefore does not accept the message; the full panel and viewport are not implicit continue targets.

The Escape branch at 0x2AAA writes status event 12 to DS:0052, removes the transient dialogue artwork, and returns -1 without clearing the underlying dialogue state. poll_input_event at 0x7C3F converts event 12 back to Escape, and the main dispatcher at 0x8904 opens Game Options. Returning from options causes the still-active dialogue to be drawn again. The common choice selector takes the same event-12 route, preserving both the choice records and current selection. Game Options is therefore an overlay continuation, not a dialogue cancellation.

Both blocking text loops also recognize BIOS key values BBh through C5h. They subtract BBh, store the result as the status event, and return -1; poll_input_event reverses that translation before returning to the main dispatcher. Values BBh..C2h are F1..F8 and reach the status switch only when word 004C enables action selection. F9 (C3h) and F10 (C4h) reach the quick-load and quick-save branches independently of that gate. A blocking Computer Bible, map, or notice routine then returns to the still active text modal, except when loading replaces the current game state. Other keys rejected by the active text loop do not fall through to the scene action matcher. In particular, an Up or Down press cannot activate a directional exploration target behind an ordinary dialogue.

The three bytes written by opcodes 0x5C and 0x5D are logical text X, text Y, and wrap width. The BOSS.BIN values [4, 30, 150] and [162, 89, 150] align exactly with the upper-left and lower-right panels in the preserved capture. FACE.BIN supplies [80, 12, 180] and [80, 170, 180], establishing that the tuple is general panel geometry rather than a small set of speaker identifiers.

The visible type is not a BIOS font. Startup routine 0xAE42 loads frame 0 of STUFF.ART, a 257-by-14 atlas arranged as two seven-row glyph strips, and builds an offset table for bytes 21h through 7Fh. The executable’s width table at DS:3462 makes the font proportional; renderer 0xAF36 advances by width plus one, treats spaces as three pixels, and copies seven source rows. Each logical source pixel becomes a 2-by-2 block on the 640-by-400 presentation surface, with an eight-logical-pixel line pitch.

The atlas has three source values which renderer 0xBE7E maps through a text style. Character and Captain Bible messages use style 2 (1,37,4), while adversary messages use style 7 (15,86,90). The live BOSS framebuffer contains exactly indexes 1, 37, and 4 in the displayed line, independently confirming the normal-dialogue mapping. The CONTINUE caption is the complete sprite in STUFF.ART frame 29 rather than text rendered at runtime; its descriptor (-17,-3,35,7) centers and overlaps it above the panel.

Choice table

Opcode 0x45 clears the current choices and resets dialogue state. Each opcode 0x44 then appends one six-byte entry, and opcode 0x46 presents the result. The runtime structure is:

The choice text normally points directly into the loaded BIN member. Opcode 0x13 removes the first entry whose target word matches its operand and shifts the later six-byte records down. No recovered BIN resource uses 0x13, but its implementation is unambiguous.

The full command lifecycle is:

1. clear_dialogue_choices (0x45, handler 0x51B7) sets the count and dialogue state to zero.
2. add_dialogue_choice (0x44, handler 0x51C6) stores the absolute target and far string pointer, then increments the count.
3. present_dialogue_choices (0x46, handler 0x5257) enters state 1 and suspends the current scene thread.
4. select_from_text_menu at 0x2556 draws the entries and returns the target word belonging to the chosen row.
5. poll_input_event writes that target to DS:7CBA. The resumed handler replaces the interpreter cursor with the target, so execution continues at the selected branch.

The input loop clamps keyboard selection at row zero and count minus one. For every wrapped row, 0x25E8..0x26AC constructs a 16-byte selector record. Its first two words are the proximity anchor (text_x + 72,row_y + 2); offsets 8 and 10 hold the separate SELECT artwork anchor. Function 0x6CE5 tests all row anchors with distance helper 0x3315, retains the strictly closest result at distance 100 or less, and therefore resolves equal distances in row order. A pointer move outside all row regions clears the pointer selection rather than retaining the prior keyboard row.

Unselected choices use style 1 (1,7,3) and the selected choice uses style 2 (1,37,4). The adjacent SELECT caption is STUFF.ART frame 28 with descriptor (-12,-3,24,7), including its lettering and border. Thus neither choice label nor continuation label should be synthesized with a host font. The caption anchor is (text_x - 11,row_y + 2) for a text origin of 23 or greater and (text_x + text_width + 12,row_y + 2) otherwise. This selector record family is shared by Game Options, slot lists, and confirmation menus; those interfaces are not rectangular host controls.

The corpus contains 40 choice definitions in six resources, 11 clear commands in six resources, and 14 present commands in seven resources. Those different totals reflect conditional paths and reuse of a previously built menu; a linear listing must not assume that every definition belongs to one runtime menu.

BOSS.BIN example

The introductory conversation constructs one five-choice menu:

Each answer eventually jumps back to the menu-building region, except the final choice, which advances the introductory sequence. This is ordinary BIN branching; the menu itself does not retain a conversation graph.

The shared text-menu input loop at 0x2556 lowercases an otherwise unmatched keyboard character at 0x27AA, scans displayed strings from row zero at 0x28BA, and compares their first byte at 0x28D0. A match is converted into the same activation event as Enter at 0x28E7. Choice menus therefore support case-insensitive first-letter activation, with the first duplicate initial winning.

The branches at 0x2796..0x2825 additionally map Home and End to row zero and the final row. Up and Down walk over the disabled marker byte 0xFE, while the direct edge assignments do not perform that skip.

Study-Bible integration

Victim conversations repeatedly ask the player to select an appropriate verse. Opcode 0x7D reads a byte plus a script-variable operand and stores a prompt component at DS:0066 and the variable’s current selector value at DS:0068. The study screen’s prompt builder at 0x446F interprets the first value as follows:

The builder looks up the expected selector directly rather than searching the acquired-verse list. It submits the resolved text to the general wrapped-text renderer with logical X 6, Y 22, width 309, and at most three lines on an eight-pixel pitch. A vertical bar forces a new line. L prompts use text style 7, P prompts use style 9, and * prompts use style 10. Because the open-book chassis begins at logical Y 51, these three possible rows occupy the black space immediately above it.

Opcode 0x49 sets the study request at DS:79F0 and suspends the current thread. The main game loop clears the request and calls handle_study_bible_request at 0x834E, which invokes the full study browser at 0x1C88. The browser clears state flags 0x14 and 0x15 before input. Its key branch at 0x1E2C recognizes ASCII 16h (Ctrl+V), finds the configured selector from DS:A0EA, and changes the current record only when the corresponding acquired-state byte is nonzero. The normal redraw then places that record on its 14-row page; the shortcut does not apply it. Selecting the expected descriptor sets flag 0x14; leaving without that match sets flag 0x15. Scripts branch on those flags around opcode 0x72, which applies a one-update scheduler yield rather than another modal suspension.

For example, NAGE.BIN sets variable 28 to a text-record selector, executes configure_study_prompt 0x2A, var[28], requests the study screen, and then branches to success, rejection, or departure paths according to flags 0x14 and 0x15. This ties the conversation graph directly to the text descriptors and companion * records documented in the text-format chapter.

QEMU validation

A visible, silent ./run.sh --trace-dos session was advanced from the title screen to the BOSS conversation. At the five-choice menu, the stable game data segment was 14E1. The one-megabyte physical-memory capture therefore placed the count at physical 0x20238 and the table at physical 0x1FF26.

The live count was five. All five records contained the exact static target words above and far pointers into BOSS.BIN at 4C13:045F, 4C13:0485, 4C13:04A5, 4C13:04C6, and 4C13:04FE. Dereferencing those pointers produced the five visible menu strings byte for byte.

Before selection, DS:8934 was 1 and DS:7CBA was zero. Selecting the final row changed DS:7CBA to 0x095C; the next visible dialogue was Before you go, I think that we should pray., exactly the opcode-0x48 string at target 0x095C. The resulting dialogue state was 2. QEMU was then stopped through its monitor.

The ignored evidence files are under build/qemu-trace/, including conversation-menu2.png, conversation-menu2-physical-1m.bin, conversation-selected.png, and conversation-selected-physical-1m.bin.

Inspection

The ordinary BIN listing now uses semantic names for the recovered dialogue, choice, study-request, and thread-suspension commands. Add --choices for a compact linear inventory of every opcode-0x44 definition:

tools/inspect_bin.py build/dd1/all/327_BOSS.BIN --choices

The summary prints source offset, target offset, and text. It explicitly warns that branches can change the menu seen at runtime.

Remaining boundaries

• The exact artwork role of every positive dialogue state is not yet named.
• Conversation choices and verse answers alter progression flags, but they do not expose a separate enemy-health, hit-test, or combat-entity structure.

Relevant executable routines

Offsets use the unpacked load-module convention documented elsewhere in this book.

Script State and Progression

Primary-state structure

The 200-byte live block at DS:727A is the scene interpreter’s shared state. New-game initialization writes 100 zero words with rep stosw, and the save system copies exactly those 100 words to and from the checkpoint block at DS:7BF2. Values are signed 16-bit integers where arithmetic or comparison requires a sign.

BIN operands do not store variable ordinals. They store even byte offsets from DS:727A; the interpreter shifts an offset right once before indexing the word array. Thus operand 0x002A identifies variable 21:

address = DS:727A + encoded_offset
index   = encoded_offset / 2

Across all 64 recovered BIN code regions, the core variable instructions reference 39 of the 100 slots. Every one of their encoded operands is even and below 200. Many high-numbered slots are scene-local temporaries rather than persistent player attributes.

Identified variables

The first gameplay entry in FIRST.BIN demonstrates the interface directly: it stores X=0 in offset 0x16, Y=6 in offset 0x18, and faith=10,000 in offset 0x2A before processing the current map cell.

Map processing also produces several context-local words for the hall scene:

These are not durable player attributes. process_current_map_cell rebuilds them from the live map, and other scenes can reuse the same general-purpose slots. The world-map chapter describes the room quotient/remainder and the adjacent Trap interaction that establish these meanings.

Variable bytecode

The core instruction family is now recovered. In this table, var operands are encoded byte offsets, value is a signed immediate where relevant, and target is an absolute BIN file offset.

The disassembler annotates known operands with both forms, for example var[21:faith]@0x002a. This also prevents immediate values and jump targets from being mistaken for variable numbers.

Boolean state flags

Variables 3 through 10, at DS:7280..728F, are also treated as a 128-bit flag bank. Identifier n selects word n >> 4 and mask 1 << (n & 15). Dedicated helpers test, set, and clear one identifier using mask and inverted-mask tables in the executable.

The scene corpus uses 78 distinct identifiers through 0x55. They mix temporary navigation/action state with durable progression. When the current map cell is processed, the executable clears the first three flag words (0x00..0x2F) and rebuilds movement and action availability from the cell and its neighbors. Flags at 0x30 and above survive that operation.

Five durable identifiers map exactly to the F4 through F8 status icons:

Flag 0x36 is the status-artwork gate. The renderer at 0x641B releases the Computer Bible, Map, Faith, and power slots and returns when it is clear; several shipped conversation scenes clear it and restore it around their authored sequences. The main loop separately gates F1 through F8 on action selection word 004C. Its pointer-status path requires flag 0x36 as well, so keyboard shortcuts can remain active when the row is hidden but clicks cannot. The branch at 0x8845 also maps ASCII b to the same Computer Bible routine as F1 whenever word 004C is nonzero. The renderer clamps Faith for frame selection and retains the empty frame at exactly zero.

The same renderer owns the dormant transient started by unused opcode 8B. While flag 0x36 and timer word 005C are nonzero, its pre- and post-VM refreshes each consume the runtime random source and use the low two bits as flip flags for zero-based STUFF.ART frame 27. The exact timer and call-order rules are recorded under Runtime random source.

Two adjacent flags control automatic combat:

The Game Options routine displays the on/off state from 0x37. When 0x38 is set it assigns the Automatic Combat row a disabled target instead of the normal toggle target. COMBAT1 through COMBAT5 and COMBAT7 set and clear 0x38 around their shared encounter lifetime. The exceptional guard program COMBAT6 does neither.

Game-options dispatcher

The main input loop handles Escape at 0x88FE after the action-selection branches have rejoined. It calls the options routine at 0x2F36 without testing word 004C, so the menu remains available while the status-control row and ordinary scene actions are disabled. Ordinary dialogue and choice routines translate their own Escape input into status event 12, which poll_input_event at 0x7C3F returns to this dispatcher. Their modal state remains active and is redrawn after Game Options closes. Other modal interfaces may consume Escape locally.

The dialogue routine at 0x2A89 and text selector at 0x2758 similarly propagate BIOS F-key values BBh..C5h through status word 0052. poll_input_event adds BBh back. The main loop sends F1..F8 to the status switch only when word 004C is nonzero, but its F9 quick-load and F10 quick-save tests at 0x892D and 0x890A are outside that gate. Status screens entered this way are synchronous: returning from one redraws an interrupted dialogue or choice unless a load changed the session.

Faith and power descriptions take a subtly different route. Status dispatcher 0x83B6 calls wrapper 0x2AFD, which invokes the same dialogue reader but ignores its return value. A plain F1 through F10 still makes the reader return negative and closes the description, yet that key never returns to the main dispatcher and cannot open another status screen or trigger quick save/load. The next scene poll redraws any interrupted dialogue or choice.

The Computer Bible’s printable b alias is different. Its comparison at 0x884C..0x885F is an exact test against 62h and is reached only after a blocking text routine has returned the key to the main dispatcher. Ordinary dialogue does not return b, and the common choice selector consumes it as a first-letter row accelerator when one matches. Only a top-level lowercase b therefore opens the Bible; Shift+B and Caps-Lock B do not, while Shift plus Caps produces lowercase ASCII and does.

Because those routines are blocking, the key or pointer event used to leave one is consumed before the main dispatcher resumes. It cannot also activate the restored dialogue, set a scene confirmation latch, or select an underlying world target during the same poll.

The status switch at 0x83B6 has 13 entries. Entries 0 through 7 are the Computer Bible, Map, Faith, and five powers; entries 8 through 11 are no-ops; entry 12 calls the same options routine. The click dispatcher at 0x87E0 special-cases entry 12 before testing action selection or flag 0x36. This is the always-present upper-right disk indicator, so its authored bounds remain an options control even when the rest of the status row is hidden.

The options routine at 0x2F36 temporarily replaces the active text-menu table and builds its rows in this exact order:

1. Continue
2. Load Game
3. Save Game
4. New Game
5. the translation string indexed by word 007C
6. Music On or Music Off from word 0048
7. Sound Effects On or Sound Effects Off from word 004A
8. Automatic Combat On or Off from flag 37
9. Quit

The installation no-combat word at 0058 suppresses row 8. Flag 38 replaces that row’s target with -2, the menu’s disabled value. A translation lock leaves the current translation row visible but prevents its target from cycling word 007C.

Before calling select_from_text_menu, the routine sets the text origin to logical (180,10) and the width to 130. choose_save_slot at 0x2B6F uses ten rows at (140,10) with width 170: the appropriate Cancel string followed by all nine labels. The confirmation helper at 0x2EEC builds two rows from Start New Game or Quit Game plus Cancel.

For each load row, choose_save_slot compares the mutable filename suffix at DS:0045 with that row’s digit and confirms that the state file exists. A match is copied to a temporary buffer and has literal << appended. Selecting a normal save or load leaves its digit as the active suffix; the F9/F10 path temporarily uses Q and restores suffix 0, so quick operations do not mark a numbered row.

The save-name routine at 0x2DF7 copies the selected label to a 27-byte local buffer and clears it first when it equals (EMPTY). Its editor at 0x2C8B limits input to 26 bytes and accepts ASCII ranges 20..3B, 3F..5A, and 61..7A, except for & and *. Backspace (08h) and Left (CBh) delete, Enter accepts, and Escape cancels. The local timer at 0x2CA5..0x2CD6 toggles a literal > at the current end every 02BCh (700) reference-timer units. Editing or deleting writes a new terminator and hides the cursor until the next toggle. After acceptance, initialize_empty_save_slot at 0x815A replaces an empty or (EMPTY) label with Game 1 through Game 9.

Before entering that editor, 0x2DF7 rebuilds a ten-row text table: disabled row zero points to Enter New Name, and rows one through nine retain every save label. It calls select_from_text_menu with the chosen slot plus one so the complete panel is drawn without entering the selector loop, releases the SELECT render slots, and passes the chosen row’s render slot and text coordinates to 0x2C8B. The editor therefore redraws only that row in style 2 while all other labels remain visible in style 1.

The common selector’s Escape branch at 0x278E reaches 0x28A3 and returns -1. The options caller distinguishes that value by nesting level. At 0x3267 it exits the main menu; the save/load calls at 0x3257 and 0x3276 loop back to rebuild the main menu; and the confirmation wrapper at 0x2EEC also reports a negative selection as unconfirmed. The label editor differs: 0x2ECC skips copying the edited local buffer on Escape, but the caller at 0x3261 still continues to save_selected_slot. Thus Escape there rejects the label edit without cancelling the selected save operation.

The function-key branch at 0x2758..0x2772 also makes the selector return -1, after recording the BIOS value relative to BBh in word 0052. Dialogue and choice callers expose that negative return directly to poll_input_event, but Game Options consumes it inside its own call stack. The main selector consequently closes at case -1/0x3267; a negative save/load selection returns nonzero to 0x325D or 0x327C and rebuilds the main menu; and a negative confirmation becomes false at 0x2F2B. No top-level F1..F10 action runs from that same key. The save-name editor at 0x2C8B uses a separate input loop and rejects function-key values.

F9’s state replacement is also a loop boundary, not a deferred scene request inside the controller. The branch at 0x8934 reads .SVQ, stores its return mode at 007A, and reaches the return test at 0x8966. A successful read therefore exits main_menu_and_game_loop. game_main stops boundary music, dispatches mode 2 at 0x8C4A..0x8C75, copies the retained checkpoint buffers to live state, and only then re-enters the scene loop. The old scene cannot execute another update with the restored variables.

F10 takes the neighboring but non-transitioning path. At 0x8911 it calls start_palette_blackout(1), which stores 0081 in the palette-effect word. The immediate compositor call at 0x8920 runs update_palette_effect; that clears the high bit, writes all 256 VGA entries black, decrements the effect to zero, and renders before write_save_state. The next compositor update reapplies the mapped scene palette. The save data and indexed framebuffer are not themselves blackened.

The same selector supplies first-letter accelerators. Its loop at 0x27AA..0x28E7 lowercases the key, scans menu rows from zero, compares the first displayed byte, and activates the first match. It does not skip the disabled target value -2; that value reaches the normal rebuild continuation. Options, slot selectors, and confirmation panels all inherit this ordering.

Home (C7) and End (CF) assign the first and last menu indices directly at 0x27BD and 0x27EF. The neighboring Up/Down paths inspect and skip disabled row marker FE; the edge assignments do not. Enter on such a directly selected disabled row returns target -2, which rebuilds the appropriate options level.

Selection dispatch proves the immediate settings behavior: translation is advanced modulo four and reloads the current text bank, music and effects XOR their enable bytes with one, and Automatic Combat toggles flag 37. The translation path at 0x31D0 calls load_text_bank directly. That loader rewrites descriptor offsets +0, +2, +5, +6, and +8, but deliberately leaves acquisition state byte +4 unchanged. Collected records therefore remain collected when their citation and verse strings change translation. Opcode 6B differs because its handler clears all 66 +4 bytes after the load.

The effects case at 0x31F5 consists only of xor byte [0x4A],1 followed by the common menu rebuild. It does not call release_sound_effect_buffer, digpak_stop_current_sound, or any other audio routine. An active effect therefore continues after the option changes to Off, although later opcode 58 starts are suppressed. Opcode 59 independently tests the same effects word at 0x5125; while it is zero the script takes the 100-unit silent fallback rather than polling the still-running driver.

Continue, a completed save, and a completed load close the interface. New Game and Quit only proceed after their confirmation menu.

The seven victim scenes each set a distinct rescue flag at successful progression points:

GANTRY.BIN tests those seven flags and mirrors the set members into 0x42..0x48 before the Unibot sequence. The bytecode proves the one-to-one transition. CP1.BIN counts those later flags as the rescued crew physically present aboard the Unibot and requires all seven before departure.

One further durable flag is specific to the Unibot road network:

The late-game programs also give exact meanings to variables 53 through 65:

ROBOT.BIN initializes variables 53 through 55. CP2.BIN uses variables 56 through 62 as both pylon-completion state and the seven-part Tower gate. FACE.BIN and CP3.BIN alternate on variable 65 to implement the final study prompt and its success/failure branches. See the Unibot and endgame chapter for the complete graph and state machine.

Two lower flags carry the result of a conversation’s study-Bible prompt:

The browser clears both flags before accepting input. Victim scenes branch on them after requesting the study screen, so they are transient result flags rather than durable progression markers. See the conversation-flow chapter for the complete prompt and suspension sequence.

Faith

Faith is variable 21 and uses a 0–10,000 scale, so one displayed percentage point is 100 internal units. The status renderer clamps values above 10,000 and below zero before selecting meter artwork. The F3 detail screen divides by 100 and writes the resulting two integer digits into the mutable Your faith is at 00%. template. A separate Your faith is at 100%. string handles 10,000.

The status-control dispatcher at 0x83B6 passes every Faith or power notice to the ordinary dialogue routine with logical presentation values (24,28,150). The five power messages are executable strings rather than generated labels:

• Helps you hit harder during battle.
• Helps protect you during battle.
• Warns of rooms that are traps.
• Causes dark halls to be lit.
• Lets you fly in some places.

Opcode 0x81 passes an immediate loss to reduce_faith at 0x3979:

• Easy divides the loss by two.
• Normal applies it unchanged.
• Difficult multiplies it by four.
• No-combat mode suppresses the subtraction.

This directly supports the manual’s statement that Easy mode loses faith less readily and connects the installation no-combat option to the same damage path.

Faith exhaustion is checked centrally after input processing rather than by individual scene scripts. handle_faith_depletion at 0x7B12 clamps a negative value to zero and calls enter_game_over_scene at 0x1B86. That routine selects the initialized resource strings OVER and seg, sets the pending-scene state, and starts the accompanying palette effect. The POWER.BIN resource is a separate in-combat study interface and must not be confused with this game-over transition.

One encounter also raises faith rather than reducing it: the Zapper victory subroutine in COMBAT7.BIN alternates direct assignments of 1 and 10,000, ending at the maximum. This implements the special full-faith reward stated in the manual.

Text-record progression state

Each loaded text descriptor has a persistent byte at record offset +4. The save chapter describes its compact checkpoint copy and serialized live records. The bytecode interpreter addresses these bytes by the descriptor’s one-byte selector:

This is the persistent bridge between dialogue/study records and scene control flow. The exact user-facing meaning varies by record: the same mechanism can represent an obtained verse, completed interaction, or another text-related condition.

Save inspection

Show named, nonzero, or checkpoint-different variables and decode the flag bank with:

tools/inspect_save.py CB/DDGAMES.SV9 --variables

The supplied saves have no active boolean flags. Both copies keep variable 16 at -1. Their live copies vary at general-purpose variable 28, and SV9 also has variable 27 set to 5; static evidence does not justify assigning gameplay meanings to those temporary slots.

Relevant executable functions

Offsets use the unpacked load-module convention documented elsewhere in this book.

World Maps

Resource set and naming

DD1.DAT contains 21 MAP members: one for every combination of level letter A through G and difficulty code E, N, or D. The codes mean Easy, Normal, and Difficult, matching the three modes described by the manual. Archive directory entries 215 through 235 contain this complete cross product, and every member expands to exactly 768 bytes.

Scene opcode 0x78 supplies a level letter. Its load_map_resource helper at load offset 0x034F first compares that letter with variable 16. A match returns without touching the mutable grid or exploration state. For a different level, it reads script variable zero as a difficulty index, selects one byte from the literal END, appends .MAP, and loads the resulting archive member into the live grid at DS:5B16. It stores the new letter in variable 16 and clears the sixteen exploration words at DS:72C4. Uses across the scene corpus supply all seven letters. For example, level C on Easy mode loads CE.MAP.

When the global no-mature flag is set, the same loader scans the new grid. A connected cell with low kind 1 through A is replaced by an empty connected hall if either parameter is at least E0: the connection nibble survives, while the low kind and both parameters become zero. Rooms and kinds B through F are not rewritten. The resource corpus contains 67 such cells across twelve Normal and Difficult maps and none in the Easy maps.

This establishes that the policy filters access to mature encounters at the map layer. It does not compact the runtime Bible descriptor table: no-mature DOS saves still contain all 46 bank-C records, including selectors E1 through E4.

Grid layout

Each resource is a headerless, row-major 16×16 grid with three bytes per cell:

cell_offset = 3 * (16 * y + x)

+0  packed connection/location byte
+1  parameter A
+2  parameter B

Coordinates range from zero through 15. Disassembly repeatedly computes 48*y + 3*x, including accesses to the four neighboring cells by adding or subtracting 3 for X and 48 for Y. The current X and Y coordinates are words at DS:7290 and DS:7292.

The first byte has two independently used nibbles:

• The high nibble is a four-direction connection mask: 0x10 is up, 0x20 is down, 0x40 is left, and 0x80 is right. It selects one of 16 connection frames when the map screen is drawn.
• The low nibble selects a location kind. Shipped scripts replace it while preserving the high nibble. More precisely, opcode 0x7B preserves the old high nibble and ORs it with the low byte of a script variable; the handler does not mask that variable to four bits. All shipped callers use only 0x00, 0x05, 0x0A, 0x0B, and 0x0C, so they have the intended low-nibble effect. Several numeric kinds can be correlated with map glyphs and gameplay branches, but a complete symbolic enumeration is not yet justified.

Parameters A and B are also manipulated separately by scene commands. The map screen uses them as text-record selectors for at least location kinds 0x6 and 0xA, consistent with the manual’s statement that stations and communication locations show verse references. Other meanings remain open.

Room encoding and dispatch

A zero connection mask changes the meaning of low kinds 0x1 through 0xF. They form five room classes of three entrance orientations each:

room_class     = (location_kind - 1) / 3
entrance_code  = (location_kind - 1) % 3

Both operations use integer quotient and remainder. The executable writes them to script variables 13 and 14. A static table at load offset 0xED7A contains the same orientation sequence for neighbor detection.

The scene-resource identities provide independent confirmation. ROOM1 loads TRAP, TRAP2, and TRAP3; ROOM2 loads PRAY; ROOM3 loads COMM, COMM2, and FACE1; and ROOM4 loads TUNNEL, TUNNEL2, and MONST1. The hall programs dispatch victim class zero to the seven named victim scenes and patch the final digit of room1 for the other four classes. These five classes are also exactly the T, P, C, J, and V rooms described by the manual and rendered by the map screen.

There is no encoding for a room below a hall cell. The executable supports all 15 class/orientation codes, but the 21 shipped maps use only 14: no map contains a south-entry Jump Tunnel (0xF) with a zero connection mask.

Room codes and connected-hall codes are separate contexts. For example, a zero-mask 0xA is a Communications room, while kind 0xA on a connected hall cell participates in station and post-encounter behavior. Treating the low nibble as one global enum would incorrectly merge these states.

The parameters are likewise class-specific. process_current_map_cell copies the current room’s parameter A and B to variables 17 and 18. Trap scripts use parameter A as a study-prompt selector and clear it after the interaction. When a Trap room is adjacent to a hall, its parameter B becomes one of three contextual prompt values in variables 23 through 25; a correct study result clears that byte in the adjacent cell. This identifies both bytes as mutable encounter state in that class without assuming that they have the same meaning in Prayer, Communications, or Jump Tunnel rooms.

Connected hallway features

When the connection mask is nonzero, the low nibble describes the hallway cell rather than a room. The following meanings have independent script, resource, or transition evidence:

The seven hall programs dynamically patch SML1 to load SML1 through SML7, and their Confront Cyber actions enter POWER. That scene patches combat1 from the current kind and returns to COMBAT1 through COMBAT7. This joins the map kinds, hallway sprites, and combat resources without depending only on visual resemblance. The manual supplies the player-facing Cyber names. CRAB is the Spider: the separate kind-0x9 ambush state conditionally turns into kind 0x5, matching the documented Spider that can drop behind Captain Bible.

Kind 0x6 has the strongest transition evidence. Its special combat victory writes kind 0xA, copies parameter B to parameter A, and clears parameter B. The result is a normal Scripture station whose verse selector is now in the field used by Get Verse. This matches the manual’s Leech Cyber, which sits on top of Scripture stations. Kind 0x7 can be walked under, but its hall branch applies base faith loss 400; defeating it restores full faith in COMBAT7. Both behaviors match the Zapper description.

Cyber parameter A selects the lie used by the confrontation. The covered station’s parameter B is preserved as the verse selector revealed after the Leech is defeated. A normal station uses parameter A, sets the corresponding text-record state, and displays Verse loaded: & when Get Verse succeeds. The dialogue formatter expands & to the selected record’s complete citation - verse text.

Connected kinds 0xC, 0xD, and 0xF control visual or environmental hall states, but their exact player-facing meanings remain unproven. Kind 0x8 does not occur on a connected cell in any shipped map. The inspector leaves all four unnamed rather than folding them into the entity table.

The hall action selectors now also have direct labels:

The three Unlock targets operate on a locked Trap-room door to the right, left, or above the hall. They use the adjacent room’s parameter B as the study prompt and clear it after the correct verse is applied. This separates the door lock from parameter A, which controls the encounter inside the Trap room.

Runtime state and scene commands

The loaded resource becomes mutable gameplay state. The following commands have direct support in their handlers:

Opcode 0x89 updates a separate 16-word row bitmap at DS:72C4:

explored_rows[y] |= 1 << x

The F2 map screen tests this bitmap while rendering its 16×16 display. This agrees with the manual: explored areas appear gold, unexplored areas gray, stations and communication points display verse references, and room types are marked with the letters P, J, T, C, and V.

The normalization routine at 0x0457 proves that resource bytes are not immutable identifiers. In one pass it changes low kind 0x6 to 0xA, moves parameter B to parameter A, and clears parameter B. In another relevant pass, location kinds 0x1 through 0x9 become 0xB. Further control-flow work is needed to name the conditions and gameplay states behind those transitions.

Combat programs perform closely matching transitions at their victory epilogues. COMBAT1 through COMBAT5 and COMBAT7 replace the current low kind with 0xB. The guard encounter in COMBAT6 instead writes kind 0xA and copies parameter B to parameter A. Every RETREAT action jumps around these writes into the shared scene-exit path, so retreat preserves the encounter cell. These scripts prove that 0xB is a completed/cleared form for ordinary combat locations and connect the special 0xA transition to the guard encounter, although the broader uses of both kinds remain more general than those labels.

Save-state correlation

Both the live grid and its checkpoint copy are serialized in every 2,752-byte state file. They occupy file offsets 0x4C0 and 0x7C0, respectively. The supplied DDGAMES.SV3 and DDGAMES.SV4 grids match CE.MAP except for four field changes:

The two packed-byte mutations preserve their high nibbles and replace their low kinds with 0xB, exactly as the normalizer does. This byte-level match independently identifies the saved 16×16×3 tables as world-map state. The other supplied saves have zeroed grids and cannot be assigned to an archive map from this field alone.

Inspection tool

Inspect a resource directly from the archive:

tools/inspect_map.py CB/DD1.DAT --map CE
tools/inspect_map.py CB/DD1.DAT --map CE --cells
tools/inspect_map.py CB/DD1.DAT --map CE --rooms
tools/inspect_map.py CB/DD1.DAT --map CE --hall-features

The compact display prints the low location-kind nibble at every coordinate. --cells adds the packed byte, named connection directions, kind, and both parameters for every nonzero cell. --rooms lists decoded room class, entrance side, and parameters. --hall-features lists only connected cells with proven nonempty features; unresolved environmental kinds remain visible in --cells. Compare a resource with the live grid in a state save with:

tools/inspect_map.py \
  CB/DD1.DAT --map CE --compare-save CB/DDGAMES.SV3

The parser requires an exact 768-byte grid and a valid level/difficulty name. Tests cover all 21 archive members, row-major addressing, connection directions, the complete encoded room domain, the 14 combinations present in the corpus, room/victim scene resources, all seven script level selectors, hall features and combat resources, the hidden-Spider transition, invalid inputs, and the four saved mutations above.

Relevant executable functions and data

Offsets use the unpacked load-module convention documented elsewhere in this book.

Unibot and Endgame Progression

The final sequence is controlled by six scene programs: GANTRY, CP1, ROBOT, CP2, FACE, and CP3. KABLAM and WIN provide the successful ending, while OVER handles both failure paths. Static decoding is sufficient to recover the rescue gate, the complete Unibot road graph, all seven energy pylons, and the Tower confrontation state machine.

Boarding the Unibot

The seven victim scenes set rescue flags 0x3A..0x40. On the gantry, GANTRY.BIN mirrors each set flag to the corresponding crew-present flag:

CP1.BIN counts the seven crew flags in variable 27. With none present it says the craft needs eight people in all; with one through six it reports how many more people are needed. Exactly seven advances to ROBOT.BIN. That scene clears the Sword, Shield, No Trap, Candle, and Flight flags, initializes Unibot variables 53 through 55 to zero, and enters CP2.BIN.

This proves that 0x42..0x48 are not merely generic late-game flags: they are the seven rescued crew members physically present for the Unibot mission.

CP2 data trailer

CP2.BIN is exactly 7,765 bytes (0x1E55). Commands occupy 0x0000..0x1D54; four signed-word tables fill the remainder:

The four exit slots are north, east, south, and west. Turning right increments the current heading and turning left decrements it, both with wraparound. Value 100 is the blocked-exit sentinel. Every nonblocked edge is reciprocal, and each coordinate changes by five units in the expected direction.

The transition values are exposed by the inspector because the script indexes them, but their exact visual interpretation remains unproven. Calling them a render or rotation field would currently go beyond the evidence.

Navigation graph

The road network has 16 nodes. N, E, S, and W are destinations; a dash is blocked.

The three player actions use selectors .r, .l, and .u: turn right, turn left, and move forward. Forward indexes the four-entry adjacency row by the current heading and disables the action when the result is 100.

On scene entry, pylon and Tower node indexes are normalized back to their adjacent road nodes: 3→2, 5→4, 7→6, 8→15, 10→9, 11→12, 13→12, and 14→1. The behavior is exact; treating it as save/resume normalization is a likely interpretation rather than a proven design name.

Script variables and road event

The ordinary-road handler also contains one special event. The first eligible road visit loads ANNOY, removes the player’s verses, sets flag 0x54, and continues without combat. Later road visits skip it. This matches the manual’s Annoy Cyber description, so 0x54 is the high-confidence one-time Annoy-event flag.

Energy pylons

Entering a pylon node maps it to pylon number 1 through 7 and variable 56 through 62. A pylon whose variable is already nonzero is skipped. Otherwise, CP2.BIN loads the matching face artwork and presents one of seven study prompts, selected by 0x11..0x17.

The expected response sets that pylon variable to one, plays the destruction sequence, and shows the corresponding crew member recovering. A wrong response produces a catastrophic defense failure and enters OVER. Thus the seven variables mean both that the pylon was destroyed and that its captive crew member was recovered.

Tower gate and confrontation

Moving into node 14 tests all seven pylon variables. If any is zero, the crew reports that the defenses cannot hold and the scene enters OVER. With all seven set, the Tower trance begins in FACE.BIN.

FACE renders dialogue for the current state; CP3 performs the transition:

The successful resource chain is CP3 → KABLAM → WIN. The failed study response follows CP3 → FACE(state 9) → CP3 → OVER. No additional hidden endgame condition appears in these programs.

Reproducible inspection

After extracting DD1.DAT, print and validate all four embedded CP2 tables:

tools/inspect_unibot.py build/dd1/all/315_CP2.BIN

The inspector rejects the wrong file size, invalid destinations, unknown node types, nonreciprocal edges, a changed pylon set, or a Tower outside node 14. Archive-backed tests independently assert the crew gate, Unibot initialization, seven pylon variables, graph endpoints, Tower states, and ending scene chain.

All findings in this chapter come from expanded BIN bytecode and its embedded tables. Interactive confirmation of the complete final sequence remains useful, but is not required for the recovered control flow.

Audio Formats

Audio resource families

DD1.DAT contains two independent audio families:

The scene interpreter prepares an effect with opcode 0x57, whose operands are an effect number and playback rate. Every nonzero invocation in the recovered command regions uses rate 9,000 and constructs D001.ABT through D041.ABT. Opcode 0x58 then starts or restarts that retained effect. A 0, 0 opcode-0x57 invocation stops active playback and releases the retained sample. Music opcode 0x52 selects a numeric track and play_music_resource constructs either a MUS###.XMI or IBM###.XMI name according to a runtime mode flag.

The decoded effect buffer belongs to the current scene. The common scene-initialization path calls release_sound_effect_buffer, stopping any active instance and discarding the retained sample before interpreting the new BIN. New-session initialization reaches the same cleanup path.

ABT header

The game contains its complete ABT decoder at unpacked load offset 0x92E0. Each member starts with this nine-byte header:

All 41 resources use a 9,000 Hz rate, delta blocks of 32 samples, and codec identifier 2. The auxiliary word is 128 in 35 files, 32 in four, 64 in one, and 320 in one. Its purpose remains unknown; the decoder explicitly consumes and discards it.

The decoded population contains 412,282 samples, or approximately 45.809 seconds at 9,000 Hz. Samples are unsigned eight-bit mono PCM. The smallest effect is 185 samples and the largest is 32,933 samples.

ABT command stream

The initial sample is followed by variable-length commands until the declared sample count has been produced:

Delta mode 1 uses one-bit codes and the signed table [-step, +step]. Mode 2 uses two-bit codes and starts at -2 * step. Modes 0 and 3 use four-bit codes and start at -8 * step. Each table advances by step, skips zero, and keeps the executable’s signed-byte wraparound. Packed codes are read most significant bits first. Each delta is added to the preceding output and clamped to the inclusive range 0 through 255.

Across the archive, exact decoding encounters:

Every member produces its declared sample count and consumes its compressed input exactly, with no unused trailer.

QEMU validation of D003.ABT

The startup sequence plays D003.ABT during the logo. QEMU was launched with the visible Cocoa display, silent audio backend, and GDB remote debugging. A breakpoint at physical address 0xA499 stopped the process at 0627:4229, immediately before the decoded effect is submitted to interrupt 66h.

The live state structure at DS:A0DE contained buffer pointer 5A45:0000, sample count 0x2368 (9,064), callback 14E1:79EC, and rate 0x2328 (9,000). Dumped 9,064 bytes from physical address 0x5A450. The live buffer and independently decoded host output are byte-for-byte identical:

ca97ad22acf3cc39d078b619168fa026deb1606082999bfb8b9a1aac4957422b

This validates the header, every command family exercised by D003.ABT, code bit order, signed delta table, clamping behavior, and final sample count against the running DOS program.

Converting ABT to WAV

Inspect an effect or write standard unsigned eight-bit mono PCM:

tools/convert_abt.py build/dd1/all/306_D003.ABT
tools/convert_abt.py \
  build/dd1/all/306_D003.ABT \
  --output build/audio/d003.wav

The decoder rejects truncated commands, output overruns, invalid block geometry, sample-count mismatches, and unused input bytes. The WAV rate comes from the ABT header rather than being hard-coded.

XMI: IFF/XMIDI music

The archive has matching numeric families MUS001.XMI through MUS016.XMI and IBM001.XMI through IBM016.XMI. Every file has two top-level IFF containers. IFF sizes are big endian, while the two-byte sequence count in INFO is little endian:

FORM XDIR
  INFO  01 00
CAT  XMID
  FORM XMID
    TIMB
    EVNT

All files declare exactly one sequence and contain one FORM XMID. TIMB is an even-length list of two-byte patch/bank pairs. EVNT uses XMIDI’s MIDI-like event representation:

• bytes below 0x80 before an event are additive delay values;
• channel statuses carry fixed-size parameters;
• note-on events add a variable-length duration after note and velocity;
• system-exclusive and meta events use variable-length payload sizes; and
• meta event FF 2F 00 ends the track.

Eleven EVNT chunks include one zero padding byte after end-of-track. One track also contains controller parameter 0xFF, so the validator preserves the game data instead of imposing a generic seven-bit MIDI parameter check.

The 32 sequences contain 7,087 events, including 6,608 duration-bearing note events and 173 TIMB entries. MUS001.XMI, loaded during startup, contains 12 timbres, 446 events, 432 notes, eight meta events, and total additive delay 3,016.

Inspect and validate a sequence with:

tools/inspect_xmi.py build/dd1/all/267_MUS001.XMI

The tool validates container sizes and padding, directory counts, form and chunk order, event boundaries, variable-length quantities, and end-of-track.

Executable routines

Offsets use the unpacked load-module convention documented elsewhere in this book.

The separate sound-driver chapter maps the DIGPAK/MIDPAK interrupt interface, the exact playback structure receiving decoded ABT data, and the installed OPL timbre library.

The Rust SDL frontend parses the same EVNT stream at XMIDI’s 120 Hz timebase and renders it on a music stream separate from digital effects. Its portable two-operator synthesizer uses the transpose, operator multiplier, total-level, envelope, waveform, and connection fields from the original SOUND.4 timbres. It intentionally approximates the installed driver’s analog OPL output rather than emulating a YM3812 chip cycle by cycle. Completed PCM is cached per music identifier and queued repeatedly until a stop or replacement request.

An exact event inventory of the 16 MUS resources found only note-on, program-change, and controller events—no pitch-bend or embedded XMIDI loop controllers. Controller 0 selects banks, controller 7 sets volume, and controller 10 supplies stereo pan which the mono OPL renderer may ignore. MUS016 additionally contains standard RPN/NRPN setup events but no pitch bends for those settings to modify. Percussion uses bank 0x7F; its directory patch selects the drum timbre and the timbre record’s signed note byte supplies the oscillator pitch.

Sound Drivers and MIDPAK Timbres

Installed driver set

SETSOUND.BAT preserves the original installer names used to create the otherwise anonymous SOUND.* files:

The identities do not depend only on the batch file. SOUND.1 contains the signatures DIGPAK, Sound Blaster 16, John W. Ratcliff’s credit, and a version 3.40 identification string. SOUND.3 contains MIDPAK, MIDI Sound Package, and the Audio Solution credits. SOUND.2 begins with a Miles Design copyright string and identifies Creative Labs Sound Blaster Pro FM internally.

Interrupt interface

Both resident packages hook software interrupt 66h. Captain Bible contains 34 literal CD 66 instructions: 31 in small API wrappers, one in the driver detection routine, and two in bootstrap paths. The request number is the complete AX value. The recovered names agree with the contemporary Ralf Brown Interrupt List’s INT 66 catalog.

DIGPAK wrappers

The documented DIGPAK sound structure is 12 bytes: a far audio-data pointer, 16-bit byte count, far playback-status pointer, and 16-bit frequency. This exactly explains the live structure at DS:A0DE used by play_sound_effect_resource. The game first invokes 068A to preformat the independently decoded ABT PCM and then 068B to play it.

MIDPAK wrappers

The bootstrap call at 0xABBB uses service 0710: BX is the segment of the loaded SOUND.2 .ADV, CX is zero, and DX:SI points to SOUND.4. This matches the MIDPAK load-driver contract exactly. play_music_resource then stops playback, sets volume, brackets registration with sleep/wake, registers the XMI byte buffer with 0704, and plays sequence zero with 0702.

The options path performs a separate stop/restart lifecycle. Turning music off calls the stop wrapper; turning it back on wakes MIDPAK and starts sequence zero from the retained registration. play_music_resource returns immediately when asked for the already current identifier, and identifier zero stops without registering another resource.

The outer game loop at 0x8C35 calls play_music_resource(0) every time main_menu_and_game_loop returns. A pending scene name or state flag 40 makes the inner loop return through 0x8740, so normal scene transitions stop music and clear the current identifier before the successor is initialized. This matters even when two consecutive scenes request the same music number: the second request is no longer rejected as an already-current no-op.

The order of checks in play_music_resource gives the disabled case different semantics. It compares the requested and current identifiers first, then returns before updating the identifier when the music enable word at 0x48 is zero. A transition while muted consequently retains the preceding registration. This is consistent with the options path, which can restart that registration when music is turned on again.

QEMU call and return evidence

The QEMU plugin now recognizes both int 21h and int 66h and reads the live EAX register at entry and return. QEMU represents the first x86 register with opaque handle value zero; treating that value as a valid handle was necessary to recover result AX rather than falling back to instruction inference. Return records also include the other general and segment registers.

A visible, host-muted startup capture produced this capability exchange:

CALL ... pc=0627:ABED int=66 AX=068C ...
RET  ... from=0627:ABED int=66 AX=0FC1 BX=2E88 CX=010C ...
         result="Sound Blaster 16"

The same query through wrapper 0x8F67 returns the same mask and ID pointer. Service 0710 returns AX zero after loading the FM driver and timbres. Observed DIGPAK status calls return both 0 and 1, matching idle and playing; MIDPAK 070C returns 1 while the title sequence is active. All captured driver returns have carry clear.

The current bounded trace contains 159 DOS calls and 7,844 driver calls. Most driver traffic is deliberate polling: 7,831 calls to DIGPAK status while the slowed one-instruction translation mode runs. Its ignored artifact is build/qemu-trace/dos-calls.log, SHA-256 ae9d9b5952171f35d9dff8a75548e399a15fb01ee27d4058b2800891766404a6.

SOUND.4 global timbre library

The file consists of a six-byte directory entry repeated until FF FF, then the timbres at their absolute offsets:

The terminator ends at 0x440, which is also the first timbre offset. There are 128 bank-zero melodic entries for patches 0 through 127 and 53 percussion entries for notes 35 through 87 in bank 0x7F.

Every timbre is exactly 14 bytes and every directory offset is contiguous:

This layout agrees byte-for-byte with the AIL structures recovered from Miles source by OPL3BankEditor’s pinned AIL parser. No padding or unreferenced trailer remains: 181 * 14 bytes extend from 0x440 to the exact 3,622-byte end of file.

Validate or list the bank with:

tools/inspect_midpak_ad.py CB/SOUND.4
tools/inspect_midpak_ad.py CB/SOUND.4 --list

The parser rejects a missing directory terminator, out-of-range or duplicate patches, a gap or overlap between records, unsupported record lengths, and a truncated final record.

Text Resource Formats

Captain Bible divides its study and gameplay text between translation-specific verse indexes inside DD1.DAT and translation-independent companion files named DDLA through DDLG and DDLR. The executable joins them at runtime.

Resource families

The first character of an extensionless archive name selects a Bible translation: