What This Portfolio Demonstrates
Three bodies of work, one methodology: build the system end to end, verify every claim with a reproducible artifact, and write it up honestly.
- Production GenAI / AI-platform engineering — MCP agent tooling, multi-provider LLM gateways, grounded citations, eval harnesses, fine-tuned transformers (series index →)
- Applied ML research — a behavioral clone + style-constrained RL agent of a real player, built from 7,554 recorded matches (the complete story →)
- Systems reverse engineering — CPS-2 arcade hardware with no source, no docs, encrypted code (below)
0. Production GenAI Series
Enterprise LLM/agent platform engineering, technique-first
- A Model Context Protocol server exposing 75+ agent tools behind a tool-RAG discovery surface, with sandboxed code-composition and confirm-guarded destructive ops
- A multi-provider LLM gateway (Anthropic, OpenAI/Azure, Google/Vertex, Bedrock) with SSE streaming and provider-native citation grounding — every AI claim traces to a page-anchored source
- A hierarchical DeBERTa classifier over a 4-level, 137-path taxonomy — deepest-level accuracy 4% → 77%+ via focal loss and branch oversampling, with CI-triggered SageMaker fine-tuning
- Offline eval harnesses (latency / token cost / quality with automated hallucination scoring) deciding which model ships
Why it's impressive: this is the full production AI stack — agents, gateways, evals, fine-tuning, MLOps, and a client-ready React 19 front end — shipped end to end.
0.5 The Memorial Bot
A behavioral clone of a deceased Fightcade player, then style-constrained RL
- 7,554 recorded matches mined into per-frame traces; VQ-VAE codebook of his actual 16-frame motor primitives
- 266-dim perception reverse-engineered from CPS-2 RAM (10 schema revisions, one 81-page community RE paper)
- Style-constrained PPO: a measurable 9-component "plays like him" vector inside the reward, ~34 verified arXiv papers folded into the design
- The 2.2M-parameter policy runs live in the browser — a hand-written forward pass verified bit-close against the trained model, in an original abstract arena (no game assets)
Why it's impressive: imitation learning, RL, RAM-level reverse engineering, and honest evaluation discipline in one artifact — with the community who knew him as the Turing judges.
Spar with it live → · Read the complete story →
Target hardware for the systems work below: Capcom CPS-2 arcade board (1998). 68000 CPU @ 11.8 MHz, Z80 sound CPU @ 8 MHz, QSound DSP, custom graphics hardware. Program code is hardware-encrypted.
1. Cross-Architecture Audio Injection
Porting a Dreamcast soundtrack to 1998 arcade hardware
- Injected 7,722 KB of MvC2 Dreamcast audio into CPS-2 QSound ROM, triggered via sound test codes
$0900-$0904(audio banks past 8MB are genuinely addressable only under a custom FBNeo core -- stock QSound mapping wraps at 8MB; see the post's Editor's update) - Built a multi-bank streaming engine in hand-assembled Z80 machine code: dispatch table hook, QSound register programming, ISR-driven bank switching at 250 Hz
- Diagnosed and fixed a critical bug in MAME's QSound HLE where
int16_tphase clamp at0x7FFFFFFprevented playback past 32K samples per bank - Three distinct bugs found and fixed: crumbled audio (end_addr capping), 10x speed (int16_t sign interpretation), ISR JR overflow (Z80 branch distance)
Why it's impressive: This is multi-CPU systems engineering across three architectures (68000, Z80, QSound DSP) with no documentation, requiring register-level understanding of a proprietary sound chip's emulation behavior.
2. CPS-2 Maximum Memory Model & Expansion
Expanding every ROM type to hardware theoretical limits
- Expanded the ROM set from 41MB to 148MB on disk (CPS-2 file-format ceiling: 128MB GFX, 16MB Audio, 4MB Program) -- and later documented honestly that padding alone isn't addressable; the real cap-break (64MB GFX + 16MB QSound, pixel-proven) required a custom FBNeo core
- Built a fully automated Python pipeline that handles ROM extraction, expansion, code patching, 68000 assembly, and ZIP packaging in a single deterministic run
- Verified expansion via GOLD marker at
mvc.13m:0x3FFFFBand in-game ULTRA SETTINGS diagnostic screen
Why it's impressive: Demonstrates hardware address space analysis, binary format engineering, and automated build pipelines -- the kind of infrastructure work that underpins large-scale systems.
3. Runtime Verification via Test Menu Injection
Embedding diagnostics into a legacy binary
- Injected a 22-line diagnostic screen into the game's F2 Test Menu using 68000 assembly
- Displays real-time verification: ROM sizes, free space, character roster counts, palette integrity, function addresses
- Uses hardware-polled input (
$800000), dual OBJ bank clearing, VRAM tile rendering, and interrupt-disabled display - Built a sound test interface with live QSound channel programming
Why it's impressive: This is documentation that runs on the hardware. If the ROM is corrupted, the values change. If a function is missing, "OK" becomes "NO". The verification is inseparable from the artifact.
4. Binary Forensics: Recovering an Unreleased Character
Finding disabled functionality in a 1998 ROM
- Discovered 85 code references for character ID 0x2E (Armored Spider-Man) -- far more than any other unused ID
- Found 4 conditional load points where
MOVE.B #$2E, D0is guarded byBEQbranches that skip execution in the retail game - Reverse engineered 3 distinct secret character table formats (Type A: 16-byte structured, Type B: 2-byte sequence, Type C: 2-byte packed) -- evidence of iterative development
- Decompiled all 4 existing secret character load functions to C, ranging from 12 bytes (Gold War Machine) to 66 bytes (Red Venom)
Why it's impressive: Systematic binary forensics with reproducible evidence. The analysis distinguishes real references from false positives (IDs 0x30/0x32 matched the MOVE.W #imm opcode 0x303C), quantifies confidence, and documents the complete unlock system architecture.
Status (July 2026): the forensics stand; the $2E revival plan itself pivoted -- the Armored Spider-Man / Iron Spider line was retired in favor of a Dark Sakura port from MSHvSF (char-id $2A there), a same-generation port with byte-identical animation/frame tables.
Methodology
All work uses:
- MAME emulator for runtime analysis and debugging
- Ghidra + GhidraMCP for static analysis and decompilation
- Python for automated build pipelines and binary manipulation
- vasm (68000) and hand-assembled Z80 for code injection
- In-game verification as the final validation layer
Source repositories and build scripts are available for full reproducibility.