Skip to content
KN-86 Deckline

Ecala (c. 1971-1973, DEC PDP-10)

Author(s): Don Daglow Sources: Daglow, “Games I’ve Shipped”, Wikipedia: Don Daglow, MobyGames: Ecala, arcade-history: Ecala, The Wargaming Scribe: Star Trek (Peterson/Daglow) Category: inspiration, Batch 10 (gameplay-mechanics mining). A conversational program with hidden state that probes the user, the machine-voice lineage KN-86’s CIPHER sits in. Serves: runtime / engineering (assigned by Josh; see cart map)

What it is

Section titled “What it is”

Ecala is a conversational program Don Daglow wrote on a DEC PDP-10 timesharing mainframe around 1971-1973, while he was a student (Pomona College). Daglow built it as a tribute to and an attempted improvement on Joseph Weizenbaum’s ELIZA (1964-66): a program you type English at, which answers back as an inquisitive interlocutor that prods you to reveal more. His own site files it as “one of the first chatbots.” It matters for this corpus less for its preserved rule set (which is not public) than for two things it establishes: an ELIZA-family conversational partner running on shared timesharing hardware, and the first rung on Daglow’s ladder from talk-program to game designer (he went on to write PDP-10 Baseball, a Star Trek, and Dungeon).

Mechanics

Section titled “Mechanics”

The specifics below separate what is documented about Ecala from the well-documented ELIZA paradigm it extends. Ecala’s own internal rules are not published; the source and materials are archived at The Strong National Museum of Play, and I did not examine that archive.

  • Confirmed about Ecala. It is a text conversational program on the PDP-10, framed as an ELIZA successor, that “would try to pry the user to reveal more and more” (Wikipedia and Daglow’s own bio material). It circulated across PDP-10 sites through DEC’s DECUS public-domain software-sharing service, the same distribution path Daglow claims for his other early programs. Wikipedia adds that the project “paved the way for his later work by suggesting new kinds of game interfaces,” which is Daglow’s own read on why a conversation program led him into games.
  • The ELIZA paradigm it belongs to (documented for ELIZA, the family Ecala extends). ELIZA-class programs scan the typed line for keywords, rank them, and fire a canned transformation rule: reflect the user’s own words back as a question, decompose the sentence and reassemble it into a prompt, or emit a content-free continuer (“Tell me more”) when no keyword hits. There is no parse of meaning and no memory of the conversation beyond simple keyword triggers. Ecala’s stated design goal was to push past ELIZA’s passivity toward a partner that actively steers the user to disclose.
  • Language / turn model (medium confidence). Contemporary accounts describe Daglow learning BASIC on the PDP-10 and writing his early programs in it, so Ecala was most likely a BASIC program; I could not confirm the exact language. The interaction is turn-based line-at-a-time teletype conversation, standard for the era’s timesharing terminals.

Mineable patterns

Section titled “Mineable patterns”
  • A conversational partner that prompts the user forward. ELIZA reflects; Ecala’s stated advance is an interlocutor that steers the user to disclose more each turn. A prompting-forward conversational loop is a reusable pattern for any text-terminal voice meant to draw the operator out.
  • Keyword-triggered canned response tables. The ELIZA-family engine is small and legible: a ranked keyword table plus reassembly templates, no parser, no model weights. It fits a tiny Lisp cart and a fixed memory budget, and its output is fully authored and inspectable.
  • A content-free continuer as a graceful fallback. When no keyword matches, emit a neutral “go on” line. Cheap coverage for unrecognized input, and it keeps a conversation alive without pretending to understand.
  • Archived, human-readable source as the record. Ecala survives because its listing was kept (now at the Strong). A conversational program whose entire behavior lives in a readable listing is the same “the source is the artifact” instinct KN-86 already leans on.

KN-86 resonance

Section titled “KN-86 resonance”

Light, concept-level only. No minigame is being designed here.

  • The machine-voice lineage CIPHER extends. CIPHER is KN-86’s authored terminal voice on the auxiliary OLED. Ecala (and its darker sibling PARRY) are the historical anchors for a small, fully-authored conversational voice built from keyword triggers and canned lines, sized for a constrained device.
  • A voice that draws the operator out. Ecala’s one distinguishing goal, prompting the user to disclose more, maps onto any deck feature that elicits operator input through short prompted exchanges, kept as a table of triggers and replies.
  • Authored and inspectable over generated. An ELIZA-class engine is a hand-written table a cart author can read and edit. That matches KN-86’s bias toward legible, offline, human-readable behavior.
  • Cross-link. parry.md is the same batch’s conversational-AI entry and carries the hidden-emotional-state mechanic that Ecala lacks; read the two together.

Sources & verification

Section titled “Sources & verification”
  • Confidence: HIGH that Ecala exists and is an ELIZA-descendant conversational chatbot by Don Daglow on the PDP-10. Five independent sources agree on identity and platform: Daglow’s own site, Wikipedia, MobyGames, arcade-history, and the Wargaming Scribe.
  • The task hint guessed Ecala might be an ecology / economics / education simulation. That is incorrect. Every source found describes a conversational program in the ELIZA lineage. The name does not denote ecology. This correction is the headline finding for this entry.
  • Year is unsettled (MEDIUM confidence). Daglow’s own site dates it 1971-72; Wikipedia, MobyGames, and arcade-history date it 1973. I state the range c. 1971-1973.
  • Implementation language is inferred, unconfirmed (MEDIUM). BASIC is likely given accounts of Daglow learning BASIC on the PDP-10, but no source states Ecala’s language outright.
  • Internal mechanics are not publicly documented (flagged in-line). Unlike ELIZA and PARRY, Ecala has no published rule set. The source is archived at The Strong National Museum of Play; I described the ELIZA family it extends and marked Ecala-specific internals as unverified. I invented no mechanics.
  • Caveat on Daglow’s early-history claims. The Wargaming Scribe notes Daglow’s dates and popularity claims for his early PDP-10 work may be overstated (his Star Trek does not appear in surviving early DECUS catalogs). This does not challenge Ecala’s existence, only the precision of its dating and reach.
  • IA note: no standalone Internet Archive item for Ecala was found; the primary artifact is the physical/source archive at The Strong.