BBS Era MUDs with BBS software archives
BBS-era MUDs and door games present unique archival challenges due to their dependence on specific serial communication protocols, FOSSIL drivers, and baud-rate-sensitive ANSI rendering. Unlike modern TCP/IP MUDs, these systems often ran as external processes spawned by BBS software, capturing the raw byte stream requires preserving timing information to maintain animation sequences and cursor positioning. This guide provides the technical workflow for capturing authentic sessions from DOS-based BBS environments and packaging them for long-term storage in public digital archives.
Distinguish Door Games from Networked MUDs
Examine the codebase to determine if the program uses BBS door kit APIs (DoorSys, chain.txt, or DropFile) versus raw TCP/IP sockets or serial calls. Door games spawn as external DOS processes communicating via file drops, while true networked MUDs of the BBS era maintained persistent socket connections through FOSSIL drivers. Check for FOSSIL INT 14h calls or references to serial port addresses (0x3F8, 0x2F8) in the source or documentation.
⚠ Common Pitfalls
- •Assuming all text games from 1985-1995 are MUDs
- •Overlooking FOSSIL driver dependencies that break modern emulation
- •Misidentifying single-player door games as multi-user
Configure DOSBox-X for Serial Port Redirection
Configure DOSBox-X to redirect serial ports to a named pipe or PTY for capture. Map COM1 to a modempipe or file output that preserves raw ANSI escape sequences. Disable keyboard layout translation to prevent character code alteration during capture. Set CPU core to normal and cputype to 386 to match typical BBS-era hardware timing.
[serial]
serial1=modempipe /tmp/bbs_capture
[dos]
keyboardlayout=none
xms=false
ems=false
umb=false
[cpu]
core=normal
cputype=386
cycles=fixed 3000⚠ Common Pitfalls
- •Using standard DOSBox which lacks proper serial pipe support
- •Enabling XMS/EMS memory managers that interfere with door game memory models
- •Setting cycles too high causing FOSSIL timing errors
Capture Raw Terminal Output with ttyrec
Execute ttyrec against the pipe created by DOSBox-X to capture both output and timing data. The timing information is critical for preserving ANSI animation sequences and door game prompt delays. Use the -e flag to specify the command that reads from the pipe. Verify the capture file size grows proportionally to session length to ensure no buffer drops occurred.
mkfifo /tmp/bbs_pipe
ttyrec -e "cat /tmp/bbs_capture" -n bbs_session.tty &
# Launch BBS software in DOSBox-X in separate terminal
# After session ends, verify:
ttytime bbs_session.tty | wc -l⚠ Common Pitfalls
- •Recording at incorrect baud rate causing timing artifacts
- •Buffer overflows during high-speed ANSI animations
- •Pipe permission errors preventing DOSBox-X write access
Generate Metadata Sidecar Files
Create JSON sidecar files following the MUD Archive Project schema v1.2. Document the emulated baud rate, specific BBS software version (e.g., WWIV 4.24, Renegade 12-08), FOSSIL driver version (X00, BNU, or ADF), and terminal type. Include cryptographic checksums of both the capture file and original binaries to ensure long-term integrity verification.
{
"schema_version": "1.2-bbs",
"capture_date": "2024-01-15T14:30:00Z",
"bbs_software": "WWIV 4.24",
"door_kit": "DoorSys 2.2",
"emulated_baud": 2400,
"fossil_driver": "X00 1.50",
"terminal_type": "ANSI-BBS",
"capture_format": "ttyrec",
"checksums": {
"md5": "d41d8cd98f00b204e9800998ecf8427e",
"sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
}
}⚠ Common Pitfalls
- •Omitting timezone information in dates
- •Using relative paths in metadata that break when archived
- •Failing to document FOSSIL driver version causing future emulation failures
Validate Capture Integrity with ttyplay
Playback the ttyrec file at original speed (-p flag) to verify ANSI sequences render correctly in xterm or similar. Check specifically for cursor positioning errors, color code misinterpretations, and door game menu alignment. Compare against known-good screenshots from period documentation if available.
# Verify timing integrity
ttytime bbs_session.tty > timing.log
# Playback for visual verification
ttyplay -p bbs_session.tty
# Check for common corruption patterns
grep -c '\[0;0H' bbs_session.tty⚠ Common Pitfalls
- •Assuming silent data corruption didn't occur
- •Testing only on modern terminals that handle ANSI differently than BBS-era clients
- •Ignoring subtle cursor positioning errors that break door game interfaces
Package for Internet Archive Upload
Combine the ttyrec file, metadata JSON, original binaries, and a technical README into a single directory. Create Internet Archive metadata XML specifying the collection as 'classicpcgames' or 'bbs_archives' and mediatype as 'software'. Include explicit subject tags for 'BBS', 'MUD', 'Door Game', and 'ANSI Art' to ensure discoverability by researchers.
<metadata>
<identifier>bbs-mud-wwiv-lord-1994</identifier>
<title>LORD BBS Door Game Session - 2400 Baud Capture</title>
<description>Preserved gameplay session of Legend of the Red Dragon v4.00 running under WWIV 4.24 with X00 FOSSIL driver. Captured at 2400 baud with original ANSI animations intact.</description>
<subject>BBS;MUD;Door Game;ANSI Art;Retro Computing;Digital Preservation</subject>
<mediatype>software</mediatype>
<collection>classicpcgames</collection>
<creator>Preservation Project</creator>
<date>1994</date>
</metadata>⚠ Common Pitfalls
- •Using generic software collections instead of specific BBS/MUD archives
- •Setting incorrect mediatype preventing proper emulation playback
- •Omitting FOSSIL driver information required for future emulation
Upload and Verify Public Access
Use the Internet Archive's ia command-line tool to upload with verification enabled. After upload, wait for processing completion (typically 10-30 minutes) and verify the item displays correctly in the browser-based emulator. Check that metadata fields are searchable and the ttyrec downloads correctly with preserved timestamps.
ia upload bbs-mud-wwiv-lord-1994 \
bbs_session.tty metadata.json meta.xml \
--metadata="subject:BBS;MUD;ANSI" \
--verify
# Verify item exists and is public
ia metadata bbs-mud-wwiv-lord-1994 | jq .metadata.title⚠ Common Pitfalls
- •Uploading without --verify leading to silent failures
- •Missing the 48-hour window for search index updates
- •Failing to check that binary files download uncorrupted
What you built
Preserving BBS-era MUDs requires maintaining the complete technical context including FOSSIL driver versions, baud rate timing, and specific BBS software configurations. The raw ANSI byte streams captured through serial port redirection provide the most authentic preservation format, allowing future researchers to experience the exact rendering timing and connection latency that defined this era of online gaming. Regular verification of archived captures against new emulation releases ensures long-term accessibility as display technologies evolve.
.