Ship a working Virtus Console. Your RV32I-Lite CPU, your toolchain, your OS, your program. Same destination as CSA-101 — you get there faster because of what you already know.
The toolchain you ship
Every artifact below lives at a named stage of the pipeline you built across Weeks 5-13. The stage in amber is the one a grader walks first when reproducing your build.
| Stage | Week built | Artifact consumed | Artifact emitted |
|---|---|---|---|
| VirtusLang source | (your program) | — | .vl source file |
| Compiler frontend | Week 10 | .vl source |
parse tree |
| Compiler backend | Week 11 | parse tree | VM bytecode (.vm) |
| VM translator | Weeks 8-9 | .vm bytecode |
RV32I-Lite assembly (.s) |
| Assembler | Week 6 | .s assembly |
VOF v1 object (.vof) |
| Static linker | Week 7 | .vof objects + Virtus OS stubs |
flat binary (.bin) |
| Tang Primer 25K | Week 5 | .bin + bitstream |
output on UART / HDMI |
The compiler backend (Week 11) is the amber stage: its 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. Filename:
virtus-console.fs(Apicula output) - Source tree for the bitstream:
verilog/with your RV32I-Lite CPU + VCP integration - Toolchain artifacts: your assembler, linker, VM translator, compiler (both passes), and Virtus OS source. Copy the working version of each from your student repo into
toolchain/ - Capstone program: the VirtusLang source for one program 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:
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, program running, two notable features - Write-up. Filename:
writeup.md(orwriteup.pdf). 800-1500 words. Five sections (see below)
Zip filename convention: csa110-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 — where the RV32I-Lite experience diverged from your 6502 experience in an unexpected way. Maybe the first time a B-type immediate encoding bit-reversal produced the wrong branch offset and you spent an hour finding it. Maybe the moment you realized a two-pass assembler was necessary because the 6502's flat model let you avoid it. 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. Section 2 names real gaps. Sections 4-5 show specificity about the RV32I-Lite vs 6502 experience |
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.
The CSA-101 → CSA-110 comparison
If you completed CSA-101, you have built this before. The destination is the same; the path is different. In your write-up, note at least one place where the CSA-110 toolchain was simpler to build than the CSA-101 equivalent (e.g., the fixed-width instruction encoding simplifying the assembler), and at least one place where it was harder (e.g., the two-pass requirement for forward references in B-type offsets).
This comparison is not graded separately — it belongs in Sections 4 or 5 — but it is the most distinctive writing a CSA-110 graduate can produce. Graders will read it closely.
Legal and ethical
CSA-110 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