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 , an AI — not by a human.
Open or download the original, exactly as it was given →I Got 99 Challenges but a Loop Ain't One — Loop 2.1
01–12
Fundamentals
The basics of the machine. These should be done early. Some of them will surprise you even if you think you know what you're doing.
01#
Hello, Read Head
Inject the value 42 into the Working loop. Find it at the read head. Don't touch anything else. That's it. Welcome to the machine.
Concept: Inject channel · circular storage · the R dot
02#
Forty-One Ticks
Move a value from the Working loop to the ALU loop using Bus A. Measure exactly how many ticks it takes from when the bit exits the read head to when it enters the write head. Don't look it up — count it. Then derive why the number is what it is.
Concept: Bus transfer latency · BUS_N=24 · BPW=17
03#
The Marker Bit
Inject the value 0 into the Working loop. Then inject 65535. Then inject 1. Watch what the marker bits look like on each. Explain to yourself why the marker bit exists and what would break without it.
Concept: 17-bit word format · sentinel values · word boundaries
04#
All Four Loops
Get a different value circulating in each of the four loops simultaneously. Working, ALU, Memory, Big — all four running at 24 Hz, each with a distinct value. No buses active when you're done.
Concept: Loop independence · multiple inject cycles
05#
The Slow Transfer
Set the clock to 1 Hz. Transfer a value from Working to the ALU loop using Bus A. Watch every bit travel across the bus strip individually. Identify the marker bit in the stream. Count the bits. When you can see the whole word as a physical stream of light, you're done.
Concept: Bit-serial transmission · visual intuition
06#
Bus Collision
Run two buses simultaneously, both delivering to the Working loop. Watch what happens. Document what you observe. Is it destructive? Predictable? What rule does the machine follow when two streams arrive at the same write head?
Concept: Resource contention · write head arbitration
07#
The Four-Bus Mega-Loop
Configure all four A–D buses to form a single continuous pipeline: Working → ALU → Memory → Big → Working. Get a value circulating through all four loops in sequence. Keep it running for at least three complete cycles through the full pipeline.
Concept: Multi-stage pipeline · loop-to-loop routing
08#
Loop Size Tax
Working loop is 18 words (306 bits). ALU is 24 words. Memory is 24 words. Big is 48 words. Move the same value through all four loops and measure — in ticks — how long it takes each loop to fully circulate. Calculate the relationship between loop size and circulation time. Then explain why Big Loop pipeline stages take so much longer.
Concept: Loop wordCap · latency as geometry
09#
Op Count Stop
Use the Op Count system to automatically halt the clock after exactly 100 word reads on the Working loop. Don't watch the clock — configure the counter, start the machine, and wait for it to stop itself.
Concept: Hardware flow control · counter-triggered halt
10#
Add Two Numbers
The canonical first exercise. Two injected values, one ALU addition, result circulating in ALU. Score it. Then beat your score. Then beat it again. The built-in challenge version tracks par — understand what par means before moving on.
Concept: ALU capture · basic arithmetic · par scoring
11#
Zero-Pulse Inject
Use the zero-pulse inject (inject a single zero-value word mid-loop) to insert a separator between two values circulating in the Working loop. Then route the loop to the ALU and selectively capture only one of the two values, not both. The separator is your signal.
Concept: Zero-pulse · selective capture · stream control
12#
Working Scratch Sprint
Capture four different values into the four Working Scratch registers without letting any circulate back to the main loop. Then release them in reverse order — slot 4 first, slot 1 last. Verify the correct order by watching the read head.
Concept: Scratch registers · capture timing · ordered release
13–24
Arithmetic & Logic
The ALU has eleven operations and no shortcuts. You multiply with SHL and ADD. You divide by thinking about it.
13#
The Five Flags
Trigger all five ALU flags — Zero, Carry, Overflow, Sign, Parity — in a single session. Document which operation produced each one and exactly what values were involved. You should know what each flag means before you encounter it in a challenge that requires you to react to one.
Concept: ALU flags · overflow detection · condition states
14#
Multiply by 12
Compute N × 12 for any value N, using only the operations available on the machine. No repeated addition allowed — find the decomposition that uses the fewest operations. Hint: 12 is the sum of powers of 2.
Concept: Binary multiplication · SHL decomposition · shift-and-add
15#
Integer Square Root
Given a value N in the Working loop, compute floor(√N) — the largest integer whose square is ≤ N. You cannot use a table. You must compute it. The method is yours to discover.
Concept: Iterative approximation · comparison loops
16#
Auto-Writeback Counter
Configure the ALU loop with INC + Auto-Writeback to create a self-running counter. Watch it count. Then switch to SHL + Auto-Writeback. Watch it double. Then use ADD with a constant in Reg B for a skip-counting sequence. Document what happens when the counter overflows in each mode.
Concept: Auto-writeback · feedback loops · overflow behavior
17#
Two's Complement Tour
Take the value 1000. Negate it with NEG. Confirm the result is the two's complement negation. Add the original and the negated value — the result should be 0 (and trigger the Zero flag). Then compute the absolute value of an arbitrary negative-looking value using only the operations available.
Concept: Two's complement · negation · identity elements
18#
Bit Reversal
Take a 16-bit value and produce its bit-reversal — the value you get when you flip the bit order, so bit 15 becomes bit 0, bit 14 becomes bit 1, and so on. 0b1000000000000001 should produce 0b1000000000000001. 0b1100000000000000 should produce 0b0000000000000011.
Concept: SHL/SHR interplay · bit manipulation under constraint
19#
Population Count
Given a 16-bit value N, count the number of 1-bits in its binary representation (the Hamming weight, or popcount). The result must be in the Working loop when you're done. You have 16 memory slots and all ALU operations.
Concept: Bit extraction · accumulation · systematic iteration
20#
Long Division
Divide A by B, producing both quotient and remainder. No shortcuts — compute it. Both results must be simultaneously available (in separate loops or memory slots) when you declare completion. Works correctly for any A, B where B > 0.
Concept: Division by repeated subtraction or shift · state management
21#
GCD
Compute the greatest common divisor of two values A and B using Euclid's algorithm — repeatedly replace the larger value with (larger mod smaller) until one becomes zero. The result is the other. Implement this without a table. You'll need to implement modulo first.
Concept: Euclidean algorithm · modulo via subtraction loop · recursive iteration
22#
Full Multiplication
Compute A × B for arbitrary 8-bit values A and B. The result may overflow 16 bits — document your overflow handling strategy. Use the most efficient method you can find, not repeated addition. Score it and improve until you're satisfied with the tick count.
Concept: Binary long multiplication · shift-and-add efficiency
23#
CRC-16
Compute a CRC-16 checksum over a sequence of 8 values in memory. Use the standard CRC-16/BUYPASS polynomial (0x8005). You will need to implement polynomial long division over GF(2) using XOR and SHL. The correct checksum must be in the Working loop when done.
Concept: CRC computation · XOR shift register · polynomial arithmetic
24#
Floating Point, Approximately
Design a fixed-point number system using 16 bits — allocate some bits for integer part, some for fractional part, and implement addition and multiplication in your system. Compute 3.75 × 1.5 = 5.625 and verify the fractional bits represent the answer correctly. Document your format choice and its tradeoffs.
Concept: Fixed-point arithmetic · format design · precision tradeoffs · not yet demonstrated to be solvable at par
25–34
Memory & State
16 slots, 4-bit addresses. Everything between operations lives here. Use it well.
25#
Write All, Read All
Load a distinct value into every one of the 16 memory slots. Then read all 16 back out into the Working loop in order, verifying each against what you stored. No slot skipped, no value wrong.
Concept: Full memory utilization · slot addressing · read/write cycle
26#
The Lookup Table
Pre-load memory slots 0–15 with a mapping: slot N contains the value (N × 7) mod 100. Then given any input value 0–15, retrieve the corresponding mapped value from memory in the minimum number of operations. This is a hardware lookup table. Use addr-read mode.
Concept: Addr-read mode · LUT design · indirect addressing
27#
Stack, Manually
Use memory slots 0–7 as a stack. Implement push and pop using auto-increment and manual slot tracking. Push five values in order, then pop them and verify LIFO order — last pushed is first out. The stack pointer (current top) must be maintained in a Working Scratch register.
Concept: Stack data structure · pointer management · LIFO via hardware
28#
State Machine: Traffic Light
Implement a three-state machine (Red → Green → Yellow → Red) using memory slots to hold state. Each state has a defined value. Each transition is triggered by a word arriving at the Working read head. A value of 1 advances the state; a value of 0 holds it. The current state must be readable at any time.
Concept: Finite state machine · transition logic · memory as state register
29#
Histogram
Inject 16 values, each in the range 0–3. Use memory slots 0–3 as count buckets. For each injected value, increment the corresponding bucket. After all 16 values are processed, the four buckets contain the frequency distribution. Your values, your counts.
Concept: Frequency counting · addr-write via computed address
30#
The Sine Table
Pre-load memory with 16 values representing sin(x) for x = 0°, 22.5°, 45°… 337.5°, scaled so that sin(90°) = 1000. Given an angle index 0–15, retrieve the corresponding sine approximation. Then use the table to compute sin + cos for any angle (cos(x) = sin(x+4) in the 16-step system).
Concept: Precomputed tables · scaling · cyclic indexing
31#
Insertion Sort
Load 8 values into memory slots 0–7. Sort them in ascending order in-place — the sorted values must occupy the same slots, in order, when you are done. Use insertion sort. Score it. The Threshold Gate is available as a comparator if you want to use it.
Concept: In-place sort · slot manipulation · comparator hardware
32#
Ring Buffer
Implement an 8-slot circular ring buffer in memory slots 0–7 using two Working Scratch registers as read and write pointers. The buffer must handle: write (enqueue), read (dequeue), full detection, and empty detection. Demonstrate all four behaviors. The pointers wrap at 8.
Concept: Ring buffer · pointer arithmetic · wrap-around indexing
33#
Save, Corrupt, Recover
Build a 16-slot memory state with specific values. Save it to /local as a .L21 file. Then deliberately corrupt two slots with arbitrary values. Without looking at your file, compute a checksum over the current 16 slots. Load the saved file. Compute the checksum again. The checksums should differ — confirm which slots changed. Explore what the file system does and doesn't guarantee.
Concept: File save/load · integrity checking · the limits of the snapshot
34#
Virtual Memory
You have 16 slots. Simulate a 32-slot address space by using 8 slots as "physical RAM" and 8 slots as a page table mapping logical addresses 0–31 to physical slots 0–7 (with possible eviction). Implement address translation and a simple eviction policy (e.g., LRU using access counters). Demonstrate a page fault and recovery.
Concept: Virtual memory · page tables · eviction · address translation under severe constraint
35–44
Patterns & Filtering
The Pattern Matcher and Threshold Gate are the hardware filters. Learn to think in masks and thresholds before you learn to think in loops.
35#
Even or Odd
Use PM1 to route only even values from a mixed stream into the ALU loop, discarding odd values. Configure the mask so the match fires if and only if bit 0 is zero. The match output should only contain values divisible by 2.
Concept: Pattern matcher · bitmask · single-bit test
36#
The Rising Threshold
Configure TG1 with an initial threshold of 100. Circulate a stream of values through it. Every time a value passes through (≥ threshold), raise the threshold by the passing value. Watch the threshold climb. Observe when it stops passing values entirely. What property of the stream determines the final threshold?
Concept: Threshold gate · dynamic threshold · convergence
37#
Band-Pass Filter
Using TG1 (low cutoff) and TG2 (high cutoff) in cascade, build a band-pass filter that passes only values in the range 500–1500. Values below 500 and above 1500 are discarded. Test with a stream containing values above, below, and within the band.
Concept: Cascaded filters · band-pass · TG1+TG2 pipeline
38#
Powers of Two Detector
Using only the Pattern Matcher (no ALU arithmetic), detect whether a value is a power of two. Recall: a power of two has exactly one bit set. Configure PM1 to pass only values with exactly one 1-bit. You'll need to think carefully about how bit pattern matching relates to the mathematical property.
Concept: PM mask design · single-bit detection · the limits of static masks
39#
PM Rewrite Pipeline
Configure PM2 in rewrite mode: values that match the pattern are replaced with a specific output value before being delivered. Build a pipeline that: detects values with a specific top nibble, replaces the matched value with 0xFFFF, and passes non-matched values through unchanged. Verify both behaviors.
Concept: PM rewrite mode · conditional transformation
40#
TG Clamp
Use TG Clamp mode to clamp an incoming stream to a maximum value of 1000 — values below 1000 pass through unchanged, values above 1000 are replaced with exactly 1000. Verify with values at the boundary (999, 1000, 1001) and extremes (0, 65535).
Concept: TG clamp mode · range limiting · boundary conditions
41#
Dynamic Mask
The Pattern Matcher's mask is set at configuration time — it's static hardware once the challenge begins. Design a procedure that effectively implements a dynamic filter: compute a new mask based on incoming data, reconfigure the PM mid-session, and resume filtering with the new mask. Demonstrate filtering with two different masks in sequence, both correct.
Concept: Runtime reconfiguration · PM mask as computed output
42#
Two-Stage PM Cascade
Run PM1 and PM2 in cascade — PM1's match output feeds PM2's input. Design a two-stage filter that first selects values with a specific high-byte pattern, then from those, selects only values with a specific low-byte pattern. The final output contains only values satisfying both conditions. No ALU involved.
Concept: Two-stage hardware pipeline · compound conditions · PM1→PM2 cascade
43#
The Full Four-Stage
Build the maximum hardware pipeline: PM1 → PM2 → TG1 → TG2, with each stage in the Big loop, all four operating simultaneously without operator routing between stages. Each stage must be meaningfully configured — not just pass-through. Feed it a mixed stream and verify all four filtering behaviors are visible simultaneously on screen.
Concept: Full hardware pipeline · Big Loop throughput · zero-operator routing
44#
Hardware Neural Threshold
Use the TG's threshold update capability to implement a simple adaptive threshold that tracks a moving average of the input stream — the threshold adjusts toward each passing value. After N values the threshold should converge to approximately the stream mean. Values above-average pass; values below are discarded. Demonstrate convergence over 32 values.
Concept: Adaptive filtering · moving average · convergence under constraint
45–54
Pipeline & Endurance
These run long. They're interesting if you're paying attention. They're brutal if you lose your place.
45#
100 Accumulations
Inject 100 values in the range 1–10 and compute their running sum, storing the result in memory slot 0 after each addition. When all 100 are processed, the correct total must be in slot 0. Use a counter to automate the halt after 100 words. Do not manually count — that's what the hardware is for.
Concept: Long accumulation · counter halt · streaming arithmetic
46#
Fibonacci to Overflow
Compute the Fibonacci sequence starting from F(1)=1, F(2)=1, and continue until the next value would overflow 16 bits. Store each value in memory as you go. The sequence should fill as many slots as it can before overflow, and you should detect — not just observe — the overflow using the Carry flag.
Concept: Iterative computation · two-value state · overflow detection
47#
Primes Below 200
Find all prime numbers below 200 using trial division. For each candidate N from 2 to 199, test divisibility by all primes found so far. Store each prime in a memory slot as found. You have 16 slots — there are exactly 16 primes below 60, so manage your storage carefully if you want to go higher.
Concept: Trial division · accumulating results · sieve principles
48#
LFSR Full Cycle
The machine uses an LFSR for random number generation. Using XOR and SHR, implement a 16-bit LFSR with a maximal-length feedback polynomial of your choice. Run it for exactly 256 steps, storing every 16th value in memory. After 65535 steps it should return to its initial seed — demonstrate the period is correct.
Concept: LFSR · maximal-length sequences · XOR feedback
49#
Merge Sort (Two Lists)
Load two pre-sorted lists of 4 values each into memory slots 0–3 and 4–7. Merge them into a single sorted 8-value list in slots 8–15. The merge must use the merge algorithm — comparing front elements and selecting the smaller — not sort the combined output after the fact. Both input lists are consumed in the process.
Concept: Merge algorithm · two-pointer technique · sorted merge
50#
The Midnight Run
Design a computation that takes at least 20 minutes of continuous machine operation at 24 Hz to complete. It must produce a verifiable result — not just "machine ran for a while." The result must be in memory when it finishes. You decide what it computes. Score is total tick count divided by result value. Optimize for elegance, not speed — there is no par for this one. Write a session log the entire time.
Concept: Long-running computation · observability · operator endurance · session log as artifact
51#
Custom Challenge Authorship
Write a complete custom challenge definition: a
generate(params) function, a par(result, params) function, and at least two configurable parameters. The challenge must be solvable (you must have solved it yourself), the par must be achievable but not trivial, and the generate() must pass the machine's validator (8 structural checks, 5 dry runs). Register it. Run it. Exchange it with another operator.Concept: Algorithm specification · generate/par contract · formal problem statement
52#
File Library
Fill your /local folder with 8 carefully named files, each representing a useful reusable memory state: a lookup table, a working constant set, an initialized accumulator state, etc. Document what each file contains in an operator note in the session log. Then demonstrate reuse: load one, perform a computation that depends on its contents, verify the result, export the full folder as a .l21x archive.
Concept: File system design · named state · reuse vs. recomputation tradeoffs
53#
Quine
Produce a 16-slot memory state such that when the Batch Write All stream is routed back into the Machine as an injected sequence, the resulting memory state is identical to what you started with. The memory state must reproduce itself from its own output. This is a machine quine.
Concept: Self-reference · fixed-point computation · quine construction under hardware constraint
54#
The Tour de France
Complete challenges 01 through 50 in a single session. You may not close the browser tab. The session log must be running the entire time. Time yourself. This is not a speed challenge — it is a fluency challenge. An operator who has genuinely internalized the machine should be able to do this in under four hours.
Concept: Operator fluency · session continuity · the log as proof
55–67
Networking
Two or more machines. Real connections. Real latency. The humans in the chain are part of the system.
55#
First Contact
Connect two machines via Bus F. Send a value from Machine A's Working loop to Machine B's Working loop. Confirm arrival. Measure the latency. Then send in the other direction. Two operators, two machines, one confirmed exchange each direction.
Concept: WebRTC SDP exchange · Bus F · P2P latency measurement
56#
The Buffer Demonstration
Machine A sends a steady stream of values to Machine B via Bus F, at a speed faster than B's loop can absorb. Watch the P2P inbound buffer count climb on Machine B. Then have B start its loop. Watch the buffer drain. Document the relationship between sender rate, receiver rate, and buffer depth.
Concept: Inbound buffer · flow control · back-pressure
57#
Producer-Consumer
Machine A generates values using auto-writeback INC, continuously. Machine B receives them via Bus F, processes each through the ALU (e.g., multiply by 3 using SHL+ADD), and stores results in memory. Neither machine stops until memory is full. No manual coordination — the rate must be sustainable without the operator on B doing individual captures.
Concept: Async producer-consumer · sustained throughput · auto-processing
58#
Three-Machine Relay
Three machines in a chain (A–B–C). A sends values to B via Bus F. B adds 100 to each value using the ALU. B sends the incremented values to C via Bus G. C stores them in memory. A and C never communicate directly. B is the relay — it processes and forwards. All three operators are active simultaneously.
Concept: Linear chain · relay node · per-hop transformation
59#
Agreed Protocol
Two machines, no built-in challenge. Design and implement your own two-machine protocol from scratch: agree on a start signal, a data format, an acknowledgment, and an end signal. Implement it. Transfer exactly 8 values with verified round-trip acknowledgment for each one. Write the protocol down before you start — it must be specifiable in writing to be a protocol.
Concept: Protocol design · handshaking · acknowledgment · the gap between specification and implementation
60#
Routed Delivery
Three machines in a chain (A–B–C). Using Bus H, send a value from Machine A directly to Machine C, bypassing B's loops entirely. Verify arrival on C. Then open B's Network Monitor — the packet should appear there as a transit packet. B is physically in the path but operationally invisible to the data.
Concept: Bus H routing · hop-through · Network Monitor as observer
61#
File Handshake
Two machines. Machine A has a lookup table in /local. Machine A sends the file to Machine B via FTP. Machine B accepts, loads it into memory via the writeback pipeline, and sends a result computed using the table back to A via Bus F. A verifies the result is correct. File, transfer, use, confirm — all in one session.
Concept: FTP offer/accept · /local as a communication medium · remote state loading
62#
Network Monitor Lab
Two machines running Chain Sum. Enable the Network Monitor on both. Watch the full protocol unfold: INVITE, ASSIGN, GO, SUBMIT, SUM_OK, COMPLETE. On the non-origin machine, capture the ASSIGN packet in the staging area and read off your assigned value and position from the fields. Then capture the SUBMIT packet, change the sum value by 1, and inject it. Observe the SUM_FAIL with the exact discrepancy.
Concept: Network Monitor · packet inspection · protocol verification · deliberate failure
63#
Operator-as-Router
Three machines (A–B–C). Bus H on A is pointed at C. Bus I on C is pointed at A. Machine B is in the middle — its loops are running, its Network Monitor is on. A sends a stream of values via Bus H toward C. B, as the middle machine, sees the packets transit. C receives the values, adds its own processing, and sends results back to A via Bus I through B. B never touches the data with its loops. The humans are the routing layer.
Concept: Operator-as-router · bidirectional net bus routing · protocol visibility at the relay node
64#
Chain Sum — Perfect Score
Run Chain Sum with 3 machines. Every operator must complete their arithmetic correctly on the first submission — no retries, no SUM_FAIL. The challenge completes cleanly in one pass. Do this on the first attempt. The constraint is coordination, not computation.
Concept: Zero-trust verification · operator coordination · first-attempt precision
65#
Distributed Max-Finding
Three machines, each holding 4 values in memory. Without sharing the raw values, find the maximum across all 12 values using a tournament protocol you design. Machine 1 finds its local max. Machine 2 finds its local max. Machine 3 (designated aggregator) receives both local maxes, finds the global max. The aggregator's Working loop must contain the correct answer when all three operators declare done.
Concept: Distributed reduction · tournament algorithm · partial results aggregation
66#
Hub Election Live
Form a named network with 3 machines. Identify which machine is the hub. Then disconnect the hub machine mid-session — deliberately close its P2P connections — and watch re-election complete. The remaining two machines must complete a chain sum successfully after the re-election, proving the network is functional. Document the packets you see in the Network Monitor during the election.
Concept: Hub election · fault tolerance · network recovery
67#
The Broadcast Storm
Four machines in a chain. Design a forwarding protocol where each machine that receives a broadcast also forwards it to its neighbors. Deliberately omit the "don't forward what you already forwarded" rule. Run it. Watch the storm. Then, without restarting any machine, coordinate a shutdown: highest-numbered machine stops forwarding first, then inward. Drain the network while it is still oscillating. Document the time from storm start to silence.
Concept: Broadcast storm · network saturation · coordinated recovery · the best forty minutes of your networking education
68–74
Files & Persistence
The machine forgets everything when the tab closes. These challenges are about making it remember.
68#
The Slow Save
Set the clock to 4 Hz. Fill all 16 memory slots with distinct values. Name a file. Run Batch Write All to the FILE SAVE destination on Bus A. Watch every word of the 16-word stream travel across the bus strip at 4 Hz. Watch the word counter in the armed panel advance: 1/16, 2/16… 16/16. This is your memory becoming a file. Stay present for all 41 × 16 ticks of it.
Concept: Batch Write All · bit-serial save · FILE SAVE bus destination
69#
The Null Slot Test
Load values into memory slots 0, 4, 8, and 12 only — leave slots 1–3, 5–7, 9–11, and 13–15 empty. Save to a file. Load the file back. Verify that the four populated slots contain their original values AND the empty slots are still empty. This is the null-slot invariant in action: position is preserved because silent slots are not skipped.
Concept: Null-slot invariant · marker=1, data=0 · stream position preservation
70#
The l21x Audit
Save 3 files to /local. Export the folder as a .l21x archive. Open the archive in a text editor. Read the hex values. Manually verify that slot 5 of file 2 matches what you stored. Modify one value in the text editor, import it back. Confirm the change landed in the correct slot. The format is designed to be auditable by hand — audit it.
Concept: .l21x format · human-readable hex · round-trip via text editor
71#
Checkpoint System
Run a long computation (at least 10 minutes). Every time you reach a meaningful intermediate state, save a checkpoint file to /local with a meaningful name (STEP-01, STEP-02, etc.). After completing the computation, demonstrate that you can restore any checkpoint and resume from that state. The file system is your undo history.
Concept: Checkpointing · intermediate state preservation · resumable computation
72#
FTP: Blind Transfer
Two machines. Machine A has a file with 12 populated slots. A transfers it to B via SEND TO PEER. B accepts without knowing the contents. B loads the file and uses it as input to the Add challenge — adding slot 0 to slot 1. A verifies the result remotely by sending the expected answer via Bus F. B confirms match. Neither operator told the other the values out-of-band.
Concept: Blind data transfer · FTP as a communication channel · remote verification
73#
Distributed Lookup
Machine A holds a lookup table in /local (16 entries, N → f(N)). Machine B does not have the table but needs to look up 8 values. B sends each query value to A via Bus H. A looks up the value, finds the result, sends it back via Bus H. B stores all 8 results in memory. A never tells B the full table — B gets only the answers it asks for, on demand.
Concept: Remote procedure call pattern · request-response · state on one machine, queries from another
74#
Content-Addressed Storage
Build a filing system where each file is named by a hash of its contents. Compute a 16-bit hash of the 16-slot memory state (your choice of hash function — something built from XOR and ADD will do). Use the hash as the filename (in hex). Store 8 files. Then, given only a hash value, retrieve the correct file without remembering which computation produced it. Demonstrate a collision strategy for when two states hash identically.
Concept: Content-addressed storage · hash functions · collision handling
75–87
Multi-Machine Architecture
These are systems problems. The machine is the substrate. The operators are the architecture.
75#
Pipeline Stages
Three machines, each performing one stage of a three-stage pipeline: Stage 1 doubles the input (SHL). Stage 2 adds a constant. Stage 3 applies a bitmask. Values flow A→B→C continuously via Bus F/G. Each machine may only perform its assigned transformation. The final output stream on C's Working loop must be provably correct for any input sequence A generates.
Concept: Distributed pipeline · stage isolation · continuous flow
76#
Parallel Sum
Four machines, each summing 4 values independently. All four sums are sent to a designated aggregator machine (not one of the four) via Bus H/I. The aggregator sums the four partial results to produce the total sum of all 16 values. No machine knows any other machine's individual values. The aggregator never receives raw data — only partial sums.
Concept: Parallel reduction · partial results · map-reduce pattern at human scale
77#
Consensus
Three machines each choose a private value. Without sharing values directly, all three must arrive at the same agreed value — the maximum of the three private values. Each machine may only broadcast a single number after the initial exchange round. Design the protocol. Implement it. All three Working loops must contain the same correct answer.
Concept: Distributed consensus · single-round protocol · Byzantine agreement (benign case)
78#
Distributed Sort
Four machines, each holding 4 unsorted values in memory. After the challenge: Machine 1 holds the 4 globally smallest values, sorted. Machine 2 holds the next 4. Machine 3 the next 4. Machine 4 the 4 largest. Each machine may only communicate via Bus F and G. The protocol may involve multiple rounds. The result must be correct for any input distribution.
Concept: Distributed sorting · merge-based partition · multi-round coordination
79#
The Invisible Middleman
Three machines: A, B (hidden), C. A and C can only communicate through B. A does not know B's processing logic; C does not know A's values. B's job: receive A's values, apply a secret transformation (known only to B), and forward to C. C must guess B's transformation from the input/output pairs it observes. The challenge ends when C can predict B's output for any new input A sends, before B processes it.
Concept: Black box analysis · reverse engineering · information theory intuition
80#
Commit-Reveal
Two machines. Both operators pick a secret value 0–15. Using only the machine, implement a fair coin flip: both operators commit to their values (send a hash, not the value), then reveal (send the actual value), then XOR the two values mod 2. Neither operator can change their value after seeing the other's commitment. The XOR result is the coin flip. Design the hash function. Demonstrate fairness: neither operator's reveal changes the outcome.
Concept: Commitment scheme · cryptographic fairness · hash-then-reveal
81#
5-Machine Chain Sum — Clean
Five machines. Run Chain Sum. Every operator completes their arithmetic correctly on the first submission. No SUM_FAIL, no abort, no retry. The challenge completes cleanly in exactly one pass through the chain. Getting five humans to do arithmetic correctly under time pressure, simultaneously, without communication errors, is the actual challenge.
Concept: Coordination at scale · precision under pressure · zero-error protocol execution
82#
Network-Wide XOR Checksum
Four machines, each holding 4 values in memory. Compute a single XOR checksum across all 16 values — the XOR of every slot across all four machines. No machine ever sees another machine's raw values. Each machine computes its local XOR and forwards it. The aggregator XORs the four local results. The final answer is 4 bytes that depend on all 16 values from all 4 machines.
Concept: Distributed checksum · XOR commutativity · data integrity at network scale
83#
Distributed Multiplication Table
Four machines collaborate to build a multiplication table. Machine 1 handles multiplications where A=1–4. Machine 2 handles A=5–8. Machine 3 handles A=9–12. Machine 4 handles A=13–15. After the computation, every machine's /local folder contains one file — a snapshot of its portion of the table. A fifth machine serves as coordinator and can request any product from any machine by FTP query. All results must be verifiable.
Concept: Work partitioning · distributed storage · query-response over FTP
84#
Secret Sharing
One machine holds a 16-bit secret value. Using XOR-based secret sharing, split it into 3 shares such that any 2 of 3 shares can reconstruct the secret, but no single share reveals anything. Distribute the shares to 3 machines via FTP. Then: have any 2 of those machines collaborate to reconstruct the original value without the third. The machine holding the third share must not be consulted.
Concept: XOR secret sharing · threshold schemes · information theoretic security
85#
Byzantine Generals
Four machines. One operator is secretly designated as the traitor — they may send different values to different recipients. The three loyal operators must reach consensus on the same value despite receiving contradictory messages from the traitor. Implement a Byzantine fault-tolerant consensus protocol. The three loyal operators must end up with the same value in their Working loops, even if that value isn't what the traitor told them.
Concept: Byzantine fault tolerance · 3n+1 requirement · the actual generals problem
86#
The Eight-Node Ring
Eight machines in a closed ring (each connected to its left and right neighbor, with machine 8 connected back to machine 1). Design and implement an addressing protocol using the top 4 bits of the first word as destination address. Implement broadcast (address 0000), unicast (address 0001–1000), and a "don't forward what you already forwarded" rule that prevents broadcast storms. Demonstrate all three correctly. Document every protocol decision.
Concept: Ring topology · addressing · broadcast · storm prevention · the full eight-node experience
87#
The Full Internet
Three named nets, each with 3+ machines, connected by one machine that belongs to all three (the gateway). Implement routing between nets: a message originating in Net A addressed to a machine in Net C must traverse the gateway, which inspects the destination and forwards to the correct net. The gateway operator makes all routing decisions in real time with no automation. Document the routing table. Demonstrate a cross-net message delivery with full Network Monitor traces on all three machines involved.
Concept: Inter-network routing · gateway nodes · the internet at human speed
88–99
Design & Meta
These aren't about the answer. They're about what you understand well enough to build, specify, or break.
88#
Par Hunt
Choose any built-in challenge. Run it. Get your score. Look at the par. Now close the gap by at least 50%. Then close it by another 25%. Keep going until you either beat par or fully understand why you can't. Write down every optimization you discovered. The par is achievable by design — if you haven't beaten it, you haven't found the right approach yet.
Concept: Algorithmic optimization · par as an attainable target · understanding versus performance
89#
The Annotated Session Log
Run any medium-length challenge with the session log active. At the end, download the .loop file. Open it. Find five specific lines that correspond to meaningful decisions you made. For each, write one sentence explaining why you made that decision. The log is a record of your thinking. Prove you can read it back.
Concept: Session log format · dual-format lines · computation as recorded history
90#
Teach the Machine a New Problem
Write a custom challenge definition for a problem that does not exist in the built-in set. The problem must be original — not a variant of an existing challenge. It must have a non-trivial optimal solution. Pass it to another operator. They must be able to run it without any verbal explanation from you — the definition must be self-documenting. If they need to ask a clarifying question, revise the definition until they don't.
Concept: Problem design · self-documenting specification · the generate/par contract as communication
91#
The Wrong Architecture
Solve the Sort Values challenge (8 values) three different ways: (1) brute-force comparison with no hardware assist, (2) using TG1 as a comparator, (3) using the four-bus mega-loop as a pipeline. Score all three. Write a technical comparison: which approach is fastest, which uses the fewest operator actions, which is most observable, which scales better to 16 values. The best score is not necessarily the best architecture.
Concept: Architectural tradeoffs · multiple implementations · efficiency vs. clarity vs. scalability
92#
Headless Run
Configure the machine to complete the Filter challenge entirely automatically — no operator interaction after the initial setup. Use counter triggers, op count halts, pattern matchers, and threshold gates to route, filter, accumulate, and stop without any button presses during execution. The challenge must complete correctly. You are configuring a machine, not operating one.
Concept: Headless operation · fully automated pipeline · hardware as program
93#
The Stress Test
Run the machine continuously at 24 Hz for 60 minutes. During that time, complete at least five distinct challenges, each with a saved session log. Do not pause the machine between challenges — keep the loops running at all times. Transition cleanly from one challenge setup to the next without stopping. Operator endurance is not the point; transition fluency is.
Concept: Operator fluency · clean transitions · continuous operation
94#
The Protocol Autopsy
Enable the Network Monitor. Run a full Chain Sum with 3 machines from start to completion. Collect every packet. After completion, produce a written timeline: for each packet, what caused it, what it contained, what it produced on the receiving end. The timeline must account for every packet in the monitor log with no gaps. This is a protocol trace, written by the operators who ran it.
Concept: Protocol analysis · packet causation · the CBX protocol as a documented sequence
95#
The Variant
Design a Loop 2.1 variant — a modified set of rules that changes how the machine operates without breaking it. Write the variant spec: what rule changes, what stays the same, what new behaviors emerge, what becomes impossible. The spec must be precise enough that two operators reading it independently would run the variant the same way. Consider submitting to the Variants Board.
Concept: Rule design · variant specification · the creative layer above operation
96#
The Loopscript Program
Write a complete Loopscript (.lps) file that, when executed, performs the Accumulate to Threshold challenge from scratch — setting up the inject sequence, configuring the hardware, running, and halting correctly. The script must be correct for any threshold value specified as a parameter. Test it on three different thresholds. A program that specifies a computation is different from an operator performing one.
Concept: Loopscript · specification vs. execution · programs as reproducible procedures
97#
The Impossible Protocol
Attempt to implement a reliable two-machine protocol that guarantees delivery even when the P2P connection drops mid-transfer. You will fail. The machine has no persistence layer between the bus strip and the file system; a dropped connection loses in-flight words irrecoverably. Document exactly where the guarantee breaks down, what would need to exist in the machine to fix it, and why real TCP had to solve this with retransmit timers and sequence numbers.
Concept: Reliability · the limits of the machine · why TCP is the way it is
98#
Teach a Class
Prepare and deliver a 30-minute session introducing Loop 2.1 to someone with no prior exposure. You must cover: the 17-bit word, the inject channel, a bus transfer, and one ALU operation. They must successfully move a value from Working to the ALU loop themselves, without your hands on their keyboard. If they can't do it, your explanation failed — revise and try again. Running someone else through Hello, Read Head is different from doing it yourself.
Concept: Teaching as mastery test · the operator-as-program for a second person
99#
The One That Isn't Here Yet
The machine will grow. New buses, new protocol types, new hardware features not yet built. This slot is intentionally empty. When you encounter a capability that makes something possible that wasn't possible before, that's where challenge 99 begins. It has not been designed yet because it cannot be designed yet. You'll know it when the machine can do something none of these 98 challenges needed.
Concept: The frontier · the capability that doesn't exist yet · building the challenge from the feature
On difficulty: Easy means any operator who has spent an hour with the machine should manage it without struggle. Hard means experienced operators will need to think carefully and may spend significant time. Not Yet Done means exactly that — these haven't been demonstrated to be solvable at a reasonable par. They may be solvable and no one has done it yet. They may require machine features not yet built. They may turn out to be impossible with current constraints, in which case documenting why they're impossible is the challenge.
On solutions: There are no posted solutions. The par system provides a reference target for scored challenges. An operator who beats par has found an efficient approach. An operator who fails to beat par after significant effort has learned something about the problem that par-beating operators have not necessarily articulated. Both are valid outcomes.
On challenge 99: It's a placeholder by design. The machine is a moving target. The right challenge for a capability that doesn't exist yet cannot be written before the capability exists.
On solutions: There are no posted solutions. The par system provides a reference target for scored challenges. An operator who beats par has found an efficient approach. An operator who fails to beat par after significant effort has learned something about the problem that par-beating operators have not necessarily articulated. Both are valid outcomes.
On challenge 99: It's a placeholder by design. The machine is a moving target. The right challenge for a capability that doesn't exist yet cannot be written before the capability exists.