rolandshacks / vs64

C64 Development Environment for Visual Studio Code
Other
97 stars 16 forks source link

Support for Commander X16 #56

Open Rytikar opened 6 months ago

Rytikar commented 6 months ago

Hi Roland,

I'm still using your extension every day with great fun and productivity gain. As I said earlier, I'm approaching the point where I would like to evaluate the feasability of porting to Commander X16. I would REALLY like to continue with my current setup. :-) Do you think it possible to add the X16 emulator into VS64? I don't think much more is needed, as code generation, build and project handling should be the same. I've looked into the source of VS64 with an idea of doing it myself, but it is quite an elaborate setup you have there, for 'just' a VS extension. Perhaps with a little help from your side on where to start I would give it a try.

Documentation for the X16 emulator is readily available, and someone made an attempt, but it's far from what you have with VS64. link

Greetings and thanks for the effort

rolandshacks commented 6 months ago

Hi.

Thanks for the request. I promise to look into it, but I cannot promise to quickly do ... I am very busy with other things (like work) these days.

Let me read some more details and then respond back here.

Kind regards! Roland

rolandshacks commented 6 months ago

What about the debugger? The X16 emu currently does not support being remote controlled (like VICE does with the binary monitor protocol). That basically reduces the capabilities to starting the emu executable with a compiled binary, correct?

rolandshacks commented 6 months ago

CPU: that's the WDC 65C816. Extending the built-in 6502 CPU emulation with additional opcodes isn't easy, that would also be a separate project for the future.

Rytikar commented 6 months ago

Yes, looks like work in progress to reach where vice is now... But it would be a start...

Rytikar commented 6 months ago

Not needed (for me at least) to enhance the built-in emulation. I'm never using it...

Rytikar commented 6 months ago

you have features to log from the code into the emulator for poor man debugging...

Rytikar commented 6 months ago

The cpu is the WDC 65C02S @ 8 MHz actually, not 65C816

rolandshacks commented 6 months ago

The most basic functionality is that a vs64 debug session would spawn a x16emu process with some given args and then await termination of that process to end the debugging session (or enforcing process termination when cancelling the debugging session). Features of the monitor would not be available in vscode.

Rytikar commented 6 months ago

Yes, I can see that. Would be a nice start I think. Need to lobby with the x16 emulator folks or do some work of my own. :-) I can see the emulator is written in C... well, I can do that...

rolandshacks commented 6 months ago

Yep. Ideally, the debug features are extended by a socket based protocol. (Instead of keyboard input and UI output).

rolandshacks commented 6 months ago

Quick update on X16 support:

v2.5.4 adds (preliminary) support for X16 launch/debug configurations. Because of the limited debugging capabilities of x16emu, stepping and introspection is not possible - but launching/relaunching should already be helpful.

More info can be found in the README (https://github.com/rolandshacks/vs64/blob/master/README.md).

Please fetch the latest .vsix package from gitlab for manual installation: https://github.com/rolandshacks/vs64/releases/latest

Feedback is welcome!

Rytikar commented 6 months ago

Hi Roland, thanks for the extra effort, very much appreciated. I gave it a test and it works. I will keep you updated using it. :-) ... now for 65c02 opcode syntax highlighting? :-D

rolandshacks commented 6 months ago

Adding opcodes just for the syntax highlighting is not a big deal (and I think would not disturb or irritate classic 6502 developers).

Just to be sure, these are the additional opcodes:

BRA PHX PHY PLX PLY STZ TRB TSB BBR[0..7] BBS[0..7] RMB[0..7] SMB[0..7]

Rytikar commented 6 months ago

I think so... I've waited 40 years for a BRA... finally! :-)

rolandshacks commented 6 months ago

@Gtach : Maybe you want to look at v2.5.5 -- get some more syntax highlighting...

Rytikar commented 6 months ago

Looks good, thanks I'm deep in learning X16, so it comes in handy. And you've been right. The cpu is actually a WDC65816, they just sell it as 65C02. So, the WAI opcode, which is used a lot (and rightly so), is not highlighted. No hurry, though.

Rytikar commented 6 months ago

Hi, as I said the starting of programs with the x16emu works generally really nice. I'm starting to use the built in debugger of the emulator. Helps, but is a far cry of what was possible with VS64 and vice, but better than nothing. You already must give the -debug argument, as one can launch the debugger with F12. I noted in the documentation one can give one breakpoint when launching the emulator: << -debug [

] enables the debugger. Optionally, set a breakpoint >>

Could it be done that, if breakpoints are set in VS, to take the first one into the -debug argument?

And, while I'm dreaming, can additional arguments for x16emu only be set in the plugin settings (thanks for that), or also in the project-config.json?

Thanks

rolandshacks commented 5 months ago

Hi. Regarding "args" - you can do that in the launch configuration. Here's a simple example:


{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "x16",
            "request": "launch",
            "name": "Launch X16",
            "preLaunchTask": "${defaultBuildTask}",
            "args": "-scale 1"
        }
    ]
}

For the rest... I'll put it on my list :-)

Rytikar commented 5 months ago

Well... DUH!

Rytikar commented 5 months ago

Had my first longer debug session with the cx16 emulator. And, while it's not as comfortable as via VS, it does work ok. But, not wanting to bother you too much, this adding of the first found breakpoint address to the -debug argument would actually help A LOT. :-) Right now I'm getting the address from the report file, start the emulator via command line in the build folder adding the address to the -debug manually. Works like a charm, but... :-)

Thanks for the effort

rolandshacks commented 5 months ago

Hi. Let me see if I can find some time...

BUT... in between - maybe you want to advocate for better debugger support in the X16 forums. If there's support from the core devs then there might be a much better was to get things done... Just my 2 cents on this.

Rytikar commented 5 months ago

Thanks Roland.

I opened an issue in the github repository of the x16emu regarding the binary monitor. Let's see what they say to that.

Btw, I'm also working a bit with the guy that makes tilemaped, a very sophisticated tile, map and sprite editor for the CX16. But don't you worry, no VS64 support needed here. The CX16 loads assets directly from file into memory. The file sizes don't lend them to be added to the code anyway. Just FYI.

Thanks a lot.

PS: I changed my 10 year old avatar picture to something more appropriate, so it's still me. :-)