[Rotwang]

This is pretty snizzy-snaz! 

I will throw in one feature request while the floor's open. No SNES debugger that I have seen has a memory window that refreshes as quickly as the one found in FCEUXD-SP. Is it at all possible to crank up the speed of the memory window auto-refresh to similar levels?

[Revenant]

I plan to change it to refresh once per frame once I start reworking parts of the original bsnes debugger GUI, so hopefully that should be fast enough.

[Rotwang]

Sounds awesome!

[Grimoire LD]

While this looks great and everything appears to be adequately made, there is one problem that irks me though, I write my code in Hex, not in ASM. So I prefer to write A90A or C905 rather than LDA 0A or CMP 05 for instance. The issue with this is that you cannot continue writing after one byte, sure you can press left after filling in one byte but that seems needlessly mundane and a step backwards to what is provided by Geiger's SNES9X. Also if you do use that method and you go to the end of the line instead of cycling back to the next bit of hex as you'd imagine the writing cursor is within the address line, which is just sort of silly. Another issues I have is with pasting, when you go to paste it doesn't even write to code... it doesn't write to anything really.

All in all it is a great looking emulator with good compatibility but some of the more crucial debugging aspects are still a bit finnicky and need some work. A great effort though.

[Rotwang]

I'd kill someone in front of their own mother to have a SNES debugger with the same functionality as FCEUXD-SP.

[Revenant]

While this looks great and everything appears to be adequately made, there is one problem that irks me though, I write my code in Hex, not in ASM. So I prefer to write A90A or C905 rather than LDA 0A or CMP 05 for instance. The issue with this is that you cannot continue writing after one byte, sure you can press left after filling in one byte but that seems needlessly mundane and a step backwards to what is provided by Geiger's SNES9X. Also if you do use that method and you go to the end of the line instead of cycling back to the next bit of hex as you'd imagine the writing cursor is within the address line, which is just sort of silly. Another issues I have is with pasting, when you go to paste it doesn't even write to code... it doesn't write to anything really.

All in all it is a great looking emulator with good compatibility but some of the more crucial debugging aspects are still a bit finnicky and need some work. A great effort though.

The hex editor is entirely a remnant of the original bsnes debugger. I'm rewriting it, don't worry.

[Grimoire LD]

That is good to hear, you've done a great job so far and I will be keeping up with your updates to it.

[sics]

The version of bsnes this was forked from definitely had 7z support via snesreader. However, upon testing just now I see it doesn't seem to work with newer 7z files. Older ones seem to work just fine, though. Apparently, LZMA2 is not supported.

Genial  , ¡Es suficiente para mi con eso!
¿Sera capaz de reconocer extensiones erróneas?
 Me explico usualmente yo reemplazo las extensiones de mis roms comprimidos por una ficticia para poder tenerlo asociado con el emulador y poder ponerle un icono personlizado.

[SC]

Genial  , ¡Es suficiente para mi con eso!
¿Sera capaz de reconocer extensiones erróneas?
 Me explico usualmente yo reemplazo las extensiones de mis roms comprimidos por una ficticia para poder tenerlo asociado con el emulador y poder ponerle un icono personlizado.

Proper Translation:

Great  , That's enough for me!
Will it be able to recognise erroneous file extensions?
I mean: I usually replace my compressed ROM file extensions by a fake one so to have it associated with an emulator and giving a custom icon to it.

sics, te sugiero que escribas en Inglés aquí, si fuese posible.
Si eres capaz de entender Inglés escrito, probablemente estés preparado para escribirlo tú mismo también.
Si alguna vez necesitas ayuda puedes decirmelo y si tengo tiempo trataré de ayudarte.
----
sics, I suggest you to write English here, if that's possible.
If you are capable to understand written English, you'll probably be ready to write it too.
If you ever need help you can ask me and I'll try to give you assistance if I find the time.

 

[sics]

No soy capaz de leerlo, utilizo varios traductores para poder interpretarlo y aun así aveces lo interpreto mal.

[Pennywise]

Este forum es solo anglais. Tu necesitas apprendar anglais por este forum. Las reglas.

Hey, I know a little Spanish, terrible as it is.

[mopoz]

The debug does not show the address to the FX-BUS?

Code: [Select]

00:e4ff a0 f3    lms r0,($01e6)  r0=$0000 SRAM=00:01E6 ALT1=0
...
00:e272 df       romb            ALT1=0 ALT2=0 ROMBR=$5c
00:e273 ef       getb            r0=$00a9 ROM=5C:FE06
...
00:e278 df       romb            ALT1=0 ALT2=0 ROMBR=$07
00:e279 df       getc            ROM=07:F8A9 COLR=$a3
It would be good like here

[neagix]

Great work! bsnes-plus is truly something that can replace the old Geiger's debugger, which is buggy and has no native support on Mac/Linux anyways..

What do you think about a few features I have been thinking on:

• labels and their management eg. memory offset 0xDA5A becomes labelled with string you specified
• labels for known SNES special memory areas
• (advanced, maybe for later) different color for memory address that was never read/read only/written so far during the emulation

If you think these can be useful, I might try to contribute on github directly, although can't make promises

[mziab]

(advanced, maybe for later) different color for memory address that was never read/read only/written so far during the emulation

That one is already implemented. The memory viewer colors bytes red, blue or gray depending on whether they're code, data or unused so far.

[neagix]

That one is already implemented. The memory viewer colors bytes red, blue or gray depending on whether they're code, data or unused so far.

Nice! Missed this one. But about data: still we could have a diversification about read and read-written?

[badinsults]

Very happy to have this project out. I was using an old version of bsnes for debugging, but with the latest version of Linux Mint, it was not possible to compile it without changing the source.

[Revenant]

Nice! Missed this one. But about data: still we could have a diversification about read and read-written?

The usage stats actually do track reads and writes separately, it's only the memory viewer that (currently) uses the same color for both.

On a related note, I was recently discussing reworking the usage tracking, including adding more specific usage contexts (see this github issue for specifics). It'll most likely be an upstream change in bsnes-classic whenever that happens, but aside from that, I've also considered adding a way to customize the colors (including separate read/write colors if it'd be useful).

As for labels, I did plan to add support for those later on as well (probably similar to the way they are handled by the FCEUX debugger).

The debug does not show the address to the FX-BUS?

Right now, the SuperFX debugger only shows all the registers that are relevant to the current and previous instructions. I did this before writing the actual register editor, which makes it slightly redundant, and I might reduce it to showing the current instruction's registers to make room for other relevant info (like ROM/RAM access locations, such as in your example).

[neagix]

The usage stats actually do track reads and writes separately, it's only the memory viewer that (currently) uses the same color for both.

On a related note, I was recently discussing reworking the usage tracking, including adding more specific usage contexts (see this github issue for specifics). It'll most likely be an upstream change in bsnes-classic whenever that happens, but aside from that, I've also considered adding a way to customize the colors (including separate read/write colors if it'd be useful).

It can be useful only to understand when a variable that one assumes is only read (e.g. a constant) suddenly becomes written. Gives insight on usage patterns.

Other ideas from the top of my mind:

• possibility to search memory (obvious one)
• some scripting language to express conditional breakpoints (LUA?
• advanced watches, with possibility for scripting too?
• comments directly in the disassembled source (I know, this would make it more IDA-like) and possibility to save and auto-reload the debugging session information

There should be github trackers for these?

Also, some old post of mine: http://neagix.blogspot.nl/2013/05/65c816-from-assembly-to-c-quest-for-die.html
I still have the source for that project of mine, as I was trying to extract context information from debugging/disassembly

[Revenant]

Still slowly working on bsnes-plus in my spare time, but I also (finally) touched up xkas-plus a bit and added a link to binaries in the OP. Check it out!

Fun fact: KALE uses xkas-plus to generate limit-removing patches (in IPS format) that can be applied from the editor, as an example of how I've extended it to be useful for systems other than the SNES.

[DackR]

Wanted to say thanks again for working on this.

I downloaded the windows binaries for bsnes-plus and tried debugging Marvelous: Another Treasure Island, but the application crashes whenever I try to start a new game or load a saved game. This happens with the original ROM as well as with my current English build of the ROM. Just thought I'd mention it.

It looks like the source was updated recently, so I may need to set up a mingw environment on my PC to give building the latest version of bsnes-plus a shot. Maybe tonight.