6502.org

I decided to use a terminal window for my Typescript-based emulator as it's more suitable to my Forth operating system. Here it's doing some floating point math: This bit me in porting my Python-based 65816 emulator to Typescript. I was trying to improve my code during the port and thought that in Typescript was a better typed way of expressing in Python. It's not. It took me a bit of testing to track this bug down. Unfortunately, it would be too much effort to port the extensive unit tests I have for the Python emulator to Typescript. I'll just have to live with the uncertainty for now as the debugging experience in the Typescript version is much better than in the Python version.

I wonder how hard this would be to hook up to the actual hardware. I have an Arduino that can take the role of bus master and stream back to the PC what happens with the busses and control signals. You would probably still have to run the sim in parallel to get access to internal registers, but it might be useful to find when the sim is not agreeing with the hardware?

Would love to play with these, bytearray and tmr4, if you're able to share the link

That would be a fun and interesting technical project. I'm using a message-based system for communications between the emulator and the debug adapter, which implements Microsoft's interface protocol for passing runtime events and information to the VS Code frontend. Adapting this for the Arduino should be easy. More in line with Microsoft's vision though would be developing a debug adapter to link directly to the Arduino. The technical details on that are beyond me right now but it doesn't seem much different than the process used by the VS65 Debugger extension (github), that does something similar for the VICE emulator.

As for validating the simulation, I'd rather just port my Python unit tests to Typescript. There are some 65816-based tests packages you could use (here and here for example) but unless you're using the developer's system, getting them to run on your system could be a pain (so much so that I just expanded the PY65 65c02 unit tests into the above, not a small task and it's only about 98% complete at this point).

My code isn't ready for sharing yet. It's hardcoded to my Forth operating system binary and listing file and still has limited functionality. I'll be posting it here though at some point. Note that it uses a custom ca65 listing file. It looks like bytearray is using an approach that fits much better with the VS Code source file paradigm. I imagine keeping things synched up is harder with that approach but is more technically satisfying as it doesn't need a consolidated listing file.

I've updated my GitHub with my version of a VS Code 65816 simulator. It has the following features:

• * Runs a program from reset vector, optionally stopping on entry
  * Supports multi-file programs
  * Can set launch arguments for program
  * Follow along with execution directly in assembly source files
  * Control program execution with continue/pause, single step, step-into, step-over, step-out and run-to-cursor
  * Four types of breakpoints (conditional breakpoints not yet supported):
  • * Source: set directly in assembly source files; stops execution when that line is reached
    * Function: set on function name or memory address; stops execution when that function is entered or memory address is reached during program execution
    * Data: set on X, Y, K, B and D register; stops execution when a write access to these registers is made
    * Instruction mnemonic or opcode (opcode allows a break even if there is no supporting source code)
  * Registers and hardware stack displayed in Variables pane and can be modified when program is paused
  * Watch pane functional for program symbols and memory addresses (not expressions) and the values of these can be changed when the program is paused
  * Variable/watch changes highlighted after each step and on execution pause
  * Drill down on variables/watches that represent a memory range (variable ranges can be opened in a separate hex editor window allowing modification of the memory range)
  * Symbol address and value displayed when hovering over a symbol in source code
  * Call stack displayed when stepping through program. Clicking on an entry opens the source code in an editor at that line. On continue, call stack collapses stack to current instruction.
  * Integrated terminal window for input/output with default read/write addresses at $f004 and $f001 respectively.
  * Source files listed in debug pane Loaded Scripts Explorer

The simulator runs as a VS Code extension and uses CC65 assembler source and listing files, along with the map and symbol files from the linker. I've included a "hello world" example if you'd like to try it out without bothering with CC65.

Thanks for sharing the source! This looks really promising. I've had a play with it and added it to the list of things to implement in my build.

I found a VS Code extension that hooks VS Code up to a W65C02SXB. It was released a few days ago. It's available at the Visual Studio Marketplace. There might be something in there to incorporate into your project. I believe it's mostly written in C#.

I made my Github repo public with my 65816 OS and the included vscode debugger + emulator written in TypeScript.

https://github.com/alexanderbh/65816-OS

It is a bit of a mess as it is just a playground for myself. But perhaps someone out there could take some inspiration from it.

You can read about each of the parts (OS, debugger, emulator) in the readme.

Thanks for publishing! I think it's almost always the right thing to do, for works-in-progress as well as polished-and-final projects.

I agree. There is just that barrier of publishing something that is just a hobby project and far from complete/stable.

But for sure there are things I have made in that repo that I would have loved to find somewhere else. Things like how to connect to the vscode debugger UI. How to map between memory addresses and source file lines.

Maybe someone will stumble upon this and use it to make something far better.