Classroom Public page

SPK-101 Capstone Specification

1,332 words

The capstone is one documented ROM hack. You pick the ROM and the change; you make the change; you write up what you did, why, and how; you ship a zip file. Full specification below.

What you ship

A single zip file containing all five of the following:

  1. The modified ROM file, your hack
  2. The unmodified original ROM file, kept separately so the change can be reproduced
  3. A SHA-256 hash of the original ROM file, saved as a plain text file (original-rom-sha256.txt)
  4. The 1-page write-up, saved as writeup.md or writeup.pdf
  5. Before/after screenshots, saved as before.png and after.png (or multiple if your hack needs more than one)

Zip filename convention: spk101-capstone-{your-name}-{ROM-name}.zip (lowercase; hyphens; no spaces). Example: spk101-capstone-jamie-smith-blob-2-blob.zip.

Legal ROM rules

Your capstone ROM must be ONE of these:

Option A: Open-source homebrew ROM. A ROM you downloaded from a homebrew community where the author has released the work under a permissive license (Creative Commons, MIT, public-domain dedication). Examples:

  • NESdev competition entries on the NESdev wiki
  • itch.io NES homebrew releases marked as freely-distributable
  • The Roth Brothers NES homebrew compilation
  • GBdev community releases on gbdev.io
  • SNESdev community releases on wiki.superfamicom.org

Option B: A personal cartridge dump. A ROM you personally dumped from a cartridge you personally own using a hardware tool you operate (a Sanni Cart Reader, Retrode, or similar). The cartridge must be your physical property; you must have produced the dump yourself; you must not redistribute the dump.

NOT allowed: ROMs from commercial games you do not own; ROMs of any kind downloaded from ROM-archive sites that do not have explicit author permission; "borrowed" ROMs from friends or the internet.

If you cannot dump your own cartridges and do not want to find a homebrew ROM you like, the academy maintains a curated list of homebrew options on the vca-spk-101.html page. Email interested@virtuscyberacademy.org for help selecting.

What constitutes a valid change

Your modification must be:

  • Visible: when the modified ROM is loaded in the appropriate emulator, the change is observable (a different color; a different sprite; different text; a different number)
  • Intentional: you can explain what you changed, where in the ROM the byte(s) lived, and why you chose that change
  • Stable: the modified ROM still boots and runs; it does not crash the emulator partway through

Examples of acceptable changes (any one of these is fine, you do not need to combine them):

  • Change the color of one sprite or one palette
  • Change the text of one title-screen string, one menu item, or one in-game message
  • Change the appearance of one sprite tile (the player character; an enemy; an item)
  • Change one numeric game-state value (the starting life count; the score-per-pickup; the player's starting position)
  • Swap one byte of music data (the pitch of one note in the title music)
  • Change the location of one item or enemy in one level

Examples of changes that are MORE than the capstone asks for (these are great if you want them, but the bar is set lower):

  • A "total color overhaul" that retouches every palette
  • A "translation patch" that changes every line of in-game text
  • An "overhaul mod" that adds new gameplay mechanics

The capstone asks for one clear change. More is welcome; less is not.

The 1-page write-up

The write-up is what makes the capstone a capstone (as opposed to just a code change). Write ~500-800 words in plain English. Cover these five sections:

  1. What I changed (50-100 words): the specific modification you made, described in one or two sentences a non-programmer would understand
  2. Where the byte(s) lived (100-150 words): the offset(s) in the ROM file where the modified bytes are; how you found them; what you tried first that did not work
  3. Why I chose this change (100-150 words): what made this change interesting to you; what you hoped to see; what you actually saw
  4. What I had to learn to make it work (100-150 words): the concepts from the course (and any additional reading) you drew on; the moment in the process when something "clicked"
  5. What I would do differently next time (~100 words): if you were starting the capstone over, what would you do differently? What did you learn about your own work process?

Optional additional sections:

  • Patch file: if you produced an IPS or BPS patch alongside the modified ROM, mention it and include it in the zip
  • Future work: if you have ideas for follow-on changes that build on this one, name them

Tone: write the way you talk. Plain English. No graduate-school vocabulary. Imagine you are explaining the change to a friend who does not own retro consoles. That tone is correct.

Success criteria

Your capstone is graded on three things, equally weighted:

  1. The modification works. When the modified ROM is loaded in the appropriate emulator and compared to the unmodified original, the change is observable and the game still runs
  2. You can explain what you changed. The write-up identifies the byte offset(s) you modified and what those bytes encoded; the explanation matches what the modified ROM actually does
  3. You can explain why. The write-up names a reason (curiosity, aesthetic, "I wanted to see if it would work," "I noticed this thing in the game and wondered if I could change it"); the reason is clearly stated

There is no minimum complexity threshold. A clear, well-explained palette swap earns the same grade as a clear, well-explained level edit.

What the capstone does NOT require

To be explicit:

  • No original game development: you are NOT writing a new game from scratch
  • No new sound or music: you do NOT have to compose anything
  • No high-fidelity polish: a "rough but working" change with a thoughtful write-up is full credit
  • No commercial-game hacking: stick to homebrew or your own cartridge dump
  • No reverse-engineering tools beyond what the course taught: Mesen / SameBoy / bsnes-plus debuggers and a hex editor are enough; you do NOT need Ghidra, IDA, radare2, or any disassembler more sophisticated than what the in-emulator debuggers provide

Timeline within week 6

Recommended day-by-day pacing:

  • Day 1: Read this capstone spec carefully; reread week-6-capstone.md for context. Pick your ROM and your change. Write the 1-paragraph capstone proposal in your lab journal (labs/lab-6-1-capstone-scoping.md)
  • Days 2-4: Execute the change. Iterate. Take screenshots. Note byte offsets. Save your work frequently
  • Day 5: Verify the change runs correctly. Make any final adjustments
  • Day 6: Write up the 1-page document. Package the zip. Verify the zip contents
  • Day 7: Buffer day. If you ran into a snag earlier in the week, day 7 is your catch-up time. Otherwise rest

Zip contents checklist

Before you submit, your zip should contain exactly these:

spk101-capstone-{your-name}-{ROM-name}.zip
├── modified-rom.{nes,gb,sfc}            (your hack)
├── original-rom.{nes,gb,sfc}            (the unmodified ROM you started from)
├── original-rom-sha256.txt              (one line: the SHA-256 hex digest of original-rom)
├── writeup.md                           (or writeup.pdf)
├── before.png                           (screenshot of the unmodified ROM running)
└── after.png                            (screenshot of the modified ROM running)

To compute the SHA-256 hash of your original ROM:

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

Paste the hex digest into original-rom-sha256.txt.

Submission

Email the capstone zip to interested@virtuscyberacademy.org with subject SPK-101 capstone, {your-name}. The course staff replies within 7 days with the grade and a short note acknowledging what you shipped.

If you want feedback during week 6 before final submission, the academy's Discord channel (link distributed at course start) has an instructor-monitored capstone-help thread.

Examples

A few hypothetical capstones at the "fully sufficient" mark:

  • "I changed the color of the player character in blob-2-blob.nes from green to purple. I found the palette byte at offset 0x1C40, learned about NES palette structure from the NESdev wiki, swapped the byte from 0x1A to 0x05, and verified the change worked in Mesen."
  • "I changed the title text of gb-homebrew-puzzle.gb from 'PUZZLES' to 'MAZES'. The text lived at offset 0x134, which is the Game Boy header title field. I found it via hex editor ASCII search and overwrote it with the new characters."
  • "I changed the starting life count in sfc-homebrew-platformer.sfc from 3 to 9. I used bsnes-plus's debugger to find the RAM byte that held the lives counter, traced back to the PRG-ROM constant that initialized it, and modified the constant from 03 to 09."

Each of these is a real capstone-grade change, achievable in a week.

Capstone specification v0.1. Refines after first pilot cohort.