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.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
- For making cartridges of your Super NES games, see Reproduction.
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
2. The call stack allows you to follow the series of JSR/JSL commands (and interrupts) that changed the PC and lead you to your current location so you can see what called what.
3. I have no idea what you're talking about with this one. Do you have more information? Like what game/addresses are involved?
Then I'm not sure if it's bugged because in the code that I'm debugging it has:ansarya wrote:1. The "sub start" lines indicate the start of a routine. That means that a JSR or JSL command jumped to that location.
Code: Select all
LDA #$FF STA $4305 --- sub start --- STA $4306 --- sub start --- LDA #$01 STA $420B
Just some code that I've written. I just can't think of a reason why a jump from the subroutine would occur to an earlier pointansarya wrote:Do you have more information? Like what game/addresses are involved?
Code: Select all
... LDA #$18 STA A1T0L LDA #$80 STA A1T0H STZ A1B0 LDA #$FF ; This is where the code execution end up STA DAS0L STA DAS0H LDA #%00000001 STA MDMAEN DEX BPL MemClear LDA #$00 TCD PHA PLB TAX DEX TXS REP #$10 .i16 JSR RegisterSetup ... some other code here RegisterSetup: LDX #$0000 LDA #$80 ; Code jumps from here STA inidisp STA INIDISP LDA #$03 STA obj_sel STA OBSEL STX OAMADDL LDA #$09 STA bg_mode STA BGMODE STZ MOSAIC ... more code RTS
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.Nicole wrote:Are you sure an interrupt vector isn't set to that address?
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).
Code: Select all
M = 1 A = 8 bit X = 0 X/Y = 16 bit HEX Correct Debugger A2 00 00 LDX #$0000 LDX #$00 A9 80 LDA #$80 BRK 85 08 STA $08 BRA $00803B 8D 00 21 STA $2100 PHP A9 03 LDA #$03 STA $2100 85 09 STA $09 LDA #$03 8D 01 21 STA $2101 STA $09 STA $2101 ... ... ...
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.)ansarya wrote:One another note, should I be using the Development Build version instead of the 2.0 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?Ice Man wrote:Will you add support for Mega Man X3 Zero Project? Game doesn't boot sadly.
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.)
Yes awesome!Sour wrote: and a "Registry Viewer" tool was added in the debug menu (similar to bsnes-plus' property viewer.)
I have noticed some weird behavior with the event viewer.
Normally when advancing per scanline it runs ahead of the main window but when going through Vblank it is suddenly 1 frame behind the main window.
Advancing the scanline to the bottom of the screen and then advancing 1 frame it will quickly show
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.
So as a feature request:
Make the debugger detect whether 8 bit or 16 bit mode should be used and display the code accordingly.
There's an option to reset the cdl log in the debugger's file menu.
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 emulatorbyuu 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.
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.