Classroom Public page

Lab 6.3: Write Up Your Capstone, Ship the Zip

1,124 words

~2 hours on day 6 of week 6. Convert your execution journal into a polished 1-page write-up; package everything; submit.

Goal: produce the final capstone deliverable per CAPSTONE.md: a zip file containing the modified ROM, the original ROM, the SHA-256 hash, the 1-page write-up, and before/after screenshots.

Estimated time: 2 hours

Prerequisites: lab 6.2 complete (working modified ROM; before/after screenshots; execution notes)

Steps

Step 1: Compute the SHA-256 of the original ROM (10 minutes)

In a terminal, navigate to your capstone working directory. Compute the hash:

  • Linux: sha256sum original.nes (or .gb / .sfc)
  • macOS: shasum -a 256 original.nes
  • Windows: certutil -hashfile original.nes SHA256

Copy the hex digest. Create original-rom-sha256.txt and paste the hash on its own line.

Verify the file looks like this (a 64-character hex string followed by a filename):

a1b2c3d4e5f60718293a4b5c6d7e8f9012345678abcdef0123456789012345ab  original.nes

(Just the hex digest is also fine; some tools include the filename, some don't.)

Step 2: Draft the write-up (60 minutes)

Open ~/spk-101/capstone/writeup.md. Follow the 5-section structure from CAPSTONE.md:

Section 1: What I changed (50-100 words)

One or two sentences a non-programmer could understand. Lead with the visible effect.

Example: "I changed the color of the player character's hat in lan-master.nes from blue to red. The hat color is now a striking crimson; everything else in the game is unchanged."

Section 2: Where the bytes lived (100-150 words)

Specific. Include the byte offset, what encoded value lived there, what you changed it to.

Example: "The player's hat color is part of palette 1 (sprite palettes; the second of four sprite palettes the game uses). The palette byte for the hat color lives at file offset 0x2A14. The original byte was 0x12 (NES color 'sky blue'). I changed it to 0x16 (NES color 'crimson red'). I found it by first identifying the palette in Mesen's PPU Viewer (palette 1, slot 2), then searching the PRG-ROM for the original 4-byte palette sequence 0x0F 0x12 0x20 0x30. That sequence appears only once in PRG-ROM, so I had high confidence that was the right location."

Section 3: Why I chose this change (100-150 words)

What made it interesting? What did you hope to see? What did you actually see?

Example: "I picked the hat color because the player character is the most-on-screen sprite of any element in the game. A subtle palette change there transforms the whole experience: the game feels stylistically different even though gameplay is unchanged. I hoped the red would look 'angry'; in practice it looks more 'jaunty,' which surprised me. I think the angle is that NES palettes are bright by design, there is no muted-red option that would have given the 'serious' tone I expected."

Section 4: What I had to learn to make it work (100-150 words)

Concepts from the course (and any additional reading) you drew on. The moment something "clicked."

Example: "I drew on three skills from the course: reading the INES header to compute the CHR-ROM / PRG-ROM split (week 2); using the PPU Viewer to identify which palette controls which on-screen elements (weeks 2 and 4); searching PRG-ROM for specific byte sequences to find palette data (lab 4.1). The moment something clicked was when I realized 'sprite palettes' and 'background palettes' are separate, I had initially looked in the wrong place. The NESdev wiki's palette page was extremely helpful: https://www.nesdev.org/wiki/PPU_palettes."

Section 5: What I would do differently next time (~100 words)

Reflection. What did you learn about your own work process?

Example: "I would test the palette location more carefully before committing. My first attempt modified the wrong palette entry; I spent 45 minutes confused before realizing the issue. Next time I would write a 1-paragraph hypothesis BEFORE editing any bytes, predicting what visual change I expect. If the actual change does not match my prediction, that is data telling me my hypothesis was wrong and I should look elsewhere. The lab notes I kept were invaluable; I should keep them more carefully from the start."

Step 3: Trim and polish (20 minutes)

Re-read your write-up. Trim filler. Remove sentences that do not add information. Aim for the 500-800 word total target.

Plain English throughout. No graduate-school vocabulary. Read it out loud; if a sentence is hard to say, rewrite it.

Step 4: Package the zip (15 minutes)

Your capstone zip contents should be exactly five items per CAPSTONE.md:

spk101-capstone-{your-name}-{ROM-name}.zip
├── modified-rom.{nes,gb,sfc}
├── original-rom.{nes,gb,sfc}
├── original-rom-sha256.txt
├── writeup.md
├── before.png
└── after.png

(Six items total; the spec lists five but before/after are 2 files.)

Rename your working.{ext} to modified-rom.{ext}. Rename your original.{ext} to original-rom.{ext}.

Pick the clearest before/after screenshot pair from lab 6.2 and copy them as before.png and after.png.

Create the zip. Linux/macOS: zip -r spk101-capstone-yourname-rom.zip modified-rom.nes original-rom.nes original-rom-sha256.txt writeup.md before.png after.png (substitute your actual filenames).

Windows: select all 6 files in File Explorer, right-click, "Send to" → "Compressed (zipped) folder," then rename.

Verify the zip contents: extract to a temporary location; confirm all 6 files are present and readable.

Step 5: Submit (10 minutes)

Email the zip to interested@virtuscyberacademy.org with subject SPK-101 capstone, {your-name}.

In the email body, include:

  • 2-3 sentences describing your capstone (essentially your section 1 from the write-up)
  • A note that the full write-up is in the attached zip
  • Your name (so the academy knows whose grade to assign)

Step 6: Final reflection (5 minutes)

Open ~/spk-101/journal/lab-6-3-notes.md (your final journal entry). Write:

  • The moment you sent the email
  • How you feel about the work you shipped
  • One thing you learned about yourself during the capstone (work process, attention to detail, willingness to iterate)

Expected output

  • A polished writeup.md with the 5 required sections
  • A complete spk101-capstone-{your-name}-{ROM-name}.zip with 6 files
  • An email sent to interested@virtuscyberacademy.org
  • A final journal entry

Common pitfalls

  • Forgetting to include the unmodified original ROM in the zip: this is required (so the academy can verify the change is reproducible)
  • Forgetting the SHA-256 file: per CAPSTONE.md this is required (it makes the original ROM identifiable even if downloaded later from a different mirror)
  • Write-up that does not specify the byte offset: the byte offset is the most concrete piece of evidence in your capstone. Include it
  • Write-up tone problems: graduate-school vocabulary; trying to sound impressive. Write the way you talk
  • Zip filename has spaces: use hyphens. Spaces in filenames cause issues in some email systems

Stretch (optional)

If you finished early and have time on day 7:

  • Write a "future work" addendum to your write-up describing 2-3 changes you would make on a second capstone
  • Generate a small IPS or BPS patch file using Flips (if you used Flips during execution). Include the patch in your zip alongside the full modified ROM. This means future students can apply your hack to their own copy of the same ROM rather than re-distributing the modified version
  • Post your modified ROM (with the original author's permission, if it's a homebrew with active community presence) on the homebrew community's forum or Discord. Take a screenshot of the post; save in your journal

Lab 6.3 v0.1. The final lab of SPK-101. The closing moment.