Week 6: Capstone, Ship the Modification · SPK-101 · Virtus Cyber Academy Classroom

Pick a ROM. Make a real change. Write up what you did, why, and how. Then sit through the closing lecture that maps what you learned in SPK-101 to what CSA-101 builds.

Theme

The capstone is the artifact you ship. You pick a ROM (NES, Game Boy, or SNES; homebrew or a personal cartridge dump). You decide what to change. You make the change. You write a 1-page document explaining the change. You produce before/after screenshots. You package it all into a zip file.

The capstone is small on purpose. It is not "make a new game." It is not "rewrite the engine." It is "make one real change and explain it." The smallness is what makes the capstone achievable in week 6 (after 5 weeks of building skills) and what makes the explanation possible (you understand a small change in full).

After the capstone you sit through the closing lecture. The lecture maps every skill you used in SPK-101 to a corresponding skill you will develop in CSA-101. The bridge is real: every SPK-101 graduate who continues to CSA-101 carries vocabulary, instinct, and "I can do this" muscle memory into the next course.

Reading list (~30 minutes)

Re-read courses/spk-101/CAPSTONE.md, the full capstone specification. Re-read carefully; you will follow it this week.
Re-read the vca-csa-101.html public course page at https://virtuscyberacademy.org/vca-csa-101, the academy's main course, the one SPK-101 graduates take next. Skim the course overview, the equipment row, the week-by-week table. Notice what you recognize from SPK-101 and what is new.

Lecture outline (~2 hours)

The week's lecture has two parts: the capstone-orientation talk at week start (~30 minutes) and the closing-bridge talk at week end (~90 minutes after the capstone is shipped).

Part 1: Capstone orientation (week start, ~30 minutes)

The capstone is one student-chosen ROM modification
Pick something you find personally interesting. The grading does NOT favor ambitious changes over modest changes; a thoughtful palette swap with a clear write-up earns full marks
Plan your time: ~3 hours picking the ROM and the change, ~6-8 hours executing the change, ~2 hours writing up
Document as you go. Take screenshots before you change anything. Note the byte offsets you find. Keep a running log of what you tried that did NOT work; the failed attempts are interesting in the write-up
Avoid these pitfalls: trying to combine too many changes (one is plenty); picking a ROM you have not run before this week (use a ROM you know from earlier in the course); leaving the write-up until the last evening

Part 2: Closing bridge (week end, ~90 minutes)

After the capstones are shipped, the closing lecture maps SPK-101 skills to CSA-101 modules.

Skill: "I can install an emulator and run a ROM" → CSA-101 module: "I can flash a bitstream and run a CPU."

SPK-101 used existing emulators. CSA-101 has you build your own CPU in HDL (Hardware Description Language) and synthesize it onto an FPGA development board (the Sipeed Tang Primer 25K). Your CPU runs real RISC-V binaries. Same instinct ("the emulator / FPGA pretends to be a CPU"), one level deeper

Skill: "I can read 6502 assembly" → CSA-101 module: "I can read and write RV32I-Lite assembly."

SPK-101 read existing 6502 code. CSA-101 specifies a small RISC-V variant (RV32I-Lite: 11 instructions plus 8 pseudo-instructions, 8 registers, 4 instruction formats). You will read it; you will write it; you will hand-encode it into 32-bit binary words; you will run your hand-encoded binaries on the CPU you built. Same instinct (CPU instructions are bytes with a structure) at a deeper depth

Skill: "I can open a ROM in a hex editor and find bytes" → CSA-101 module: "I can read a binary object file and find symbols."

SPK-101 hex-viewed NES ROMs to find sprites and text. CSA-101 has you build an assembler from scratch (one that produces a custom academy object format called VOF) and a static linker (that produces flat binary images runnable on your CPU). You write the tools; you understand the bytes those tools produce

Skill: "I can make a ROM hack" → CSA-101 module: "I can write a Jack-equivalent compiler and have it emit code I wrote the runtime for."

SPK-101 modified bytes in an existing ROM. CSA-101 has you build a compiler for a small high-level language (think simplified Java); the compiler emits VM bytecode; you write the VM translator; the translator emits assembly; the assembler emits object code; the linker produces a flat image; the image runs on your CPU. The whole stack. Each layer is something you wrote

Skill: "I can write up a ROM hack" → CSA-101 module: "I write a Toolchain Diary and submit lab deliverables."

SPK-101's capstone write-up is the first time you described your own work in plain English. CSA-101 has you do this every chapter, in a running document called the Toolchain Diary. You journal each new practitioner tool you encounter (xxd, objdump, riscv32-unknown-elf-as, Ghidra, gdb, and more). The diary becomes your personal reference document, the one you reach for years after the grade is posted

The throughline. SPK-101 spent 50 hours showing you that computing is not magic; CSA-101 spends 155 hours showing you that you can build the entire stack from logic gates upward. The bridge is real. If you want to take CSA-101 after SPK-101, the academy welcomes you. If you want to take CSA-101 someday but not yet, take the time you need. If SPK-101 was enough and you do not want to continue, that is a real result too.

Labs (~5 hours total, capstone-week distinct from prior weeks)

This week the "labs" are the capstone itself.

Lab 6.1: Pick your ROM and your change (labs/lab-6-1-capstone-scoping.md)

Goal: Select the ROM you will modify; select the specific change; write a 1-paragraph capstone proposal
Time: ~60 minutes; should happen on day 1 of the week
Artifact: a 1-paragraph proposal in your lab journal saying what ROM you are using, what you are changing, and why

Lab 6.2: Execute the change (labs/lab-6-2-capstone-execution.md)

Goal: Make the modification; verify it runs in the emulator; save your work
Time: ~6-8 hours, spread across days 2-5 of the week
Artifact: the modified ROM; the unmodified ROM (kept separately); before/after screenshots; a working notes log

Lab 6.3: Write up the capstone (labs/lab-6-3-capstone-writeup.md)

Goal: Write the 1-page document; package the deliverable; produce the final zip
Time: ~2 hours; should happen on day 6 of the week
Artifact: the final capstone deliverable per CAPSTONE.md (zip containing modified ROM + original ROM SHA-256 + write-up + before/after screenshots)

Independent practice (~0 hours)

Capstone week absorbs the independent-practice budget into the capstone itself. The "independent practice" of this week is your continued exploration as part of the capstone work.

Reflection prompts (~30 minutes; for week end)

Six weeks ago, you may not have known what an emulator was, what a ROM file contained, or that you could modify a ROM. What is the moment in the course where things first started to feel like "I can do this"?
The capstone asked you to make one change and explain it. Now that you have shipped, was the explanation easier or harder than the change itself?
The closing lecture mapped SPK-101 skills to CSA-101 modules. Which of those mappings was most interesting to you?
If you were going to design the next course after SPK-101 for someone like yourself, what would you put in it?
What did SPK-101 NOT teach you that you wish it had?

Visual Helpers

You have three cognitive tools available from the cognitive tools supplement. This is a good week to review the one that helped you most in Weeks 2-4 -- reading it again now that the capstone is concrete will often make it click in a way it did not the first time.

If your capstone involves finding a specific byte offset: Re-read the offset calculation worked example in the supplement before you start Lab 6.2. Confirm your formula and your numbers on paper before you open the hex editor.

If your capstone involves sprite editing: Re-read the Bitplane Decomposer section. Decode the tile you plan to modify on graph paper first. Know exactly which bits you are changing before you change them.

If your capstone involves reading assembly in the debugger: Keep the Addressing Mode Flowchart nearby. You will read instructions in Mesen's disassembler; the # rule applies every time.

Visual Helper 4: NES debugger state inspector

The capstone has you reach for an external debugger (Mesen, FCEUX, or NestopiaUE) to see what your ROM modification is actually doing while the game runs. The four-panel inspector below embeds a small NES emulator (jsnes, a pure-JavaScript port shipped under Apache 2.0) directly into the lesson page so you can see the same kind of state your external debugger surfaces while you read about what each panel means. Use this to anchor what to look for in Mesen, not as a replacement for it; Mesen has audio, sprite OAM, scanline tracking, and breakpoint conditions this inspector does not.

Panel A walks the six architecturally-visible 6502 registers (A, X, Y, SP, PC, P) plus the eight bit positions of the P (status) register written out as N V - B D I Z C. Panel B walks three 256-byte memory pages: the page containing the current program counter, the zero-page at $0000-$00FF (the 6502's scratchpad), and the stack page at $0100-$01FF (where JSR pushes return addresses). Panel C walks the PPU state: current scanline and dot, active nametable base, the 16-entry background and 16-entry sprite palettes (PPU $3F00-$3F1F), and a live tilemap preview of nametable 0. Panel D carries step, run, pause, reset, and breakpoint controls plus a control-flow-aware disassembly side-pane. Panel E walks the APU, the audio half of the system: the 16 APU registers at $4000-$400F plus $4015 (channel enable) and $4017 (frame counter), a per-channel grid for Pulse 1, Pulse 2, Triangle, and Noise (the entire NES sound palette), and a small oscilloscope per channel plus a master oscilloscope below. Panel F walks the Object Attribute Memory, the 256 bytes that describe the 64 hardware sprites: a clickable row per sprite shows Y, tile index, attribute byte, and X; the detail panel on the right decodes the focused sprite into its fields and previews its tile. Panel G walks the cartridge mapper, the small piece of hardware on the cart that decides which slice of PRG-ROM the CPU sees at $8000-$FFFF and which slice of CHR-ROM the PPU sees at $0000-$1FFF; for plain NROM carts those windows never change, but for MMC1 / MMC3 / and most commercial games the cart watches CPU writes and re-routes the address bus mid-game.

The disassembly side-pane is built by walking the ROM from its reset vector and following branches, JSR, JMP, and RTS to build a code-vs-data classification of the PRG-ROM bytes. Bytes the trace can reach are shown as instructions; bytes the trace cannot reach are not shown (they belong to data tables, strings, or unreachable code). This is the entry-point-aware disassembly the week-2 hex viewer referenced as a forward-fold; when this page loads, it registers its trace with the wk-2 hex viewer so subsequent visits to wk-2 surface control-flow-aware annotation on the same ROM.

The APU's four channels each do one thing. Pulse 1 and Pulse 2 are square-wave generators with selectable duty (12.5%, 25%, 50%, 75%); they cover most lead and bass parts in NES music. Triangle is a fixed-shape ramp generator (no volume control, just on/off) that usually carries the bassline. Noise is a pseudo-random shift register driven by a wavelength table; it covers percussion and sound effects. The Panel E grid shows each channel's current enabled state, its envelope volume (0-15), its frequency in Hz computed from the period the CPU has written, and a duty / linear-counter / random-mode tag specific to that channel. The 16 APU registers below the grid show every byte the CPU has written to $4000-$400F plus $4015 and $4017, in hex and in binary, with a short legend describing the bits in each one that actually do something. Audio output is off by default; click Enable sound to route the emulator's output through Web Audio, drop the volume slider until the level matches what you can stand, and use the per-channel mute buttons to isolate any one channel.

The cartridge mapper is the unsung hero of NES games larger than 32 KB. The 6502 can only see 32 KB of cartridge code at once (the $8000-$FFFF window). NROM games fit in that window and run forever; MMC1, MMC3, and the other named mapper chips let games swap 8-to-32 KB chunks of their PRG-ROM in and out of that window by responding to CPU writes the game itself emits. The Panel G table shows which slots of the window are currently fixed versus switchable, what bank of cartridge ROM is mapped into each switchable slot, and decodes any mapper-specific registers (for MMC1 the 5-bit shift register and the control byte; for MMC3 the bank-select command, the IRQ counter, and the IRQ enable flag). The last-write line at the bottom of the panel shows the most recent CPU write that hit cartridge space; if you click Run and watch the bank-layout cells, you will see them briefly flash gold whenever the game swaps a bank. MMC3's IRQ counter is what makes scanline-precise effects like Super Mario Bros 3's status bar possible.

The NES PPU can draw 64 hardware sprites per frame, with eight bytes of state per sprite stored in a 256-byte block called OAM. Each sprite uses four OAM bytes: byte 0 is Y position minus one (so Y = 240 hides a sprite below the visible area), byte 1 is the tile index into the sprite pattern table, byte 2 is the attribute byte (bits 0-1 pick a sprite palette $3F10-$3F1F, bit 5 sets priority behind the background, bits 6-7 flip the tile horizontally and vertically), and byte 3 is X position. The Panel F table lays out all 64 sprites; rows whose Y >= 240 are dimmed because they are offscreen by convention. Click a row to focus that sprite; the detail panel on the right decodes the four bytes into named fields and renders the tile the sprite is currently using, with flips applied, in the chosen sprite palette. Toggle the overlay checkbox at the top of Panel F to draw sprite rectangles directly on the Panel C nametable canvas, with the focused sprite outlined in gold and sprite 0 outlined in red; the red ring is where the sprite-zero-hit flag fires, which most NES games use as a mid-frame timer to split the screen.

Scene A · Boot and step The debugger boots `nestest.nes` (Kevin Horton's public-domain 6502 test ROM) by default. Right after boot the program counter (PC) sits at the address the 6502's reset vector points to. Click Step once; the inspector advances the emulator one instruction, the PC moves forward by the byte size of that instruction, and Panel A's next-instruction line echoes the mnemonic plus the operand plus the raw bytes. Watch the A / X / Y registers move when arithmetic instructions run; watch the SP move down by 2 when a JSR pushes a return address. This is the same fetch-decode-execute cycle CSA-101 chapter 4 walks at depth.

Scene B · Breakpoint at the reset subroutine Type a hex address into the breakpoint input (try `$C66E` which is nestest's first conditional branch destination) and click Add breakpoint. Click Run. The emulator runs until it hits the breakpoint, then pauses and refreshes all four panels. Watch how the stack page (Panel B's third sub-view) has grown bytes from `$01FF` downward as JSR calls pushed return addresses, and how the zero-page has accumulated whatever values the init subroutine wrote during the run-up. Real 6502 debugging looks exactly like this loop: set a breakpoint, run to it, inspect what state the code has built up by the time the breakpoint fires.

Scene C · Control-flow trace and ROM toggle The disassembly side-pane in Panel D shows a window of about 16 instructions around the current PC, with arrow markers that name the kind of control-flow each one does: `↳` for branches, `→` for unconditional jumps, `⤿` for JSR (subroutine call), and `↩` for RTS (subroutine return). Lines marked with a left border are jump targets reached from elsewhere in the trace. Use the Switch ROM bar above the panels to toggle from `nestest.nes` to `academy-nes20-demo.nes` (a small hand-crafted NES 2.0 demo ROM); the trace re-runs from the new ROM's reset vector and the side-pane repopulates. Notice how the demo ROM's trace is much smaller (only a handful of instructions before the JMP back to itself loop) while nestest reaches deep into a multi-test suite.

Scene D · The APU and what makes the sound Panel E exposes the audio half of the system. Click Run to start the emulator, then click Enable sound; the master volume defaults to 30% so the first click does not surprise you. As the ROM runs, watch the channel rows: Pulse 1 and Pulse 2 will show duty 12.5% / 25% / 50% / 75% as the CPU toggles their `$4000` and `$4004` registers; Triangle will show a linear-counter value the CPU loaded into `$4008`; Noise will show short or long mode from `$400E` bit 7. The per-channel oscilloscopes update each video frame: square waves draw as flat-topped pulses, the triangle as the up-and-down ramp it always is, and the noise channel as the rough peaks of the pseudo-random shift register. The 16 APU registers below the grid update live as the CPU writes them, so you can match a byte write at `$4000` to a duty-mode change in the Pulse 1 row. Use the per-channel mute buttons to silence one channel at a time without stopping the emulator; the oscilloscopes keep drawing because muting is a speaker-level affordance, not an emulator-level one. Real NES audio engines look exactly like this: a handful of CPU writes to memory-mapped registers that the APU translates into the waveforms you hear.

Scene E · OAM and where the sprites live Panel F lists all 64 sprite slots that the PPU can draw per frame. Click Run, then scroll through the rows: most slots will sit at Y >= 240 (dimmed because they are offscreen, the conventional way to "hide" a sprite without disabling the channel), and the active sprites will cluster at the screen positions of the player, enemies, projectiles, and any HUD elements drawn as sprites. Click any row to focus that sprite; the right panel decodes the four bytes into Y, tile index, palette index 0-3 (which selects one of `$3F10`, `$3F14`, `$3F18`, `$3F1C` for the four-color sub-palette), priority (in front of or behind the background), flip-H, flip-V, and X. The tile preview canvas below renders that sprite's tile in the chosen palette with flips applied. Toggle Show sprite rects on Panel C to draw an overlay on the nametable canvas: gold ring for the focused sprite, red ring for sprite 0 (whose pixel-vs-background overlap is the famous sprite-zero-hit signal most NES games use to time mid-frame raster splits), green ring for every other onscreen sprite. The sprite-zero-hit indicator at the top of the panel flips to "yes" the moment the PPU detects the overlap, which is the same signal a real cartridge's code is polling `$2002` bit 6 for.

Scene F · Mapper, banks, and why most NES games are bigger than they look Panel G identifies whatever cartridge the debugger has loaded. Both default ROMs in this lesson (`nestest.nes` and `academy-nes20-demo.nes`) are NROM cartridges, which is the simplest case: 16 or 32 KB of PRG-ROM mapped once into `$8000`-`$FFFF` and never changed. Watch the PRG layout grid for those ROMs: the slots are tagged FIXED, and the bank values do not move. When the debugger later loads a game with a real mapper, the layout switches: MMC1 will show a fixed slot at either `$8000`-`$BFFF` or `$C000`-`$FFFF` and a switchable slot at the other end, with the switchable bank number updating every time the game writes to its serial control port. MMC3 splits the window into four 8 KB slots, two of which are fixed at the last two banks of PRG-ROM and two of which the game swaps via the `$8000` / `$8001` bank-select / bank-data register pair. The decoded register grid on the right side of Panel G tells you exactly what the game just said to the cartridge: for MMC1 you see the 5-bit shift register filling up as the game writes one bit at a time, then snapping back to zero when the fifth write commits a new control value; for MMC3 you see the bank-select command (0 to 7) and the IRQ counter ticking down toward the scanline split. The last-write line shows the most recent cartridge-space write in `$ADDR <- $VAL (label)` form, so you can correlate a single byte the CPU wrote with the bank-layout cells that just flashed gold.

Scene G · Diffing two save states to find the byte that moved The Diff slots button next to Save and Load opens a side-by-side comparison between two of the four save slots. Pick slot A and slot B from the dropdowns; the four sections below report what changed: which CPU registers moved (with the status-flag bits broken out so you can see which arithmetic side-effects landed), which bytes of work RAM at `$0000`-`$07FF` differ, which palette bytes at `$3F00`-`$3F1F` were rewritten, and which of the 64 OAM sprite slots got new Y / tile / attribute / X values. Use the filter chips to narrow the view when one section dominates. This is the workflow ROM-hackers and TAS authors live in. When you do not have source code, save the state right before the variable you want changes, save again right after, and diff. The byte that moved is your variable. Try it: clear all four slots, save to S1 right after boot, click Run for a second, click Pause, save to S2, then Diff S1 vs S2. The work-RAM bytes that show up in the diff are everything the game touched during that second; one of them is the frame counter, several are the player's position, and others are scratch space the game uses for whatever it was computing at the moment you paused.

Loading NES debugger…

What comes next

If you are continuing to CSA-101, your next step is the vca-csa-101.html course page and the CSA-101 outline at draft-chapters/. The academy will let you know when CSA-101 enrollment opens.

If you are not continuing immediately, the capstone you shipped is real work. Save the zip. Save your lab journal. The skills will still be there when you come back.

Whichever choice you make, the SPK-101 cohort thanks you for spending these six weeks with us. The spark was real.

All technical terms used here are in the glossary.