VSCode debug adapter for my 65816 simulator

[bytearray]

EDIT:
I made the debugger+emulator. See github repo: https://github.com/alexanderbh/65816-OS



I am writing a multitasking OS for my 65816 breadboard computer and I found the development cycle too slow. Write code, burn ROM, plug in, nothing works, repeat.
I have a scheduler running based on interrupts that switches between tasks. But I could use some insights into the machine when I develop to speed things up.

So my plan is to write a simulator for my 65816 system and then hook it up to the vscode debugger. The simulator i written in Typescript. It is not implementing all the opcodes yet, but that will come.

The debug adapter is working though. Translating between the ProgramCounter and the source files. Stepping, breakpoints, watching symbols, etc.
It appears to process cycles that corresponds to around 10MHz. My breadboard system runs at 12MHz.

My question is: Have anyone else written a debug adapter for their simulator? Or how do you guys debug bigger projects like an OS?

[BigEd]

Looks very handy! (For the uninitiated, it seems "Debug Adapter" means something specific in the world of Visual Studio, whereby an external program can interact with the source code debugger. Or something like that...)

[BigEd]

To answer your question, in part, one way to debug some new and complex code is broadly as you are doing - using a suitably instrumented emulator and do everything in software on your PC.

Another way is to hook up something to your actual hardware to capture what's happening, and possibly to interact with the live system. @hoglet has a 'protocol decoder' project which would probably be a great help in bringing up an '816 OS. See
viewtopic.php?p=91526#p91526
for pointers. (The 6502 version of the decoder includes a 65816 model.)

[Dr Jefyll]

Developing a simulator is a large investment of effort, as you know. And, until it's 100% debugged, it has potential to actually hinder your progress (although of course at other times it will help).

It might be worth applying a comparatively small amount of effort toward improving your original approach. Instead of, "Write code, burn ROM, plug in," you could choose one of the several different ways to send code from a host computer directly into the test system's RAM. This'd still be a boon even if you decide to go ahead with the simulator (and indeed it might be helpful in debugging the latter). Just a suggestion!

-- Jeff

[BigEd]

Good point! Pasting srecord data down a serial connection is something I’ve done.

[Proxy]

Yeah i agree with Jefyll.
I also got annoyed of the constant ROM programming on my SBC so i made a small Serial bootloader whichs allows me to load and run programs by simply dragging and dropping a binary file (with a custom header) into some Terminal Software that support file transfer (like TeraTerm).
It was completely worth it as it made developing software a lot easier and faster.

and I don't know how advanced VSCode can be, but i'm sure there is some way to have the IDE hook into the COM Port that your SBC takes up and have it directly upload the program after compiling/assembling it, and then show the Terminal. which would basically mean that you wouldn't need a seperate Terminal software anymore. you just press a button and the IDE will do everything for you.

[bytearray]

Thanks for the input. The debug adapter part is a protocol that is at least used in Visual Studio Code:
https://microsoft.github.io/debug-adapter-protocol/

I have considered the serial connection to send over new code. It will help on the speed to get code over, but I still have the issue of looking into the system when it is running.

Then I will have to send debugging info back over the serial connection. Things like the list of tasks, their meta data like input and output streams, signals being sent between tasks and so on.

I do a bunch of writing data out to the display. But it still feels like a black box sometimes.
It might be easier when the base of the os in in place and working.

With the simulator I will have to also implement the 6522 for my SPI and I need to simulate the RA8875 as I use that as my display.
It is a big task but I am okay with that. This is a project for life.

[BigDumbDinosaur]

Dr Jefyll wrote:

Instead of, "Write code, burn ROM, plug in," you could choose one of the several different ways to send code from a host computer directly into the test system's RAM.

That's precisely how I developed the SCSI driver and four-channel UART driver for my POC units. I use the S-record output feature of the Kowalski assembler to pass code over to the POC unit. It is a convenient and surprisingly-quick way to handle the write/assemble/test/debug cycle, especially when the code being tested has the potential to crash the machine—something that happened frequently during the earlier stages of SCSI development.

[BigDumbDinosaur]

bytearray wrote:

I have considered the serial connection to send over new code. It will help on the speed to get code over, but I still have the issue of looking into the system when it is running.

For that, you need a machine language monitor. Since you are experimenting with the 65C816, may I recommend Supermon 816?

Quote:

Then I will have to send debugging info back over the serial connection. Things like the list of tasks, their meta data like input and output streams, signals being sent between tasks and so on.

You could set up multiple serial I/O (SIO) paths so you can run code and debug at the same time. Motorola S-records are good for that purpose and are entirely reliable on a hard-wired SIO connection without having to resort to an error-checking protocol, such as XMODEM (which is woefully obsolete, but still useful in some cases).

Quote:

I do a bunch of writing data out to the display. But it still feels like a black box sometimes. It might be easier when the base of the os in in place and working.

Welcome to the wacky world of bare metal development. Unfortunately, it's neither easy or painless. However, with the right development tools and a functioning SBC on which to test, it's not as difficult as it might seem.

Quote:

With the simulator I will have to also implement the 6522 for my SPI and I need to simulate the RA8875 as I use that as my display.

It seems you may be putting the wagon before the horse. The first step, if I were doing this, would be to build 65C816 hardware that is capable of hosting a test environment. That will enable you to test pieces of code in a predictable and repeatable way. Any simulator is a complicated thing to write. The 65C816's internal behavior has a lot of little twists and turns that will make it even more complicated. So, yes, this will likely be a long-term project that will keep you out of the bars on Saturday night.

[jeffythedragonslayer]

I use the Mesen-SX disassembler and debugger. It still has problems with source debugging. I would use this tool if it could connect to super nintendo emulators.

[drogon]

bytearray wrote:

Or how do you guys debug bigger projects like an OS?

Probably not the answer you're after but I use PRINT, or a variant.

The multi-tasking in my BCPL OS is written in '816 asm, but it's fairly simple - an interrupt handler sets a flag every 10mS and the bytecode interpreter checks for the flag being set on every jump bytecode and if it's set then it does a task switch which involves traversing a linked-list, changing the stack and global pointers and bytecode PC as required and another BCPL task takes over.

(This idea isn't new - it's implemented in the microcode of the Inmos Transputer).

I have asm level print routines that can dump the (bcpl) registers and inside my ('816 asm) OS there is a RAM dump command. That's all I've used.

Also this principle: Typing is no substitute for thinking. - Kemney & Kurtz; BASIC; 1964.

-Gordon

[tmr4]

I modified Py65, a 6502 emulator, for the 65816. I posted about it a while back. It's pretty complete but only runs at about 500 kHz equivalent on my tablet PC (a bit faster on my desktop). I pretty much do all of my development on it now. I sometimes run it in VSCode to take advantage of its debugging capabilities.

Edit: btw - thanks for the DAP link. From it I learned that I can connect the VSCode debugger to my already running emulator. This speeds up debugging since starting my emulator in the VSCode debugger is very slow.

[tmr4]

Thanks again for posting this. It took me about a day to convert the core part of my Python 65816 emulator to Typescript and kludge it into Microsoft's Mock-Debug extension. It only has basic debug functionality so far, but the 65816 is fully modelled. It's a much better debugging experience than debugging the Python emulator as this links directly to the source listing. Here's a sample shot:

[bytearray]

tmr4 wrote:

Thanks again for posting this. It took me about a day to convert the core part of my Python 65816 emulator to Typescript and kludge it into Microsoft's Mock-Debug extension. It only has basic debug functionality so far, but the 65816 is fully modelled. It's a much better debugging experience than debugging the Python emulator as this links directly to the source listing. Here's a sample shot:

That is awesome @tmr4. I started with the mock-debug extension as well. It is a really nice experience to work with my 65816 code this way. I have found several bugs that I would not have found debugging on my hardware. Because I can follow the code step by step and inspect the stacks and memory and so on.

My 65816 simulator is complete. And I added a 6522 VIA as well for my SPI communication. The 6522 is talking SPI with my simulated RA8875 display chip. I added a custom webview to my debug extension that my simulator updates when SPI bytes come in on the Memory Write register on the RA8875.

Thanks for your input above guys about validating on real hardware. I have the hardware running and it is working. I could not have made the simulator without verifying the results look like in real life.

But this debugging experience is just so nice. I have an interrupt driven scheduler (VIA timer) that switches between multiple tasks. Saves the registers, switches the Stack and Direct page to the active task, all that. And being able to just break at any point is amazing. Since I got this running in the simulator I have made a lot of progress. Progress that would have taken me weeks of evenings doing on the real device. Both because of the ROM burning but also because I can put a breakpoint and just step through my code. Verifying that it does what I imagined.

Here are some updated pics of the debug adapter. The numbers being written out is 5 different tasks running in "parallel" writing out their task id. Next up is the input bar below the screen will trigger my (working) PS/2 interrupt handler which reads the scan codes and puts it in the input stream given to the task running my shell app.

PS: The simulator is, by complete chance, running almost at the same speed as my breadboard implementation, which is running at I think 12MHz. The simulator is just running as fast as it can so it is by pure luck it is in the same ball park. It is nice because the task switching and printing to the display is almost 1-1 in terms of execution speed.

PPS: My wife zones out when I try to explain why it is fun to do this. I hope you guys will understand.

[tmr4]

Looks good! I agree that debugging in an integrated debugger, with an active link to the source code is a superior experience. For me, a good debugger is essential. I wouldn't have developed my Forth operating system without one.

I'm also adding interrupt capability for a VIA and ACIA. Good idea on the custom webview. Right now, I'm just dumping output to the console. It's not really satisfying, but is enough to verify that things are working as expected.