Classroom Public page

Lab 6.2: Execute the Capstone, Make the Change

875 words

~6-8 hours, spread across days 2-5 of week 6. The actual modification work.

Goal: implement the change you scoped in lab 6.1. Save artifacts as you go. Document setbacks. End with a working modified ROM.

Estimated time: 6-8 hours, broken across multiple days

Prerequisites: lab 6.1 complete (you have a written proposal)

Steps

Step 1: Set up your working environment (15 minutes, day 2)

Create a clean workspace for the capstone:

~/spk-101/capstone/
├── original.{nes,gb,sfc}      (copy of the unmodified ROM)
├── working.{nes,gb,sfc}       (your hack-in-progress)
├── notes.md                   (your running execution journal)
├── screenshots/
│   ├── before-{scene}.png     (unmodified screenshots; take these now)
│   └── (after screenshots come later)
└── attempts/                  (where you save snapshot iterations)

Copy your chosen ROM TWICE: once as original.{ext} (you will not touch this; it goes in the final zip), once as working.{ext} (this is what you edit).

Take 2-3 baseline screenshots of the scene(s) you will be modifying. Save these as your "before" images.

Step 2: Identify your target byte(s) (60-120 minutes, day 2)

Apply the strategy you wrote in lab 6.1. Probable steps depending on your change:

  • Palette change: search PRG-ROM for the palette byte sequence (lab 4.1 technique)
  • Text change: search PRG-ROM for the ASCII byte sequence or tile-index sequence (lab 4.2 technique)
  • Tile redesign: calculate CHR-ROM offset for the tile (lab 4.3 / lab 2.2 technique)
  • Numeric value: trace RAM → write breakpoint → PRG-ROM constant (lab 4.4 technique)
  • Header field (Game Boy / SNES): navigate directly to the header offset (lab 5.1 / 5.2 technique)

Write down in notes.md:

  • The byte offset(s) you identified
  • The original value(s)
  • The proposed new value(s)
  • What you tried that did NOT work first

If you cannot find your target after ~2 hours of trying, consider falling back to your plan B from lab 6.1. The capstone grade does not penalize you for switching tactics; it rewards a clearly-documented chain of work.

Step 3: Make the change and verify (60 minutes, day 3)

Open working.{ext} in your hex editor. Make the byte change. Save.

Load working.{ext} in the appropriate emulator (Mesen / SameBoy / bsnes-plus). Navigate to the scene where your change should be visible. Verify.

If the change worked: take 2-3 "after" screenshots. Save them.

If the change did not work as expected:

  • Save working.{ext} to attempts/attempt-1.{ext} (so you have a record)
  • Try a different byte; iterate
  • After 2-3 iterations, you usually find the right byte

Document each iteration in notes.md. The failed attempts are interesting in the write-up.

Step 4: Iterate on quality (60-180 minutes, days 3-5)

Now that the basic change works, you may want to polish:

  • For a palette change: try a few color options; pick the one you like best
  • For a text change: see if there's a more interesting replacement word
  • For a tile redesign: refine the pixel art; iterate on the design
  • For a numeric change: try a few values; pick the one with the most interesting gameplay effect

Re-take screenshots if your final version differs from your first working version.

Step 5: Verify gameplay stability (30 minutes, day 5)

Play through your modified ROM. Confirm:

  • The game still boots
  • The game does not crash partway
  • Other scenes (besides the one you modified) still look and play normally
  • Your change shows up consistently every time the relevant scene loads

If anything is broken: revert to a working working.{ext} from attempts/. Reduce your change to the minimum that achieves the visible effect. Stability matters more than ambition.

Step 6: Take final screenshots (30 minutes, day 5)

You should end day 5 with:

  • 2-3 "before" screenshots (from step 1)
  • 2-3 "after" screenshots showing your change clearly
  • A few additional in-context shots (e.g., player walking around in the modified palette; full title screen showing modified text)

Pick the single clearest before/after pair. These become before.png and after.png for the capstone zip.

Step 7: Final notes (15 minutes, day 5)

Update notes.md with:

  • Final byte offset(s) and value(s) changed
  • The chain of attempts (what worked, what didn't)
  • Total time spent (rough estimate)
  • Any moments where something "clicked"
  • Anything you wish you had done differently

This becomes the source material for the lab 6.3 write-up.

Expected output

  • A working modified ROM (working.{ext}, this becomes modified-rom.{ext} in the final zip)
  • The unmodified original (still untouched in ~/spk-101/capstone/original.{ext})
  • Before/after screenshots (at least 2-3 pairs)
  • A detailed notes.md execution journal

Common pitfalls

  • Skipping the "always copy first" rule: editing the original is the cardinal mistake. You lose the ability to compare or revert. ALWAYS work on working.{ext}
  • Not documenting failures: failed attempts are interesting in the write-up. If you find the right byte on the first try, your write-up has less depth than if you tried three things and the third worked
  • Spending day 2 still searching for the byte: by end of day 3 at the latest, you should have a working change. If you are still hunting on day 4, switch to plan B or simplify the change
  • Adding bonus changes after the first works: do NOT. One change. Polish that one. Bonus changes belong in a "future work" note in your write-up

Stretch (optional)

If you finished early (the change works by end of day 3):

  • Polish the screenshots; ensure they clearly show your modification
  • Reread CAPSTONE.md for the write-up requirements; start drafting (do not finalize until lab 6.3)
  • Compute the SHA-256 of the original ROM now (will speed up lab 6.3 zip packaging)

Lab 6.2 v0.1. The execution lab. The week's main work.