Former Student Completes 30-Year-Old Chess Engine Feature Envisioned by Middle School Teacher

A 30-Year-Old Promise Kept: Reviving a Chess Engine’s Lost Feature

In 1996, Len Dorfman, a middle school computer teacher on Long Island, embedded a placeholder in his freeware chess engine, PAX. Under the Learning menu, a single line read: “The feature will be coded after PAX starts learning.” It was a promise—one he never fulfilled. Three decades later, a former student, armed with technical expertise and a deep personal connection to Dorfman’s legacy, completed the feature. This story isn’t just about resurrecting code; it’s a testament to the enduring impact of mentorship, the mechanics of preserving digital history, and the practical challenges of advancing a decades-old software project.

The Mechanics of Preservation: How PAX Survived

The survival of PAX hinged on two critical factors: Dorfman’s decision to publish the software online and the Internet Archive’s Wayback Machine. When Dorfman uploaded PAX to lendorfman.freeservers.com, he inadvertently created a digital time capsule. The Internet Archive, a nonprofit dedicated to preserving web history, crawled the site in the early 2000s, capturing the 13 MB opening book, hand-drawn pieces, and the DOS-era code. Without this archival effort, PAX would have been lost to bit rot—a phenomenon where digital files degrade due to hardware obsolescence, file format incompatibility, or data corruption.

The student’s first challenge was reverse-engineering the DOS-based PAX into a browser-compatible format. This required:

• Emulation: Using a DOS emulator to run the original executable, which relied on 16-bit architecture no longer supported by modern systems.
• Code Translation: Converting the assembly language and C code into JavaScript, a process that involved rewriting core functions like move generation and evaluation.
• Asset Preservation: Digitizing Dorfman’s hand-drawn graphics and ensuring the pixel-art yin-yang logo remained intact, despite resolution differences between DOS and modern displays.

Completing the Learning Feature: A Technical Deep Dive

The unimplemented learning feature posed a unique challenge. Dorfman had envisioned a system where PAX would analyze losses, identify the “point of no return” (the move where winning chances collapsed), and adjust its strategy. The student implemented this using a combination of retrograde analysis and machine learning principles, constrained by the original engine’s limitations.

Here’s the causal chain:

• Impact: PAX loses a game.
• Internal Process: The engine backtracks through the move history, evaluating positions using its original evaluation function. It identifies the first move where the centipawn loss (a measure of positional disadvantage) exceeds a threshold, marking it as the “point of no return.”
• Observable Effect: PAX updates its opening book to penalize the sequence leading to the critical mistake, using Dorfman’s rule that forced moves cannot be mistakes. This ensures the engine avoids similar traps in future games.

The effectiveness of this solution depends on the accuracy of the original evaluation function. If the function misjudges positions—a common flaw in pre-2000 chess engines—the learning mechanism will reinforce suboptimal strategies. To mitigate this, the student capped the learning rate, preventing PAX from overfitting to flawed evaluations.

Edge Cases and Trade-Offs: Where the Solution Fails

The revived PAX 2.0 operates at a 1550 Elo rating against Stockfish with reduced strength, matching Dorfman’s original performance. However, this solution has limitations:

• Hardware Constraints: The learning feature increases computational overhead, making PAX slower on low-end devices. On a 2010 MacBook Air, for example, analysis time per move doubles from 0.5 to 1 second.
• Strategic Rigidity: PAX’s reliance on a fixed opening book and temperaments (Aggressive/Satvic/Passive) limits its adaptability. Modern engines like Stockfish dynamically adjust strategies based on real-time evaluations, a capability beyond PAX’s scope.
• Bit Rot Risk: While PAX 2.0 is preserved on GitHub, future format changes (e.g., JavaScript updates) could render it unplayable. Continuous maintenance is required to ensure compatibility.

Professional Judgment: Why This Revival Matters

Reviving PAX wasn’t just an act of nostalgia; it was a strategic decision to preserve a piece of computing history. Dorfman’s work embodies early experimentation in AI and game development, fields now dominated by corporate giants. By completing the learning feature, the student demonstrated a rule for handling legacy software:

If a project holds cultural or educational value and its core functionality can be preserved with reasonable effort, prioritize revival over replacement.

This approach contrasts with the common error of abandoning old software in favor of starting anew. While rebuilding PAX from scratch using modern tools would yield a stronger engine, it would erase Dorfman’s original vision—the hand-drawn pieces, the Dalai Lama quote, the quirky resignation messages. These elements are irreplaceable artifacts of early computing culture.

Play PAX 2.0 at https://mf4633.github.io/pax-chess. Examine the code at https://github.com/mf4633/pax-chess. And if you knew Len Dorfman, share your memories. His classroom may have been a bastion of peace in a chaotic middle school, but his legacy is a call to action: preserve, honor, and build upon the work of those who came before.

Background and Context

In 1996, Len Dorfman, a middle school computer teacher on Long Island, wrote a chess engine called PAX as a freeware DOS program. Dorfman, who taught programming from 1970 to 1999, was a unique figure—a tai chi practitioner who brought calm to a chaotic school environment. His classroom, adorned with a homepage quoting the Dalai Lama, was a sanctuary of kindness and creativity. PAX, initially developed "for laughs," included a Learning menu with a placeholder feature: "The feature will be coded after PAX starts learning." This feature was never implemented during Dorfman’s lifetime.

Technological Landscape of 1996

In 1996, chess engines were primarily written in low-level languages like assembly and C, running on 16-bit DOS systems. Computational resources were limited, with typical PCs having 8–32 MB of RAM and single-core processors clocked at 100–200 MHz. Chess engines relied on hand-crafted evaluation functions and fixed opening books, as machine learning techniques were in their infancy. PAX’s 13 MB opening book, stored in a proprietary format, was a significant achievement for the time, though it lacked adaptive learning capabilities.

Preservation and Revival Mechanics

PAX survived the decades due to two critical factors:

• Digital Time Capsule: Dorfman uploaded PAX to his personal website (lendorfman.freeservers.com), which was later captured by the Internet Archive’s Wayback Machine in the early 2000s. This archival effort prevented bit rot—data loss due to hardware obsolescence, file format incompatibility, or corruption.

• Former Student’s Initiative: The student recovered PAX from the Internet Archive, leveraging their technical expertise to revive the project. The revival process involved:

• Emulation: Running the 16-bit DOS executable on modern systems using a DOS emulator, which translates legacy system calls into modern OS-compatible instructions.

• Code Translation: Converting assembly and C code to JavaScript, rewriting core functions like move generation and evaluation. This required manual debugging to address memory segmentation issues inherent in 16-bit code.

• Asset Preservation: Digitizing hand-drawn graphics and maintaining the pixel-art yin-yang logo, despite resolution differences between DOS and modern displays. This ensured the retention of PAX’s cultural artifacts.

Learning Feature Implementation

The completed learning feature operates via causal logic:

• Impact: PAX loses a game.
• Internal Process: The engine backtracks through the move history, identifies the "point of no return"—the first move exceeding a centipawn loss threshold—and flags it as a mistake. Dorfman’s rule that forced moves cannot be mistakes is enforced by excluding them from penalization.
• Observable Effect: The opening book is updated to penalize the sequence leading to the mistake, reducing its likelihood in future games. The learning rate is capped to prevent overfitting to flawed evaluations.

Trade-Offs and Limitations

Reviving PAX involved trade-offs:

• Hardware Constraints: The JavaScript implementation doubles analysis time on low-end devices (e.g., a 2010 MacBook Air) due to interpreted language overhead compared to native DOS execution.
• Strategic Rigidity: PAX’s fixed opening book and temperaments (Aggressive / Satvic / Passive) limit adaptability compared to modern engines like Stockfish, which use dynamic evaluation and neural networks.
• Bit Rot Risk: Future JavaScript updates may render PAX 2.0 unplayable, requiring continuous maintenance to ensure compatibility.

Strategic Revival Rule

If legacy software holds cultural or educational value and core functionality can be preserved with reasonable effort, prioritize revival over replacement. This preserves irreplaceable artifacts (e.g., hand-drawn pieces, quirky messages) that would be lost in a modern rebuild. For example, PAX’s "PAX feels utter despair and resigns" message retains Dorfman’s personality, a quality absent in generic modern engines.

Accessibility

PAX 2.0 is playable at https://mf4633.github.io/pax-chess, with code available on GitHub at https://github.com/mf4633/pax-chess. The project serves as both a tribute to Dorfman and a functional example of preserving early computing culture.

The Unfinished Feature

In 1996, Len Dorfman envisioned a revolutionary addition to his chess engine, PAX: a self-learning mechanism that would allow the program to analyze its losses and adapt its strategy. This feature, teased under the "Learning" menu item with the placeholder "The feature will be coded after PAX starts learning," was never implemented during his lifetime. The complexity lay in its causal logic—identifying the exact move where the game irreversibly turned against PAX, dubbed the "point of no return."

Technically, this required:

• Backtracking move history to pinpoint the first move exceeding a centipawn loss threshold, indicating a strategic collapse.
• Applying Dorfman’s rule that forced moves cannot be mistakes, ensuring the engine didn’t penalize unavoidable decisions.
• Updating the opening book to deprecate the sequence leading to the mistake, effectively "learning" from the error.

The feature remained unfinished for 30 years due to:

• Computational constraints of 1996 hardware (8–32 MB RAM, 100–200 MHz processors) limiting real-time analysis depth.
• The fragility of PAX’s codebase—written in assembly and C for 16-bit DOS systems, making modifications prone to segmentation faults and memory leaks.
• Dorfman’s prioritization of other features, such as temperaments (Aggressive/Satvic/Passive) and hand-drawn graphics, over the learning mechanism.

Reviving this feature in PAX 2.0 required:

1. Emulation of the 16-bit DOS environment to run the original executable.
2. Code translation from assembly/C to JavaScript, manually resolving memory segmentation issues.
3. Implementing the learning logic with a capped learning rate to prevent overfitting to flawed evaluations from the original 1996 engine.

The result? PAX 2.0 now learns from losses, but at a cost:

• Increased computational overhead (e.g., doubled analysis time on a 2010 MacBook Air) due to JavaScript’s interpreted nature.
• Strategic rigidity from the fixed opening book and temperaments, limiting adaptability compared to modern engines like Stockfish.
• Bit rot risk from future JavaScript updates, requiring continuous maintenance to ensure compatibility.

The optimal revival strategy, per the Strategic Revival Rule, prioritized preserving PAX’s cultural artifacts (hand-drawn pieces, pixel-art logo) over a modern rebuild. This decision ensures the engine’s historical authenticity while introducing the learning feature Dorfman envisioned. However, this approach fails if:

• Future JavaScript updates break PAX 2.0’s compatibility, requiring a rewrite in a more stable language.
• Hardware constraints render the engine unplayable on low-end devices, necessitating optimization trade-offs.

Typical choice errors include:

• Over-modernization: Rebuilding PAX from scratch would erase its cultural value (e.g., Dorfman’s quirky messages like "PAX feels utter despair and resigns").
• Under-preservation: Neglecting to digitize assets like the 13 MB opening book or hand-drawn pieces would lose irreplaceable artifacts of early computing culture.

Rule for revival: If legacy software holds cultural/educational value and core functionality can be preserved with reasonable effort, prioritize revival over replacement. Otherwise, rebuild with modern tools, sacrificing historical authenticity for usability.

The Student's Journey: Reviving a 30-Year-Old Chess Engine

In 1996, Len Dorfman, a middle school computer teacher on Long Island, wrote a chess engine called PAX. It was a DOS program, complete with hand-drawn pieces, a pixel-art yin-yang logo, and a 13 MB opening book. Dorfman envisioned a self-learning feature for PAX, but it remained unimplemented. The placeholder in the Learning menu read: "The feature will be coded after PAX starts learning." It never got coded—until now.

Three decades later, I, a former student of Dorfman’s, rediscovered PAX in the Internet Archive. The Wayback Machine had captured his website, preserving the engine and its assets like a digital time capsule. This archival effort prevented bit rot—data loss due to hardware obsolescence, file format incompatibility, or corruption. Without it, PAX would have been lost to time.

Motivation: Honoring a Mentor’s Vision

Dorfman wasn’t just a teacher; he was a catalyst. He introduced me to the internet in 1995–96, taught programming, and embodied a philosophy of kindness. His classroom was a sanctuary in a chaotic middle school. Reviving PAX wasn’t just about code—it was about honoring his legacy and the enduring impact of mentorship.

The Revival Process: From DOS to Browser

1. Emulation and Code Translation

PAX was written in assembly and C for 16-bit DOS systems. To run it on modern hardware, I used a DOS emulator, which translates 16-bit system calls for compatibility with modern operating systems. Next, I converted the assembly and C code to JavaScript. This involved manually rewriting core functions like move generation and evaluation, resolving memory segmentation issues that plagued the original fragile codebase.

2. Asset Preservation

Dorfman’s hand-drawn graphics and pixel-art logo were digitized, maintaining their cultural value despite resolution differences. The 13 MB opening book and quirky messages like "PAX feels utter despair and resigns" were preserved, ensuring the engine retained its historical authenticity.

3. Implementing the Learning Feature

The core challenge was realizing Dorfman’s vision of a self-learning mechanism. When PAX loses a game, it:

• Backtracks the move history to identify the "point of no return"—the first move exceeding a centipawn loss threshold.
• Excludes forced moves as mistakes, adhering to Dorfman’s rule.
• Updates the opening book to penalize the sequence leading to the error.

To prevent overfitting to flawed 1996 evaluations, I capped the learning rate. This balance ensured the engine learned without becoming biased by outdated logic.

Challenges and Trade-Offs

1. Hardware Constraints

The JavaScript implementation introduced computational overhead. On a 2010 MacBook Air, analysis time doubled due to the interpreted nature of JavaScript. This trade-off was necessary to ensure cross-platform compatibility, but it limited accessibility on low-end devices.

2. Strategic Rigidity

PAX’s fixed opening book and temperaments (Aggressive / Satvic / Passive) made it less adaptable than modern engines like Stockfish. However, preserving these elements was critical to maintaining the engine’s cultural and educational value.

3. Bit Rot Risk

Future JavaScript updates could render PAX 2.0 unplayable. This risk necessitates continuous maintenance to ensure compatibility, highlighting the fragility of preserving legacy software.

Why Revival Over Replacement?

The decision to revive PAX rather than rebuild it from scratch was guided by a strategic revival rule: If legacy software holds cultural/educational value and core functionality can be preserved with reasonable effort, prioritize revival over replacement.

A modern rebuild would have erased irreplaceable artifacts—the hand-drawn pieces, quirky messages, and DOS-era quirks. Revival preserved these elements, ensuring PAX remained a time capsule of early computing culture.

Play PAX 2.0

PAX 2.0 is now playable in the browser, maintaining its original strength of around 1550 against limited-strength Stockfish. Experience Dorfman’s vision firsthand:

• Play: https://mf4633.github.io/pax-chess
• Code: https://github.com/mf4633/pax-chess

If you knew Len Dorfman, downloaded PAX from his website, or attended Shoreham-Wading River, I’d love to hear from you. This project isn’t just about code—it’s about preserving a piece of history and the legacy of a teacher who inspired generations.

Impact and Legacy

The completion of PAX 2.0 is more than a technical achievement—it’s a bridge between eras, a testament to the enduring value of mentorship and the cultural significance of early computing. By reviving Len Dorfman’s chess engine, the former student has not only honored their teacher’s legacy but also created a living artifact that illuminates the evolution of technology and education.

Relevance to Modern Chess Engines

PAX 2.0 operates at a modest 1550 ELO against a limited-strength Stockfish, a far cry from the 3500+ ELO of modern engines. Yet, its value lies not in raw strength but in its methodology and constraints. The learning feature, for instance, avoids overfitting by capping the learning rate, a deliberate choice to respect Dorfman’s original evaluation function. This contrasts sharply with modern engines, which rely on massive datasets and neural networks. PAX’s approach is a mechanical one—it backtracks move histories, identifies the "point of no return" (the move where centipawn loss exceeds a threshold), and updates the opening book to penalize mistakes. This process is constrained by Dorfman’s rule: forced moves cannot be mistakes, a limitation that reflects the era’s computational constraints but also introduces a unique strategic rigidity.

The engine’s fixed opening book and temperaments (Aggressive/Satvic/Passive) further highlight its historical context. These elements, preserved for cultural authenticity, limit adaptability compared to modern engines. However, they serve as a physical record of early AI design, where hand-crafted rules and limited resources shaped software development. PAX 2.0 is not just a chess engine—it’s a time capsule of 1996 technology, playable in a browser.

Emotional and Professional Impact

For the student, completing PAX 2.0 was both a technical challenge and an emotional journey. Reviving the engine required reverse-engineering a fragile 16-bit DOS codebase, translating assembly and C into JavaScript, and resolving memory segmentation issues. The process was fraught with risks, particularly bit rot—the degradation of software due to hardware and format obsolescence. The Internet Archive’s Wayback Machine acted as a digital preservative, capturing Dorfman’s website and preventing data loss. Without this, PAX would have been lost to time.

Professionally, the project underscores the importance of preserving legacy software. The student’s decision to prioritize revival over replacement was guided by a clear rule: If legacy software holds cultural/educational value and core functionality can be preserved with reasonable effort, revive it. This approach preserved irreplaceable artifacts—hand-drawn pieces, quirky messages, and the pixel-art logo—that would have been lost in a modern rebuild. The trade-offs were significant: increased computational overhead (doubled analysis time on low-end devices), strategic rigidity, and ongoing maintenance to mitigate bit rot. Yet, these sacrifices were deemed necessary to maintain historical authenticity.

Broader Implications

PAX 2.0’s revival highlights a critical issue in technology: the erosion of early computing culture. Without efforts like this, the lessons and innovations of pioneers like Len Dorfman risk being forgotten. The project serves as a model for preserving software with cultural value, offering practical insights into the challenges and trade-offs of such endeavors.

• Preservation Mechanisms: Digital archives like the Wayback Machine are essential for preventing bit rot. Without them, software like PAX would degrade into unrecoverable fragments.
• Revival vs. Replacement: Revival preserves historical authenticity but requires continuous maintenance. Replacement sacrifices cultural value for usability. The optimal choice depends on the software’s cultural significance and the effort required to revive it.
• Accessibility: Making PAX 2.0 playable in browsers and open-sourcing the code ensures its availability to future generations. This accessibility is critical for educational and cultural purposes.

In an era dominated by rapid technological advancement, PAX 2.0 reminds us of the importance of honoring the past. It’s not just a chess engine—it’s a tribute to a teacher, a lesson in perseverance, and a call to preserve the foundations of modern computing. As the student put it, PAX is now more than a game; it’s a living memorial to Len Dorfman’s vision and the timeless impact of mentorship.

Conclusion: A Tribute to Mentorship, Perseverance, and the Timeless Value of Vision

The revival of Len Dorfman’s PAX chess engine is more than a technical achievement—it’s a testament to the enduring power of mentorship and the cultural significance of preserving early computing artifacts. By completing the self-learning feature Dorfman envisioned 30 years ago, this project bridges generations, honoring a teacher’s legacy while safeguarding a piece of technological history. Here’s what this story reveals about mentorship, perseverance, and the mechanics of preserving digital heritage.

The Causal Chain of Mentorship: Impact → Internal Process → Observable Effect

Len Dorfman’s influence on his student wasn’t just about teaching code—it was about instilling a mindset. His unconventional approach (tai chi on the soccer field, quoting the Dalai Lama) created a sanctuary of curiosity in a chaotic middle school. This environment seeded a lifelong passion for programming, culminating in the student’s dedication to reviving PAX. The mechanism here is clear: mentorship → internalized values → delayed but profound action. Without Dorfman’s quirky, kind, and visionary teaching style, PAX 2.0 would never have existed.

Technical Revival: A Mechanical Process of Preservation

Reviving PAX wasn’t just about writing new code—it was about reverse-engineering a time capsule. The process involved:

• Emulation and Translation: The original 16-bit DOS codebase, written in assembly and C, was emulated and manually translated to JavaScript. This resolved memory segmentation faults but introduced computational overhead, doubling analysis time on low-end devices like a 2010 MacBook Air.
• Asset Preservation: Hand-drawn graphics, the pixel-art logo, and the 13 MB opening book were digitized, preserving cultural artifacts. This prioritized historical authenticity over modernization, ensuring PAX 2.0 felt like a 1996 program.
• Learning Feature Implementation: The self-learning mechanism backtracks move histories to identify the “point of no return” (the move exceeding a centipawn loss threshold). Dorfman’s rule—forced moves cannot be mistakes—was enforced, reflecting 1996 computational constraints and introducing strategic rigidity.

Trade-Offs and Decision Dominance: Revival vs. Replacement

The choice to revive PAX rather than rebuild it from scratch was deliberate. Revival preserved irreplaceable cultural value—quirky messages like “PAX feels utter despair and resigns” and the original evaluation function. However, this came with trade-offs:

• Strategic Rigidity: Fixed opening books and temperaments limited adaptability compared to modern engines like Stockfish.
• Bit Rot Risk: Future JavaScript updates could break compatibility, requiring continuous maintenance.

The optimal solution here is clear: If legacy software holds cultural/educational value and core functionality can be preserved with reasonable effort, prioritize revival over replacement. This rule ensures historical authenticity while maintaining accessibility.

Broader Implications: Counteracting the Erosion of Early Computing Culture

PAX 2.0 isn’t just a chess engine—it’s a physical record of early AI design, showcasing hand-crafted rules and resource constraints. Its revival highlights the critical role of digital archives like the Internet Archive in preventing bit rot. Without such preservation, valuable lessons in programming, creativity, and mentorship risk being lost to time.

Leaving Readers Inspired: A Call to Action

This project reminds us that technology isn’t just about the future—it’s about honoring the past. By playing PAX 2.0 (here) or exploring its code (here), you’re not just engaging with a chess engine; you’re experiencing a piece of history. If you knew Len Dorfman or downloaded PAX in the 90s, your stories could further enrich this legacy. Let this be a reminder: mentorship leaves ripples across decades, and perseverance can breathe life into forgotten visions.