SPK-101 Instructor Guide

For instructors and homeschool parents running SPK-101 with one or more students. Optional polish; the course is fully self-runnable from the student-facing materials.

Course shape at a glance

Pacing notes for younger learners (~12 years old)

SPK-101 was drafted for high-schoolers and adults working with some prior comfort around computers. A motivated 12-year-old can succeed in this course, but four spots in the material have enough abstraction density that they need deliberate slowing-down and explicit scaffolding. This section tells you where those spots are, what the failure mode looks like, and what to do.

For the three cognitive tools referenced below (Mailbox metaphor, Addressing Mode Flowchart, Bitplane Decomposer), see the full supplement at curriculum-supplements/spk-101-younger-learner-tools.md. That document has worked examples and step-by-step visual descriptions that you can read aloud, draw on a whiteboard, or hand directly to the student.

Pain point 1: Offset calculations (hex and decimal mixed arithmetic)

Where it appears: Week 2 (finding tile data in CHR-ROM), Week 4 (locating a specific sprite tile in the hex editor).

The formula that trips students up:

CHR-ROM start = 16 + (PRG-ROM size in bytes)
tile N starts at: CHR-ROM start + (N * 16)

A student who is comfortable with decimal but has not internalized hex will mentally switch bases mid-calculation and get the wrong offset. "Off-by-one" errors compound: if tile N's offset is wrong by even one byte, the resulting sprite is garbage, and the student cannot tell whether the formula or the edit was wrong.

What to do:

• Before Week 2 labs, work through one complete offset calculation by hand on a whiteboard or a piece of paper. Keep decimal and hex separate until the final step. Show the student which numbers stay in decimal (the 16-byte header, the PRG-ROM count from the header) and which are best read from the hex editor in hex.
• Have the student say the formula out loud, then fill in the numbers for their specific ROM, before they touch the hex editor.
• If a student lands at the wrong tile, ask them to re-derive the offset from scratch before checking their hex editor. The re-derivation usually catches the error.
• Budget an extra 20-30 minutes for Lab 2.2 and Lab 4.3 when working with younger students. The lightbulb usually goes on during the second calculation, not the first.
• Suggested visual aid (engineering deliverable, not yet built): the Integrated Offset Calculator (a small browser tool that takes header values as input and outputs the exact offset). Until that tool exists, a printed worksheet with the formula and two worked examples is sufficient.

Pain point 2: Bit-packed flags and binary logic (Lab 2.1)

Where it appears: Week 2, Lab 2.1 -- header byte 6 of the INES header packs the mirroring flag, the trainer presence flag, the four-screen flag, and the lower four bits of the mapper number into one byte.

The failure mode: A student reads byte 6 as a number (e.g., "it says 0x01") and does not realize that each individual bit is a separate yes/no signal. They write in their lab journal that "byte 6 = 1" without decomposing what that means.

What to do:

• Introduce the "single byte = 8 switches" framing before the lab, not during it. Say it in plain English: "This one byte is like eight light switches in a row. Each switch is either on (1) or off (0). The INES header uses these eight switches to record eight different yes/no facts about the ROM."
• Walk the student through decomposing one byte, step by step:
  1. Write the byte value in decimal (e.g., 1).
  2. Convert to binary: 0000 0001.
  3. Label each bit with its name from the INES spec (bit 0 = mirroring, bit 1 = battery, etc.).
  4. Read each label aloud: "mirroring = 1 (vertical), battery = 0 (no battery), trainer = 0..."
• Give the student a blank 8-bit worksheet (8 boxes in a row, labeled bit-7 through bit-0) to fill in before they touch the hex editor. Do this together first; then let them do it independently for the next byte.
• Budget an extra 15-20 minutes for Lab 2.1 with younger students.

Pain point 3: Bitplane encoding (NES tile decoding)

Where it appears: Week 2 (understanding how 16 bytes encode an 8x8 sprite), Week 4 Lab 4.3 (modifying sprite bytes and predicting the result).

The failure mode: A student understands that 16 bytes = one tile and that there are "two planes," but cannot connect the bit from byte 0 and the bit from byte 8 to produce the two-bit color index for pixel 0. The construction feels arbitrary.

What to do:

• Do not skip the graph-paper step. Before any computer work in Lab 2.2, have the student draw an 8x8 grid on graph paper and decode tile 0 by hand. This is slow; it is also the only way to make the bit-pair relationship concrete.
• Walk through just the first row (pixels 0-7, from byte 0 and byte 8) together before the student does the rest alone:
  1. Write byte 0 as 8 bits: e.g., 0100 1100.
  2. Write byte 8 as 8 bits: e.g., 0010 1010.
  3. Read across: bit 7 of byte 0 (Plane A) = 0, bit 7 of byte 8 (Plane B) = 0. Color = (B << 1) | A = 00₂ = color 0.
  4. Bit 6 of byte 0 (Plane A) = 1; bit 6 of byte 8 (Plane B) = 0. Color = (B << 1) | A = (0 << 1) | 1 = 01₂ = color 1.
  5. Continue for all 8 pixels.
• Once the first row is decoded together, let the student finish the remaining 7 rows alone. The pattern clicks between row 1 and row 3 for most students.
• Forward pointer: the Bitplane Decomposer visual aid in the cognitive tools supplement describes this step-by-step construction. The proposed Visual Bitplane Editor (browser tool, not yet built) will eventually replace the graph-paper pass with an interactive equivalent.

Pain point 4: Immediate vs. absolute addressing (6502 assembly)

Where it appears: Week 3 (the full addressing modes section), Week 4 (reading game code in the debugger).

The failure mode: A student reads LDA #$01 and LDA $01 as meaning the same thing. They know that LDA loads a value into the accumulator but do not track the difference that the # makes.

What to do:

• Introduce the Mailbox metaphor the first time you cover addressing modes (not as a footnote -- as the primary framing):

  "Imagine 256 numbered mailboxes in a row, numbered 0 through 255. Each mailbox holds a small piece of paper with a number on it. LDA $01 says: go to mailbox number 1, take out the paper, and read the number on it. That is what the accumulator gets. LDA #$01 says: do not look in any mailbox. The number 1 right here, in the instruction itself, is what the accumulator gets."

• Use the decision-tree question from the Addressing Mode Flowchart: "Does it have a #? Yes -- it's a literal value. No -- it's an address."

• Give at least three worked examples before asking the student to read code independently:

  1. LDA #$05 -- A gets the literal value 5
  2. LDA $05 -- A gets whatever is stored at RAM address $05
  3. STA $0200 -- writes A's current value to address $0200

• Check understanding with a counter-example: write STA #$0200 on the board and ask the student what is wrong. (STA with immediate mode is not a valid 6502 instruction; the destination of a store must always be an address, never a literal.)

• For the Addressing Mode Flowchart and Mailbox metaphor visual, see curriculum-supplements/spk-101-younger-learner-tools.md.

General timing note

With a 12-year-old working independently, plan for approximately 10-20% more time on Weeks 2, 3, and 4 than the module estimates suggest. The time goes into the four pain points above. The rest of the course (Weeks 1, 5, 6) runs close to estimate for younger students. The capstone (Week 6) may actually go faster than expected if the student is motivated, because the scoping and execution work is hands-on and concrete.

Cohort pacing recommendations

The course pace assumes one week per module. In practice, here is how to adapt:

• Self-paced (one motivated student): 6 calendar weeks works; 4 weeks if highly motivated and 10+ hours/week available
• Homeschool setting (1-3 students, parent-led): 6 weeks is comfortable. Run lectures as discussions; do labs together
• Classroom (10+ students): 6 weeks. Add a weekly lab session where students work alongside each other (peer help is valuable in weeks 3 and 4)
• Summer intensive (full-time for ~2 weeks): 50 hours fits in 10 working days at 5 hours/day. Aggressive but doable

Common student questions and answers

"Is ROM hacking legal?"

The answer depends on what you do with the modified ROM. The course is unambiguous:

• Legal: modifying a homebrew ROM (one the author has released under a permissive license) for personal use; modifying a ROM you personally dumped from a cartridge you personally own
• NOT legal: redistributing a modified copy of a commercial game (even if you bought the original); downloading a commercial game ROM you do not own

The course only uses legal-by-construction ROMs (homebrew + personal cartridge dumps). Students should be very clear about this distinction; it can come up in conversations with friends and parents.

"Why 6502 and not modern x86?"

The 6502 is small. ~56 instructions; 3 registers; 64 KB address space. A complete student can hold the entire ISA in their head in week 3. x86 has thousands of instructions and decades of accumulated complexity; nobody holds it all in their head.

The skills transfer. Reading 6502 → reading any assembly is a much smaller jump than "no assembly knowledge" → reading any assembly.

"Do I need to know programming before this?"

No. SPK-101 specifically targets students with no prior programming experience. Easy 6502 in week 3 is the introduction to programming the course uses; it is structured for true beginners.

Students who have some programming background will move slightly faster through weeks 1-3; the lab work in week 4 is where everyone's skills converge.

"What if my student can't find the right byte during week 4 labs?"

This is expected, and it is pedagogically interesting. ROM hacking is fundamentally a detective puzzle. The "I have no idea where this byte is" moment is real practice.

Help patterns:

• Ask the student to articulate their hypothesis ("I think it lives near...")
• Then ask what evidence would confirm or refute the hypothesis
• Then suggest one specific search (without giving the answer)

Avoid handing over the answer. The frustration is part of the learning.

"What if my student wants to do the capstone on a commercial game they own?"

Allowed, IF: they own the physical cartridge AND they dump it themselves with their own hardware (a Sanni Cart Reader or similar). Not allowed: ROMs downloaded from anywhere; ROMs of games they "borrowed" from a friend; ROMs of commercial games they bought digitally but do not have a physical cartridge for.

The cartridge-dumping path is genuinely fun if the student has the hardware budget (Sanni Cart Reader is ~$60-90); it adds 1-2 weekends of setup work and is not recommended for the first time through the course.

Capstone grading rubric

The capstone is graded on three equally-weighted dimensions:

There is no complexity threshold. A simple palette swap with a clear, well-explained write-up earns the same grade as a level edit with a clear, well-explained write-up. Ambition is not graded; clarity is.

What earns less than full marks

• Modified ROM does not boot, or crashes immediately
• Write-up names the change but cannot identify the byte offset
• Write-up names the change but gives no reason ("just because" without elaboration)
• Write-up borrows graduate-school vocabulary, suggesting the student did not internalize the work
• Zip is missing required artifacts (original ROM, SHA-256, screenshots)

What earns extra acknowledgment (not extra points, but worth highlighting)

• Detailed account of failed attempts and what was learned from them
• Creative reasoning behind the change
• Multiple before/after screenshots showing the change in different contexts
• Bonus deliverables: IPS/BPS patch alongside the modified ROM; community engagement (posting the hack to the homebrew author's community, with their permission)

When students get stuck

The most common stuck points:

1. Week 1: cannot get Mesen to load the homebrew ROM. Often a file-extension or zip-wrapper issue. Have them re-download and re-extract carefully
2. Week 2: cannot map "tile index" to "file offset." Walk through the offset math by hand on a whiteboard. Most students need to see it laid out once
3. Week 3: 6502 assembly feels alien. Slow down on Easy 6502. The first time someone sees LDA #$01 / STA $0200 and the simulator pixel changes, the lightbulb usually goes on
4. Week 4 (lab 4.1): cannot find the palette in PRG-ROM. Use Mesen's PPU breakpoint feature (strategy B in the lab). Or fall back to changing CHR-RAM at runtime via Mesen's PPU debugger
5. Week 4 (lab 4.3): pixel-art decoding feels overwhelming. Have the student decode just one row by hand; the others follow the same pattern
6. Week 6 capstone: scope creep. Re-read lab 6.1 with them. Pick ONE change. The grade does not reward bigger

Bridging to CSA-101

SPK-101 is the explicit gateway to the academy's main course, CSA-101 (Computer Systems Architecture I, 155 hours). The bridge lecture at the end of week 6 maps SPK-101 skills to CSA-101 modules.

If a student is asking whether to continue: ask them what they found energizing in SPK-101.

• Loved week 1's "what is an emulator" framing: CSA-101's FPGA work will be deeply satisfying. They will build their own CPU and see their own logic execute their own assembly
• Loved week 3's 6502: CSA-101 deepens this with RV32I-Lite (a RISC-V variant). The 6502 instincts transfer directly
• Loved week 4's ROM hacking: CSA-101 will give them the complete toolchain. They will write the assembler that produces the bytes they were hacking
• Loved the capstone write-up: CSA-101's Toolchain Diary is this, every chapter

Some students will not continue. SPK-101 is intentionally complete in itself. The "spark" is the deliverable; the next-course continuation is offered, not required.

Logistical notes

• Discord / community channel: the academy maintains a Discord for SPK-101 students. Invite link distributed at enrollment
• Office hours: the lead instructor offers ~1 hour/week for synchronous Q&A. Schedule shared at course start
• Capstone grading turnaround: 7 days from submission. Each capstone receives a grade plus a 2-3 sentence personalized note

Where SPK-101 fits in the academy

SPK-101 is the academy's most accessible course. It sits at the front of the catalog as a "try before you buy" experience: students who finish SPK-101 know enough to evaluate whether they want to invest in CSA-101 (Foundations track) or one of the lateral tracks (PEN-101 / RE-101 / NET-101).

Marketing copy frames SPK-101 as "the spark." The instructor's job is to keep that spark visible. Maintain energy. Celebrate the small wins. Avoid graduate-school register when explaining concepts; you are working with high-schoolers and homeschool families and curious adults; the tone is the curriculum.

Instructor guide v0.1. Updates after the first cohort completes (target: pilot cohort fall 2026).