The parts, one at a time

Each part gets: what it's for, the metaphor that makes it click, the diagram, and what it sounds like when it's sick. Confidence tags: MILLS = true of the Mills bell family generally. OURS = we've seen it on our machine. VERIFY = we haven't looked yet.

3.1 The bouncer: coin head, escalator, detector, handle lock

What it does. Two things, and they're separate: it decides whether this quarter is a real quarter, and it lets you have exactly one pull for it.

Metaphor. A nightclub door. The coin head is the ID check — wrong size, you're out (reject cup). The escalator is the velvet rope that moves one person forward per beat, in full view, so nobody can sneak back out. The detector is the bouncer's hand on the latch — it feels a body go past and unlocks the door once. The cycle latch is the guy inside making sure you don't hold the door for your friends.

stateDiagram-v2
    [*] --> Locked
    Locked --> Armed: real quarter reaches the detector
    Armed --> Cycling: handle pulled through
    Cycling --> Returning: fork finishes its stroke
    Returning --> Locked: escalator steps, detector resets, lock re-engages
    Locked --> Locked: wrong coin → reject cup

3D model. models/escalator.html (in this repo) is a schematic of the coin path: the head's gauge, the magnet, the escalator with its pawl, the detector and the reject cup. Pick what goes in — a good quarter, an undersized or oversized coin, a steel or brass slug, a quarter on a string — insert it and pull. The side view shows the escalator stepping and the top coin leaving for the routing point. MILLS-family schematic; our own head isn't photographed yet, and the magnet is VERIFY (Matt saw one in a video about the Bursting Cherry series).

Debug note. Most "bouncer" faults are the bouncer being slow, not broken — a gummed pivot or a tired return spring that doesn't get the lock back in place before the next pull. Listen for beat 9.

3.2 The teller: where quarters go once they're in

What it does. Every accepted quarter becomes inventory. The machine sorts it into one of three drawers, in strict priority.

Metaphor. A bank teller with three drawers. The payout tube is the till — the cash she pays customers from, and it gets topped up first, always. The jackpot is the vault. The cash box is the deposit bag to head office. The machine protects its ability to pay winners before it takes a profit. Working capital before revenue.

What the Mills literature says, and what ours actually does. Service references for other Mills models describe a strict cascade: till fills, then the vault fills, then the cash box gets anything. Ours doesn't work that way. We've watched it: the jackpot doesn't get a quarter every play, and it does not fill up before the cash box starts taking coins. The jackpot is progressive — it gets fed a share of the coins over time while the cash box is already collecting. So after the till, it's a splitter, not a queue.

flowchart TD
    A[Quarter leaves the escalator] --> B[Main chute]
    B --> C[Routing point at the top of the payout tube]
    C --> D{Room in the till?}
    D -->|Yes| E[(Payout tube — the till)]
    D -->|No: tube full, shutoff lever active| F[Splitter — VERIFY the mechanism]
    F -->|some coins| G[Jackpot fill deflector]
    G --> H[(Jackpot — the vault, fills progressively)]
    F -->|most coins| K[Cash-box chute]
    K --> L[(Cash box)]
    H -->|vault full| K

    E --> M[Ordinary wins are metered from here]
    H --> N[Dumps on BAR BAR BAR]

What we know about the splitter so far: from years of watching it, which coin goes to the vault looks random, and the vault takes a long time to fill. That's consistent with a small fixed share (one coin in many) delivered by something that doesn't visibly count — or with a condition that just happens rarely. "Looks random" over a handful of plays and "every 8th coin" are hard to tell apart by eye, which is why the twenty-play tally below is worth doing once.

What we don't know yet (VERIFY):

• Is it a counter — a deflector that flips every Nth coin toward the vault — or a condition — coins go vault-ward only on certain plays (after a loss, at a certain fork position)?
• What's the ratio? The slow fill says it's small — one in ten or fewer — but that's a guess.
• Does the till still get priority — i.e. after a win lowers the till, do coins go there first before the splitter sees any?
• What stops the vault from over-filling: geometry, a door, or the deflector parking?

FILL IN: twenty consecutive plays with the back open and the till full. For each play note: win/lose, and where the quarter went (till / vault / cash box). That gives us the ratio and tells us whether it's a counter or a condition. → §7.4

"Full" isn't measured by anything. It's geometry: the coin column gets tall enough to push a shutoff lever, a chute physically can't take another one, or a deflector flips the next coin down a different path.

stateDiagram-v2
    [*] --> TillEmpty
    TillEmpty --> TillFilling: paid plays
    TillFilling --> TillFull: column reaches the shutoff
    TillFull --> Splitting: splitter feeds vault a share, cash box the rest
    Splitting --> TillFilling: any win lowers the till
    Splitting --> Splitting: vault grows progressively
    Splitting --> VaultEmptied: BAR BAR BAR dump
    VaultEmptied --> Splitting: vault starts rebuilding

Why this matters when debugging:

• An emptied machine can't pay a full win until the till is refilled. Hand-load the tube when servicing, or you'll chase a phantom payout bug.
• If quarters go to the cash box while the till is visibly low, the tube shutoff or diverter is stuck.
• If the vault never gets a coin over many plays, the splitter or the jackpot fill deflector is missing, stuck, or bypassed. A previous operator may have done that on purpose (see §3.5 — they cheated in the routing too).
• If the vault seems to get a coin every play, something is stuck the other way.

FILL IN: the quarter trace, the twenty-play split count, and the capacity count (§7.4). Until we have those numbers, "full" and "progressive" are concepts, not specs.

3.3 The camshaft: handle and operating fork

What it does. One pull provides all the energy for the cycle and sequences every other subsystem off its travel.

Metaphor (Dan's). The cam. One rotating input, and every valve, every timing event, comes off its profile at the right crank angle. The handle doesn't "turn the reels" any more than a cam "opens the valves" — it drives a fork whose travel causes the kicker to cock and release, the slides to position, the clock to release, and the reset to arm.

Metaphor (Matt's). The main loop. Everything else is a callback registered to a point on the stroke.

flowchart TD
    A[Handle pull] --> B[Handle shaft & cam]
    B --> C[Starting lever]
    C --> D[Operating fork]
    D --> E[Kicker cocked, then released]
    D --> F[Slide pushbar positioned]
    D --> G[Clock released]
    D --> H[Reset linkages armed]
    D --> I[Jackpot reset contact - if fitted, VERIFY]

Feel is the diagnostic. A good pull is one smooth, rising resistance, a clear let-go when the kicker fires, then a clean spring return. A notch, a dead spot, or a hang localizes to one branch above. Cycle it by hand with the chassis out and you'll feel exactly where the cam profile has a lump in it.

3.4 The engine and the clock: reels, kicker, stops

Three jobs, three parts, and keeping them separate is everything:

• The kicker puts energy into the reels. (The starter motor.)
• The clock decides when each reel gets stopped. (The distributor — timing, not power.)
• The reel's position at that instant decides what symbol shows. (Where the crank happens to be.)

The clock knows nothing about symbols. That's why a bad clock gives you mistimed or simultaneous stops, never wrong symbols — and why a wrong payout is never a clock problem. If you find yourself adjusting the clock to fix a payout, stop; you're in the wrong subsystem.

sequenceDiagram
    participant O as Operating fork
    participant K as Kicker
    participant C as Clock / governor
    participant S1 as Stop lever 1
    participant S2 as Stop lever 2
    participant S3 as Stop lever 3
    participant R as Reels

    O->>K: cock and fire
    K->>R: all three spin
    O->>C: release clock
    C->>C: tick tick tick (governed)
    C->>S1: release
    S1->>R: reel 1 drops onto its stop star
    C->>C: tick tick
    C->>S2: release
    S2->>R: reel 2
    C->>C: tick tick
    C->>S3: release
    S3->>R: reel 3
    R->>R: brakes settle each reel dead on index

Clock sick-sounds:

The clock gets one drop of light oil at actual pivots, nothing else. Never grease it.

3.5 The punch-card reader: hammers and holes

This is the part that turned the machine into a computer for us, so it gets the long explanation.

What it does. Behind each reel is a code disc — a metal disc with holes or notches at every stop position. The disc is the machine-readable copy of the printed strip. When the reels stop, a row of hammers (Mills calls them payout fingers; we're keeping "hammers" because that's what they look like when they drop) tries to fall forward. A hammer aimed at a hole falls through. A hammer aimed at solid metal doesn't. A win exists only when every hammer that combination needs falls at the same time.

Metaphor. A punch card reader. Three cards (discs), a row of pins (hammers), and a payout that only fires when the right pins all find holes. Or, for Dan: three cams on one shaft, and a follower that only drops when all three lobes line up. Or, for Matt: it's a hardware AND gate — every hammer is an input, and the payout lever is the output that goes high only when they all do.

flowchart LR
    A[Printed symbol at stop N] --- B[Reel indexed at stop N]
    B --- C[Hole pattern at stop N on the disc]
    C --> D{Hammer aimed at a hole?}
    D -->|Yes| E[Hammer drops]
    D -->|No| F[Hammer blocked]

flowchart TD
    A[Hammer 1 drops into reel-1 disc?] --> D{Every hammer this win needs is down?}
    B[Hammer 2 drops into reel-2 disc?] --> D
    C[Hammer 3 drops into reel-3 disc?] --> D
    D -->|No| E[Payout lever blocked. No pay.]
    D -->|Yes| F[Payout lever completes its travel]
    F --> G[Selects this win's payout slide]

Mills stacks horizontal and vertical payout levers to combine the hammers — that's the wiring of the AND gates. It's why:

• disc order matters (swap two discs and every payout is wrong),
• disc alignment to the strip matters (a disc rotated one stop pays for the symbol next door),
• a bent hammer silently kills one win,
• a missing 0.030" spacer can shift a hammer sideways just enough to miss its hole.

The discs and the hammers (OURS + Mills). There are three discs, one per reel, each with multiple holes — Dan and Matt have seen them. In the Mills layout the holes sit at different radii: one ring for cherry stops, another for bells, another for bars, and so on. A row of fingers on each reel, each at a different radius, pushes toward the disc when the reels stop. The finger whose ring has a hole at that stop goes through — that's the "drop" — and the others hit metal. (Claude's earlier read of IMG-01 as a "stack of four or five discs" was the stop star and the hole disc seen edge-on. Corrected.)

Still to settle by eye: is it one finger per reel that finds different holes, or several fingers per reel, each owning a symbol? Test, clock frozen: set reel 1 on a cherry, release, watch; then a bell. Same finger or a different one? Then count the fingers behind each reel. Whichever it is, the count of quarters still comes from the slide stack (§3.6), not from the finger.

3D model. models/hammers-and-wheels.html (in this repo) is a spinnable model of the three reels, the disc behind each with its rings of holes, and the finger comb over each disc. Pick symbols, pull, and watch which fingers go through. It uses the VID-01 stop timing. Schematic, not a scan — the real castings look different; the logic is the same.

The operator's cheat. Early operators plugged holes with solder or lead to stop a combination from paying while the symbols still showed a win. It's the 1937 equivalent of commenting out a branch. When we photograph the discs (Chapter 7), we're looking for exactly this: a hole that's filled, a hole that's the wrong size, a disc that isn't the same pattern as its siblings. If our machine has been "adjusted" this way, it explains a lot, and it's ours to decide whether to reverse it.

FILL IN: each code disc face, straight on, every hole visible, ruler in frame. IMG-01 shows reel 1's disc edge-on, not the hole pattern. This is the shot that finds a plugged hole. → §7.3

Debug note. With the clock frozen (§1.4), set a win by hand and watch the hammers. Every hammer that should drop, drops? Then the reader is fine and the problem is downstream (slides, §3.6). One hammer stays up? You've found it — bent, blocked, spaced wrong, or aimed at a plugged hole.

3.6 The meter: payout slides

What it does. Under the tube sits a vertical stack of six thin slides, and the coin column runs down through all of them. Each slide owns a slice of the column — a few quarters deep. A pay is made by pulling several slides forward together; each carries its slice out from under the column into the cup. The count is the sum of the slides that moved.

Our stack (OURS — Dan and Matt measured it):

Metaphor. A cash drawer with six compartments of fixed size, and each lever pulls a different set of them open at once. Nobody counts. 3 is one compartment; 20 is all of them.

Which lever pulls which slides — VERIFY. The card values force some of it and leave the rest open: 3 = B alone; 20 = all six. For 5, 10, 14 and 18 there is more than one set that adds up (10 could be A+B+E or A+C+D; 14 could be A+B+C+E or A+B+D+E). Assumed until observed: 5 = A+B · 10 = A+B+E · 14 = A+B+C+E · 18 = A+B+C+D+E.

FILL IN: with the clock frozen, set each winning combination and note which slides move. Six rows, one look each. → §7.5

flowchart TD
    A[Winning category] --> B[Its payout lever falls]
    B --> C[Lifts the locks on that lever's set of slides]
    C --> D[Fork pushes the whole stack]
    D --> E[Only the unlocked slides travel — together]
    E --> F[Each carries its slice of the column to the cup]
    F --> G[Count = sum of the slides that moved]
    G --> H[Return stroke: slides home, locks on, column drops to refill]

How the count actually happens

Nothing in this machine counts to 14. The hammers decide which win; the slide set decides how many; and "how many" is cut into the metal.

1. Hammers read the discs. Each finger is aimed at one ring on one disc. When the reels stop, the fingers over a hole go through; the rest hit metal.
2. Levers combine fingers into a win. One payout lever per row on the card, each held up by all the fingers its row needs. That's the AND gate, and one finger can serve several rows.
3. A fallen lever unlocks a set of slides. Normally all six are locked. The lever that fell lifts the locks on its set.
4. The fork pushes; only the unlocked slides travel. Each carries the quarters sitting in its slice of the column out to the cup. B alone is 3. A through F is 20. A slide that's gummed lags its partners and drops short — that's the gunky-quarter short pay.
5. Reset. Slides home, locks on, fingers lifted, column drops and refills the slices. Part of the last click.

Debug split: right symbols, no pay → a finger didn't drop or its lever binds; freeze the clock and watch which finger stays up. Right symbols, short pay → the right slides moved but one didn't carry its slice, or one of the set stuck; gunk, a burred coin, a tired slide spring. The reader is innocent.

The slides run dry. Always. They meter quarters by thickness and diameter with very little clearance. Oil on a slide collects grit and gunk from the coins and you get short pays, intermittent pays, and slides that stick forward — which is a reset failure, which kills the last click. This is where our gunky-quarter problem lived. Clean, don't lubricate.

Our award card (OURS — transcribed from IMG-03):

"BAR" on every row is the Bell-Fruit-Gum logo. It's the standard Mills bell card. Note there is no separate jackpot line — BAR BAR BAR is printed as a flat 20. Whether the vault also dumps on three bars is still open (§8.5); the red header line across the top of the card, which we can't read in IMG-03, may say.

The full hammer-by-hammer truth table gets built with the breakpoint trick and lives in §8.4.

FILL IN: a straight-on close-up of just the red header line at the top of the award card. → §7.3

3.7 The vault: jackpot

3.7.1 Two chambers

MILLS (many models). A visible primary jackpot and a hidden reserve. The reserve exists so that the front looks full again right after a dump — a merchandising trick as much as a mechanical one.

stateDiagram-v2
    [*] --> BothLoaded
    BothLoaded --> PrimaryDumped: BAR BAR BAR trips the latch
    PrimaryDumped --> PrimaryRelatched: next cycle pushes the door shut
    PrimaryRelatched --> ReserveTransferred: reserve drops into the primary
    ReserveTransferred --> ReserveRelatched: following cycle
    ReserveRelatched --> ReserveRefilling: overflow coins rebuild the reserve
    ReserveRefilling --> BothLoaded: reserve full

Whether ours has one chamber, two, or something odd behind that big center cherry diamond is VERIFY — Bursting Cherry fronts came in more than one jackpot configuration and the artwork doesn't tell you what's behind it. Open questions in §8.5.

FILL IN: the jackpot assembly from behind the front casting, with the chassis out — inlet, outlet, doors, latches, and the trip lever. Nothing we've shot so far shows the vault. → §7.3

3.7.2 Trigger chain

flowchart TD
    A[Reel 1 on BAR] --> D[Reel-1 disc jackpot hole aligned]
    B[Reel 2 on BAR] --> E[Reel-2 disc jackpot hole aligned]
    C[Reel 3 on BAR] --> F[Reel-3 disc jackpot hole aligned]
    D --> G[Jackpot hammer drops]
    E --> G
    F --> G
    G --> H[Jackpot payout lever travels]
    H --> I[Jackpot slide / pushbar moves]
    I --> J[Trip tab on the CHASSIS reaches the lever on the CABINET]
    J --> K[Latch releases]
    K --> L[Trap door opens — the vault empties into the cup]

Whether BAR BAR BAR also meters 20 from the till on top of the dump: VERIFY. On Mills machines those can be two linked but separate events. Record them separately (§7.5).

3.7.3 The handshake — where jackpots usually die

Everything that reads the reels lives on the removable chassis. The vault, its latch, and its trap door live on the cabinet. The only connection is a tab on the chassis physically bumping a lever on the cabinet.

Metaphor. Two teams, one API. The chassis team can do everything right — detect BAR BAR BAR, move the lever, throw the slide — and the vault never opens, because the tab is a sixteenth of an inch short of the lever. It's the interface contract that fails, not either side.

flowchart LR
    subgraph CHASSIS
        A[Jackpot lever] --> B[Pushbar / trip tab]
    end
    subgraph CABINET
        C[Jackpot trip lever] --> D[Latch] --> E[Trap door]
    end
    B -. must physically touch .-> C

Causes: chassis not seated fully forward, base plate shifted, tab or lever bent, missing pin or spacer, wrong jackpot assembly, or a cabinet and a mechanism that were never together at the factory (see §7.2 — this is why we identify the machine before anything else).

3.7.4 Reset / refill

flowchart TD
    A[Primary dumped] --> B[Next handle cycle]
    B --> C[Primary door pushed closed]
    C --> D[Latch re-engages]
    D --> E[Reserve release permitted]
    E --> F[Reserve drops into the primary]
    F --> G[Reserve door re-closes on the following cycle]
    G --> H[Overflow coins refill the reserve]

How many cycles that takes on ours: VERIFY (§7.5).

3.8 Cleanup: the reset — and the last click

A machine can run one perfect cycle and be broken, if it doesn't put everything back. This is the beat we found missing. After every pull, all of these must be true, and every one is spring-driven:

• payout slides fully home
• hammers withdrawn from the discs
• all three stop levers back
• clock back
• jackpot trip back
• detector reset, escalator stepped
• handle lock re-engaged
• operating fork home

Metaphor. Garbage collection. Exhaust stroke. The finally block. If it doesn't run, the next call starts in a dirty state and something downstream fails in a way that looks unrelated.

Debug note. Because every item on that list is a spring pulling something home, hand-cycling the chassis and running this checklist is the fastest spring survey in the whole machine. Anything that comes home slow, partial, or not at all is your suspect — go to Chapter 4.