Hi,
I have seen that in the past bsnes had an integrated debugger. Is that feature still avlaible ? I'm currently using snes9x from geiger with debug capability but it sometimes lacks of certain fonctionnality. I was wondering if any other active emulator was able to do debugger
++ Lint
Is a debugger still available ?
-
Nach
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
It hasn't been updated to work with changes in bsnes.
--Lint;
--Lint;
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
-
Nightcrawler
- Romhacking God
- Posts: 922
- Joined: Wed Jul 28, 2004 11:27 pm
- Contact:
While we're talking about Geiger's debugger. Does anyone have the source code for this? Being for SNES9x 1.41, it's severely outdated. I was hoping to port his debugging code to SNES9x 1.51, though I think that's wishful thinking as I bet the implementation is not modular in nature like that by a long shot.
Anyway, we really need a decent up to date SNES debugger. We're stuck in 2005.
Anyway, we really need a decent up to date SNES debugger. We're stuck in 2005.
[url=http://transcorp.romhacking.net]TransCorp[/url] - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
I've never really needed anything more than Sleuth's debugger for most things (although breakpoint on memory access would be useful at times). Granted, I'm not a romhacker. What all does Geiger's build do beyond this?
Oh, I also remember seeing a teaser build of a debugger window for zsnes from pagefault a long time ago. Is that still being worked on?
Oh, I also remember seeing a teaser build of a debugger window for zsnes from pagefault a long time ago. Is that still being worked on?
-
byuu
I took out the fully functional debugger with a UI and core rewrite in v014.
The main reason I haven't re-added it is that I'm unable to implement savestates. That alone severely hinders most uses for a SNES debugger. Unlike most PC software, it can take hours to get to a certain point in a SNES program.
The second reason is because I want to keep the Windows and Linux ports in sync. I did recently get the font size somewhat under control (the default GTK+ font on my PC is still wider than Tahoma/Win32), but I still have a lot to do there.
One, I need to create an API to specify monospace fonts for controls. Two, I need to determine the actual size of each monospace char, including padding, so that I can dynamically size the debugger window based on this to fit a specific number of XxY characters without scrolling or lots of blank space. Three, I need to see if it's even possible to get as much control as I had with Win32 editboxes to do things like jump the cursor selection around and smooth scroll text to simulate a terminal. Three, I'd have to figure out a nicer way to add the hooks. The old v013 debugger hooks were really nasty and had significant speed hits (just the if(debugger_enabled == true) checks when false in critical areas) unless the entire debugger was compiled out of the emulator.
There's some alternatives for the last one: function pointers, derived debug-enabled classes, etc. But I really need to think about it before jumping in to writing another debugger.
Lastly, there's the fact that bsnes v014 and above were no longer opcode-based emulators. The ability to cycle step and such is not something most people would care about, but it does cause issues you don't see in opcode-based emulators, such as H/DMA and DRAM refresh occurring right in between your opcodes.
I'm also really torn on whether to design a console or a UI-based debugger. The console is definitely faster and more flexible, but has a steeper learning curve.
All of that makes a debugger not very useful for others, and me being able to easily manipulate the source means I essentially have the ultimate debugger already (break on the 37th write of an even number to $7e2162 while the screen is enabled on line 216? No problem). Sucks for you guys, though :P
For the time being, I do have a tracing interface for the CPU and SMP, with optional masking, but you have to compile your own version to enable it. See src/snes/tracer/tracer.h for the API.
The main reason I haven't re-added it is that I'm unable to implement savestates. That alone severely hinders most uses for a SNES debugger. Unlike most PC software, it can take hours to get to a certain point in a SNES program.
The second reason is because I want to keep the Windows and Linux ports in sync. I did recently get the font size somewhat under control (the default GTK+ font on my PC is still wider than Tahoma/Win32), but I still have a lot to do there.
One, I need to create an API to specify monospace fonts for controls. Two, I need to determine the actual size of each monospace char, including padding, so that I can dynamically size the debugger window based on this to fit a specific number of XxY characters without scrolling or lots of blank space. Three, I need to see if it's even possible to get as much control as I had with Win32 editboxes to do things like jump the cursor selection around and smooth scroll text to simulate a terminal. Three, I'd have to figure out a nicer way to add the hooks. The old v013 debugger hooks were really nasty and had significant speed hits (just the if(debugger_enabled == true) checks when false in critical areas) unless the entire debugger was compiled out of the emulator.
There's some alternatives for the last one: function pointers, derived debug-enabled classes, etc. But I really need to think about it before jumping in to writing another debugger.
Lastly, there's the fact that bsnes v014 and above were no longer opcode-based emulators. The ability to cycle step and such is not something most people would care about, but it does cause issues you don't see in opcode-based emulators, such as H/DMA and DRAM refresh occurring right in between your opcodes.
I'm also really torn on whether to design a console or a UI-based debugger. The console is definitely faster and more flexible, but has a steeper learning curve.
All of that makes a debugger not very useful for others, and me being able to easily manipulate the source means I essentially have the ultimate debugger already (break on the 37th write of an even number to $7e2162 while the screen is enabled on line 216? No problem). Sucks for you guys, though :P
For the time being, I do have a tracing interface for the CPU and SMP, with optional masking, but you have to compile your own version to enable it. See src/snes/tracer/tracer.h for the API.