DEC PDP-10 Terminal Parsing Mechanics
“Architecture of the First Shared Virtual Space”
PDP-10 BCPL Terminal Sandbox
Real-time MUD1 Lexical Command Parser (circa 1978)
1The DEC PDP-10 System Architecture
The birth of MUD1 in 1978 was entirely dependent on the unique computing environment of the Digital Equipment Corporation PDP-10 mainframe computer. Running on the TOPS-10 or TENEX/TOPS-20 operating system, the PDP-10 utilized a 36-bit word length—a significant departure from modern 8-bit byte structures. This 36-bit layout allowed developers to pack five 7-bit ASCII characters into a single word with one bit left over, optimizing memory and file sizes. Roy Trubshaw and Richard Bartle programmed the initial MUD in MACRO-10 (assembly language) and BCPL, a direct ancestor of the C programming language, designed specifically to operate within these tight mainframe boundaries.
- 36-Bit Memory Words: Allowed efficient string storage via 7-bit ASCII packaging.
- Timesharing Sockets: Enabled dozens of remote physical terminals (teletypes) to connect to a single central processor.
- Virtual Address Limits: Program code and data had to fit within a 256-kiloword (approx. 1.15 MB) address space.
2Lexical Analysis of Early Command Parsers
Since graphics were non-existent, the player's interaction with the game was entirely conversational. The parser acted as the gatekeeper, translating raw text input into state changes. Early parsers used simple Verb-Noun matching structures. The code grabbed the first word of the user input, searched a pre-compiled verb table (e.g., 'GET', 'KILL', 'OPEN'), and then scanned the remaining words for nouns matching items in the player's current room. If a match was found, the server modified the entity database—updating the object's parent container from 'Room ID 45' to 'Player Inventory'—and returned a formatted string confirming the action.
- String Tokenization: Splitting terminal input into distinct command verb and object tokens.
- Abbreviation Matching: Allowing users to type 'G SW' instead of 'GET SWORD' to save valuable dial-up typing time.
- Context-Sensitive Synonyms: Mapping multiple strings ('TAKE', 'GRAB', 'GET') to a single internal command identifier.
3The Shared Database and Socket Buffer Synchronization
To support multiple users in a single virtual world, the server had to process actions concurrently without corrupting the game state. MUD1 achieved this by utilizing a single-threaded main loop that polled terminal socket buffers. Incoming terminal characters were collected in small ring buffers. During each tick (approx. 100ms), the game engine processed pending commands sequentially, updated the state database, and broadcast the resulting text updates back to the affected terminals. Because disk reads were too slow, the entire virtual world—rooms, items, player positions—was stored directly in core random-access memory, marking a revolutionary milestone in real-time, shared database design.
- Socket Polling: The PDP-10's SCNSER (Scanner Service) reported character availability on virtual serial terminals.
- State Locking: Sequential execution prevented classic database race conditions where two players try to pick up the same sword simultaneously.
- Asynchronous Output: System-level output buffers queued message delivery, ensuring slow teletype terminals did not block faster dial-up users.