What you have to ship in Module 10 to earn the CON-101 certificate. Read this in Week 1 so your Module-7 homebrew choices line up with the capstone target.
Tier 1, browser-only homebrew (pass)
An original NES homebrew ROM you wrote yourself, runnable in the browser via the academy jsnes embed, that uses sprites, the background tile map, a controller input, and at least one of audio or a score display. Roughly fifty to two hundred lines of 6502, anchored on the Module 7 lab. A five-minute recorded demo plus a written report.
Tier 2, modified core (certificate, B-minus minimum)
The Tier-1 homebrew ROM running on a soft NES core you modified yourself. The modification has to be non-trivial. A palette change is not enough. Acceptable examples:
- A new mapper variant the stock community core did not support.
- An audio-mix change visible in the APU register trace.
- A scanline-counter modification that changes when sprite-zero hit fires.
- A new memory-mapped I/O peripheral you wired into the bus and reached from your ROM.
- A controller-input remap that changes how a button maps to a game action.
The demo has to show the homebrew ROM running on the modified core for at least sixty seconds with HDMI video and audio. The written report has to call out the modification, walk the design choice, and reference at least one of the readings (Hugg, Copetti, Altice, Bogost + Montfort).
Tier 3, original soft core (distinction)
The Tier-2 homebrew ROM running on a soft core you authored from scratch, possibly starting from the academy starter-core skeleton. This is the rare bird; most students do Tier 2.
Rubric
| Dimension | Weight | What earns it |
|---|---|---|
| Modification depth | 40% | The modification you made is non-trivial, the design choice is explained, the reading is referenced. |
| Engineering discipline and reproducibility | 30% | A clean repo, a README that walks a stranger through reproducing your modified core, a Toolchain Diary entry per tool you used. |
| Demo and report quality | 30% | The five-minute demo shows the artefact actually working. The written report is clear, references the readings, names the alternatives you considered. |
What graders are looking for
- The artefact actually runs. We will reproduce your build before grading. If the README does not work for us, the score drops.
- You read the community core's HDL before modifying it. The report has to show you understood the existing structure.
- Your modification is intentional. The report explains the choice, the alternative you rejected, and the trade-off.
- You can demonstrate. The five-minute demo is the part most students skimp on. Plan for it.
Submission format
Git repo URL plus a five-minute recorded demo (MP4 or webm, link to wherever you host it). The repo has to include the modified core source, your homebrew ROM source, the Toolchain Diary, the README, and a short report (one to three pages).