WHERE IN THE IDE
Debug / Problems / project tests → Ask AI with the relevant source selected
Before you start
- Reproduce the problem from a fresh build.
- Write down exact keys or inputs, expected output and observed output.
- Keep current source, accepted binaries and debugger source maps aligned.
A model cannot infer your live PC, memory, bank or input history unless that information is included. Supply the values you actually observed, not plausible-looking example numbers.
STEP 01
Identify the failing layer
A syntax error belongs to the parser; a rejected include belongs to assembly isolation; a missing screen can be a tape-order error; a wrong score can be game logic. Read Problems and the build result before opening an AI request. Do not ask the model to fix a runtime issue that is actually an old build.
STEP 02
Capture a small reproducible case
Use a source breakpoint near the wrong behavior. Record the BASIC line or ASM PC, relevant variables/registers and the input sequence. On 128K, include physical bank identity where relevant. For linked BASIC routines, retain the linked source identity instead of reporting only an ambiguous line number.
The 128K project stopped at BASIC line 110, after GO SUB 8000 returned. The line profile maps the linked music routine back to music_1.bas.
STEP 03
Request a hypothesis, not an immediate rewrite
Fill this template with real evidence. Remove fields you cannot observe and label unknowns explicitly.
Diagnose only; do not change code yet.
Target: [48K or original 128K].
Fresh build: [what I built].
Steps to reproduce: [exact inputs in order].
Expected: [observable result].
Actual: [observed result].
Stopped at: [source and line, or PC plus physical bank].
Relevant values: [actual variables/registers/memory].
Use the included source to give two ranked explanations and one discriminating test for each. Separate observations from guesses. Do not claim you inspected the running emulator.STEP 04
Run the discriminating check
Step a BASIC line or Z80 instruction, inspect the return stack or compare a memory byte as the hypothesis requires. Check whether the proposed cause predicts the next observed state. If not, report the new result before accepting a patch.
STEP 05
Apply one correction and preserve the test
Once a cause is supported, ask for the smallest patch to that path. Review and accept it, rebuild and repeat the exact original inputs. Where useful, encode deterministic key input and memory or SCREEN$ assertions in a project test. For banked memory, use a bank-qualified expectation.
STEP 06
Test the nearby paths too
Repeat at least one previously working path, an edge input and restart/replay. Keep failure evidence from the fresh test run. Passing one isolated test is not proof that every game state, independent emulator or physical machine behaves correctly.
If something goes wrong
- The answer invents register or memory values
- Reject the claim. Supply the actual values and require observations and hypotheses to be labeled separately.
- A logical 128K address appears inconsistent
- Record the physical RAM bank and paging state. The same logical window can map different data.
- A stopped routine test is called a failure
- Check whether it was stopped, safety-paused or truly violated the return contract. Inconclusive evidence is not an execution error.
READY TO MOVE ON?
Check the result, not just the response.
- The explanation predicts an observed state change.
- The original reproduction now passes after a fresh build.
- A neighboring behavior has not regressed.