Barry Walker

If you’ve ever tried to debug 6502 assembly at 2am, squinting at a hex dump and wondering which zero-page address you just clobbered, you’ve probably wished for a smarter debugging partner. I built one.

VICE MCP is a Model Context Protocol server embedded directly into VICE, the industry-standard Commodore 64/128/VIC-20/PET emulator. It gives AI assistants like Claude direct, programmatic access to the running emulator – no screen scraping, no clipboard hacks, no middleware. The AI can read and write memory, set breakpoints, inspect VIC-II registers, poke SID channels, load programs, and step through code one instruction at a time.

Why Build This?

The Commodore 64 has one of the most active retro computing communities in the world. People are still writing games, demos, and utilities for a machine released in 1982. The tooling has gotten dramatically better over the decades – cross-assemblers, cycle-exact emulators, logic analyzers for real hardware – but one gap remained: the tools can’t reason about what they’re looking at.

A traditional debugger shows you the state. You still have to figure out why the sprite is flickering, why the music sounds wrong, why the program crashes after loading from disk. That reasoning step is exactly what large language models are good at.

How It Works

VICE MCP runs as an HTTP server inside the emulator process itself. When you launch VICE with -mcpserver, it starts listening on port 6510 (yes, that’s the C64’s CPU – I couldn’t resist) and exposes 63 tools via the standard MCP protocol:

• Memory tools: Read/write RAM, inspect zero page, view memory maps, search for byte patterns
• Execution tools: Step, continue, pause, reset. Set PC to arbitrary addresses
• Breakpoint tools: Set/clear/list breakpoints with conditions. Get notified via SSE when they hit
• Display tools: Read screen memory (both PETSCII and character RAM), inspect sprite registers, get VIC-II state
• Audio tools: Read SID register state across all three voices
• Machine tools: Query the current machine type, get/set configuration
• Disk tools: Attach/detach disk images, read directories
• Input tools: Type text, press keys, simulate joystick input

The server speaks JSON-RPC 2.0 over HTTP POST, with Server-Sent Events for asynchronous notifications (breakpoint hits, state changes). It’s the same protocol that Claude Desktop and other MCP clients already understand.

What Can You Actually Do With It?

Here’s where it gets interesting. With VICE MCP connected to Claude, you can have conversations like:

“Load the program at $C000 and run it. When it crashes, show me the stack trace and tell me what went wrong.”

“The sprite on player 2 is glitching. Read the VIC-II registers and the sprite data pointers and figure out what’s misconfigured.”

“I’m trying to play a SID tune but voice 3 is silent. Check the SID registers and tell me if the ADSR envelope is set up correctly.”

“Search memory from $0800 to $9FFF for the PETSCII string ‘READY.’ and tell me where the BASIC ROM copied it to.”

The AI doesn’t just read the data – it understands the Commodore 64’s architecture. It knows that $D011 is the VIC-II control register, that bit 5 controls the bitmap mode, that $D418 is the SID volume/filter register. When it reads these values, it can explain what they mean in context.

Architecture Decisions

A few choices worth noting:

Embedded, not external. The MCP server runs inside VICE, not as a separate process that connects via the monitor protocol. This gives it access to internal state that the monitor doesn’t expose and eliminates serialization overhead for bulk memory reads.

C, not Python. VICE is written in C. The MCP server is written in C. No FFI boundaries, no GIL, no garbage collection pauses during emulation. The server uses libmicrohttpd for HTTP and cJSON for JSON parsing – both compiled directly into the library.

Port 6510. The MOS 6510 is the CPU in the Commodore 64. If you know, you know.

Getting Started

Build VICE with --enable-mcp-server and launch:

./x64sc -mcpserver

Connect any MCP client to http://localhost:6510/mcp. The server supports the full MCP lifecycle: initialize, tools/list, tools/call, and SSE for notifications.

The project is open source and available on GitHub.

The Other Half: Unit Testing 6502 Assembly

VICE MCP gives you AI-powered debugging, but there’s another piece of the puzzle: automated testing. If you’re writing 6502 assembly in 2026, there’s no reason it shouldn’t get the same DevOps treatment as the rest of your code.

sim6502 is a unit testing framework I built specifically for 6502 assembly. It has its own testing DSL that feels familiar if you’ve used any modern test framework:

suite("Sprite positioning tests") {
  symbols("/code/include_me_full_r.sym")
  load("/code/include_me_full_r.prg")
  load("/code/kernal.rom", address = $e000)

  test("sprite-x-position", "Sprite X < 256 clears MSB") {
    x = $00
    a = $ff
    y = $00
    $02 = $40
    [vic.MSIGX] = $00

    jsr([PositionSprite], stop_on_rts = true, fail_on_brk = true)

    assert([vic.SP0X]  == $ff, "Sprite 0's X pos is at $ff")
    assert([vic.SP0Y]  == $40, "Sprite 0's Y pos is at $40")
    assert([vic.MSIGX] == $00, "Sprite 0's MSB is cleared")
  }
}

You load your assembled binary, set up memory and registers, call a subroutine, and assert on the results. You can assert on memory contents, CPU state, cycle counts – everything you need to verify that your code does what it’s supposed to.

By default, sim6502 uses its own built-in 6502 simulator. Fast, simple, good for pure CPU logic. But here’s where VICE MCP comes in.

Where They Meet: Hardware-Accurate Testing

Some 6502 code can’t be tested in isolation. If your routine talks to the VIC-II, depends on CIA timer behavior, or interacts with SID registers, a bare CPU simulator isn’t enough. You need the full hardware.

sim6502 can use VICE MCP as an execution backend:

# Run tests against VICE for hardware-accurate results
sim6502 -s tests.6502 --backend vice

# Auto-launch VICE and run tests
sim6502 -s tests.6502 --backend vice --launch-vice

# Connect to VICE on a remote host
sim6502 -s tests.6502 --backend vice --vice-host 192.168.1.100

Same test files, same assertions, same CI pipeline – but now your tests are executing on a cycle-accurate Commodore 64 emulator with real VIC-II, SID, and CIA chips. The --backend vice flag swaps the internal simulator for VICE MCP, translating each test operation into MCP calls against the running emulator.

This means you can write a sprite routine, test it against the fast internal simulator during development, then validate it against VICE in CI to catch any hardware-specific edge cases. Same workflow you’d use with unit tests and integration tests in any modern project.

What’s Next

The VICE MCP tool set already includes snapshot save/restore for reproducible debugging sessions, machine configuration, and chip-state inspection for VIC-II, SID, and CIA. Next up: better support for multi-machine setups (C128, VIC-20, PET) and richer display tools for bitmap and multicolor graphics modes.

sim6502 now includes a language server with diagnostics, completions, and symbol resolution – so you get IDE support for writing your test files, too.

If you’re in the C64 community and want to try AI-assisted retro computing with proper test coverage, grab both projects and point Claude at them. Your 6502 code deserves better than SYS 49152 and hoping for the best.