Summary of "Let's Create a Commodore C64 BASIC Interpreter in VSCode!"

Overview

This document summarizes a technical experiment: using OpenAI Codex to generate a C implementation of Microsoft CBM BASIC v2 (6502) equivalent, targeting both modern macOS/Linux and a historical PDP-11 running 2.11BSD. The project imposed old-style C (K&R) constraints, limited memory/text-space assumptions, and a PDP-11-aware timing/sleep command.

What was attempted

Use OpenAI Codex with a single, verbose prompt to generate a complete BASIC interpreter (full source + Makefile).
Target platforms:
- PDP-11 running 2.11BSD Unix (preferential build when detected).
- Modern macOS/Linux for fast local iteration.
Add a new BASIC command: sleep n (n in ticks). Example: sleep 60 ≈ 1 second.
- PDP-11 timing considerations: hardware timer runs at about 60 Hz, so effective minimum timing granularity is roughly 1/30 second for practical behavior.
Constraints:
- K&R (KN&R) C dialect: old-style function declarations, declarations at the start of scopes.
- Keep code small enough to fit in non-split text/data if possible.
- Use dynamic allocation for file/line storage (no pre-allocated file buffer).
- Performance minded.

Key technical concepts and implementation details

Prompt-driven code generation
- A single large prompt to Codex produced a sizeable C codebase (~1k+ lines) plus a Makefile scaffold.
- The generated code used conditional compilation macros to select PDP-11 vs macOS/Linux behavior.
Conditional compilation and portability
- Architecture macros detect platform (via uname in Makefile) and enable PDP-11 specific flags (including split I/D-space flags) or modern builds.
- The generated source included branches for different timing and system APIs.
Data structures
- Lines: stored as a linked list of dynamically allocated line nodes (line number, text, next pointer), mirroring Commodore BASIC’s approach.
- Control frames: fixed-depth frames for FOR loops and GOSUB/RETURN nesting, bounded by configured max-nesting limits.
Parser and executor components (emitted by the AI)
- Lexer / keyword matching.
- Parser modules: expressions, relational operators, terms, factors, primaries, variables, and functions.
- Executor statements: PRINT, INPUT, GOTO, GOSUB, RETURN, FOR/NEXT, LET, and the new SLEEP.
- Built-in functions: trigonometric and other math functions. TAB was initially missing/buggy and later fixed by iterative feedback.
Sleep/timing
- Implemented a BASIC sleep command with PDP-11-specific timing logic.
- Initial PDP-11 timing was too fast; it was adjusted to account for the 60 Hz power-line timer and platform differences until observed behavior matched expectations.
Makefile and build
- Makefile detects the platform (via uname) to select appropriate compile flags.
- PDP-11 builds required special flags and omission of headers not present on 2.11BSD (e.g., stdint.h) — these issues were resolved by iterating on both Makefile and source.
Dynamic memory usage
- File reading and storage allocate memory per line; no pre-allocated file buffer is used.

Testing and iterative workflow

Start from an empty project folder and give one detailed prompt to Codex.
Inspect the generated files (headers, architecture defines, parser/executor).
Test on macOS/Linux first for faster compile/test cycles.
Transfer source to PDP-11 (author used automatic FTP-on-save and telnet access).
Run make on the PDP-11, capture build errors, and report them back to Codex.
Accept and apply fixes from the regenerated output; repeat compile → run → observe cycles until stable.
Validate by running BASIC programs:
- Simple demo loop programs.
- A graphical-like sine wave program using PRINT + TAB + SIN to emulate output columns.
- Iteratively fix TAB implementation and tune sleep timing on PDP-11.

Problems encountered and resolutions

Cross-platform compilation issues
- The AI-generated code compiled and ran on macOS/Linux out-of-the-box but required manual iterative fixes for 2.11BSD/PDP-11 (missing headers, wrong flags).
- Resolved by updating the Makefile and source to avoid unavailable headers and to use PDP-11-friendly flags.
Missing/buggy functions
- TAB and other edge-case functions were buggy or absent initially; corrected after testing and feedback.
- sleep timing had to be tuned for the PDP-11’s 60 Hz timer granularity.
Closed-loop testing limitation
- Codex cannot itself run a remote compile/test on the PDP-11; the human-in-the-loop transferred files and fed back errors for further fixes.

Outcomes and analysis

Codex produced a near-complete, source-compatible CBM BASIC v2 equivalent in C that:
- Worked immediately on macOS/Linux.
- Could be made to run on an actual PDP-11 2.11BSD system with iterative human-assisted fixes.
Development speed vs polish
- The AI generated a large working codebase in minutes (author notes ~10 minutes of Codex generation time).
- Making the code robust on PDP-11 required further human iteration to handle platform quirks and historical C constraints.
Demonstrated capability
- The experiment shows that a single well-crafted prompt plus human feedback can generate low-level, retro-computing compatible software that respects platform constraints (old C dialect, memory/text-space limits, hardware timer differences).

Open question / future improvement

Allowing Codex (or a similar system) to run a remote shell or integrate with a remote build/test environment would enable closed-loop compile/test cycles on the target machine directly, reducing the human iteration burden.

Relevant references

Microsoft 6502 CBM BASIC v2 (Commodore lineage)
PDP-11 running 2.11BSD Unix
K&R (KN&R) C constraints
OpenAI Codex
Historical notes: Bill & Paul (Gates & Allen) / MITS references

Main speaker / sources

Dave (video author / presenter)
OpenAI Codex (AI code generator used)
Referenced systems/software: Microsoft CBM Basic v2 (6502), PDP-11 2.11BSD Unix, K&R C