Testing if VICE sends MemoryGet responses with matched ReqID
instead of as async events (ReqID=0xff).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
VICE API v1 sends some responses (RegisterInfo, MemoryGet) as async
events with ReqID=0xff instead of matched responses. This caused
timeouts because we were waiting for responses with our request ID.
Fix: Match async responses (ReqID=0xff) to pending requests by
expected response type instead of request ID.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Multiple fixes based on live testing:
- API version changed to 0x01 (VICE 3.x uses v1, not v2)
- Command codes updated per KB docs:
- RegistersGet: 0x22 (was 0x31)
- Continue: 0x31 (was 0x81)
- Step: 0x32 (was 0x82)
- Body length field now excludes ReqID and Cmd (just command body)
- Response parsing: totalLength = 9 + bodyLength
Added test script for debugging protocol issues.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Per KB docs, the actual protocol format is:
- Request: STX(1) + API(1) + Length(4) + ReqID(1) + Cmd(1) + Body (header = 8)
- Response: STX(1) + API(1) + Length(4) + Type(1) + Error(1) + ReqID(1) + Body (header = 9)
Previous fix incorrectly used 4-byte request IDs. Also added debug
logging to stderr to help diagnose protocol issues.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The request ID field is 4 bytes (not 1), and the packet structure was
incorrect:
- Request: STX(1) + API(1) + Length(4) + ReqID(4) + Cmd(1) + Body
- Response: STX(1) + API(1) + Length(4) + Type(1) + Error(1) + ReqID(4) + Body
This was causing all commands after connect() to timeout because response
matching was reading the wrong bytes for the request ID.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Protocol layer:
- Add DisplayGet command (0x84) for screen capture
- Add PaletteGet command (0x91) for color palette
- Implement getDisplay() and getPalette() client methods
New tools:
- screenshot: Capture display as indexed pixel data with palette
- Returns base64-encoded pixel buffer for efficient transfer
- Includes display dimensions and visible area bounds
- Optionally includes RGB palette values
- renderScreen: ASCII art representation of current display
- Converts pixel luminance to ASCII shading characters
- Configurable output dimensions and character set
- Useful for quick visual debugging in text-only contexts
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Protocol layer:
- Add watchpoint support (setWatchpoint, toggleCheckpoint, listWatchpoints)
- Add snapshot methods (saveSnapshot, loadSnapshot)
- Add autostart support
- Update command codes to match VICE binary monitor protocol
- Refactor BreakpointInfo to CheckpointInfo for unified handling
New tools:
- toggleBreakpoint: Enable/disable breakpoints without deleting
- setWatchpoint: Memory read/write watchpoints
- listWatchpoints: Show active watchpoints
- runTo: Run until specific address (temporary breakpoint)
- disassemble: 6502 disassembler with KERNAL/BASIC labels
- saveSnapshot/loadSnapshot: Machine state persistence
- loadProgram: Autostart PRG/D64/T64 files
Utilities:
- Add full 6502 disassembler with all addressing modes
- Include KERNAL/BASIC entry point labels
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Fix status hint: clarify step() vs setBreakpoint+continue for pausing
- Add flag string to getRegisters: "NV-BDIZC" format (uppercase=set)
- Add listBreakpoints tool with local breakpoint tracking
- Track breakpoints in client for listing support
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>