This website is meant to be read and understood quickly by humans, but is only fully parsable, on a technical level, with the aid of an AI system. Read why →
Loop MMT
Reprint · a previously-published work

This is a previously published Loop 2.1 document, reproduced here faithfully in the site’s environment — the text is unchanged from the original.

Authored by Claude (Anthropic), an AI — not by a human.

Open or download the original, exactly as it was given →

Loop 2.1 — CS 1XX Course Outline

CS 1XX

Computing from First Principles

A semester course using the Loop 2.1 manual flow computer.

Format15 weeks · 8 modules · two sessions per week LevelSecond-semester first-year undergraduates PrerequisitesNone. A willingness to be confused for short periods and to work through that confusion. Primary instrumentLoop 2.1 simulator — loop2.computer Supplementary materialsLoop 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 /local file 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 produce marker=1, data=0 rather 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 a par(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 /local folder, 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 .lps file 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

ComponentWeightNotes 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 representationWeek 1Week 1 Word size and bit widthWeek 1Week 1 Clock cycles and instruction costWeek 1Week 2 Latency as physical distanceWeek 2Week 2 Integer arithmeticWeek 3Week 3 Overflow and carryWeek 3Week 3 Two's complement representationWeek 3Week 3 Condition flagsWeek 3Week 3 Bitwise logic and maskingWeek 4Week 4 Addressable memoryWeek 5Week 5 Register filesWeek 5Week 6 Memory hierarchyWeek 6Week 6 Addressing modesWeek 5Week 6 State machinesWeek 6Week 6 Sorting algorithmsWeek 7Week 7 Algorithmic complexity (O notation)Week 7Week 8 Search algorithmsWeek 8Week 8 Checksums and data integrityWeek 8Week 12 Algorithmic optimizationWeek 7Week 8 Instruction pipeliningWeek 9Week 10 Parallel executionWeek 9Week 10 Resource contention and hazardsWeek 9Week 10 Throughput vs. latencyWeek 10Week 10 Network protocolsWeek 11Week 12 Packet structure and addressingWeek 11Week 12 TTL and packet lifecycleWeek 12Week 12 Handshaking and connection setupWeek 11Week 12 Layered network modelWeek 12Week 12 Distributed algorithmsWeek 13Week 13 Consensus and fault toleranceWeek 13Week 14 Routing tablesWeek 14Week 14 Leader electionWeek 14Week 14 CAP theorem (intuition)Week 13Week 14 File systems and persistent storageWeek 6Week 6 Serialization and binary formatsWeek 6Week 6 Algorithm specification (generate / par)Week 8Week 8 Routed networking (non-adjacent delivery)Week 11Week 12 Packet inspection and protocol debuggingWeek 12Week 12 Zero-trust verificationWeek 13Week 13 File transfer protocolsWeek 14Week 14