What problem does it solve? Modifying the collision and physics code of a Z80 assembly Breakout game (colisiones.asm, pelota.asm) is error-prone: subtle invariants around fixed-point velocity, attribute-based cell classification, and stack discipline have each caused real shipped bugs. This Skill documents the implemented design, the invariants tests enforce, and the reasoning that constrains any change. ## Core Features & Use Cases - Physics invariants reference: Documents the 8.8 fixed-point position/velocity model, the |v|=256 magnitude rule, one-cell-per-frame step limit, and non-zero row velocity requirement. - Collision semantics: Explains position-first cell classification, two-cell brick destruction with single decrement, colour-8 indestructible bricks, and the seven-entry paddle rebound table. - Game-flow rules: Covers lethal floor handling, lives, game over vs completion screens, reset routine responsibilities, and the jp-not-call rule for leaving the frame loop. - Use Case: Before changing the paddle rebound angle or adding a level, consult the pre-change checklist (§12) to verify the erase-restore test, wall range comparisons, and rebound table variety still hold. ## Quick Start Ask the assistant to review a planned change to colisiones.asm against the collision-and-physics checklist before editing the assembly code.
