I started a new debugger tool for my x65 project. Previously I created a dozen of single-purpose python scripts (running on a linux PC) that let me single-step the CPU, read CPU registers, dump memory and so on. The scripts use a common ‘backend’ modules to connect to the x65 hardware over the USB / FTDI interface, but otherwise each script acts on its own.
These python scripts and modules are located in the project subdirectory x65pyhost:
cpuidec.py disable-abrt02.sh do-cpustep.py do-loadbin.py do-poke.py do-vchartest.py do-vlogo.py
cpuregs.py do-cpureset.py do-dump.py do-loadprg.py do-readregs.py do-veradump.py enable-abrt02.sh x65ftdi.py dbg.py do-cpurun.py do-i2cdump.py do-memtest.py do-savebin.py do-videotest.py icd.py vera.py
Some of the scripts were demonstrated in my previous post: Reading of 6502/65816 CPU Registers by a PC-based Debugger.
The new debugger tool, called very unimaginatively ‘dbg.py‘, will integrate all functions. It will work as a stand-alone full-screen debugger on the PC host. For the User Interface I decided to use the python framework ‘textual’. Textual is a cross-platform GUI (or rather TUI = text user interface) library which lets me create rich interface while staying in a text console.
The following screenshot shows the current (very early) state of the debugger. The debugger is running on linux PC in a window terminal. The program communicates with x65 board over the USB interface. The screen is divided in two halves. On the left side there is an instruction trace from the CPU (each line is one CPU cycle; instructions typically execute in 2-4 cycles). On the right side there is the current CPU register contents. The empty space on the right will be probably filled with configurable memory dumps and other settings.
So far the debugger supports just two commands: ‘s’ – single-step the CPU, and ‘r’ – run / stop the CPU.
