Find the first wrong step

Someone has changed our timed character program. Right movement works, but left movement does not. Your job is to find out why, make a small repair, and show that it works.

Start by reproducing the symptom. A motionless character could mean several things: perhaps the program missed a key, perhaps it kept the old position, or perhaps it failed to draw a changed position. We need evidence to tell those explanations apart.

The investigation below introduces each debugger reading when it becomes useful. Follow the stages at your own pace; switching stages keeps your source edits and notes. Explanations and repairs stay folded away until you ask for them.

Stop at a label to see its source.

What would count as a successful repair?

Keep a short record of four things:

• The symptom you reproduced, including something that still worked.
• The first instruction whose result disagreed with what the program needed to do.
• The smallest change you made, and why it addresses that disagreement.
• The ordinary movement and boundary tests you repeated afterwards.

For the left edge, change the initial position: defb 15 to position: defb 0, assemble again and stop at the left decision. Predict whether a decrement should happen. Restore your normal starting position afterwards.

A successful ordinary move does not establish that the edge is safe. Likewise, a correct position byte does not establish that the old picture was erased. Case 2 asks you to make that distinction with less guidance.

Working with this debugger

A breakpoint is an address where you ask execution to stop. The buttons supply a key and run to the named label from your assembled source; they do not change the position directly. If you have already moved, the current position may differ from the starting value. Assemble again for a fresh machine.

Step executes the paused machine, rather than replaying a scripted answer. Resume returns to normal running. The source excerpt comes from the last assembly; the next instruction is disassembled from actual machine memory. Different formatting or numeric addresses do not mean they are different instructions.

The main view starts with the position byte and A. Z appears when the zero test matters; PC appears when you need to establish where the branch went. More registers and recent steps are available in the folded machine-state panel. Your prediction is kept for comparison; there is no automatic marking of your answer.

A source edit does not change the running program until you assemble it. Revert restores the supplied faulty case 1, not a repaired answer. Loading case 2 replaces the editor contents only when you press its button.

Take the method with you

Reproduce the fault. Choose an explanation you can test. Stop before the relevant work, predict a change, and compare it with what the machine did. Follow the evidence until you find the first disagreement, then repair and repeat the test.

The two exercise sources are debug-branch.asm and debug-trail.asm, deliberate faulty variants of lesson 7’s clocked-character.asm. They use the same Asm198x and Pasmo build commands, with the relevant filename substituted. They are investigation cases, not new game checkpoints.

This completes our introduction to instructions, memory, drawing, input, timing and investigation. Continue with Meteor Storm, beginning with a pixel crossing a byte boundary and building towards a complete timed game.