What problem does it solve? Changing ball or paddle speed in this Z80 assembly game is error-prone because all pacing comes from counted busy-wait delay loops with no interrupts or vsync, so editing one constant silently changes the feel of everything else. This Skill documents the frame loop architecture, T-state delay budgets, and coupling between the two timing constants so changes are deliberate rather than guesswork. ## Core Features & Use Cases - Frame budget derivation: Provides worked T-state arithmetic for each delay loop (Esperar_pelota, esperar, teclado) so you can re-derive frame time after any change. - Coupled retuning guidance: Explains that ball speed and paddle responsiveness share one frame, and gives a table for adjusting both constants together to hit a target. - Hard constraints and traps: Enforces the one-cell-per-frame step rule, the non-zero row velocity invariant, and warns that a delay constant of 0 wraps to the longest delay. - Use Case: You want to make the ball faster without breaking collision detection. The Skill tells you to lower the $1100 delay constant in pelota.asm, never raise the step size, and to compensate the paddle by adjusting CONTADOR in pala.asm. ## Quick Start Ask the AI to explain how to safely make the ball faster in this game and which constants in pelota.asm and pala.asm to change together.
