Super Mario World 2

Page 1 of 4 1, 2, 3, 4  Next

Go down

20180130

Post 

Super Mario World 2






Last edited by Conn on Tue 17 Apr 2018 - 19:06; edited 6 times in total
avatar
Conn



Since : 2013-07-01

Back to top Go down

Share this post on: diggdeliciousredditstumbleuponslashdotyahoogooglelive

Super Mario World 2 :: Comments

avatar

Post on Tue 30 Jan 2018 - 6:18 by Colines

Hm... Game is randomly crashing on 1-3 =(

higan v106 though. It just crashs without explanation or pattern.

Couldn't reproduce on bsnes-plus, so looks like no debugger available... Oh boy... Gonna wait for a SuperFX hardware implementation so I can make a Super Mario World 2 MSU-1+ Laughing

Back to top Go down

Post on Tue 30 Jan 2018 - 7:41 by Señor Ventura

Wait a moment... The super fx is already emulated???????

Back to top Go down

avatar

Post on Tue 30 Jan 2018 - 12:34 by Conn

Colines, as you expect, I can't do anything here, and after 1-2 weeks going down the road with bug fixing this hack I do not have the energy for higan. If you have that energy, nice Smile

What you can try is to setup higan without needing the manifest, means you simply call the tracks instead smw2_msu-x.pcm simply track-x.pcm, call the rom "program.rom" and the msu file "msu1.rom".

Other than that, if you consider higan compatibility mandatory, there is no other way than asking at byuu board to help. I'm blind on higan, since it, as you also wrote, has no debugger (and even if it had, the code asm is correct, it is a SFX trouble, which cannot be traced).

Gonna wait for a SuperFX hardware implementation
Does Ikari have any plans doing that?

Back to top Go down

avatar

Post on Tue 30 Jan 2018 - 13:39 by Colines

Conn wrote:Colines, as you expect, I can't do anything here, and after 1-2 weeks going down the road with bug fixing this hack I do not have the energy for higan. If you have that energy, nice

Don't worry about that, go rest and enjoy for going this far, it's up to us now ;-)

What you can try is to setup higan without needing the manifest, means you simply call the tracks instead smw2_msu-x.pcm simply track-x.pcm, call the rom "program.rom" and the msu file "msu1.rom".

I'm afraid that does nothing at all, since my manifest was literally taken from higan database (which assumes program.rom, save.ram and so on), with just the MSU-1 addition and the file naming changes.

Other than that, if you consider higan compatibility mandatory, there is no other way than asking at byuu board to help. I'm blind on higan, since it, as you also wrote, has no debugger (and even if it had, the code asm is correct, it is a SFX trouble, which cannot be traced).

Already did it: =)
https://board.byuu.org/viewtopic.php?f=8&t=1954

Let's see if somebody is willing to help us!

Does Ikari have any plans doing that?

Wasn't talking particularly about the SD2SNES, but whatever SuperFX implementation any joe hardware can make up ;D

qwertymodo has been pondering about a project involving MSU-1 as you can read in the link, and he is one of the few capable genius who can deal with SuperFX cartridges, so who knows what will be coming? =D

Back to top Go down

avatar

Post on Tue 30 Jan 2018 - 15:10 by Conn

ok, I tried it myself on higan 106:
- I noticed that my manifest only featured until theme 25 -> corrected to support 45 tracks now, if you redownload the patch and take the new manifest

I played until level 1-7: no crash at all. Did you import an older version one day? This could be the ram issue, we've noticed once.
Rename your ~freshly~ patched rom into smw2_msu1dbghg.sfc or whatever, import this rom, copy the new manifest along with the tracks and the smw2_msu1.msu into the import folder(name of the folder now should be "smw2_msu1dbghg.sfc" and it includes the program.rom - no need to rename the pcm or msu file since the manifest points to the correct file names - and try again.

Can somebody else try higan as well to confirm or contradict crashing?

Back to top Go down

avatar

Post on Tue 30 Jan 2018 - 15:36 by Colines

Maybe you got lucky? The crash seems to happen only at 1-3, and randomly, I was able to go very far in the level many times before crashing.

Ram refresh, renaming the files, nothing changes this behavior.

Additionally, we should take note of that:

Conn manifest:
Code:
superfx
    map address=00-3f,80-bf:3000-34ff
    rom name=program.rom size=0x200000
      map address=00-3f,80-bf:8000-ffff mask=0x8000
      map address=40-5f,c0-df:0000-ffff
    ram name=save.ram size=0x8000
      map address=00-3f,80-bf:6000-7fff size=0x2000
      map address=70-71,f0-f1:0000-ffff

icarus manifest:
Code:
superfx
    map address=00-3f,80-bf:3000-34ff
    rom name=program.rom size=0x200000
      map address=00-3f:8000-ffff mask=0x8000
      map address=40-5f:0000-ffff
    ram name=save.ram size=0x8000
      map address=00-3f,80-bf:6000-7fff size=0x2000
      map address=70-71:0000-ffff

Not sure if it makes any difference (don't understand PCB layouts), but icarus seems to be missing parts of the rom and ram memory, or whatever. I will take a look at higan's source code to see how they work.

But doesn't matter which one I use, it breaks nevertheless.

Back to top Go down

avatar

Post on Tue 30 Jan 2018 - 15:56 by Conn

Ah, that's the level with the underground music change. This switch of the music bank here is highly problematic, and caused me to make a nmi countdown - the apu must initialize before you can mute.
If you look into my asm I made a countdown of 5 nmi. But when getting into this problem it immediately crashed when entering the pipe that leads to the music bank switch. I'll maybe try a bit more later, but wasted enough time already on this game, and chances are generally little that I can do anything here.

What you could try: in the asm you find at the end a countdown table, give every value with a 05 a 0a instead (leave the 02), to give the apu more time to initiate. But this is wild guessing and may result in that the spc is played again.

Back to top Go down

avatar

Post on Tue 30 Jan 2018 - 22:50 by Conn

I think I can anticipate a clue why this problem exists for you and not for me: my computer is ancient and higan 106 runs at 30 fps. Means as soon the apu gets the order to change music bank in 1-3 the apu has plenty of time to initialize on my 30 fps (apu is not much coupled to the cpu). At your side, your computer is so fast that the 05 nmi cpu countdown is over before the apu initialized and gets a mute order before finished initializing.

Here's the countdown set to 0a, it seems to still work with snes9x and bsnes, try if you get the same problem. To exclude the ram bug thingy, please rename the freshly patched rom and import again!
Attachments
test0a.zip You don't have permission to download attachments.(4 Kb) Downloaded 4 times

Back to top Go down

avatar

Post on Fri 2 Feb 2018 - 1:16 by Colines

Conn wrote:This switch of the music bank here is highly problematic, and caused me to make a nmi countdown - the apu must initialize before you can mute.
If you look into my asm I made a countdown of 5 nmi.

Sorry the late reply, I realized that instead of being a lazy bastard only demanding things, I could maybe you know, be actually helpful =P

Have been studying your code and it's in fact sophisticated, and hell, I'm desperately tempted to make a MSU+ version because it's so impressive, that it inspired me to think of other ways to implement it, given all the work you had to figure out the inner working of the sound engine.

But time constraints are deal-breaking, we will see if I can get around them to actually start something and not just keep babbling.

Here's the countdown set to 0a, it seems to still work with snes9x and bsnes, try if you get the same problem. To exclude the ram bug thingy, please rename the freshly patched rom and import again!

Unfortunately, that haven't countered the crashing effect :'(



Of course, most of the time it just goes into a black screen.

Back to top Go down

avatar

Post on Fri 2 Feb 2018 - 2:59 by Conn

Oh wow, that's a real crash. I guess it does not have anything to do with my routine (of course it has globally), but I thought it was a hang up at a audio read routine lda $2140 cmp #$xxxx BNE yy. Means an endless loop, in which the screen would freeze. Your bug screen is showing a misplaced opcode which results eventually in brk opcodes crashing.
Since bsnes plays the code just fine, my best guess is that something is still wrong with the emulator reading the commands (similar to the bug we once had with bsnes). But since I have no chance to trace higan, this is blind. There's nothing I can do, unfortunately.

Do you have a clue at which instances it breaks, you say randomly but sometimes it is not completely random, like you jump on an enemy, collect a coin, making a sfx or whatever...

Back to top Go down

avatar

Post on Fri 2 Feb 2018 - 3:36 by Conn

The strange thing: something changed in higan 100, so that I can play this rom only with 30 fps in this version. I played 1-3 thus 5 times in slow motion and it never crashed. Then I tried higan 97 which still plays at full speed on my computer and I got the same crash like you experienced.
There could be an inaccuarcity at full speed, but really I can only speculate. Maybe byuu has time to look into the problem. At least, after all the troubles this patch caused I'm happy that it's at least 100% compatible with bsnes and snes9x. Though I wished it was also compatible with higan of course. If Ikari ever comes to emulate Super FX in his sd2snes, I'm curious to see how that goes Wink

Back to top Go down

avatar

Post on Fri 2 Feb 2018 - 4:43 by Colines

After a little bit of playtesting, I found out the crash is prominently recurring in this spot:



The crash also seems to be sensible to the Chomp Rocks' rolling sfx, which makes me wonder if there is some sort of APU overflow going on, but it does seem to be CPU related.

Things to note:

After crashing, neither reseting or powercycling (turning console off and then on) makes the game work again, it actually might corrupt your save game.

Which effectively means it crashs the whole hardware console, so it's likely sadly to happen on RH too ='(

Maybe byuu has time to look into the problem.

I'm definately going to post our results there at his message board!!

And since bsnes-plus plays it just fine, I might as well ping Revenant (Devin Acker) to see if he is able to determine wether there is an emulation flaw on his side or higan's ;D

Damn, too much trouble for something that isn't even possible to test on the real thing, and I bet the day we address all of this, it still won't work on real hardware. Laughing

Back to top Go down

avatar

Post on Fri 2 Feb 2018 - 6:23 by Conn

I hope they can find out more. I could fixed my slow motion with clearing sync audio hook. Now it runs at normal speed and crashes (with hook on and at 30 fps it didn't crash).
But this can't be the reason because in higan 97 it crashes either hook set or not.


Ah well, we only can hope that the emu devs (byuu or Devin) may find a clue...

Back to top Go down

avatar

Post on Fri 2 Feb 2018 - 14:24 by qwertymodo

Remember, higan's SNES core is literally just the newer version of bsnes. Yes, bsnes-plus has backported many accuracy improvements, but at the end of the day it's still missing *years* of work. If there's ever a question of it working in bsnes-plus but not in higan, it's almost certainly not higan that's wrong. And yes, I'm well aware of just how much that sucks to hear, considering the debugging capabilities of each (or lack thereof). Maybe you can try getting Star Rod working, which is an unofficial fork of higan with the debugger enabled (I'm not even going to try to spell it, laet-something). That might help track down the problem.

Back to top Go down

avatar

Post on Fri 2 Feb 2018 - 21:39 by Conn

Yes, Colines suggested Star-Rod, I got it to work and with much difficulties I got a trace log without mask.

Here's the trace log:
https://drive.google.com/open?id=142WW-4N0Ca8DIIU4cgi1RD-KqpEAabjp

Here's the problem:
Native:
Code:

00815f lda $00816b,x [008198] A:0101 X:002d Y:0005 S:01fa D:0000 B:01 nvMXdizc
008163 pha                    A:01c0 X:002d Y:0005 S:01fa D:0000 B:01 NvMXdizc
Since it has a 0c pushed to stack it returns to the right address
008169 rtl                    A:01e5 X:002d Y:0005 S:01f8 D:0000 B:01 NvMXdizc
01c0e6 lda #$10               A:01e5 X:002d Y:0005 S:01fb D:0000 B:01 NvMXdizc


Bug:
Code:

00815f lda $007f6b,x [007f98] A:0101 X:002d Y:0005 S:01fa D:0000 B:01 nvMXdizc
008163 pha                    A:0100 X:002d Y:0005 S:01fa D:0000 B:01 nvMXdiZc
Here it gets a 00 into stack
008169 rtl                    A:01e5 X:002d Y:0005 S:01f8 D:0000 B:01 NvMXdizc
0100e6 brk #$00               A:01e5 X:002d Y:0005 S:01fb D:0000 B:01 NvMXdizc

And returns wrong.

snes 00815f is rom pc address 0x0015F: BF 6B 81 00 -> higan somehow makes that to BF 6B 7F 00
That is ROM, I do not know how an emulator can alter the bytes here and why my patch does it (it surely not touches anything here).

I do not want to start a discussion about which emulator is best, most accurate, which not - at least in the end it is my code causing the troubles... but here I'm overasked why higan takes the wrong rom address, which can't be. I also do assume that sd2snes might not have this problem, once it supports Super FX. Maybe somebody wants to point byuu to this trace, he should have the best idea what might go wrong.

Edit:
Aaah, got the bug:
7ef7d0 lda $0161     [400161] A:1482 X:1482 Y:0122 S:01e3 D:0000 B:40 nvmxdIzc
7ef7d3 and #$00ff             A:0081 X:1482 Y:0122 S:01e3 D:0000 B:40 nvmxdIzc
It must be a long addressing at it seems that some nmi have a 40 in B, so I need to make lda $7e0161

If you look what above is going wrong at address 0x0015F it is actually the byte 0x00161 that gets replaced (that short addressing to free ram). It somehow saves to rom. Will fix it up in a sec.

Last edited by Conn on Sat 3 Feb 2018 - 0:18; edited 1 time in total

Back to top Go down

avatar

Post on Sat 3 Feb 2018 - 0:06 by Conn

Ok new version v15 is up (redownload from first post). I briefly tested 1-3 (around 5 times) and no crash, so with luck, all is good now Very Happy

Back to top Go down

avatar

Post on Sat 3 Feb 2018 - 3:11 by Colines

qwertymodo wrote:which is an unofficial fork of higan with the debugger enabled (I'm not even going to try to spell it, laet-something).

laevateinn ;D

While bsnes-plus is a great emulator and certainly deserves praise for what it is, qwertymodo said it right, being based off on bsnes-classic, which in turn is forked from a 6 years old higan version, there is still too much left behind. Also, bsnes-classic made heavy changes to the SNES core (particularly the SuperFX emulation) at the time, nobody can say for sure if something went broke when that happened.

But Conn is right, there is no point discussing which emulator is the best/more accurate, we are past beyond the ZSNES x Snes9x war era Razz

I would say to use the emulator that best suites your needs, and just use higan for testing or researching purposes, to ensure hardware compatibility, if you so desire Wink

Conn wrote:I briefly tested 1-3 (around 5 times) and no crash, so with luck, all is good now

I confirm that, it's working wonderfully, well done Conn, you did it once again Smile

Haven't tested all levels, and this is going to take a while to accomplish, but hopefully, all insanity-leading bugs are gone and we won't find anything else. ^^

This chapter is ended! Happy song, Credits rolling

Back to top Go down

avatar

Post on Sat 3 Feb 2018 - 3:38 by qwertymodo

It wasn't a question of "which is the best emulator", it was a question of "this is actually a bug in the asm, it just happens to be a bug with some obscure behavior that doesn't trigger on less accurate emulators" kind of like the original behavior with the SuperFX ROM bus handling that required you to move the code to RAM. Looking at that original problem and saying "it works in Snes9x, it must be a bug in bsnes-plus" was exactly backwards.

Back to top Go down

avatar

Post on Sat 3 Feb 2018 - 4:04 by Colines

Yeah, I wasn't trying to turn your argument into a "emulator x is better than emulator y" debate, just complementing what Conn said earlier Wink

But you brought up a nice point, it's not about if the emulator is buggy or whatever, it's just that such behavior isn't documented into the emulator's source code yet, which one might confuse with a bug in more documented versions.

Back to top Go down

avatar

Post on Sat 3 Feb 2018 - 4:24 by qwertymodo

No, it *is* a bug in the emulator, it's just that the bug allows you to do things you shouldn't be able to do, so when your asm relies on doing those things you're not supposed to be able to do, then it appears to work "correctly" only on the buggy emulator, like SMW hacks that write to VRAM outside of VBLANK or use huge echo buffers.

Back to top Go down

avatar

Post on Sat 3 Feb 2018 - 4:51 by Conn

the problem here, neither bsnes nor snes9x had is that with short addressing
lda $0161 and with DB: 40 you access the rom data and can write to rom 00/8161 (respectively pc 00/0161), instead ram 7e/0161. This should never be allowed, so I ~assume~ this a higan emulator bug - but I am not much familiar with emulator design to certify it as one.
So I do not know if this is relevant for byuu.

Speaking for myself, I am just more than happy that this issue is eventually solved, hopefully this msu game is now fixed forever! Very Happy

As for emulators, I think zsnes is the best... honestly Very Happy nice graphics, very nice GUI. I still use it for finding cheats (and thus ram addresses for my hacks) as the cheat finding engine is really awesome.
Second choice: snes9x: easy to use, nice fast forward function.
Third choice bsnes, that is because it is sometimes slow on my engine and the fasten function is not sufficient. Don't ask me how often I need to load a rom and fast forward to a specific spot Sad
fourth choice: higan, rom import makes it complex for hacking purpose, and later versions are too slow for my outdated computer, no debugger function.

But this is from my ~personal~ view as hack developer, as player you might have a different view of course.

Back to top Go down

avatar

Post on Sat 3 Feb 2018 - 5:03 by qwertymodo

Conn wrote:As for emulators, I think zsnes is the best... honestly Very Happy nice graphics, very nice GUI. I still use it for finding cheats (and thus ram addresses for my hacks) as the cheat finding engine is really awesome.

Back to top Go down

avatar

Post on Sat 3 Feb 2018 - 6:13 by Colines

qwertymodo wrote:No, it *is* a bug in the emulator, it's just that the bug allows you to do things you shouldn't be able to do

I know that Razz

But we can't outright deny other people's perspectives without pulling a backfire effect on us, specially in cases where their preferences are being questioned.

Also, you can't stop them taking ZSNES' flaws as "advantages" xD
https://www.smwcentral.net/?p=viewthread&t=59561&page=3&pid=967705#p967705

Of course, he is joking, but not everyone is aware or cares about the technical stuff as long as it works \o/

Conn wrote:As for emulators, I think zsnes is the best... honestly Very Happy nice graphics, very nice GUI. I still use it for finding cheats (and thus ram addresses for my hacks) as the cheat finding engine is really awesome.

WAR WAS BEGINNING

Back to top Go down

avatar

Post on Sat 3 Feb 2018 - 6:39 by qwertymodo

Back to top Go down

Post  by Sponsored content

Back to top Go down

Page 1 of 4 1, 2, 3, 4  Next

Back to top


 
Permissions in this forum:
You cannot reply to topics in this forum