DQ3 loves to fiddle with the stack all the time, especially to store data for a routine directly after the JSL that calls it and then change the return address, for instance

Yeah, horrible as it is for disassembly, I love that trick. I do it all the time in my own 65816 code. It's a cool way to pass constants to functions (integers, strings, you name it) without consuming registers, which are absolutely in dire demand on this architecture. Can be a bit of a hassle without macro support to do the stack relative calculations for you, though.

I was debugging some code and I have a few questions about the debugger:
1. What are the "sub start" lines?
2. What is "call stack" used for?
3. Why does the debugger sometimes jump back in code when the opcode is not a jump/branch type opcode? This usually causes the code to get stuck in a short section and every jump back adds one new line to call stack

Nicole wrote:Are you sure an interrupt vector isn't set to that address?

I'll have to check that, but I'm pretty sure no, since they were defined with labels. All interrups should be disabled at that point anyway since it's part of the reset code.

EDIT: Interrupts should be ruled out now. The address the program execution jumps to is $00:803A, and none of my interrupt vectors point to that address. Even if it was interrupt, I can't think of a reason why the code would jump there from exactly the same point every single time. The jump always seems to happen at $00:80B0 according to the call stack, which is LDX #$00.

EDIT 2: Not sure why, but the debugger now displays the code differently. Now I sort of understand why the code jump. The code was interpreted as having a BRA instruction in it, which causes the jump.

Here is a short section from the start of the subroutine with hex (from compiled file), correct (from source code), which is also what the debugger displayed earlier, and what the debugger shows now and executes. I also included the states of M and X bits from the debugger (which are as intended).

ansarya wrote:One another note, should I be using the Development Build version instead of the 2.0 release?

Super late reply, but yes, feel free to use the dev builds, they are usually pretty stable (and often fix a lot of things over the previous release.)

I'll to reproduce the buggy disassembly scenarios. Like you guys discussed, the X/M flags can be a bit of a pain, but from what I've read it looks like at least some of those issues are just bugs and fixable (e.g the ADC properly taking up 3 bytes but only showing up as a 2-byte instruction)

Mesen does have "mark as data/code" shortcuts, but iirc I haven't implemented them in Mesen-S just yet. Will probably try to look into that soon-ish, too.

As far as I can tell, this hack seems to expect the standard "LoROM" mapping, which is different from the standard CX4 board mappings, as far as I understand. It also doesn't seem to boot in either bsnes/higan, either (most likely because of this.) So it only seems to run on snes9x as far as I can tell?
I can make it work in Mesen-S, too, but unsure if I want to mess with the default memory mappings (precisely because they lead to romhack authors assuming things that are potentially wrong compared to hardware.) I guess I could add an option to be more lenient in terms of memory mappings so that these kind of hacks can run, though.

---

In other news, I've recently started working on Mesen-S again. So far I've fixed a number of (mostly non-emulation related) issues, and improved performance when the debugger tools are opened by a pretty decent margin (should be about ~50% faster than before.)

Cheat and turbo support have also been added, and a "Registry Viewer" tool was added in the debug menu (similar to bsnes-plus' property viewer.)
Also added a few of the most frequently requested options that exist in Mesen but were missing in Mesen-S (e.g the ability to disable the game selection screen, etc.)

This release fills in most of the gaps in functionality compared to mesen (overclocking, netplay, cheats, etc.) and adds support for most of the enhancement chips (all except 2)
It should also run a bit faster than 0.2.0 did (~10% faster or so, as far as I can tell), and the debugger tools should be a bit less CPU hungry than before (~20-25% faster than before when the debug tools are active)

Excluding the ~9 titles that aren't supported or have issues (+ BS-X stuff), it should run pretty much everything else in the SNES library at this point.

If you were editing the ROM, that's probably part of the problem then. The debugger currently keeps track of the 8-bit code/16-bit code/data sections and saves them in a "cdl" file, but if you change the ROM, the CDL will no longer match and the debugger will get confused.

byuu wrote:As for performance ... unfortunately SNES emulation lives in the shadow of ZSNES, and likely always will. It has completely distorted what the general public thinks of how demanding SNES emulation really is. I like the analogy of Nesticle versus Nestopia. We went from needing a 25MHz CPU to an 800MHz CPU, but it was necessary. Thankfully, everyone has an 800MHz+ CPU, so it was never an issue. pNES and Mesen need even more resources, because they do far more. It shouldn't be a surprise that SNES emulation went from needing 200MHz to needing 2-4GHz, but now we're butting up against a nearly stagnant IPC rise over the past decade and a half, and on the other end folks are pushing run-ahead and Raspberry Pis, and so things have only gotten worse, not better, over time.

Realistically, I don't see why an accurate SNES emulator should need over 2Ghz. Each time I add a new system to kindred I change the way I do things and over time I've improved my methods. It's probably been more beneficial then rewriting the 65816 core eight times. Mind you the original 65816 code back in 1998 was 188KB and today it is a manageable 18K. Shrinking the code is always going to give a boost in performance. I developed kindred on a netbook for a while, I'm hopeful I can get running again on said netbook. That being said we are still a long way from a perfect SNES emulator

I remember a programming assignment at university, we had to draw a calendar on screen and highlight the current day of the week, it was in Haskell. I said to the other students, I reckon I can do that in 4 lines of code and they laughed at me. Next day they all turn up to class with 2 to 3 pages of code and I rock up with a sheet with 3 lines of code on it. You have to optimistic.