It is currently Wed Apr 24, 2019 6:47 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Wed Nov 28, 2018 4:45 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 429
Location: FL
Most likely. The qt5 branch is basically finished (pending some tiny makefile tweaks or something, possibly).


Top
 Profile  
 
PostPosted: Tue Dec 11, 2018 12:33 pm 
Offline

Joined: Sun Jul 22, 2018 2:36 pm
Posts: 33
Just to give a small update:

I've been porting my work on bsnes-plus to a branch off of the Qt5+newdebugger branch and everything seems to be working nicely, now. The only huge deviation compared to what was there before was my own rewrite to the symbol map - on top of the re-write already done by Revenant :P Most notably, instead of the symbol map storing a list of Symbols that could operate in a vaguely polymorphic way each 'symbol' is now just an address with some text associated with it, and Labels, Comments, Source lines, all have their own lists. Similarly, access of symbol data is just done by asking for, specifically, a Label at some addr or a Comment at some addr, as opposed to fetching a Symbol and trying to get a comment or line from it manually. Of course, this had a small effect on the other systems that read and write to the symbol map, but it's all fine - and I would argue the code is a bit simpler to read and compute, anyway.

The only functional difference is that the Symbols list (accessed from the Debugger window) doesn't display Comments - it's only Labels - and I wonder if it's worth trying to keep Comments in there? Would that still be valuable for developers (I guess esp. people trying to disassemble/understand existing ROMs?) to search specifically for Comments when appending existing ROM code, or would Labels be sufficient?

Anyway, that aside, I've got just a couple i's to dot and t's to cross for an initial release/PR to the bsnes-plus branch. I've got two big things left I want to rework:

1) breakpoint handling in the emulator, to better distinguish between "user defined breakpoints" and "debug-adapter specific breakpoints", and allow for a more flexible number of breakpoints in general, instead of a flat eight.

2) rework some of the IPC to not simply rely on stdin and stdout, or at least not require the emulator executable to have to be launched from the VS Code extension (i.e. allow for attach to a running process). If nothing else, it would be to try and ease the debugging of the debug-adapter-protocol itself. Right now, the only way I have to debug bsnes-plus itself is to launch it from gdb, so when I launch it from the VS Code extension, there's no facility to attach a debugger to a running instance of the bsnes-plus process, which has made moments of debugging issues a bit bothersome, to say the least. Even to help my own sanity for future development of the debug adapter protocol, it would be good to help make sure other people don't end up a creek without a paddle.


Top
 Profile  
 
PostPosted: Mon Dec 17, 2018 9:45 am 
Offline

Joined: Sun Jul 22, 2018 2:36 pm
Posts: 33
Work on the vscode-newdbg branch is continuing, checking off a few more things here and there.

One major thing recently, though, was the IPC rewrite I wanted to do: Communication now happens over Tcp Sockets so it's possible to, e.g., attach VS Code to a running emulator instead of launching it directly.

Related to this, I also had to expand how my VS Code debug adapter works so that a connection is established over tcp, of course, but as a part of that, I figured it's just non-trivial enough now that it might as well exist on the VS Code Marketplace: https://marketplace.visualstudio.com/it ... orom-debug (or just search for "retrorom" in VS Code's Extensions viewliet :mrgreen: ) Note that, unless you're really up on your updates, you'll likely have to update VS Code itself: the extension relies on some newly-finalized debugging functionality.

So, trying this whole thing out for yourself has one less major step in it!


Top
 Profile  
 
PostPosted: Mon Dec 17, 2018 1:57 pm 
Offline

Joined: Fri Dec 30, 2011 7:15 am
Posts: 50
Location: Sweden
Written a little bit of snes asm recently... won't be needing something as elaborate as this, but I just have to say I find this project really amazing!
So cool to be able to breakpoint snes asm and all that jazz!


Top
 Profile  
 
PostPosted: Sun Dec 23, 2018 10:10 pm 
Offline

Joined: Sun Jul 22, 2018 2:36 pm
Posts: 33
A small update before the holidays. Nothing user-facing or substantial from the last post, but wanted to give this because it'll be at least an extra week and a half before anything else.

For one, I do want to note one thing I failed to previously: for bsnes-plus itself on Windows if you want to fetch the vscode-newdbg branch linked in the OP, things are set up there right now so that you only need to have mingw64 installed, just fetch the repo, and run the 'cc' script to build everything: The necessary Qt5 dependencies are contained in a submodule in the project right now, so you do not need to do a separate install of Qt5 and re-set your PATH envvar or whatever to get things to work.

Two, I've been doing a lot of work refactoring a lot (all?) of the stuff related to breakpoints, which is going well. The main intent for the work is:

-Allow for an unlimited number of breakpoints, not just 8. This will involve a rework of the Breakpoint Editor window, of course, to show a list of breakpoints as opposed to a grid of widgets. Still hemming and hawwing over how to go about this, but I think some regression of usability (at least, measured in terms of # of clicks to add/modify a breakpoint) might be inevitable. Trying to find ways to minimize that, though.

-Fix a couple big issues related to how the external debug adapter system was using the breakpoints: breakpoints are set during Launch events from Code properly, and the list of breakpoints are not unintentionally cleared out when you enable or disable them in Code (including breakpoints from files not related to the one you just touched).

-Fix some other design issues behind-the-scenes, where systems tended to directly query the BreakpointEditor UI for information about breakpoints and call it to modify breakpoints (effectively treating the window and its widgets as a data model...tut tut).

I've got most of it done, now: I need to do some more testing to identify and address some bugs around it, do a final performance pass on it especially for the breakpoint_test function (need to get down to ~O(1) complexity from O(n)), and whipping up the new UI for the Breakpoint Editor. I might whiddle away at this over the break, but there are some other things I want to distract myself with in the meantime.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: Molive and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group