Attract-mode wait loop: animates the current scene once per interrupt and polls for coin-insert / fire / any-key input to start the game or jump to a fresh title screen. Re-entered every frame via titlescr_wait_loop; run_title_screen is re-run (new scene) when a key other than fire is pressed.

Per-frame animation driver: waits for the next interrupt, draws the 6 "foreground" objects (records 0-5 of the $BB00 array) via compute_glyph_blit_params, steps the object animation scripts (object_script_step), clears the playfield bitmap (clear_playfield_buffer), then draws the 3 "background" objects (records 6-8) via the alternate blitter compute_glyph_blit_params_b. Loops forever in the ordinary case, but object_script_step (via oss_fetch_opcode_cont's $D2 "end of script" handling, `POP HL : RET` with no matching PUSH) will pop this loop's own return address as data and RET again beneath it, unwinding straight out of this self-loop back to titlescr_animate_frame's *caller* (C605's own continuation) the moment any object's script reaches $D2 -- see oss_fetch_opcode_cont. This is the normal exit: whichever scene object's script ends first stops the whole per-frame animation and hands control back to run_title_screen, which is what starts the tune and enters the (non-animating) attract-mode wait loop. blit_abort_restore_sp / run_title_screen_24-style RET-via-restored-SP inside the blitters is a separate, unrelated mechanism (aborting one partially off-screen glyph draw, not this loop). Uses EXX around each compute_glyph_blit_params/compute_glyph_blit_params_b call: the object record's script pointer (B/C) and screen-position byte (L) are loaded into the shadow registers so the blitter can use HL/DE/BC freely without disturbing the loop's own IX/DE/B state in the main set.

Object animation script interpreter: advances all 9 objects' scripts by one frame. Each object record (9 bytes, offsets relative to IX): +$00 current opcode / countdown-active flag (0 = idle, fetch next op) +$01 countdown value for the "wait N frames" opcode +$02 X velocity/step, +$03 Y velocity/step +$04/+$05 script pointer (low/high) -- the object's byte-code cursor +$06 screen row/position byte consumed by the blitters +$07/+$08 current X/Y screen position The script byte-code (fetched at oss_fetch_opcode) is a simple state machine: opcode bytes >= $80 (sign bit set) are treated as immediate 2-axis step deltas (oss_op_immediate_step); opcodes $C8-$D0 select a movement/velocity mode (constant velocity, decelerate-to-stop via the D272 lookup table, accelerate, or a literal position jump) and may consume further operand bytes from the script stream. $D1 is not one of these -- it is never tested by either dispatch chain below, so an object whose script emits it (this happens in every one of the 5 title scenes, always right after an initial constant-velocity burst) gets $D1 stored as its active opcode by chain 2 and then permanently frozen by chain 1: chain 1's oss_object_loop dispatch matches none of $C9-$CF for $D1, so it jumps straight to oss_next_object without ever reaching oss_countdown's countdown decrement, and the object can never go idle (opcode -> 0) to fetch a new instruction again. This is a genuine quirk of the original data/interpreter, not a disassembly error -- see $CCF2 for object 0's example. Two separate dispatch chains share this state machine: 1. oss_object_loop (the per-object per-frame entry): dispatches on the *active* opcode already stored at +$00 ($C9-$CF, one of the six movement modes below) and performs one frame's worth of incremental movement. An idle object (+$00 = 0) instead falls through to oss_fetch_opcode to fetch a fresh opcode from the script stream. 2. oss_fetch_opcode_cont (oss_fetch_opcode_cont): dispatches on the *next script byte* fetched from the stream ($C8-$D2, or an immediate step if bit 7 is clear), reads that opcode's operand bytes from the stream, and stores them into +$00-+$03 ready for chain 1 to act on next frame. The six active movement modes (chain 1) are: constant velocity ($C9, oss_op_velocity -- position += velocity every frame, no countdown); decelerate X/Y ($CA/$CB, oss_op_decel_x/oss_op_decel_y -- apply the current step, then look up the next speed from D272 indexed by the +$01/+$03 countdown value, negate it into the other axis's velocity, and count the countdown up toward zero); and three accelerate-X variants ($CC/$CD/$CE, oss_op_accel_x_a/ oss_op_accel_x_c/oss_op_accel_x_b -- apply the current step, look up the next speed from D272 the same way, and count +$02 down/up/down respectively). The "wait N frames" opcode ($CF) has no chain-1 handler of its own: chain 1 falls through to oss_countdown (oss_countdown), which just decrements +$01 and goes idle (opcode -> 0) when it reaches zero. D272 (oss_lookup_speed, oss_lookup_speed) is a 256-byte deceleration/ acceleration curve table indexed by the countdown value passed in C (B is temporarily zeroed for the table-relative add and shuttled through A so the caller's B -- the outer object-loop DJNZ counter -- survives the call); table[C] >> 2 gives that countdown step's velocity magnitude, shared by all five countdown-driven modes.

Clear the screen bitmap ($4000-$57FF) and attribute area ($5800-$59FF) to zero. This entry point is used by the routine at insert_high_score_entry.

Clear the bitmap/attributes (clear_playfield_and_attrs) then set the border attribute rows ($5900-$59FF) to a fixed pattern: black border rows top/bottom (2 bytes each) sandwiching 28 rows of attribute $45 (BRIGHT cyan on black: bit 6 set, ink 5, paper 0) per attribute-cell column, repeated across all 16 columns.

Compute the screen address and masked-sprite blitter parameters for a single title-screen glyph/object, then dispatch to a width-specific unrolled OR-blit routine (blit_masked_sprite_dispatch onward) which draws it into the playfield bitmap. Called (via EXX-banked BC/L, see ts_draw_fg_objects) once per foreground object per frame. B = object Y screen position (+$08, clamped to a max of $6F -- the overflow past $6F is banked via run_title_screen_16 and used later as a row-skip count), C = object X screen position (+$07), L = the object's screen row/height byte (+$06, set by the script's $C8 opcode). compute_glyph_blit_params- C8CC clamp B; run_title_screen_16-C8EC then build a masked-sprite screen destination address in D/E from B and C, using the same "rotate through carry, XOR, mask $F8, XOR" idiom the ROM uses to interleave a pixel row into the non-linear screen-third layout (not traced bit- exactly here: getting each rotate/XOR wrong silently corrupts only the row within a third, which is easy to get subtly wrong without emulator verification -- flag for later verification against a working build). C8ED-C8FE then use C (object X) and L (screen row/height byte) to index the 4-byte-per-entry glyph table at glyphs (mask width, byte-count, source address), giving B/C/HL = mask width, byte count, and source glyph address. C902 restores the row-clamp flag banked at run_title_screen_16: if set, the source address is used as-is; otherwise cgb_row_offset_loop-C916 (cgb_row_offset_loop) walks the source pointer forward row-by-row (stride = C<<1, i.e. mask-width*2 bytes/row) for the overflow-past-$6F row count, before falling into the blit dispatch at blit_masked_sprite_dispatch.

Masked-sprite blit dispatch: HL/DE hold the destination screen address (from the caller), the popped HL/DE here hold the source glyph address and its mask width in C. Dispatches to one of 6 width-specific unrolled OR-blit routines (blit_width1 .. blit_width7) which draw the glyph into the bitmap by treating the source address as a stack pointer (LD SP,HL) and POPping pixel/mask byte pairs -- see the project's known "LD SP,HL; POP x N sprite copy" translation pitfall. The real SP is saved at $C93D and restored by each blit routine (or by blit_abort_restore_sp on early abort) before returning.

Shared "abort the blit early" tail: restores the real SP (saved at $C93D by blit_masked_sprite_dispatch/blit_masked_sprite_dispatch_b) and returns to the object-draw loop.

Second glyph blit-parameter computation, structurally identical to compute_glyph_blit_params above but feeding the alternate dispatch table at blit_masked_sprite_dispatch_b. Used for the 3 "background" objects (see ts_draw_bg_objects).

Alternate masked-sprite blit dispatch used by the background-object draw path (ts_draw_bg_objects via compute_glyph_blit_params_b). Identical width-selection logic to blit_masked_sprite_dispatch, but preserves B (via an extra push/pop) as a small fixed delay count, and its early-exit tail (run_title_screen_24) simply restores DE rather than aborting via blit_abort_restore_sp.

Width-1 (mask-only, no fill byte) unrolled OR-blit. blit_masked_sprite_dispatch/blit_masked_sprite_dispatch_b dispatch here when the width selector (C, decremented to 0) picks this variant. Draws 2 scanlines per POP DE: E blits into the current HL byte (LD A,(HL) / OR E / LD (HL),A -- a masked, non-overwriting sprite draw), then INC H steps to the next screen row; if that crosses a third boundary (H AND $07 = 0), the SUB $08 / ADD A,$20 / carry-adjust pattern at advance_glyph_scanline fixes up H/L, otherwise the row falls straight through. D then blits the same way into the following row, with its own boundary fix-up at run_title_screen_28. A short fixed delay (run_title_screen_26, a 30-iteration DEC-A loop) pads out the timing before DJNZ repeats for the next row-pair (B counts row-pairs); once B reaches 0, execution falls into blit_abort_restore_sp, which restores the real SP and returns.

Width-2 unrolled OR-blit variant (see blit_width1 for the general pattern).

Width-3 unrolled OR-blit variant (see blit_width1 for the general pattern).

Width-4 unrolled OR-blit variant (see blit_width1 for the general pattern).

Width-5 unrolled OR-blit variant (see blit_width1 for the general pattern).

Width-6 unrolled OR-blit variant (see blit_width1 for the general pattern).

Width-7 unrolled OR-blit variant (see blit_width1 for the general pattern); the widest/final entry in the dispatch chain, reached when C reaches 0 without matching any of the DEC C; JP Z tests above.

Clear the playfield bitmap ($4800-$57FF, i.e. the lower two screen thirds, excluding the top third at $4000-$47FF which holds the fixed title/credits text) to zero, ready for the next frame's objects. Classic "LD SP,HL; PUSH x N" fast-fill trick (see the project's known translation pitfall of the same name): SP is repointed at the bitmap, then 14 PUSH DE instructions fill 28 bytes per pass, DJNZ-looped 8 times per screen-third row (C = 8, giving 8 x 28 = 224 bytes per call through the inner loop, i.e. one attribute-row's worth), stepping through third-boundary wraps via the usual ADD A,$20 / carry pattern. The real SP is saved at $CC4D and restored before returning.