Draft
Conversation
Implements minimal viable debugger with: - Debug Adapter Protocol (DAP) server in C# - Address-based breakpoints - Step/continue/pause execution - Register and flag inspection - Disassembly view at current PC - VSCode extension integration New projects: - src/apps/Highbyte.DotNet6502.DebugAdapter - DAP server - vscode-extension/ - VSCode extension files Features: - Launch .prg files from VSCode - Set breakpoints at memory addresses - View CPU state (PC, SP, A, X, Y, flags) - Step through 6502 instructions - Disassembly in call stack view Limitations (MVP): - No source-level debugging - Address-only breakpoints - No memory inspection - No conditional breakpoints
- Add .vscode/launch.json for Extension Development Host - Add .vscode/tasks.json for npm compile task - Fix documentation to clarify F5 workflow: 1. Open vscode-extension folder in VSCode 2. Press F5 to launch Extension Development Host 3. In new window, open folder with .prg file - Update TESTING.md, DEVELOPMENT.md, README.md, MVP-COMPLETE.md - Fix: .vscode directory now at correct path (vscode-extension/.vscode)
- Add build-test-program.ps1: PowerShell script to assemble test-program.asm using ACME - Add launch.json.example: Sample debug configuration for test-program.prg - Add QUICK-TEST.md: Step-by-step guide for testing the debugger - Add test-program.prg: Pre-built binary (17 bytes) for immediate testing - Uses ACME assembler at user's specified path
- Create vscode-extension-test/ folder for testing the debugger - This folder has its own .vscode/launch.json for 6502 debugging - Prevents confusion with vscode-extension/.vscode/launch.json (for extension dev) - Add README explaining the two-folder structure - Update QUICK-TEST.md to use the test folder Workflow: 1. Main window: Open vscode-extension/, press F5 → Extension Dev Host 2. Dev Host window: Open vscode-extension-test/, press F5 → Debug 6502 program
- Removed test-program.asm, test-program.prg, build-test-program.ps1 - Removed launch.json.example - These files now only exist in vscode-extension-test/ folder - Keeps extension source folder clean and focused on extension code - Avoids confusion about which folder to use for testing
- Use frame ID 0 (standard for top frame) instead of 1 - Add PC address to stack frame name for clarity - Add presentationHint to frames and scopes - Validate frameId in scopes request - Add KNOWN-ISSUES.md explaining Variables panel behavior The Variables panel clearing after each step is normal VSCode/DAP behavior, not a bug. All debuggers work this way.
Current state: - Added padding with synthetic addresses when VS Code requests instructions before 0x0000 - Added padding at end when we run out of instructions - Behavior: Initial stop at 0x060e focuses on 0x05bf (incorrect), but highlights 0x0000 (correct) - Subsequent stepping correctly highlights and focuses on the right addresses - Memory addresses in disassembly still corrupted (0x0000-0x0033 then jumps to 0x0538) This is a checkpoint - the least incorrect state seen so far.
…ition after major jump is still wrong.
…sition after major jump is still wrong.
…ble commands to work similar to ACME assembler.
…header load address.
…g a 6502 assembly program via the VSCode extension.
… be used for C64 as prelaunchtask.
…bugger to TcpDebugServerManager and DebugAdapterLogic
…tations) before an instruction is executed instead of after. Fixes issue that prevented breakpoint being set on first instruction in a program.
… the emulated system and not just the cpu (makes sure C64 raster scan line is calculated between steps, etc.). Breaking: Removes passing unnecessary SystemRunner instance to ISystem interface methods ExecuteOneFrame and ExecuteOneInstruction.
…m a preBuildTask.
…ically when stepping through a macro.
… also exit the emulator in launch mode.
…el, and REPL. Enable setting CPU registers and flags via Variables and REPL.
…e, .data, .rodata etc). Default assume code.
… to location of .dbg file. Fix startup so debugging is possible from first instruction executed (C64 kernal for example).
…gging to debug from first CPU instruction.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Major features and changes:
1. Debug Adapter
A debug adapter library to enable debugging from VSCode. It supports both source level debugging via CC65 toolchain .dbg files, and disassembly debugging when source and .dbg files are not available.
2. Debug Adapter hosts
The Avalonia Desktop app hosts the Debug Adapter (enabled via command line option) and exposes TCP endpoint for debug client connections.
Also a generic debug console app that hosts the Debug Adapter and debug clients connect via traditional STDIN/STDOUT.
3. VSCode debugger extension
A VSCode debugger extension that connects to one of the Debug Adapter hosts above.