Super Mario World 2 - Yoshi's Island
Page 1 of 8
Page 1 of 8 • 1, 2, 3, 4, 5, 6, 7, 8 
20180129
Super Mario World 2 - Yoshi's Island
Patch
Patch (v29: fuzz eating fixed):
- Code:
http://bszelda.zeldalegends.net/stuff/Con/smw2_msu1_patch.zip
Mirror Link: https://mega.nz/file/0aUkjR5T#NgbiOL_INLVgJOHMt5vdjjwntiLAwcF3yt6m-A2cM5M
PCM Sets
Yoshi Island Orchestral Set presented by JUD6MENT (v2 - Feb 6th, 2023 Update):
- Code:
https://mega.nz/file/VPMhhADC#sKdxUA_SyPLz5sm7yPsjTaOGZpaVXfqPIIdK-ABpy7A
Mirror Link: https://www.mediafire.com/file/nrxqbi1e6jrmp9x/Yoshi_Island_Orchestral_2023_Update_-_JUD6MENT.zip/file
PCM Set (v2) presented by Enmet:
- Code:
https://drive.google.com/open?id=1z4qtKGsIEplC5b7Aar3L3Ya9-Rjtds5d
PCM Set (v2) presented by daniloroxette:
- Code:
https://mega.nz/#!QQpzmKrZ!xwRe4KWe-WCn4gnwWlF0TsFb9EqUyaBnXe9Pd-W00tw
SMW2+ Rom Hack in MSU-1
SMW2+ - MSU1 PCM Rename Generator by ABOhiccups
- Code:
https://github.com/ABOhiccups/MSU1-PCM-Rename-Generator/releases/tag/smw2%2B
Needed for SMW2+2: https://www.romhacking.net/hacks/395/
Last edited by Conn on Sun 5 Feb 2023 - 5:33; edited 29 times in total
Conn
- Since : 2013-06-30
Share this post on:
Super Mario World 2 - Yoshi's Island :: Comments
Mon 29 Jan 2018 - 16: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+
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+
Mon 29 Jan 2018 - 17:41 by Señor Ventura
Wait a moment... The super fx is already emulated???????
Mon 29 Jan 2018 - 22: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 
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).
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).
Does Ikari have any plans doing that?Gonna wait for a SuperFX hardware implementation
Mon 29 Jan 2018 - 23: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
Tue 30 Jan 2018 - 1: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?
- 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?
Tue 30 Jan 2018 - 1: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:
icarus manifest:
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.
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.
Tue 30 Jan 2018 - 1: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.
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.
Tue 30 Jan 2018 - 8: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!
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
Thu 1 Feb 2018 - 11: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.
Thu 1 Feb 2018 - 12: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...
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...
Thu 1 Feb 2018 - 13: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
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
Thu 1 Feb 2018 - 14: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 ='(
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.
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.
Thu 1 Feb 2018 - 16: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...
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...
Fri 2 Feb 2018 - 0: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.
Fri 2 Feb 2018 - 7: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:
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:
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:
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 Fri 2 Feb 2018 - 10:18; edited 1 time in total
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
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
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:
It must be a long addressing at it seems that some nmi have a 40 in B, so I need to make lda $7e01617ef7d0 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
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 Fri 2 Feb 2018 - 10:18; edited 1 time in total
Fri 2 Feb 2018 - 10: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 
Fri 2 Feb 2018 - 13: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
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
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
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!
Fri 2 Feb 2018 - 13: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.
Fri 2 Feb 2018 - 14: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
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.
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.
Fri 2 Feb 2018 - 14: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.
Fri 2 Feb 2018 - 14: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!
As for emulators, I think zsnes is the best... honestly 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
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.
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!
As for emulators, I think zsnes is the best... honestly
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
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.
Fri 2 Feb 2018 - 15:03 by qwertymodo
Conn wrote:As for emulators, I think zsnes is the best... honestly
Fri 2 Feb 2018 - 16: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
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
Page 1 of 8 • 1, 2, 3, 4, 5, 6, 7, 8
Similar topics» Super Mario World 2 - Yohi's Island (USA) MSU1+FastROM
» Super Mario World
» Super Mario World Co-op
» Super Mario World MSU+
» Super Mario World (U) ips ?
» Super Mario World
» Super Mario World Co-op
» Super Mario World MSU+
» Super Mario World (U) ips ?
Permissions in this forum:
You cannot reply to topics in this forum