Logic bytecode interpreter notes

This page records clean-room observations about the interpreter for logic payload bytecode. It is based on local disassembly of build/cleanroom/AGI.decrypted.exe, the runtime tables in SQ2/AGIDATA.OVL, and decoded SQ2 logic payloads from an explicitly selected local game directory.

For a compact generated coverage index that lists every action opcode, every known condition opcode, operand shapes, and current evidence level, see Logic Opcode Evidence Matrix.

Runtime tables

After startup, DS points at AGIDATA.OVL. Both bytecode dispatchers use tables in that overlay rather than in the executable image.

The action dispatcher at image offset 0x02c4 calls through:

handler = u16le(DS:0x061d + opcode * 4)

Each action-table entry is four bytes:

u16 handler_image_offset
u8  fixed_operand_count
u8  variable_operand_bitmask

The condition dispatcher at image offset 0x07e3 calls through:

handler = u16le(DS:0x08fd + opcode * 4)

Each condition-table entry has the same four-byte shape. The condition scanner uses the third byte as the fixed operand count when it needs to skip an unexecuted condition.

The fourth byte is an operand metadata bitmask. From decoded handlers, bit 7 corresponds to operand 0, bit 6 to operand 1, and so on. A set bit means that the corresponding operand is a variable slot/reference rather than an immediate literal for table-aware decoding. The dispatcher does not apply this bitmask generically; each handler still consumes operands directly and decides whether a variable slot is read from or written to.

Examples:

AGIDATA.OVL contains valid-looking condition entries for opcodes 0x00 through 0x12. Bytes after that are strings and zero-filled data, even though the dispatcher only rejects condition opcodes >= 0x26. In the current local SQ2 scan, condition opcodes above 0x12 were not needed for successfully parsing ordinary condition lists.

Main interpreter loop

The main logic interpreter is at image offset 0x293c. It starts from the current instruction pointer stored in a logic cache record:

si = logic_record[0x06]

loop:
    opcode = *si++

    if opcode == 0x00:
        return si

    if opcode == 0xfe:
        delta = s16le(*si); si += 2
        si += delta
        continue

    if opcode == 0xff:
        evaluate_condition_then_maybe_execute_block()
        continue

    execute_action(opcode)
    if action returns si == 0:
        return 0
    continue

The 0xfe branch is visible at image offsets 0x2953..0x295a: it reads a little-endian word with lodsw and adds it to SI.

Action execution is delegated to 0x02c4. That dispatcher rejects opcodes 0x00 and 0xfc..0xff, reports an error for opcodes above 0xaf, then calls the action table at DS:0x061d.

Putting the observed dispatch ranges together:

Cross-version note: the local Gold Rush / AGI v3 interpreter accepts action opcodes through 0xb5. Those slots are documented below as GR-specific extensions; the invalid-range statement above remains the SQ2 / AGI 2.936 behavior.

Shared opcode version note: the local Gold Rush / AGI 3.002.149 interpreter keeps the same parser contracts as SQ2 for shared action opcodes 0x00..0xaf, but source comparison found the following behavior-level deltas. These are version observations, not replacements for the SQ2 rows in the main catalog.

The motion-mode 4 observation is intentionally narrower than an ordinary script-level opcode claim. Static comparison shows GR’s mode dispatcher accepts object byte +0x22 == 4 and routes it to the same target-direction helper used for mode 3. A copied-interpreter QEMU probe then patches only the generated fixture’s action-0x51 setup byte from mode 3 to mode 4; that instrumented case renders identically to the unmodified mode-3 fixture while a stationary control remains different. No ordinary bytecode setter for mode 4 has been observed yet.

Top-Level Cycle Timing

The top-level engine cycle observed at code.engine.main_cycle (0x0150) wraps logic execution with object and input/update passes. The current source model is:

1. Run several input, sound, and display-maintenance helpers. One of these is code.engine.wait_for_cycle_counter (0x7f78), which reads byte DS:0x0013 (v10), waits until word [0x1784] is at least that value, then clears [0x1784]. Lower v10 values therefore reduce the top-level cycle wait; generated timed-carousel fixtures use v10 = 1 for fast but still capturable pacing.
2. Mirror direction state between object 0 byte +0x21 and global byte [0x000f], depending on global word [0x0139]: when [0x0139] == 0, copy object 0 +0x21 to [0x000f]; otherwise copy [0x000f] back to object 0 +0x21.
3. Call code.motion.pre_mode_and_boundary_update (0x0644). This pass scans active/update-eligible objects whose byte +0x01 == 1, dispatches motion mode byte +0x22 through code.motion.dispatch_mode_step (0x067a), and applies rectangle-boundary checks through code.motion.rectangle_boundary_check (0x06d9) when enabled.
4. Invoke logic 0 through code.logic.call_logic (0x12ae). Nested logic calls use the same helper but preserve and restore the previous current-logic record.
5. If byte [0x1757] is zero, call code.object.frame_timer_update (0x0563). That pass performs automatic direction-based group selection, frame-timer callbacks, movement update code.motion.update_objects (0x150a), and update-list draw/dirty-rectangle refresh. If [0x1757] is nonzero, the top-level loop skips 0x0563 for that cycle.

This ordering matters for generated probes and for compatibility. After logic 0 returns, code.engine.main_cycle also restores object 0 byte +0x21 from global byte [0x000f] before continuing the frame/update path. A logic script that writes object 0 +0x21 after the top-of-cycle mirror is therefore too late to seed [0x000f] for the following cycle unless another helper also updates the global direction byte. For example, automatic group selection observes object byte +0x01 before code.motion.update_objects later decrements that countdown byte. A one-shot script write of +0x01 = 2 therefore delays direction-based group selection by one later cycle rather than suppressing it permanently.

SQ2 logic 0 is the global per-cycle script. A source pass over the actual SQ2 logic resource shows that logic 0 handles global menu/input/status work first, then calls the current room script with action 0x17 (call_logic_var) using byte variable 0 at logic bytecode offset 0x053e. Room logics sampled from logic resources 1 through 10 begin with an if flag 5 entry block that loads views, pictures, sounds, and object state for that room, then fall through to normal per-cycle behavior. This means room-switch compatibility fixtures need to model both pieces: the engine’s room-switch helper and logic 0’s later call_logic_var(v0) room dispatch.

Conditional blocks

Opcode 0xff introduces a condition list. The condition parser uses these marker bytes:

The condition parser keeps two state bytes in BX. BL is the pending inversion flag for 0xfd; after each condition result is XORed with BL, the parser clears BL. BH tracks whether parsing is inside an OR group.

Observed 0xfc behavior:

• If BH == 0, 0xfc starts an OR group by setting BH = 1.
• If BH != 0, a second 0xfc means the OR group ended without a true term, so the whole condition list fails.
• A false condition inside an OR group continues scanning for another OR term.
• A true condition inside an OR group clears BH, skips the remaining OR terms until the next 0xfc, then resumes normal condition parsing.
• A false condition outside an OR group fails the whole condition list.
• A true condition outside an OR group simply advances to the next condition.

When all required conditions pass, execution continues with the following bytecode. When the condition list fails, the interpreter scans forward without executing actions until it finds a block-ending 0xff, then reads a little-endian relative offset and adds it to SI.

When a condition list has already failed, or when a true OR-term needs to skip the rest of its OR group, the condition-list scanner must know condition instruction lengths. For most condition opcodes it uses the fixed operand count in the condition dispatch table. There is a special case for condition opcode 0x0e (input_word_sequence): the scanner reads one count byte and skips count * 2 additional bytes. This special case appears in the condition skip paths at image offsets 0x29af..0x29b8 and 0x29d7..0x29e0.

Condition table

The current DS:0x08fd condition table entries are:

The bytes after condition-table entry 0x12 decode as string/data bytes and then zero fill if forced through the same 4-byte entry parser. Although the condition dispatcher only rejects opcodes >= 0x26, no valid local condition list uses opcodes 0x13..0x25; for this build they are treated as invalid/reserved rather than real predicates.

Condition-list byte ranges:

The first seven handlers directly expose byte variable comparisons. The byte variable array begins at DS:0x0009.

The handler reads two byte operands and passes them to helper 0x0eac. Helper 0x0eac builds two temporary normalized strings through helper 0x0ef8, then compares the resulting zero-terminated byte strings exactly. The string-slot address is computed as 0x020d + slot * 0x28.

The 0x0ef8 normalization step:

• walks the source slot until a zero byte;
• skips bytes present in the zero-terminated table at DS:0x094b;
• in local SQ2 data, DS:0x094b contains space, tab, ., ,, ;, :, ', !, and -;
• converts ASCII uppercase A..Z to lowercase a..z through helper 0x4fea;
• writes a zero terminator to the temporary buffer.

Unlike action 0x75 (parse_string_slot), this predicate does not parse dictionary words and does not use the parsed-word tables. It is a direct case-insensitive comparison after dropping the listed punctuation/spacing bytes.

Condition opcodes 0x0b (object_left_baseline_in_rect), 0x10 (object_width_baseline_in_rect), 0x11 (object_center_baseline_in_rect), and 0x12 (object_right_baseline_in_rect) all load an entry from a 43-byte structure array rooted at [0x096b] using the first operand as an index. They compare that object’s baseline position or horizontal extent against four subsequent byte operands:

arg0: object index
arg1: left bound
arg2: top/Y bound
arg3: right bound
arg4: bottom/Y bound

The shared helper at 0x091a loads:

object = [0x096b] + arg0 * 0x2b
dh = object[+0x03]
ch = object[+0x03]
dl = object[+0x05]

The common comparison at 0x08f0 returns true when:

dh >= arg1
dl >= arg2
ch <= arg3
dl <= arg4

The four handlers differ only in how they choose dh and ch before the comparison:

Flag helpers use a bitfield rooted at DS:0x0109. Helper 0x7511 computes:

byte_address = DS:0x0109 + flag_number / 8
mask = 0x80 >> (flag_number & 7)

Helper 0x74ee sets the bit, 0x74f4 clears it, 0x74fc toggles it, and 0x7502 tests it. Initialization helper 0x752a clears 0x20 bytes starting at DS:0x0109.

Condition opcode 0x0e (input_word_sequence) is the most common condition in the local SQ2 scripts. Its bytecode operands are variable length:

u8 count
u16le word_id[count]

Handler 0x095c compares those word IDs with a parsed input-word buffer rooted at DS:0x0c7b; word [0x0ca3] is used as the parsed-word count. The handler returns false without consuming the word list when the parsed-word count is zero, when flag 4 is already set, or when flag 2 is clear. Otherwise it walks the operand word IDs and the parsed input words together. Operand word 0x270f terminates the test successfully and skips any remaining operand words; operand word 0x0001 behaves as a wildcard for one parsed word. On a full match the handler sets flag 4 and returns true; on a mismatch it skips the remaining operand words and returns false. Because parser failures store a nonzero count/error-position and set flag 2, a terminator-only pattern can match an unknown-token parse state; QEMU batch parser_unknown_terminator_001 confirms this source-modeled edge.

Parsed input producer

Action 0x75 (parse_string_slot) is the observed producer for the parsed-word state consumed by condition 0x0e (input_word_sequence). It reads a string-slot index, accepts only slots 0..11, and passes fixed string slot 0x020d + slot * 0x28 to parser helper 0x18ac. Before parsing it clears flags 2 and 4.

Helper 0x18ac clears two 20-byte word tables:

0x0c7b: parsed dictionary word IDs, up to 10 words
0x0c8f: pointers to the normalized words in buffer 0x0ca7, up to 10 words

It normalizes the source string through helper 0x199d into buffer 0x0ca7. The normalization step:

• treats bytes from DS:0x0c67 as separators. In SQ2 this string is ,.?!();:[]{}.
• treats bytes from DS:0x0c75 as ignored punctuation. In SQ2 these bytes are 0x27, 0x60, 0x2d, and 0x22.
• collapses runs of separators to one space.
• drops ignored punctuation instead of making a new word.
• trims a trailing space and writes a zero terminator.

Helper 0x1a6b then looks up each normalized word in WORDS.TOK, whose loaded base pointer is stored at [0x0ca5]. The file starts with 26 big-endian word offsets, one for each lowercase initial letter. A zero offset means no words for that initial. Dictionary entries are prefix-compressed:

u8 prefix_len_from_previous_decoded_word
encoded suffix bytes, last byte has bit 7 set
u16be word_id

For each suffix byte, (byte & 0x7f) ^ 0x7f gives the decoded lowercase character. The high bit only marks the final suffix byte. Local inspection of SQ2/WORDS.TOK finds 1,099 entries; for example look has word ID 0x0002, get has word ID 0x0005, and anyword has word ID 0x0001.

Parser result handling in 0x18ac:

• Recognized words with nonzero IDs are appended to 0x0c7b, and their normalized-word pointers are appended to 0x0c8f.
• Word ID zero is ignored; single-letter a and i followed by a space or terminator are handled this way, as are entries whose dictionary ID is zero. Ignored zero-ID words do not consume one of the ten parsed output slots.
• An unrecognized token stores its pointer in the next 0x0c8f output slot, sets byte variable [0x0012] and word [0x0ca3] to parsed_nonzero_word_count + 1, and stops parsing. Thus an unknown word after ignored zero-ID words such as the still reports output slot 1, not the raw token ordinal.
• If at least one token position is produced, flag 2 is set. Condition 0x0e (input_word_sequence) later sets flag 4 after a successful command-pattern match.

Raw event queue

Condition 0x0d (raw_key_event_available) is separate from parsed-word matching. Handler 0x09be first checks byte variable [0x001c]; if it is already nonzero, the condition returns true. Otherwise it calls helper 0x459e until that helper returns something other than 0xffff:

event = dequeue_event()                         # 0x44f9
if no event:
    return false
normalize_enter_escape(event)                   # 0x4634
if event.type == 1:
    return event.value
return 0xffff

When 0x459e returns a nonzero key-like value, condition 0x0d (raw_key_event_available) stores the low byte in [0x001c] and returns true. A zero return means no available event and the condition returns false. A 0xffff return means a non-key event was discarded and polling should continue.

QEMU fixture raw_key_condition_001 validates this predicate dynamically. The generated logic draws only when condition 0x0d succeeds, does not install any script key mapping with 0x79, and then sends a plain x key through the QEMU monitor. The original interpreter capture matched the validation draw, proving that the raw type-1 event path can satisfy 0x0d directly.

The queue itself is a 20-entry circular buffer of 4-byte records:

storage: 0x11ba .. 0x1209
[0x120a]: write pointer
[0x120c]: read pointer

record +0x00: event type word
record +0x02: event value word

Helper 0x44a9(type, value) enqueues a record and fails if advancing the write pointer would collide with the read pointer. Helper 0x44f9() dequeues one record, returning zero when the queue is empty.

The keyboard IRQ hook at image 0x6036 also feeds this queue. For selected scan codes in the range 0x47..0x51, it checks an enable table at 0x1519 + (scan - 0x47) and a pressed latch at 0x1524 + (scan - 0x47). On a key release, if the latch was set, it clears the latch and tests byte [0x1530]. When that byte is nonzero, the hook enqueues event (type=2, value=0) through code.input.enqueue_event (0x44a9). Action 0xad increments [0x1530], so it acts as a source-backed gate/count for this release-event path.

Keyboard helper 0x5a89 uses BIOS int 16h: it returns zero if no key is waiting, otherwise reads one key. If the ASCII byte is nonzero it clears AH and returns just that byte; if ASCII is zero, the BIOS scan-code word is returned intact.

Helper 0x467f drains available BIOS key events through 0x5a89 and enqueues them:

• If helper 0x46b6 finds the returned key word in table DS:0x16b3, it enqueues type 2 with the mapped value.
• Otherwise it enqueues type 1 with the raw key word.

The local DS:0x16b3 table maps BIOS arrow/keypad scan words to direction-like values:

The adjacent hardware/display remap table at DS:0x16d7 maps single-byte numeric keypad values to the same type-2 movement values when display adapter word [0x112e] == 2: 0x38, 0x39, 0x36, 0x33, 0x32, 0x31, 0x34, and 0x37 map to 1..8. The trailing 0x35 -> 0 entry is present in the table but does not enqueue a movement value.

Helper 0x4634 normalizes some multi-byte key words after dequeue: values 0x0101 and 0x0301 become 0x000d, while 0x0201 and 0x0401 become 0x001b.

Helper 0x4566(event_record) performs a script-configured remap for type-1 events. It scans four-byte slots rooted at 0x0145; when slot word +0 equals the event value, it changes the event type to 3 and replaces the value with slot word +2. Action 0x79 (map_key_event) appends entries to this table. An attempted QEMU probe mapping 0x5000 through 0x79 did not set the target status byte when driven with monitor sendkey down; this is recorded as a QEMU/input-instrumentation gap, not as evidence against the source table.

When display adapter word [0x112e] == 2, helper 0x46e8 can also remap type-1 event values through table DS:0x16d7, changing the event type to 2. The local table maps ASCII digits to direction-like values:

Action table

The action table at DS:0x061d has entries for opcodes 0x00..0xaf. The main dispatcher only executes opcodes 0x01..0xaf; 0x00 terminates the current logic loop and 0xfc..0xff are structural bytes.

All action-table entries through 0xaf now have local labels. Some labels remain deliberately implementation-shaped where the handler’s state mutation is clear but the user-facing command name is not.

Coverage audit:

• tools/disassemble_logic.py labels every action byte 0x00..0xaf.
• 0x00 is a structural byte handled by the main interpreter loop, not by the normal action dispatcher.
• 0xfc..0xff are structural bytes and are rejected by the action dispatcher.
• The current condition catalog labels all valid-looking condition-table entries 0x00..0x12; bytes 0x13..0x25 are treated as reserved/invalid in this SQ2 build even though the dispatcher only rejects >= 0x26.

Examples of action entries:

This table entry points at the same no-op helper used by action 0x7f, but the main interpreter loop handles opcode byte 0x00 before entering the action dispatcher. Runtime opcode 0x00 returns the instruction pointer immediately after the terminator. It does not write the logic record’s resume-pointer field. Later bytes in the same logic payload can still be reached by a jump from earlier code.

The action dispatcher itself does not use the operand-count byte; handlers consume operands directly from SI and return the next SI in AX. The table metadata is used by scanner/debug paths that need to skip or display bytecode.

Decoded action families

Variable action handlers directly operate on the byte array rooted at DS:0x0009.

Flag action handlers use the same bitfield helpers as condition opcodes 0x07 and 0x08.

Several object/view actions use entries in the 43-byte structure array rooted at [0x096b]. Field names remain provisional; these notes record observed storage and calls rather than assigning final game-level names.

Helper 0x3ae7 finds a cached resource record via 0x3979, stores the resource payload pointer at object field [+0x08], stores the selected resource number at byte [+0x07], copies byte [payload+0x02] to object byte [+0x0b], then calls 0x3bb7. Helper 0x3bb7 validates object field [+0x08], checks its second argument against byte [+0x0b], then calls 0x3c1b and 0x3ccb to update derived object fields.

Resource and interpreter-control actions observed so far:

QEMU fixture resource_lifecycle_003 validates several resource lifecycle paths with synthetic resources:

• 0x15 (load_logic_var) can load a variable-selected logic resource before 0x16 calls it.
• 0x1c (overlay_picture_var) requires the target picture to have already been loaded with 0x18. The overlay changes logical picture state, but the composed picture was not visible in the QEMU capture until 0x1a (show_picture_like) ran afterward.
• 0x1b (discard_picture_var) can discard a loaded picture and allow a later reload/overlay path.
• 0x20 (discard_view) and 0x99 (discard_view_var) can discard a loaded view; reloading that view with 0x1e then permits normal drawing.
• 0x1f (load_view_var) is validated by starting without the usual preloaded view 11, setting a variable to 11, executing 0x1f, and then successfully drawing that view.

QEMU fixture menu_sound_001 dispatch-smokes 0x62 (load_sound) followed by 0x64 (stop_sound_or_clear_sound_state) with sound resource 1. QEMU fixture sound_completion_001 adds a behavior assertion across 0x62, 0x63, and 0x64: it first loads sound 1 with 0x62, starts it with completion flag operand 77 through 0x63, then clears sound state with 0x64 and draws only after flag 77 is set. This validates the load/start/stop completion-flag contract for those opcodes, but it does not yet model audio output or asynchronous playback timing.

QEMU fixture priority_diag_sound_001 validates the same stop-flag behavior in the narrower priority/diagnostic batch: after 0x63 has associated completion flag 77 with sound 1, 0x64 sets that flag while clearing sound state. The same batch validates 0x1d as a blocking priority/control display that returns after Enter and 0x85 as an object-diagnostics display action that returns after Enter.

Source mapping clarifies the sound state transition. Action 0x63 first calls the same stop helper used by 0x64, then reads the sound resource number and completion flag operand. It stores the flag number in [0x126a], clears that flag, locates an already loaded sound resource through helper 0x50d8, reports an error if it cannot be found, and calls the hardware/driver start helper 0x7f96 with the located record. Action 0x64 is a thin wrapper around code.sound.stop_or_clear_state; that helper only sets the configured completion flag when active-state word [0x1258] is nonzero, then clears the active-state word and calls the hardware/driver stop helper 0x80af.

The sound loader and driver-start helpers also reveal the sound resource container. code.sound.load_resource reads the payload through the sound directory, stores the raw payload pointer at cache-record +0x04, then reads four little-endian words from the payload header and stores four derived payload-relative channel pointers at record offsets +0x06, +0x08, +0x0a, and +0x0c. code.sound.driver_start copies those four pointers into the runtime channel pointer table, initializes four countdown words to 1, initializes active/tone state words, and marks sound state active at [0x1258]. The driver tick reads duration u16, treats 0xffff as a channel terminator, otherwise reads a 16-bit tone/control word followed by one control byte whose low nibble is the observed attenuation/control value.

The timer interrupt hook calls code.sound.driver_tick while [0x1258] is nonzero. code.sound.driver_tick first tests flag 9 through the shared flag helper; if flag 9 is clear, it immediately runs the stop/core completion path. When playback is allowed, the tick loop advances channel 0 only for hardware selector [0x112e] values 0 and 8, and advances channels 0 through 3 for other observed selector values. Each channel’s countdown starts at 1, so its first event or terminator is consumed on the first tick. Event durations are stored as 16-bit countdown values. Duration zero would wrap before the next record read; no present SQ2 sound resource uses duration zero. Natural completion occurs when all active channels have consumed 0xffff terminators, which reaches the same stop/core path that clears active state and sets the configured completion flag. Tone-to-frequency conversion, attenuation envelopes, and hardware port effects remain provisional.

Resource Event Log

The engine keeps a compact replay log for resource and transient-display work that must be reconstructed after a restore or display-mode rebuild. The log is not a general trace. It records the operations needed to rebuild persistent room state from a reset cache, and some helper paths intentionally disable recording while doing temporary work.

Each entry is a two-byte pair:

u8 kind
u8 value

data.event.pair_capacity ([0x0141]) is the maximum number of pairs. code.event.reset_pair_buffer allocates capacity * 2 bytes if the base pointer is zero, stores the base at [0x1707], resets the write pointer [0x1709] to the base, and clears data.event.pair_count ([0x0143]).

code.event.record_pair appends only when both gates allow it:

• flag 7 must be clear;
• data.event.recording_enabled ([0x170d]) must be nonzero.

When appending, it checks the write pointer against base + capacity * 2, reports error code 0x0b on overflow, writes the low bytes of (kind, value), advances the write pointer by two, and increments the pair count. It also maintains data.event.pair_high_water ([0x170f]) from the current write distance; the heap/status diagnostic displays this value.

Known event kinds:

Kind 5 is a four-pair packet rather than a single resource event. Helper 0x2d52 first records (5, 0), then records ([0x0eae], [0x0eaf]), ([0x0eb0], [0x0eb1]), and ([0x0eb2], [0x0eb3]). Restore replay consumes those three following pairs and writes them back to the same staged globals before calling 0x2d52.

Restore-time replay at code.restore.replay_resource_events stops sound, resets room caches, disables event recording, prepares the replay cursor, then walks pairs with code.event.next_replay_pair. Disabling recording is what prevents the replayed loads/discards from appending duplicates to the log. The event-kind dispatch table lives at image 0x6915; a linear disassembly can misread the first post-table instruction as data. When disassembled at the loop-exit target, image 0x6927 is call 0x706d, so replay re-enables event recording immediately after code.event.next_replay_pair returns zero and before it rebinds object views. After that it restores object flags saved around the cache reset, refreshes the display, and redraws text/input state. This source finding explains the earlier QEMU observation that recording was enabled again by the following script action.

Because kinds 6 and 7 enter the ordinary discard helpers, replay reproduces the same ordered family truncation. A later kind 1 or 2 pair can retain a resource again after that truncation; restore therefore rebuilds retention order from the active pair sequence rather than from an unordered final set.

The temporary view-resource display actions 0x81 and 0xa2 also call code.event.disable_recording before their internal load/display/discard sequence, then call code.event.enable_recording before returning. This keeps view preview/text display from becoming part of the room restore model.

Room/state switch helper 0x1792, reached by actions 0x12 (switch_room_like) and 0x13 (switch_room_like_var), first stops active sound state, resets heap/update-list state through code.heap.reset_dynamic_state, clears parser/input state, initializes the resource/event pair buffer, and enables resource/event pair recording. It then resets all object records from [0x096b] to [0x096d]. For each 43-byte record it clears active/update bits 0x0001 and 0x0040, sets bit 0x0010, clears pointer fields +0x08, +0x10, and +0x14, and stores 1 in bytes +0x00, +0x01, +0x1e, +0x1f, and +0x20. The last three are the step-size byte and the frame-timer reload/current bytes; they are seeded to one, not zero.

After the object reset, helper 0x10d0 resets the room resource caches. It preserves the first logic cache record by writing zero to that record’s next link, then clears the view cache root [0x0ffa], sound cache root [0x125a], and picture cache root [0x120e]. The room-switch helper then sets the object-boundary flag word [0x0139] = 1, clears word [0x013d], restores the horizon-like global [0x012d] to 0x24, copies current room byte variable 0 to previous-room byte variable 1, writes the destination room to byte variable 0, clears object-boundary bytes [0x000d] and [0x000e], copies object 0’s view/resource byte +0x07 to byte variable 16, refreshes object/resource state, loads the destination logic through code.logic.load_cached, reloads optional trace logic [0x1d12] when configured, handles the entry-boundary selector, sets flag 5, refreshes display/resource state, redraws the status line, redraws the input line, and returns zero.

The zero return is important. code.engine.main_cycle calls logic 0 through code.logic.call_logic(0); if that call returns zero, it clears temporary room-boundary variables and immediately calls logic 0 again instead of continuing the post-logic frame/update path. This explains why one-shot synthetic room-switch probes that draw after 0x12/0x13 are the wrong shape: the switch action intentionally aborts the current bytecode stream so the next logic-0 pass can perform entry initialization and room dispatch.

Entry-boundary selector byte variable 2 (DS:0x000b) is interpreted after the destination logic is loaded: 1 places object 0 Y at 0xa7, 2 places X at 0, 3 places Y at 0x25, and 4 places X at 0xa0 - object_width; the byte is then cleared.

In script terms, byte variable 0 (DS:0x0009) is the current room, byte variable 1 (DS:0x000a) is the previous room, and byte variable 2 (DS:0x000b) is the entry-boundary selector consumed by the switch helper. The helper loads the destination logic resource but does not by itself execute that room’s bytecode. In SQ2, logic 0 later dispatches the current room via call_logic_var(v0).

Several early QEMU probes for 0x12/0x13 did not produce stable reusable evidence. A direct var0 assertion after the switch failed, a target-logic draw probe failed, a logic-0 re-entry fixture with 0x92 (restore_logic_entry_ip) before the switch did not reach its validation draw, and a first synthetic call_logic_var(v0) dispatch fixture still produced the same blank-screen mismatch. Those failures were fixture-shape problems rather than disproofs of the source model.

A later QEMU fixture room_switch_reentry_001 matched the original engine for both 0x12 and 0x13. In that fixture, logic 0 sets a private init flag before executing the switch action. Because the switch returns zero, the current logic invocation aborts and code.engine.main_cycle immediately calls logic 0 again. On the second pass, logic 0 skips the switch and executes call_logic_var(v0). The destination logic then checks flag 5, loads and shows its own picture, loads its view, and draws a validation sprite. This validates the user-visible re-entry/current-room dispatch shape: a room switch prepares state and loads the destination logic, but room-local drawing/setup belongs to the destination room logic reached on the following logic-0 pass.

QEMU fixture room_previous_001 validates the byte-variable room update contract for both 0x12 and 0x13. The fixture writes a synthetic previous room into byte variable 0 before switching to room 1, and writes an invalid boundary selector into byte variable 2. The destination room logic draws only if byte variable 0 is the destination room, byte variable 1 is the synthetic previous room, and byte variable 2 has been cleared. The matched immediate and variable-selected cases confirm that the switch helper copies old v0 to v1, writes the destination room to v0, and clears v2 on both operand paths.

QEMU fixtures room_boundary_002 and room_boundary_var_001 validate the four entry-boundary selector cases through normal bytecode-visible object state for both immediate and variable-selected room switches. The fixture initializes object 0 with loaded view 11 frame 0 at (44,80) before switching rooms. The destination room logic then reads object 0 with action 0x27 and draws only if the expected position and cleared selector byte are observed. The matched cases confirm selector 1 writes Y 0xa7, selector 2 writes X 0, selector 3 writes Y 0x25, selector 4 writes X 140 (0xa0 - 20 for the selected cel width), and all four clear byte variable 2 on both operand paths. An earlier attempt that bound object 0’s view without first loading view 11 did not reach the switch; the right-edge selector is only meaningful when object width has already been derived.

QEMU fixture room_object_reset_001 validates one visible object-reset effect for both operand paths. Logic 0 loads view 11, sets up object 10, activates it as a persistent object, and then switches rooms. The destination room logic draws a single validation sprite. Both immediate and variable-selected cases match only when the pre-switch persistent object is absent from the destination room render, confirming that active object draw state does not survive the room switch.

The broader internal reset effects are still source-backed from the disassembly: object/resource reset beyond the bytecode-visible fields checked above, resource/event recording, optional trace logic reload, and the exact redraw/input refresh calls.

Additional object-state actions:

QEMU batch object_root_partition_004 validates the visible behavior of 0x3a, 0x3b, and 0x3c: clearing bit 0x0010 moves an active object into the root 0x1703 partition drawn before root 0x16ff; setting the bit moves it back into the later-drawn 0x16ff partition; and 0x3c refreshes the lists without an object-local field write.

Static analysis of code.object.frame_timer_update (0x0563) ties bit 0x2000 to automatic group selection. The helper initializes a local target group to sentinel value 4. If bit 0x2000 is clear and object byte +0x0b is 2 or 3, it indexes data.object.group_for_direction_two_or_three_groups (AGIDATA.OVL:0x08dd) by direction byte +0x21; if +0x0b >= 4, it instead indexes data.object.group_for_direction_four_plus_groups (AGIDATA.OVL:0x08e7). When object byte +0x01 == 1, the target group is not sentinel 4, and the target differs from byte +0x0a, it calls code.object.select_group (0x3bb7). QEMU batches object_bit_2000_002 and object_bit_2000_004 validate this behavior:

Gold Rush / AGI v3 keeps the same table values but changes the high group-count branch. Its code.object.frame_timer_update at image 0x055c sends exactly four groups directly through the four-plus table, while views with more than four groups use that table only when flag 0x14 is set. QEMU report build/gr-v3-behavior/frame_selection_gate_qemu_001.json validates exact-four view 177 selecting group 1 for direction 6 whether flag 0x14 is clear or set, and more-than-four view 39 selecting group 1 only when flag 0x14 is set.

• In the four-plus-groups table, view 4 with direction 6 changes from group 0 to group 1 after 0x2e; after 0x2d, the same object remains on group 0.
• In the two/three-groups table, view 5 with direction 6 changes from group 0 to group 1.
• Direction 5 in the two/three-groups table yields sentinel 4, so no group change occurs.
• A one-shot +0x01 = 2 delays selection until the countdown reaches 1 in a later cycle. A probe that writes +0x01 = 2 every logic cycle keeps the object on its original group, confirming the exact +0x01 == 1 gate.

QEMU probes validate the observable flag-clearing side effect of 0x49 and 0x4b: each clears its flag operand before following bytecode tests that the flag is no longer set. Later frame-timer movement probes validate visible frame-mode behavior for 0x48, 0x4a, and 0x4b.

Static analysis now ties 0x46..0x4c to the frame-cycling path. Per-cycle helper code.object.frame_timer_update (0x0563) scans active objects with (flags & 0x0051) == 0x0051; when bit 0x0020 is set, byte +0x20 is nonzero, and decrementing +0x20 reaches zero, it calls code.object.advance_frame_by_mode (0x48b3) and reloads +0x20 from +0x1f. The advance helper treats +0x23 as a frame mode: mode 0 loops forward, mode 1 advances forward and completes at the last frame, mode 2 steps backward until it reaches frame 0 and completes, and mode 3 loops backward. Completion in modes 1 and 2 sets flag +0x27, clears bit 0x0020, clears direction byte +0x21, and resets +0x23 to 0. Actions 0x49 and 0x4b also set bit 0x1000; the first advance callback after setup clears that bit and returns without changing frame.

QEMU movement batch frame_timer_001 validates the visible mode-1 path: after 0x4c seeds the interval and 0x49 starts mode 1, view 11/group 0 advances from frame 0 to frame 1. The same batch validates that 0x46 prevents the advance by clearing bit 0x0020, and 0x47 restores the advance when executed after 0x46.

QEMU movement batch frame_timer_modes_002 validates the remaining visible frame-mode actions: 0x48 mode 0 wraps view 11/group 0 from frame 1 to frame 0, 0x4b mode 2 moves from frame 1 to frame 0 and stops, and 0x4a mode 3 wraps backward from frame 0 to frame 1. The looping-mode fixtures stop the timer with 0x46 after a bytecode guard observes the expected frame through 0x32.

Movement probe move_collision_clear_skip_bit_blocks_again validates 0x44 by first setting collision-skip bit 0x0200 with 0x43, then clearing it with 0x44, and observing that the default object-object collision stop returns.

QEMU horizon probes validate 0x3f, 0x3d, and 0x3e together. With 0x3f setting [0x012d] = 100, ordinary placement at baseline 80 clamps to baseline 101. Setting bit 0x0008 with 0x3d keeps the object at baseline 80, and clearing the bit with 0x3e restores the clamp.

Movement-mode actions have compact setup contracts but richer per-cycle semantics, so the entry points are summarized in a table and the state machines are described below it.

Actions 0x51 and 0x52 share the same targeted-movement state machine.

The handler sets object byte [+0x22] = 3, stores target X/Y in [+0x27] and [+0x28], copies old step size [+0x1e] to [+0x29], stores the completion flag in [+0x2a], clears that flag, sets object bit 0x0010, and calls helper 0x1672. If operand 3 is nonzero, it temporarily replaces [+0x1e] with that step size; completion helper 0x16b9 restores [+0x1e] from [+0x29], sets the completion flag through 0x74c6, clears [+0x22], and clears ego direction byte [0x000f] when the object is object 0.

Helper 0x1672 computes the initial direction byte [+0x21] from current position [+0x03]/[+0x05] to target [+0x27]/[+0x28] using step size [+0x1e]. The direction lookup table at DS:0x0a85 is:

target above:  8 1 2
target level:  7 0 3
target below:  6 5 4
               left near right

The center value is zero, so an object already within one step of both target coordinates completes immediately.

QEMU probes with generated logic resources confirm two valid ways this target mode can complete. A script can reissue 0x51 each cycle while the completion flag is clear; that matched QEMU for reachable horizontal and vertical targets, and for unreachable right/bottom targets that complete at the movement clamp. A one-shot 0x51 setup can also complete without script reissue when object byte +0x01 is set to 1, because the pre-movement dispatcher path 0x067a -> 0x1672 recomputes the direction and detects arrival.

For action 0x53, the setup handler sets object byte [+0x22] = 2; stores max(operand1, object[+0x1e]) in [+0x27]; stores the completion flag number in [+0x28]; clears that flag; stores sentinel 0xff in [+0x29]; and sets object bit 0x0010. The per-cycle helper at 0x0b36 computes the object’s horizontal center and the first object’s horizontal center, calls direction helper 0x16ed(object_center_x, object_y, first_object_center_x, first_object_y, object[+0x27]), and writes the returned direction to [+0x21] when its local delay permits. If the returned direction is zero, the object is already within the threshold: the helper clears [+0x21] and [+0x22] and sets the completion flag through 0x74c6. If object bit 0x4000 says the object did not move in the last position comparison, the helper temporarily chooses a random nonzero direction and computes a retry delay in [+0x29] before returning to the direct approach direction.

QEMU validates the direct autonomous mode-2 path with object 1 approaching object 0: with step 5, countdown byte +0x01 = 1, and threshold 35, object 1 stops at (50,80) when object 0 is at (80,80). An exploratory threshold 25 probe landed at (60,75), consistent with the source path that enters stuck recovery after a blocked or stationary comparison.

For action 0x54, the per-cycle helper at 0x3f5a decrements [+0x27] as a countdown; when it reaches zero, or when object bit 0x4000 reports no movement, it chooses a random direction 0..8 via helper 0x3fa3, stores it in [+0x21], mirrors it to byte [0x000f] for the first object, and reseeds [+0x27] to a random delay in the range 6..50.

A QEMU property probe validates this path without assuming a deterministic final coordinate: after setting step 5, countdown byte +0x01 = 1, and starting 0x54, the object rendered exactly at a valid final position. In the recorded run the final position was (140,112).

In local SQ2 data, the template at DS:0x1713 is:

Object %d:
x: %d  xsize: %d
y: %d  ysize: %d
pri: %d
stepsize: %d

The single observed local use is in logic 99. The script accepts parsed words object or sp, prompts with message 7 (object #:), stores the number in variable 64, and then executes this action. This makes 0x85 a developer or diagnostic object-inspection command, and it independently confirms that object fields [+0x03], [+0x05], [+0x1a], [+0x1c], [+0x24], and [+0x1e] are displayed as X, Y, width, height, priority/control, and step size.

Actions that update object byte [+0x24]:

Message-display actions use the current logic resource’s message table through helper 0x21f0.

QEMU fixture text_input_002 validates that 0x65, 0x66, and 0x97 display a message/window, accept Enter through the display helper, then return to following bytecode. The same batch validates one typed-input path for 0x76: entering 42 stores byte value 42 in the destination variable. Later fixture text_ui_003 validates the formatted/positioned display variants 0x67, 0x68, and 0x98 with the same return-to-bytecode behavior. These message paths can leave text-plane pixels visible after dismissal; the QEMU fixtures issue a full picture refresh (0x1a) before comparing graphics output when the validation draw would otherwise be contaminated by that display state.

Menu/list-like UI actions use a circular list rooted at word globals [0x1d2c], [0x1d2e], and [0x1d30]. The final user-level names remain provisional; the observed structures look like a top-level list of headings with per-heading circular sublists of selectable items.

QEMU fixture menu_sound_001 dispatch-smokes 0x9c..0xa0 by creating a heading, adding one item, finalizing the structure, disabling and re-enabling that item id, and then drawing a known view. A separate case sets flag 0x0e, runs 0xa1, and draws.

QEMU fixture menu_interaction_001 validates the one-item interactive Enter path. The fixture builds a menu heading and enabled item id 7, finalizes the structure, sets flag 0x0e, and runs 0xa1. The following input cycle enters code.menu.interact (0x93d1); pressing Enter on the enabled item calls 0x44a9(3, 7). The generated logic then draws only when condition 0x0c 7 observes the resulting status byte. The comparison refreshes the picture before the validation draw because the menu leaves a top text strip visible.

QEMU fixture menu_edges_002 validates three additional menu edge cases. Escape exits the interactive menu without setting item status byte 7. Enter on a disabled item also leaves status byte 7 clear before Escape exits. Disabling then re-enabling the same item allows Enter to enqueue status byte 7 again. These promote 0x9c..0xa0 from setup-only dispatch evidence to behavior evidence for the tested setup, disable, and re-enable paths. A down-arrow navigation fixture was attempted twice, but the QEMU key sequence did not reach the expected second-item status path, so arrow-key navigation remains source-backed from the code.menu.interact dispatch table.

Source mapping of code.menu.interact shows the navigation model. The menu loop waits through code.input.wait_for_event_or_tick, then normalizes the event record through the Enter/Escape helper and the display-adapter remap helper. Event type 1 is interpreted as raw Enter/Escape: Enter enqueues a type-3 event with the current item’s id only if the item enable word [item+0x0a] is nonzero; Escape leaves without enqueueing a selection. Event type 2 is interpreted as a movement code. Movement values 1..8 dispatch through the word table at 0x9526, then the loop stores the current heading/item in [0x1d2e] and [0x1d30] before waiting again. Item navigation does not skip disabled items; the enable word is tested when Enter is pressed. Left/right heading navigation skips headings whose enable word is zero, while Home/End-like heading jumps select the root or root-previous heading directly.

Text-window and input-line actions:

code.input.edit_string (0x0da9) is the shared line editor used by both 0x73 and 0x76. Static disassembly shows that it clamps the requested maximum length to 0x28, copies the destination buffer into a local edit buffer, draws the existing text, waits for a nonzero/non-0xffff event through code.input.wait_event (0x45d7), and dispatches key values through data.input.edit_key_table (0x0e64). Observed table entries map 0x08 to single-character backspace, 0x03 and 0x18 to clear-current-input, 0x0d to accept by zero-terminating the local buffer and copying it back to the destination slot, and 0x1b to cancel without copying. Other input bytes append when space remains and are echoed through the character display helper.

QEMU fixture prompt_string_003 validates the 0x73 path. One case proves the prompt returns after typed text plus Enter; a second initializes string slot 1 from message text look, runs 0x73 into slot 0, then conditionally draws only if the two string slots compare equal. The matched capture proves that typed text was copied into the destination slot. Like the formatted-message probes, the fixture refreshes the picture with 0x1a before the validation draw because the text overlay can otherwise remain visible in the captured display.

QEMU fixture text_ui_003 originally dispatch-smoked 0x77, 0x78, 0x89, and 0x8a as an input-line toggle/refresh/erase group, and 0xa9 as text-window cleanup. Later focused batches promote the input-line opcodes and the unconditional [0x0d0f] clear side of 0xa9 to the behavior-level observations above. Follow-up fixture text_rect_clear_behaviour_003 validates the display-surface effect of 0x69 and 0x9a without relying on a picture refresh: formatted message text is acknowledged, the clear action runs, and the captured screen matches only when the expected display surface includes the black text-cell rectangle written by the BIOS clear helper.

QEMU fixture text_hide_clear_behaviour_001 extends that display-surface coverage to the single-row text clear used by the status and input line handlers. The two cases first display formatted text on row 5, configure the row globals through 0x6f, run either 0x71 or 0x77, and then validate that logical Y 40..47 is black before the final object draw. This promotes 0x71 (hide_status_line_like) and 0x77 (disable_input_line_like) beyond dispatch-smoke coverage for the normal EGA display path.

QEMU fixture text_enable_attr_behaviour_002 promotes two more handlers from that cluster. Case input_line_enable_clears_configured_row sets the prompt marker to an empty message, displays formatted text on row 5, configures the input row with 0x6f(0, 5, 22), then runs 0x78; the capture matches when the configured row is black before the final object draw. Case text_attribute_enable_clears_visible_surface runs 0x6a and then attempts the usual transient-object validation draw; the original capture remains a fully black logical surface, so the case compares only the visible surface and does not compose the validation object. This is evidence for the alternate text-attribute mode surface clear, not for ordinary graphics drawing.

QEMU fixture text_prompt_attr_behaviour_001 promotes two neighboring handlers. Case text_attribute_disable_restores_picture_draw runs 0x6a, then 0x6b, then refreshes the picture and draws the validation object; the match confirms that leaving alternate text-attribute mode restores the normal graphics path. Case input_prompt_empty_message_suppresses_marker first sets a nonempty prompt marker, displays/acknowledges formatted text on row 5, sets the prompt marker from an empty message, and runs 0x78; the capture matches only when the configured input row is black with no prompt-marker glyph.

QEMU fixture text_status_002 originally dispatch-smoked low-risk text/status/input handlers in this cluster: 0x6d for text-attribute configuration; 0x6e for a one-count screen-shake return; 0x70 for status-line show; and 0x79 for key-event mapping table insertion. Later focused batches promote 0x6d and 0x70 to the behavior-level observations above. The source-backed details still matter: 0x6f stores its first operand in [0x05dd], stores operand + 0x15 in [0x05df], and derives display offset global [0x1379] from that first operand. An intermediate QEMU run with first operand 1 shifted the later validation draw relative to the local renderer, so the final smoke fixture uses operand 0 and leaves non-default display-offset semantics for a dedicated behavior probe.

QEMU fixture input_key_string_behaviour_001 adds that dedicated behavior coverage. Case input_line_config_operand1_offsets_display_by_8 runs 0x6f(1, 0, 22), refreshes the picture, and draws a view at script baseline 80; the original interpreter capture matches the local renderer only when the expected baseline is 88, confirming the observed arg0 << 3 offset in normal display mode. Case mapped_key_sets_status_byte installs 0x79('x', 0, 7), sends key x, and draws only when condition 0x0c observes status byte [0x1218 + 7]. This confirms the path through code.input.map_key_event (0x4c3d) and helper 0x4566, where a matching type-1 event becomes type 3 and sets the mapped status byte.

QEMU fixture diagnostics_system_001 validates that 0x87, 0x88, and 0x8d display their diagnostic/pause/version messages, accept Enter, and return to following bytecode. The same batch originally smoke-exercised several global/system handlers. Separate focused or source-backed work now covers the formerly smoke-only actions: 0xab/0xac, 0xa3/0xa4, and the object-0 motion-byte effect of 0x84 have focused QEMU evidence; 0x83, 0x8e, 0xaa, and 0xad are covered from source because their main effects are global/timing/save-selector state not cleanly exposed by ordinary single-room script probes.

Resource/table actions outside the main object table:

QEMU fixture view_resource_display_001 validates that 0x81 and 0xa2 display/preview view resource 11, accept Enter, return to following bytecode, and allow a subsequent picture refresh plus validation draw.

Interpreter/session control actions:

QEMU fixture system_dialog_001 validates several control paths in this cluster. 0x8f returns when the resolved message begins with the expected SQ2 signature. 0x80 and 0x86(0) display confirmation prompts and return to following bytecode when Escape cancels. 0x8b follows the no-joystick path under the current QEMU environment and returns. 0x8c returns without toggling when byte variable 0 is zero. Two later display-mode replay cases patch the hardware/mode guard words and launch with SIERRA -p -c; screenshot comparison validates the observable CGA row-interleaved remapping of the recorded picture, while the paired QEMU memory probe validates the internal replay log rather than relying on the screenshot alone. 0x96 followed by 0x95 dispatch-smokes the trace-window configuration path with flag 10 clear. Later fixture trace_window_enable_002 sets flag 10, configures the trace window with 0x96(0, 1, 2), and runs 0x95; the original-engine capture matches bounded checks for a red border, white fill, and black trace text. The trace window then becomes active, so the dispatcher may pause before the next action and format the current opcode/operands into that window.

QEMU fixture file_log_001 validates that 0x7d and 0x7e open their save/restore selector paths and return after Escape cancellation. It also dispatch-smokes 0x90 by appending a formatted record to the DOS logfile and returning to following bytecode.

The shared save/restore selector helper code.save.select_slot_or_path (0x85e5) is responsible for the modal UI around choosing a slot or path. It captures whether the prompt marker was visible, erases the marker, pushes text attribute state, stops active sound, sets a text attribute pair, and calls the path prompt helper at 0x8705. If runtime buffer [0x0e72] is empty, that helper displays the save or restore path question, edits path buffer 0x1962 through modal helper 0x8794, and validates the path with 0x5bdd; helper 0x86a3 displays the insert-disk style message when the selected drive/path is not available. Slot helper 0x8814 scans up to 12 numbered save files through summary reader 0x8b9f, displays their 31-byte descriptions, highlights the current row with glyph 0x1a, and handles Enter, Escape, and movement events 1 and 5 for accept, cancel, up, and down. In save mode, accepting an empty description slot prompts for a new 31-byte description into 0x1c6c before the caller creates the file. On exit, 0x85e5 formats the selected filename into 0x1c8c, restores text state, and redraws the prompt marker if it had been visible. A zero return means cancel/no selection; a nonzero return lets the caller perform actual file I/O.

Follow-up fixture log_file_contents_001 ran the log append case alone, then converted the post-run qcow2 disk image to raw and extracted LF00000\LOGFILE with mtools. The file bytes were:

Room 0
Input line:
LOG

This matches the source-derived 0x90 format: leading newlines, current room, empty input-line buffer, and the resolved current-logic message.

Miscellaneous actions:

Remaining table entries:

Gold Rush v3 extra action slots

The local Gold Rush / AGI 3.002.149 action dispatcher accepts entries through 0xb5 using the v3 table at AGIDATA.OVL:0x0440. KQ4D / AGI 3.002.102 has the same v3 action-table shape at AGIDATA.OVL:0x0620. The decoded Gold Rush scripts observed so far do not use these slots, so the following descriptions are source-backed from handler disassembly and cross-references rather than QEMU behavior probes.

QEMU fixture display_mode_replay_uses_rolled_back_event_count validates the observable pair-log effect of 0xab and 0xac. The script saves the current pair count, records a later picture operation, restores the saved count, then enters display-mode replay. The memory-backed replay notes show the rolled-back picture is absent from the active pair buffer, and the automated capture matches the expected replayed-picture state.

Local SQ2 scan

The local helper tools/disassemble_logic.py extracts logic resources, applies the dispatch tables, and prints decoded bytecode. It detects dispatch-table bases from the observed operand metadata signature, so v3 inputs whose tables move within AGIDATA.OVL can still be decoded after their resource container is recognized. It also has a --stats mode for linear opcode counts. This is still a static bytecode listing, not a live execution trace.

One LOGDIR entry decodes to VOL.0:0x1ffff but does not have a valid volume record header; the stats mode reports this as logic 141 and skips it.

Using the action table operand counts and the condition table operand counts, the current local scan of present SQ2 logic resources found these structural byte counts:

Frequently encountered action opcodes at statement boundaries included:

Frequently encountered condition opcodes included:

The current scanner is intentionally conservative. It correctly identifies the main structural bytes and many statement boundaries. Remaining interpreter work is concentrated less on unnamed action opcodes and more on refining implementation-level contracts for object/view fields, display-specific buffer variants, and the more hardware-facing input and graphics helpers.