# Batch 2 -- resolving the batch 1 ambiguities

Batch 1 nailed down literal encoding, arithmetic ops, and `x`'s store
pattern very cleanly, but left two open questions (see
`docs/reverse_engineering.md` in the repo for full context):

1. Is a variable reference really 1 byte, or 2? (`x`'s tests were
   consistent with 1 byte, but every test involving a *second* variable had
   one more byte than expected.)
2. What are `y` and `z`'s slot bytes?

Same process as batch 1: Build each `.mbs` in RoborunPlus, export as `.hex`
with the same base name, save back in this folder.

## What each file resolves

| File | Purpose |
|---|---|
| `20_x_store_only.mbs` | `x = 9` alone -- sanity check against batch 1's `x`-tests using a value (9) that can't be confused with a slot index, in case 0/1/127/128 were accidentally ambiguous. |
| `21_y_store_only.mbs` | `y = 9` alone -- isolates `y`'s slot byte the same clean way batch 1 isolated `x`'s. |
| `22_z_store_only.mbs` | `z = 9` alone -- isolates `z`'s slot byte. |
| `23_two_stores_x_then_y.mbs` | `x = 9` then `y = 9`, **no variable loads at all**. If the "extra byte" from batch 1's `09_var_to_var` shows up here too, it's a per-statement/multi-statement thing, not specific to loading a variable. If it doesn't show up here, the extra byte is specifically tied to the *load*. |
| `24_load_x_store_y.mbs` | `y = x` as the **only** statement in the program (x defaults to 0, that's fine -- we only care about the instruction encoding, not the runtime value). Removes the confound of a preceding `x = 5` push statement that made batch 1's version harder to segment. |
| `25_increment_alone.mbs` | `x++` on its own, no `GoTo`/label around it -- isolates the increment opcode without the branch-target noise from batch 1's `18_goto.mbs`. |