Daniel Lund

Software engineer / Reno, Nevada

Software engineer who likes difficult systems.

I build AI experiments, developer tools, low-level software, and other projects that usually sounded easier at the beginning.

Explore my projects
FIELD ONLINE 00:00:00 PT X 000 / Y 000

I like projects that cross layers: emulation, neural networks, terminal interfaces, APIs, infrastructure, hardware, and the ugly bugs between them.

C++, Python, TypeScript, 6502 assembly,
and a growing pile of hardware.

01 — SELECTED WORK

Projects I took too far

Working builds, source code, and evidence that they actually work.

Reinforcement learning / reverse engineering / CUDA

1942//PPO

I trained a reinforcement-learning agent to complete the NES game 1942 from a fresh power-on.

No action tape, scripted controller, manual assistance, or last-second rescue. The final policy cleared all 32 stages in one uninterrupted run while making 64,178 controller decisions on its own.

32/32stages
64,178decisions
0action overrides
71 minverified run

The project combines NES emulation, raw RAM observation, PyTorch PPO training, CUDA acceleration, automated evaluation, and enough debugging to make me briefly hate the year 1942.

PyTorchPPOStable-Retro6502
View source Private Read the technical breakdown

Market systems / terminal UX / defensive engineering

Option Sentinel

A terminal application I built to monitor option positions, inspect risk, manage orders, and avoid accidentally doing something expensive.

Livebroker data
Dry-runby default
Failsclosed

It connects to Schwab, provides per-leg close and roll workflows, displays intraday charts, and treats uncertain broker responses as failures instead of pretending everything worked.

A deterministic fake broker lets me develop and test the dangerous parts without touching a real account.

PythonSchwab APIcursesSQLite
View on GitHub

// Forge-220M-Instruct — the finished 220M model, instruction-tuned on 460K conversations.

// Real, unedited completions (trimmed only for length), generated on Daniel's GPU. Pick a prompt below.

Language models / from scratch / C#

Forge/220M

I built a small language model from scratch in C# — tokenizer, transformer, optimizer, GPU kernels — trained it on 4.4 billion tokens, then taught it to follow instructions.

No PyTorch, no ONNX, no inference framework. The byte-level BPE tokenizer, the GPT architecture, AdamW, the SIMD CPU backend, the CUDA and D3D12 kernels, and the checkpoint format are all hand-written. The panel on the left shows real completions from the finished instruction-tuned model.

219Mparameters
4.4Btokens trained
460Kinstruction chats
0ML frameworks

The base model learned from a FineWeb-Edu–heavy web mixture downloaded, tokenized, and checksummed by the project's own tooling. Training ran on rented NVIDIA GPUs through a custom ILGPU CUDA backend, with a ComputeSharp D3D12 backend for Windows GPUs and a SIMD CPU backend for everything else. A two-epoch pass over the SmolTalk dataset — user spans masked out of the loss — turned the base model into Forge-220M-Instruct.

A 220M model answers questions the way a 220M model can: mostly coherent, occasionally confident nonsense, always interesting. There used to be a live demo here; one shared vCPU made each reply take a minute, so the model retired to recordings.

C#.NET 9CUDAD3D12BPE
View source Private

02 — LAB / EXPERIMENTS

Smaller things I’m working on

Not everything needs a case study. These are builds, tests, and useful detours.

01 ESP32 Morse Embedded / Wi-Fi

A Wi-Fi-controlled ESP32 that takes a message and timing from a tiny local web interface, then blinks it in Morse code.

View repository ↗
02 NES assembly 6502 / NROM

Small ROMs built close to the hardware: controller polling, palette updates during VBlank, memory maps, and the occasional argument with an emulator.

03 Local AI systems Hermes / LLM tooling

Local models, Hermes-based setups, and the glue required to turn a model running on a machine into something I can actually use.

04 Printer automation 3D printing / Automation

Removing repetitive steps from the path between a model, a slicer, a printer, and a finished part.

05 Home infrastructure Docker / Unraid

Containers, storage, local services, monitoring, and all the maintenance work created by trying to reduce maintenance work.

03 — ABOUT / APPROACH

About Daniel

I’m a software engineer in Reno, Nevada. My professional work is primarily C++ and systems development, while my personal projects range from reinforcement learning and emulation to developer infrastructure, hardware, and automation.

I enjoy finding the part of a system that everyone assumed was working.

How I build things

I like projects that require understanding the entire system instead of hiding behind one layer of it. That usually means tracing the real control path, finding the actual source of truth, and building enough instrumentation to prove the result.

  1. 01

    Find the real problem

    The visible failure is often five layers away from the thing that caused it.

  2. 02

    Make failures obvious

    Unknown, incomplete, and failed are different states. Software should not quietly turn all three into “success.”

  3. 03

    Prove that it works

    Logs, audits, repeatable tests, recordings, and clean evaluation environments beat “it seemed to work when I tried it.”

04 — CONTACT

Got something interesting?

Software, AI, infrastructure, hardware, a stubborn bug, or a project that has completely gotten out of hand.

Email Daniel GitHub LinkedIn