Ship a working Virtus Console. Your CPU, your toolchain, your OS, your program. End of the ladder.
The toolchain you ship
Every artifact below lives at a named stage of the pipeline you built across Chs 5-12. The stage in amber is the one a grader walks first when reproducing your build.
Figure 1. The CSA-101 toolchain end-to-end. Solid green outlines are stages (programs you wrote); dashed outlines are artifacts (files those programs read or emit). Amber marks the compiler backend, the stage whose output is the contract every downstream stage consumes.
What you ship
A single zip file containing all of the following:
- Bitstream for your Tang Primer 25K (or Tang Nano 20K, advanced-track alt). Filename:
virtus-console.fs(Apicula output) - Source tree for the bitstream:
verilog/containing your RV32I-Lite CPU plus VCP integration. Buildable with the academy toolchain (Yosys + nextpnr-himbaechel + apicula gowin_pack) - Toolchain artifacts: your assembler, linker, VM translator, compiler, and Virtus OS source. Copy the working version of each from your student repo into
toolchain/ - Capstone program. The Jack-equivalent source for one program you wrote that uses the Virtus Console. Source in
program/. The program must use at least: Math, Output, Screen, and one input source (GamePad or Console) - Built binary. The capstone program compiled all the way through your toolchain. Binary at
program-built/program.bin. SHA-256 atprogram-built/program.bin.sha256 - Demo video (60-90 seconds). Filename:
capstone-demo.mp4(or.mov,.webm). Shows: cold boot, capstone program running, two notable features - Write-up. Filename:
writeup.md(orwriteup.pdf). 800-1500 words. Five sections (see below)
Zip filename convention: csa101-capstone-{your-name}.zip (lowercase; hyphens; no spaces).
Write-up sections
Section 1: What works (200-400 words)
What did you build? Lead with the most-visible capability of your capstone program. Walk through which Virtus OS services your program uses; which RV32I-Lite features your CPU exercises; what runs end-to-end without intervention.
Section 2: What doesn't (200-400 words)
What didn't make the cut? Be specific. "I tried to implement Sound.playSquare but the VCP audio channel produced static; I traced it to a missing clock-domain crossing and ran out of time" beats "audio doesn't work yet." The honest accounting is graded; the omission is not.
Section 3: What's next (100-200 words)
If you had another two weeks on this, what would you ship? Forward-pointer to CSA-201 / CON-101 / RE-101 if you are continuing.
Section 4: What surprised you (200-400 words)
The course was 14 weeks. Pick the moment that genuinely caught you off-guard. Maybe Petzold's flashlight in week 1 becoming a meaningful echo in week 13. Maybe the first time riscv32-unknown-elf-as produced the same bytes your hand-encoding had. Maybe the seeded-failure debug in lab 5.5. Write the moment plain.
Section 5: What you would do differently (100-200 words)
The capstone is your one chance to reflect on your work process. Where did you waste time? Where did you under-plan? What pattern would you carry forward into CSA-201 or your next personal project?
Success criteria
Three equally-weighted dimensions:
| Dimension | Full marks |
|---|---|
| The console works | The bitstream flashes; the capstone program boots; the demo video shows actual running output. No fakes |
| The toolchain reproduces | A grader can take your toolchain/ and program/ directories and rebuild program-built/program.bin byte-for-byte. The SHA-256 you ship matches the rebuild |
| The write-up is honest | The five sections reflect actual work. The "what doesn't" section names real gaps. The reflection sections show specificity |
No minimum complexity threshold. A simple "Hello World" Virtus Console program that boots reliably and is honestly written up earns the same grade as an elaborate game that crashes on cold boot.
Legal and ethical
CSA-101 produces work that is 100% your own. No copyrighted ROMs; no decompiled commercial code; no LLM-generated Verilog you did not understand line-by-line. The bitstream you ship is yours; the toolchain you ship is yours; the OS you ship is yours; the program is yours.
If you used AI assistance during the course, name where and how in your write-up. The academy does not prohibit AI assistance; it requires the assistance to be visible.
Timeline within week 14
Recommended day-by-day:
- Day 1: Final polish on Virtus OS services. Re-run the compliance suite. Address any flakiness
- Day 2-3: Capstone program polish. Smoke-test the boot path. Capture initial screenshots
- Day 4: Demo video recording. Multiple takes; pick the clearest
- Day 5: Write-up draft (sections 1 + 2)
- Day 6: Write-up draft (sections 3 + 4 + 5). Trim and polish
- Day 7: Final assembly. Build the zip. Verify contents. Submit
Submission
Email the zip to interested@virtuscyberacademy.org with subject CSA-101 capstone, {your-name}.
Course staff replies within 10 days with the grade and a personalized note. Capstones the staff finds particularly notable get a follow-up question about whether you would be willing to talk to future cohorts.
Examples of "fully sufficient" capstones
- A Virtus Console showing a 4×4 sliding-puzzle game; player controls via GamePad; win-state detection emits a tone via Sound; reset returns to the title screen. Demo video shows one full game.
- A Virtus Console running a 8×8 maze with a sprite that moves under Keyboard control; walls are drawn via Screen.drawLine; a coin pickup triggers a Sound chirp. Demo video shows the player navigating from start to coin.
- A Virtus Console showing a static graphical demo: title screen with the student's chosen name; a 32×32 sprite that animates in a 2-frame cycle; a beep loop. Demo video shows boot and ~10 seconds of animation.
Each of these is achievable in the course's hours and earns full capstone credit when paired with an honest write-up.
Capstone specification v0.1 prepared 2026-05-11. Refines after first pilot cohort.