CS 1XX
Computing from First Principles
A semester course using the Loop 2.1 manual flow computer.
| Format | 15 weeks · 8 modules · two sessions per week |
| Level | Second-semester first-year undergraduates |
| Prerequisites | None. A willingness to be confused for short periods and to work through that confusion. |
| Primary instrument | Loop 2.1 simulator — loop2.computer |
| Supplementary materials | Loop 2.1 User Manual · Loopscript 1.0 Specification |
This course uses Loop 2.1 as its primary instrument. The machine has no stored program. Data circulates in hardware loops. The student is the program. Every concept introduced — data representation, memory, arithmetic, logic, algorithms, networks, protocols — is first experienced physically on the machine before it is named, formalized, or abstracted.
The course is built around the conviction that understanding a thing costs more than learning its name, and is worth more.
Instructional Principle
Experience before terminology. Every concept is encountered on the machine first. The formal name arrives after the student has already felt the thing. By the time a student learns what "latency" means in a textbook, they have already sat at a machine waiting 41 ticks for a bus transfer to complete and wondered why it was taking so long.
Course Philosophy
Why This Machine
Modern CS education teaches computation at the level of abstractions. Students write filter(x => x % 4 === 0) in JavaScript and get an answer in one millisecond. The data teleports. The cost is zero. The cost was never zero — it was just invisible, which is a different thing entirely.
Loop 2.1 dissolves the abstraction. Data has position. Data has width. Data moves at finite speed through a finite channel. Every operation has a setup cost and a time cost and a routing cost, and the operator cannot pretend those costs are zero, because the operator is the one paying them.
This course does not replace a traditional CS curriculum. It precedes one. Students who spend a semester operating Loop 2.1 will enter their second year having felt the physical reality of everything they will spend the rest of their education abstracting. That foundation changes how abstractions land.
The Oh Moment
In early classroom trials, instructors identified a recurring phenomenon they called the "oh moment" — the instant a student makes an unexpected conceptual connection. A student routing data between loops pauses and says: "wait, is this why you can't just do two things at once in a CPU?" The machine produces these moments at a rate that traditional instruction does not. This course is designed to maximize them.
Curriculum
The Eight Modules
The course is organized into eight two-week modules. Each module introduces concepts through direct machine experience first, then names and formalizes them. CS concepts listed under each module are introduced experientially in that module; formal treatment may continue into subsequent modules.
Module 1
The Physical Reality of Data
Weeks 1–2
Theme: Data is not abstract. It has location, velocity, and cost.
Week by Week
- Week 1: What the machine is and isn't. The operator-as-program paradigm. First session: inject a value, watch it circulate, find it at the read head. The 17-bit word format — marker bit, data bits, why the marker bit exists. Binary representation hands-on: flip switches, read the display, develop fluency with bit patterns before any formal notation is introduced.
- Week 2: The cost of moving data. Bus transfers take 41 ticks. Students measure this empirically before being told the formula. The concept of latency as physical distance. Comparison: why the same operation in Python feels instantaneous. First challenge: Add Two Numbers. Score on efficiency. Discuss why the score matters.
CS Concepts Introduced
binary representation
word size
circular storage
latency
clock cycles
instruction cost
marker / sentinel bits
Challenge Work
- Add Two Numbers — first scored session
- Empirical latency measurement — measure bus transfer time, derive the formula
Module 2
Arithmetic and Logic
Weeks 3–4
Theme: Computation is transformation. The ALU is a transformer.
Week by Week
- Week 3: The ALU in depth. Registers A, B, C, D and flexible operand routing. ADD, SUB, the carry flag — what overflow means physically. The five flags (Zero, Carry, Overflow, Sign, Parity) as information the operator reads and acts on. Why flags don't branch automatically: the operator decides. The Multiply challenge using repeated addition — students discover binary multiplication (SHL + ADD) independently when they realize it's faster.
- Week 4: Bitwise operations. AND, OR, XOR, NOT as physical bit manipulation. Mask patterns — students discover the concept by configuring the Pattern Matcher before the word "bitmask" appears in any slide. The Filter challenge. Debrief: write
filter(x => x % 4 === 0)in JavaScript in one second, then build the same operation on the machine in twenty minutes. What did the twenty minutes teach that the one second didn't?
CS Concepts Introduced
integer arithmetic
overflow
two's complement
bitwise logic
masking
condition flags
cost of operations
flags vs. branches
Challenge Work
- Multiply — discover SHL+ADD optimization independently
- Filter — the central lesson of this module
- Written reflection: what is the cost of an operation?
Module 3
Memory and State
Weeks 5–6
Theme: Memory is where computation lives between operations.
Week by Week
- Week 5: The 16 memory slots as addressable storage. 4-bit addressing — why 4 bits gives exactly 16 addresses. Write mode, read mode, auto-increment. Building a simple lookup table. The distinction between a value in a loop (transient, moving) and a value in a slot (persistent, addressed). Address-read mode: encoding destination addresses inside data words. Students discover why real memory systems need an address bus.
- Week 6: Working scratch registers as fast local storage. Why a register file exists alongside main memory. The cost model: scratch register access vs. memory slot access vs. loop circulation. State machines implemented manually — route values through a sequence of operations, tracking state in memory slots. Introduction to the session log as a record of state transitions.
- Week 6 Extension — Persistent Storage: The
/localfile system. Saving memory slots as a .L21 binary snapshot requires bit movement — the operator runs Batch Write All directed to the FILE SAVE bus destination and watches the 16-word stream arrive. Loading streams 16 words through the Memory loop's writeback pipeline. The null-slot invariant: why empty slots must producemarker=1, data=0rather than nothing, or position information is lost. The .l21x archive format as human-readable hex — editable in any text editor, importable without touching the machine. Discussion: what does "persistent" mean when a browser tab closing destroys all loop state?
CS Concepts Introduced
addressable memory
registers
memory hierarchy
addressing modes
state machines
persistent vs. transient storage
why caches exist
file systems
serialization
binary formats vs. text formats
Challenge Work
- Count Matches — requires accumulation across multiple passes
- State machine exercise — implement a 3-state sequence using memory slots
- File snapshot exercise — save a working memory state, reload it, verify slot-by-slot that the round trip is exact
Module 4
Algorithms as Physical Procedures
Weeks 7–8
Theme: An algorithm is a plan for moving data. Elegance is measurable.
Week by Week
- Week 7: Sorting. Students attempt to sort 8 values in the Big Loop by hand — manual comparison, swap, repeat. They discover selection sort independently. Then: using the Threshold Gate as a comparator to extract minimums systematically. Comparison of the manual approach vs. the hardware-assisted approach — same O(n²) complexity, very different operator action count. Introduction to the par scoring system as a formal measure of algorithmic quality.
- Week 8: Searching and accumulation. Find the Maximum challenge — brute force vs. TG-assisted rising threshold. XOR Checksum: why XOR works for integrity verification. Running sums and the Accumulate to Threshold challenge. Discussion: what makes one algorithm better than another when all of them produce the correct answer?
- Week 8 Extension — Algorithm Specification: Custom challenge authorship. Students write a
generate(params)function that produces challenge values and a correct answer, and apar(result, params)function that specifies the expert score for that instance. The machine validates both — eight structural checks, five dry runs, 50ms timeout — and rejects anything that doesn't meet contract. The exercise forces students to specify an algorithm precisely enough that a machine can verify it: what are the inputs, what is the output, what counts as correct, what is efficient? This is the first time in the course students write a formal algorithm specification rather than implementing one.
CS Concepts Introduced
sorting algorithms
algorithmic complexity
search
checksums
data integrity
algorithmic efficiency
optimization
Challenge Work
- Sort Values — scored; par gap reveals optimization potential
- Find the Maximum — attempt brute force first, then TG method
- XOR Checksum
- Accumulate to Threshold
- Custom challenge design — write, validate, and exchange challenge definitions with another student
- Midterm: timed challenge session with written debrief
Module 5
Hardware Pipelines and Parallel Operations
Weeks 9–10
Theme: Multiple things can happen at the same time if you design for it.
Week by Week
- Week 9: Running multiple buses simultaneously. Buses A and B operating in parallel — two transfers at once. The four-bus mega-loop pipeline (Working → ALU → Memory → Big → Working). Students discover pipeline hazards empirically: what happens when two buses try to deliver to the same loop in the same tick? The concept of resource contention. Counter-triggered operations and the Op Count halt system as hardware-level flow control.
- Week 10: The Pattern Matcher and Threshold Gate as parallel hardware. PM1 and PM2 in cascade: a two-stage pipeline that operates independently of any bus. TG1 and TG2 cascade: a band-pass filter built from two comparators. The full four-stage Big Loop pipeline running without operator routing between stages. Discussion: what is a hardware pipeline? Why does a CPU have one?
CS Concepts Introduced
instruction pipelining
parallel execution
resource contention
pipeline hazards
hardware filtering
throughput vs. latency
flow control
Challenge Work
- Transform Nth — requires simultaneous bus and gate management
- Pipeline design exercise: build a four-stage loop pipeline, measure throughput improvement
Module 6
Networks and Protocols
Weeks 11–12
Theme: When two machines talk, they need a shared language. That language is a protocol.
Week by Week
- Week 11: P2P connections. The WebRTC SDP exchange — why connection setup requires an out-of-band handshake. Latency measurement and what it means. Sending words from one machine to another via Bus F (left neighbor) or Bus G (right neighbor). Two students connect machines and build a simple two-node distributed computation: one machine generates values, the other processes them. Students discover handshaking independently: what happens when the receiving loop isn't ready? Introduction to Buses H and I — routed net buses that send words to any machine in the connected topology by machine ID, not just direct neighbors. Run PING NETWORK to discover topology; select a peer target in the Bus H or I sidebar; words route through intermediate machines without touching their loops. Students use Bus H to send a value three hops away and confirm arrival.
- Week 12: The CBX protocol and the Network Monitor. The Network Monitor captures the last 20 meaningful packets flowing through the machine — INVITE, ASSIGN, GO, SUBMIT, SUM_OK, SUM_FAIL, ABORT, COMPLETE, and file transfer packets. Students watch a Chain Sum challenge unfold packet by packet: the invitation goes out, each machine's acceptance returns, the GO fires, running sums arrive and are verified in real time. Then: capture a packet in the staging area, modify a field (change a submitted sum), inject it back. The origin's SUM_FAIL arrives immediately with the exact discrepancy. Discussion: this is not a security exercise — this is how you learn what the protocol is actually doing by attempting to defeat it. TTL and packet lifecycle: set a packet's TTL to 1, watch it die at the next hop.
CS Concepts Introduced
network protocols
packet structure
addressing
TTL
checksums
handshaking
flow control
layered network model
routing by address
packet inspection and debugging
protocol verification
Challenge Work
- Two-node pipeline exercise — design and implement a protocol between two directly connected machines using Bus F and G
- Routed delivery exercise — send a value via Bus H to a non-adjacent machine; verify arrival
- Network Monitor exercise — watch a Chain Sum run packet by packet; capture, modify, inject a SUBMIT; observe SUM_FAIL with discrepancy
- Written reflection: why does the internet work this way?
Module 7
Distributed Systems and Human Coordination
Weeks 13–14
Theme: When multiple computers work together, the humans coordinating them are part of the system.
Week by Week
- Week 13: The Chain Sum challenge as a distributed algorithm. Five students, five machines, one correct answer that requires every machine to contribute. The origin assigns all values and therefore knows every correct intermediate sum — this is a zero-trust verification scheme: no machine needs to trust any other, because the origin can verify independently. What happens when one machine submits a wrong answer: full abort, the failing position and exact discrepancy are named, the network restarts. Students deliberately submit a wrong value (via Network Monitor injection) and observe the detection. Discussion: what does fault tolerance mean? What makes a distributed algorithm correct?
- Week 14: Named networks and file transfer. Students form a named network, observe hub election when the hub machine is deliberately disconnected, read the distributed routing table. Then: file transfer. A student selects a .L21 file from their
/localfolder, presses SEND TO PEER, selects a recipient two hops away. The FTP_OFFER packet routes through the intermediate machine (visible in that machine's Network Monitor), arrives at the destination. The recipient sees filename, sender handle, and slot count before deciding whether to accept. Discussion: this is a three-message protocol — offer, accept, decline. What guarantees does it provide? What doesn't it guarantee? What would a production file transfer protocol add? Students also use Buses H and I in a router pattern: receive data from one remote machine, transform in loops, forward to a third. The operator is the routing layer. Students design a multi-machine computation that requires this pattern to complete.
CS Concepts Introduced
distributed algorithms
consensus
fault tolerance
routing tables
leader election
CAP theorem (intuition)
network topology
zero-trust verification
file transfer protocols
operator as routing layer
Challenge Work
- Chain Sum — full class participation, multi-machine; includes deliberate wrong-submission via Network Monitor injection
- Network formation exercise — form, observe, and deliberately break a named network; trigger hub re-election
- File transfer exercise — send a memory snapshot two hops across the chain; the recipient loads it and verifies the slot values match the sender's
- Multi-machine computation with router pattern — use Bus H and I to route data through an intermediate operator who transforms it
- Protocol design discussion: what does the three-message FTP protocol guarantee? What would you add for production use?
Module 8
Integration and Reflection
Week 15
Theme: Everything you've learned is connected.
Week 15
- Final project presentations. Students present their most efficient solution to a challenge of their choice, explaining the algorithmic decisions, the hardware components used, and what they would do differently.
- Course-level synthesis: how does everything covered — binary representation, memory, arithmetic, algorithms, pipelines, networks, protocols — appear in a conventional computer?
- The Loop 2.1 machine as a model that makes all of it visible.
- Closing discussion: what did you understand in week 15 that you couldn't have understood in week 1?
Final Project Requirements
- A novel computation of the student's own design
- Documented with a session log
- Transcribed as a Loopscript
.lpsfile - Annotated with explanation of every significant decision
- Presented live — demonstrated and discussed, not read from notes
Synthesis Question
- Written: "Name one thing the machine taught you that a textbook could not have."
Assessment
Grading Structure
| Component | Weight | Notes |
|---|---|---|
| Weekly challenge scores | 35% | Efficiency and speed modes, logged via the session log system. Scored against par. Best N of M sessions count — students are not penalized for early inefficiency. |
| Short written reflections | 20% | One per module, 200–300 words. Prompt provided. Graded on evidence of genuine engagement with the concept, not correctness. A wrong but thoughtful reflection scores better than a correct but superficial one. |
| Midterm | 20% | A timed challenge session (end of Module 4) with a written debrief explaining every significant decision made during the session. The debrief is graded; the challenge score is context. |
| Final project | 25% | Novel computation, session log, Loopscript documentation, live presentation. Graded on algorithmic quality, clarity of documentation, and the quality of the live explanation. |
On Scoring
Challenge scores reward efficiency — getting from input to correct output in the fewest operator actions and ticks. The par system provides a reference target for each challenge. Beating par is unusual in the first half of the course and should not be expected. Approaching par by the end of the semester is the goal. The score is a tool for developing intuition about algorithmic quality, not a measure of student worth.
On Collaboration
Operating Loop 2.1 is an individual activity — each student runs their own machine. Discussion of strategies, approaches, and architectural ideas is encouraged and should happen constantly. Sharing session logs or Loopscript files as study aids is permitted. Submitting another student's session log as your own is not.
Reference
CS Topic Cross-Reference
Every topic in this table is encountered experientially on the machine before it is formalized in lecture or reading. The "First Encountered" column indicates when students have already felt the concept; "Formalized" indicates when it receives its proper name, definition, and theoretical treatment.
| CS Topic | First Encountered | Formalized |
|---|---|---|
| Binary representation | Week 1 | Week 1 |
| Word size and bit width | Week 1 | Week 1 |
| Clock cycles and instruction cost | Week 1 | Week 2 |
| Latency as physical distance | Week 2 | Week 2 |
| Integer arithmetic | Week 3 | Week 3 |
| Overflow and carry | Week 3 | Week 3 |
| Two's complement representation | Week 3 | Week 3 |
| Condition flags | Week 3 | Week 3 |
| Bitwise logic and masking | Week 4 | Week 4 |
| Addressable memory | Week 5 | Week 5 |
| Register files | Week 5 | Week 6 |
| Memory hierarchy | Week 6 | Week 6 |
| Addressing modes | Week 5 | Week 6 |
| State machines | Week 6 | Week 6 |
| Sorting algorithms | Week 7 | Week 7 |
| Algorithmic complexity (O notation) | Week 7 | Week 8 |
| Search algorithms | Week 8 | Week 8 |
| Checksums and data integrity | Week 8 | Week 12 |
| Algorithmic optimization | Week 7 | Week 8 |
| Instruction pipelining | Week 9 | Week 10 |
| Parallel execution | Week 9 | Week 10 |
| Resource contention and hazards | Week 9 | Week 10 |
| Throughput vs. latency | Week 10 | Week 10 |
| Network protocols | Week 11 | Week 12 |
| Packet structure and addressing | Week 11 | Week 12 |
| TTL and packet lifecycle | Week 12 | Week 12 |
| Handshaking and connection setup | Week 11 | Week 12 |
| Layered network model | Week 12 | Week 12 |
| Distributed algorithms | Week 13 | Week 13 |
| Consensus and fault tolerance | Week 13 | Week 14 |
| Routing tables | Week 14 | Week 14 |
| Leader election | Week 14 | Week 14 |
| CAP theorem (intuition) | Week 13 | Week 14 |
| File systems and persistent storage | Week 6 | Week 6 |
| Serialization and binary formats | Week 6 | Week 6 |
| Algorithm specification (generate / par) | Week 8 | Week 8 |
| Routed networking (non-adjacent delivery) | Week 11 | Week 12 |
| Packet inspection and protocol debugging | Week 12 | Week 12 |
| Zero-trust verification | Week 13 | Week 13 |
| File transfer protocols | Week 14 | Week 14 |