Homebrew Discussion SNES Online - Mod Discussion

Status
Not open for further replies.

DarkAkuma

Well-Known Member
Member
Joined
Sep 20, 2008
Messages
412
Trophies
1
XP
2,459
Country
United States
Seems about right, and mostly matches my personal list. If I'd nit pick the list, id point out that Falo indicates that 0x6D has some relation to the SA1 chip, even if its not officially used in the stock Kirby game. And I'd refer to 0x44 more as a "SDA pointer" (Or SDA Pointer Pointer =p). I'm not sure what SDA stands for, I just know Nintendo used the .sda extension on the Wii for the data that the pointer points to.

I'm not convinced on the SFX clock speed thing either, but I have no other idea for that instruction.
 

Falo

Well-Known Member
Member
Joined
Jul 22, 2012
Messages
680
Trophies
2
XP
2,627
Country
Germany
id point out that Falo indicates that 0x6D has some relation to the SA1 chip, even if its not officially used in the stock Kirby game.
The emulator checks if the PresetId matches Kirby 3 or if 0x6D is non-zero, then it sets a flag to true.

sub_20E10, Value50 is a flag table:
Code:
    v4 = info->Value50;
    if ( v4 != 0xF0000000 )
    {
      *(_DWORD *)(this + 304) = v4 & 1;
      *(_DWORD *)(this + 308) = (v4 >> 1) & 1;
      *(_DWORD *)(this + 312) = (v4 >> 2) & 1;
      *(_DWORD *)(this + 316) = (v4 >> 3) & 1;
      *(_DWORD *)(this + 320) = (v4 >> 4) & 1;
      *(_DWORD *)(this + 324) = (v4 >> 5) & 1;
      *(_DWORD *)(this + 328) = (v4 >> 6) & 1;
      *(_DWORD *)(this + 332) = (v4 >> 7) & 1;
      *(_DWORD *)(this + 336) = (unsigned __int8)v4 >> 8;
      *(_DWORD *)(this + 340) = (v4 >> 9) & 1;
      *(_DWORD *)(this + 344) = (v4 >> 10) & 1;
      *(_DWORD *)(this + 348) = (v4 >> 11) & 1;
      *(_DWORD *)(this + 352) = (v4 >> 12) & 1;
      *(_DWORD *)(this + 356) = (v4 >> 13) & 1;
      *(_DWORD *)(this + 360) = (v4 >> 14) & 1;
      *(_DWORD *)(this + 364) = (v4 >> 15) & 1;
      *(_DWORD *)(this + 368) = (v4 >> 16) & 0xF;
      *(_DWORD *)(this + 372) = (v4 >> 20) & 0xF;
      *(_DWORD *)(this + 376) = (v4 >> 24) & 3;
      *(_DWORD *)(this + 380) = (v4 >> 26) & 3;
    }

Value74's default value is >=6 or higher, if it's less then 6 the emulator loads some extra PresetId based settings.
 

DarkAkuma

Well-Known Member
Member
Joined
Sep 20, 2008
Messages
412
Trophies
1
XP
2,459
Country
United States
The emulator checks if the PresetId matches Kirby 3 or if 0x6D is non-zero, then it sets a flag to true.

Does make me think about something. Kirby's Dreamland 3 was a game on the SNESC where the correct ID had a bug with saving. Thankfully this game happened to be one of the few with a second ID. Issue was something about SRAM not saving properly. This value could be a fix for that, as I've read that the issue is no longer a problem on the switch which uses the main proper ID.

Alternatively, there was a transparency issue people found because a moron coded the wrong ID into his program (SMRPGs ID) for use with KDL3 and all other SA1 games. The issue was of course fixed by using either of the proper ID's, but maybe this could be related to that too?

sub_20E10, Value50 is a flag table:
Code:
    v4 = info->Value50;
    if ( v4 != 0xF0000000 )
    {
      *(_DWORD *)(this + 304) = v4 & 1;
      *(_DWORD *)(this + 308) = (v4 >> 1) & 1;
      *(_DWORD *)(this + 312) = (v4 >> 2) & 1;
      *(_DWORD *)(this + 316) = (v4 >> 3) & 1;
      *(_DWORD *)(this + 320) = (v4 >> 4) & 1;
      *(_DWORD *)(this + 324) = (v4 >> 5) & 1;
      *(_DWORD *)(this + 328) = (v4 >> 6) & 1;
      *(_DWORD *)(this + 332) = (v4 >> 7) & 1;
      *(_DWORD *)(this + 336) = (unsigned __int8)v4 >> 8;
      *(_DWORD *)(this + 340) = (v4 >> 9) & 1;
      *(_DWORD *)(this + 344) = (v4 >> 10) & 1;
      *(_DWORD *)(this + 348) = (v4 >> 11) & 1;
      *(_DWORD *)(this + 352) = (v4 >> 12) & 1;
      *(_DWORD *)(this + 356) = (v4 >> 13) & 1;
      *(_DWORD *)(this + 360) = (v4 >> 14) & 1;
      *(_DWORD *)(this + 364) = (v4 >> 15) & 1;
      *(_DWORD *)(this + 368) = (v4 >> 16) & 0xF;
      *(_DWORD *)(this + 372) = (v4 >> 20) & 0xF;
      *(_DWORD *)(this + 376) = (v4 >> 24) & 3;
      *(_DWORD *)(this + 380) = (v4 >> 26) & 3;
    }

Yea. I have no clue what that could be. Maybe just general development flags added for optimization hacks testing. And they forgot to just code those hacks into the preset id. Things like enable/disable different layers/sound channels, etc.

Value74's default value is >=6 or higher, if it's less then 6 the emulator loads some extra PresetId based settings.

By default, you mean internal default. Like if 74 06 was not supplied like it is for every game, it would still act as if it was set to "74 06"? That would be weird, since its in every footer when it wouldn't need to be.

And it doesn't check the distinct value over 6 at all? So as far as its concerned, 06 and 07 are the same thing?

Curious what stuff it loads for <6...
 

AlanLC

Well-Known Member
Member
Joined
Aug 18, 2014
Messages
413
Trophies
0
Age
45
XP
2,595
Country
Brazil
0x41 - ??? not currently used
0x44 - sda pointer for S-DD1 graphics
0x47 - preset
0x50 - ??? (Joe & Mac = 1E)
0x53 - ??? not currently used
0x55 - ??? maybe sfx clock speed
0x61 - ??? not currently used
0x63 - 01 = hirom, if missing or 00, lorom
0x65 - special chip
0x68 - ??? overscan? (0, 1, 2, 3 valid values)
0x6A - ??? (Super Mario Kart, Brawl Brothers, both use 38)
0x6D - ??? not currently used (some relation to SA1)
0x70 - players
0x72 - ??? not currently used
0x74 - ??? (usually 06, Super Tennis = 07)
0x76 - volume

so is this quick summary accurate for what's been discovered/theorized? have I missed/skipped anything?

EDIT: updated due to nitpicking :D

Bugs bunny rabbit rampage
0x63 - 00 or 01 graphic glitch
0x63 - 02 No graphic glitch
 

DarkAkuma

Well-Known Member
Member
Joined
Sep 20, 2008
Messages
412
Trophies
1
XP
2,459
Country
United States
Bugs bunny rabbit rampage
0x63 - 00 or 01 graphic glitch
0x63 - 02 No graphic glitch

That is strange. This is Falo original quote about the value.

0x63 = snes header location memory bank, default = 0x0 (0x7FC0), Mario Kart uses 0x1 (0xFFC0)

That game is a LoROM game, meaning its header is at 0x7FC0. So 63 00 "should" work fine. 63 01 should not though. It shouldn't even boot at all really. Id think 02 could just be causing a case default to 00, if it wasn't for you saying 00 causes a glitch.

Really, based on what RadMcFist has said, I'm surprised changing a value in the footer is showing any effect at all for you...
 

AlanLC

Well-Known Member
Member
Joined
Aug 18, 2014
Messages
413
Trophies
0
Age
45
XP
2,595
Country
Brazil
I tried with 63 00, but it did not work, only 63 02 no graphical glitch.


63 00 or 63 01
299E58A6-A157-4416-86C4-70798A0374FB.jpeg




63 02
75151003-4BCF-4714-B0E6-E8F38560E6B3.jpeg
 
Last edited by AlanLC,
  • Like
Reactions: 18Phoenix and k1r92

DarkAkuma

Well-Known Member
Member
Joined
Sep 20, 2008
Messages
412
Trophies
1
XP
2,459
Country
United States
Hmm. Well, Falo didn't post code related to that value. So maybe its not quite what he thought. The fact that that glitch is happening in the middle of the screen, the same spot where SMK divides the screen in 2 player mode, is interesting. That value is only used with SMK officially. So maybe its something that hacks the screen redraw. Like a optimization for netplay.
 

18Phoenix

Well-Known Member
OP
Member
Joined
Nov 21, 2005
Messages
766
Trophies
1
XP
2,298
Country
Germany
I tried with 63 00, but it did not work, only 63 02 no graphical glitch.
Hi, Alan. Have you deactivate the backroundwallpaper ? Which value is it in the sysmain.scn ?
But it doesn't bother anyway, on the contrary, it looks better with.


--------------------- MERGED ---------------------------


I've checked some hacked roms, some run, some don't.
Strange is that <The Legend of Zelda - Parallel Worlds> doesn't start, but the German version does and works fine.
(Sadly <The Legend of Zelda - Parallel Remodel> doesn't work at all.)
So what did the original English "source" version make different that it doesn't start?
 
Last edited by 18Phoenix,

AlanLC

Well-Known Member
Member
Joined
Aug 18, 2014
Messages
413
Trophies
0
Age
45
XP
2,595
Country
Brazil
Hi, Alan. Have you deactivate the backroundwallpaper ? Which value is it in the sysmain.scn ?
But it doesn't bother anyway, on the contrary, it looks better with.

bootapp/resoucers/sprites/colorhalftone.png
I erase the gradient in Photoshop, making it transparent.
 
  • Like
Reactions: 18Phoenix

RadMcFist

Well-Known Member
Member
Joined
Sep 16, 2019
Messages
114
Trophies
0
Age
39
XP
698
Country
United States
Why I'm not including the footer at the end of the file with that one comes from that fact that the Switchs .sfrom footer heavily draws from header2 of the previous .sfrom format. That header2 was technically often at the end of the file, but not always. In particular with SFA2 it was in the middle of the file. The decompresses graphics data was at the end of the file. So it makes sense to adapt that setup to the new .sfrom format when there's no direct evidence to show a change. I also suspect that the emulator searches for the footer by either the "47 02 00 00", "43 61 6E 31" (Can1), or both. Not just assumes it's at the end of the file. And from that position may determine the ROMs size based off the start of the footer to the beginning of the file.

I can try putting the footer at the end of the file. The 0x44 value can point to the location of the graphics data, so it can find it either way as long as the footer is located by the emu. Maybe it will calculate the ROM size if needed based off the start of the graphics data when supplied.

SFA2 Test 5
SFA2 Test 6

Test 5 is just using the SMK footer move to the end. There's a header 3 that points to the graphics data start location, but that header3 is itself unreferenced in the footer of course since SMKs footer does use that value.

Test 6 is like the 3rd test patch, using my best conclusion for a proper footer. Just the footer is moved to the end, and its value 0x44 points to header3.
OK! Thanks for the explanation and the patience, I just like to try to make some sense of what I'm doing and at least try to learn something. In any case, it's another failure: I tried both patches and in both cases the game failed to load.

By the way, you don't have to hold back on the tests on my behalf. I can run as many as you want, I can have a whole "DarkAkuma Tests" lclassics database testing out any changes to any games that you want, it doesn't have to be only SFA2 By the way, if you're still testing this specific game only because I mentioned it that time and not because you want it to work, don't worry about it! I can do without it until it works eventually when you guys inevitably figure out everything eventually! In any case, I'm at your service and I can at least follow your instructions with a hex editor (and I'll try not to ask too many stupid questions).

Really, based on what RadMcFist has said, I'm surprised changing a value in the footer is showing any effect at all for you...
I tried it out myself and indeed it works. The graphic glitch wasn't as bad on my test as it was on his screenshots, just a couple of tiles and it repeated always on the same two tiles every time I got to that part of the background. It also definitely isn't limited to the middle of the screen: it moves with you and when you jump so it can be all over and is definitely not a Mario Kart split-screen specific thing. My guess is it fails to load those tiles correctly for some reason. Maybe AlanLC and I used different versions of the rom and that's why it was more extreme on his game than on mine (heck, I used an ages old rom I had lying around with an all caps .SMC extension so his rom was probably much better).

Edit:
I also took screenshots.

2019091807330700-05DC14F80A13996B94160CD375AFD506.jpg 2019091807332600-05DC14F80A13996B94160CD375AFD506.jpg

The first one is the glitch as it first appears. The second is of the second time the glitch appears (it repeats every time that those particular tiles show up on that specific mountain, it stops happening when those mountains stop showing on screen, so it's just those tiles at least on this part of the game, I didn't play further.) and you can clearly see it's on a different position on the screen (lower). I thought for sure I'd taken another one of the glitch way over Bugs head as he was falling later on that same stage, but apparently I didn't. I can take it lates if you wanna see it still.

These footer numbers are obviously there for some reason but form what I'm seeing and playing and testing, at least some of them that should have some effect on games you would think would require them to play correctly (Yoshi's Island, Star Fox 2, etc) don't really have any effect. For example, if I understood some of your posts correctly, you know for sure that the volume part of the footer is absolutely irrelevant because the volume is controlled by the lclassics file, not by the footer. I know you still have doubts, but I assure you that Star Fox 2 runs exactly like it should but with the Mario Kart footer (and probably other footers too, haven't tested), so you can at least be sure that the FX2 chip clock can't possible be on the footer, or if it is and the emulator doesn't find it it, well, doesn't give a crap and runs the game at max speed? I don't know if that's possible. Like I said before, tell me what numbers to change and I'll do it.

Just to confirm this, I just put MK's footer on Yoshi's Island, Star Fox 1 and Stunt Race and played all three for about 15 minutes each. They all play exactly the same as they do with their regular, official footer. I used the official roms too, not my own, just with another footer and another entry on the lclassics database (so different folder, name, any old signature (forgot which one I used at this point) and two images).

These are all games that I know my heart, having played them to exhaustion and to completeness (Star Fox was even my first non-Game Boy game) on real hardware and on several emulators over the years (where they either ran like shit or just "OK" but not well enough that anyone who knows them can't tell the difference.) But on top of that, I don't have to rely on that old a memory (or common sense or just basic knowledge of how the snes works), I just have to launch these games with the official footer and with the mario kart footer one after the other and compare that. Hell, next time a friends come over with his Switch, I can launch the same game with the two different footers right next to each other. And it's not just me, anyone with a hacked Switch and a hex editor can do this.

My point is that whatever makes these games run correctly is definitely not on their footer, unless it's also on mario kart's footer (or possibly every other footer, I'll test that later), and it obviously isn't. In the end, you can believe me or doubt what I'm seeing, I understand, but it's not only that they run just like they do officially but that they run AT ALL with a footer that shouldn't be making any sense to the emulator. My guess is that some stuff on the footer matters, some obviously doesn't and I know that sounds stupid and hard to believe, but that's what I'm seeing and playing. I wish I could show you, man, it's such a shame that you can't test these out on the Switch.
 
Last edited by RadMcFist,
  • Like
Reactions: 18Phoenix

DarkAkuma

Well-Known Member
Member
Joined
Sep 20, 2008
Messages
412
Trophies
1
XP
2,459
Country
United States
By the way, you don't have to hold back on the tests on my behalf. I can run as many as you want, I can have a whole "DarkAkuma Tests" lclassics database testing out any changes to any games that you want, it doesn't have to be only SFA2 By the way, if you're still testing this specific game only because I mentioned it that time and not because you want it to work, don't worry about it! I can do without it until it works eventually when you guys inevitably figure out everything eventually! In any case, I'm at your service and I can at least follow your instructions with a hex editor (and I'll try not to ask too many stupid questions).

I haven't been particularly holding back, just focused. SFA2 was a good test for now because it has the most telling binary result. Work, or doesn't. It also allows me to know if I'm properly grasping the footer format when I'm having to create new data entries and adjust their values. And personally... I got started on the whole .sfrom thing with SNESC thanks to SFA2, and more specifically Star Ocean. From the very beginning it was my goal to get Star Ocean running on SNESC canoe, and I knew the path to that was through SFA2. But that quest, everything I figured out, preset ids, patches, header bytes, etc, all came about as a result to the point that I eventually had to make use of all that regardless of SO/SFA2.

It's kind of a goal now for switch, but mostly I just want to follow through with my previous finding and get the switch format figured out asap. When I worked on the SNESC stuff, I quickly realized that 99% of it could have been figured out MANY years earlier with WiiU/3DS. But no one did, and as a result the injection modding stuff is not as effective as it should be.

I could come up with ideas for other tests. But testing them will be less conclusive. I'd imagine many times the game will boot, regardless of the settings. There will just be small differences at unknown points in the game. For example, most games boot on the SNESC using preset id 0x0000. Even if they have an official one. But that doesn't mean they run perfectly. More specific examples would be like SoM. On SNESC it will boot with 0x0000, but it wont work optimally because the menus will be blurry due to not using higher resolution mode. If you use the proper ID and VC patch though, it will boot and look crisp.

These footer numbers are obviously there for some reason but form what I'm seeing and playing and testing, at least some of them that should have some effect on games you would think would require them to play correctly (Yoshi's Island, Star Fox 2, etc) don't really have any effect. For example, if I understood some of your posts correctly, you know for sure that the volume part of the footer is absolutely irrelevant because the volume is controlled by the lclassics file, not by the footer. I know you still have doubts, but I assure you that Star Fox 2 runs exactly like it should but with the Mario Kart footer (and probably other footers too, haven't tested), so you can at least be sure that the FX2 chip clock can't possible be on the footer, or if it is and the emulator doesn't find it it, well, doesn't give a crap and runs the game at max speed? I don't know if that's possible. Like I said before, tell me what numbers to change and I'll do it.

If I was to test anything else right now, it would be to the goal of understanding what can/cant be changed in a stock footer. What makes the emulator say this footer is valid, and this footer is not. The fact that 63 01 can be changed and has an effect still puzzles me.

My best guess is that stock game footers are considered valid and identified as such by the emu based on their preset id. Doesn't seem like the preset id is doing much else right now, if its not even controlling if a special chip is used or not.

In fact, here are 2 more tests build off that idea. They both use Joe & Mac 2's footer/ID, but with a modification. I changed the use of instruction 50 to 44, and the value to the appropriate pointer. I chose this games footer to modify as it seemed closest to what should be a valid custom SFA2 footer. No need to change the length or anything. It's also only 1 of 2 with a > 2 byte instruction and of those 2 the instruction+value length matches at a total of 8 bytes.

SFA2 Test 7
SFA2 Test 8

The differences between the 2 patches are just where the footer is located. Middle or end of file.

My point is that whatever makes these games run correctly is definitely not on their footer, unless it's also on mario kart's footer (or possibly every other footer, I'll test that later), and it obviously isn't. In the end, you can believe me or doubt what I'm seeing, I understand, but it's not only that they run just like they do officially but that they run AT ALL with a footer that shouldn't be making any sense to the emulator. My guess is that some stuff on the footer matters, some obviously doesn't and I know that sounds stupid and hard to believe, but that's what I'm seeing and playing. I wish I could show you, man, it's such a shame that you can't test these out on the Switch.

As mentioned, games are known to "boot" regardless of preset id (the main component of the footer). Generally though, special chip games are an exception as the enabling of that games special chip is part of the games preset id. You could only use a special chip game with another ID if you used the special chip byte manually. And even then, ids from other special chip games were an exception as you would be trying to use 2 chips at the same time i guess.

The fact that special chip games boot with other ids at all, without the special chip byte set... is odd. There's some measure of auto detection in the emu code now. But the preset ids likely still exist for a reason. If changing the 63 01 instruction has an effect, it seems that the footers arent completely ignored. We just have to figure out what we can and cant change, and deduce why...

EDIT:

As for general other tests that could be done. I'll see how many I can come up with.

I'll just post the footers to test with each game, as it doesn't seem like anyone else is jumping in to test now.

Code:
Dungeon Master (E-NTSC)
47 02 00 00 BD 10 74 06 63 01 6A 38 70 02 0E 00 00 00 43 61 6E 31 // general boot test. if it does boot, are the graphics messed up? (it boots with a couple ids on SNESC, but graphics are messed up as DSP-3 is not emulated.)
47 02 00 00 3B 12 65 0C 74 06 70 01 55 02 00 00 3C 05 12 00 00 00 43 61 6E 31 // if the above does not boot, this is "optional" to try as the special chip does not seem needed. but if you do, try 65 02 (DSP-1), 65 05 (DSP-2), and maybe 65 0D (Not used before) at the least. beyond that its up to you. You can try up to 0F, but beyond 0C its just guessing that they added new chips to support.

Tales of Phantasia (J-NTSC, No translation patch applied)
47 02 00 00 BE 10 74 06 63 01 6A 38 70 02 0E 00 00 00 43 61 6E 31 // try 63 02, 63 03 too if it doesn't boot at first. this is to try and test ExHiROM support.

Secret of Mana (E-NTSC)
47 02 00 00 BD 10 74 06 63 01 6A 38 70 02 0E 00 00 00 43 61 6E 31 // will it boot? is the file select menu blurry and hard to read?
47 02 00 00 4A 12 68 03 74 06 70 04 0C 00 00 00 43 61 6E 31 // assuming the last one was hard to read, does this one fix the issue? is the screen resolution/framing any different?

Super Tennis (E-NTSC)
47 02 00 00 66 12 74 06 70 02 0A 00 00 00 43 61 6E 31 // this is just testing what happens when you set 74 down to 06 like every other game. Not expecting a noticeable difference. maybe try 00 or 01 too. even FF!

Super Mario World (E-NTSC)
47 02 00 00 11 10 76 0A 74 06 70 02 0C 00 00 00 43 61 6E 31 // this is a test of changing the volume byte. I made the volume really low. in terms of the SNESC volume byte, on the switch this game is normally at %145. This test is at %10.

Star Fox
47 02 00 00 3B 12 65 0C 74 06 70 01 55 02 00 00 4A 06 12 00 00 00 43 61 6E 31 // this is using Yoshi's Island's "clock speed" value. test is to see if it plays slower/faster, or things glitch out due to timing of the emulated chip.

Super Mario World 2: Yoshis Island
47 02 00 00 3D 12 65 0C 74 06 70 01 55 02 00 00 3C 05 12 00 00 00 43 61 6E 31 // same as above, but this is using Star Foxes "clock speed" value.

Super Mario Kart
47 02 00 00 BD 10 74 06 63 01 6A 38 70 01 0E 00 00 00 43 61 6E 31 // does the second controller no longer work?
 
Last edited by DarkAkuma,

gamji

Member
Newcomer
Joined
Sep 13, 2019
Messages
13
Trophies
0
Age
26
XP
129
Country
Colombia

68 is only present in Super Family Tennis. It's set to 03.

Skimmed the last couple pages. Are there still no solid guesses for 6AXX or 74XX yet?

thanks i was able to fix the game by adding this to the super mario world footer

new Footer: 12106803740670020C
 

RadMcFist

Well-Known Member
Member
Joined
Sep 16, 2019
Messages
114
Trophies
0
Age
39
XP
698
Country
United States
I'm super tired right now but just wanted to let you know that we have the first successful result! Star Fox does indeed run at a better frame rate with that new footer, so that value was indeed for the FX clock speed and it's one of the values that actually works.

I've been super busy today with work so was only able to run some of the tests this late. Here are the results so far:

Dungeon Master boots with the first footer but has severe graphical glitches once you get past the intro, like you said. Doesn't boot with the second footer.

Secret of Mana we already knew launches with the usual footer and yes, the hi-res menus look weird, as expected (I think me and 18Phoenix mentioned this before? Maybe not). The second footer doesn't boot. I noticed a bit late to run another test that the Preset ID on the second footer was 4A 12. Is that the Super Family Tennis footer? I think someone mentioned earlier on the thread that taking SFT from the Japanese app and putting it on the Western one didn't work (if this is true it would confirm even further that a Preset ID from a game not included officially cannot be used, even across regions) and that using a different footer made the menu graphics glitchy beyond the usual high resolution "blurriness". SFT is one the games I'm planning to try next so I'll see for myself and try some stuff out like using a different Preset ID with the rest of the footer intact. I of course tried Secret of Mana just like youtold me to but I'll try with BD 10 as well later.

There were no changes to the volume of Super Mario World or the second controller in Super Mario Kart. As you know, the volume is controlled on the NES and and now the SNES Switch apps by the lclassics file. There's an entry there for number of players but I'm pretty much 100% sure that's just for the details screen and doesn't really change how the game behaves since that's how it was on the NES app where I kept forgetting to change it in games like Contra or TMNT and they could still be played my 2 players no problem anyway. Maybe these values are just a left over from previous incarnations of the emulators? Or was left there for future proofing in case they decide to go back to the previous method later? Or maybe someone is lazy?

Like I said, Star Fox runs noticeably faster, enough to make the make the intro sequence end before the music can catch up and it's the same with the Corneria intro sequence (poor dude can barely get "Prepare for launch" before the arwings blast off). During the actual game it's a bit harder to notice, of course, but it's enough to throw off my muscle memory from knowing this game by heart and miss some timing and queues. The Switch's built in video recording is great for doing comparisons between the overclocked and standard versions, by the way. The credits sequence will probably run a hell of a lot faster and end way before the music does, the complete opposite of what happened in some emulators where the music would end up and there would still be half the development team left to mention! I'll probably end up adding this and the faster Gradius 3 to my final selection of games as something similar to the SP Versions of some games the NES app has (maybe 18Phoenix will do the same to his packs?). Stunt Race could also benefit from this, right?

I tried Yoshi as well but didn't really notice any difference even though I played the official version immediately after to compare. I'll have to play more though as I didn't spend much time with it now and in the first two stages there's nothing that should require the extra clock speed, only a few rotating sprites. Maybe I'll notice something once I get to a castle that has those 3D slabs dropping on Yoshi or one of the huge rotating boss sprites. If there's really a change in clock speed, that will surely trigger noticeable issues. I'll at least beat a couple of worlds and I'm picky about how this game runs, I hated how it played on the otherwise good snes9x version for Wii when everyone else was saying it ran perfectly fine, so I'm sure I'll find something if there's something to be found.

Tested a few versions of Tales of Phantasia (clean, no translation) and they all booted to a black screen, just like the expanded Trials of Mana rom does (and some other expanded rom that I mentioned before too, I should start taking notes). Same as Secret of Mana before, the Preset ID you used is BE 10. I figure that was probably intentional since it did load even if it didn't work (a "wrong" Preset IDs means the game doesn't boot, from what I've seen).

I still have to test Super Tennis (but the roms are ready) and the new SFA2 patches. I had to finish some work today and didn't have time for anything else and testing Super Tennis will take a bit of time since I don't really know that game that much so I'll just play a few matches with my brother.

So that's it for this report! Throw more stuff at me if you think of anything, I'm finished with work for now. I'll also finish testing what's still pending and report back later.



I haven't been particularly holding back, just focused. SFA2 was a good test for now because it has the most telling binary result. Work, or doesn't. It also allows me to know if I'm properly grasping the footer format when I'm having to create new data entries and adjust their values. And personally... I got started on the whole .sfrom thing with SNESC thanks to SFA2, and more specifically Star Ocean. From the very beginning it was my goal to get Star Ocean running on SNESC canoe, and I knew the path to that was through SFA2. But that quest, everything I figured out, preset ids, patches, header bytes, etc, all came about as a result to the point that I eventually had to make use of all that regardless of SO/SFA2.

It's kind of a goal now for switch, but mostly I just want to follow through with my previous finding and get the switch format figured out asap. When I worked on the SNESC stuff, I quickly realized that 99% of it could have been figured out MANY years earlier with WiiU/3DS. But no one did, and as a result the injection modding stuff is not as effective as it should be.
Oh, man, I was gonna mention in the post you were replying to that one great possible off-shoot of getting SFA2 working is getting Star Ocean to work as well! It's a game I'd also love to see working. I've said it before and I'll say it again, it's a real shame that you can't do these test yourself. I'm sure you'd get there much faster without having to rely on our inexperienced help. In any case though, count on me to try my best to help as long as you're willing!

I could come up with ideas for other tests. But testing them will be less conclusive. I'd imagine many times the game will boot, regardless of the settings. There will just be small differences at unknown points in the game. For example, most games boot on the SNESC using preset id 0x0000. Even if they have an official one. But that doesn't mean they run perfectly. More specific examples would be like SoM. On SNESC it will boot with 0x0000, but it wont work optimally because the menus will be blurry due to not using higher resolution mode. If you use the proper ID and VC patch though, it will boot and look crisp.

If I was to test anything else right now, it would be to the goal of understanding what can/cant be changed in a stock footer. What makes the emulator say this footer is valid, and this footer is not. The fact that 63 01 can be changed and has an effect still puzzles me.

My best guess is that stock game footers are considered valid and identified as such by the emu based on their preset id. Doesn't seem like the preset id is doing much else right now, if its not even controlling if a special chip is used or not.
As mentioned, games are known to "boot" regardless of preset id (the main component of the footer). Generally though, special chip games are an exception as the enabling of that games special chip is part of the games preset id. You could only use a special chip game with another ID if you used the special chip byte manually. And even then, ids from other special chip games were an exception as you would be trying to use 2 chips at the same time i guess.

The fact that special chip games boot with other ids at all, without the special chip byte set... is odd. There's some measure of auto detection in the emu code now. But the preset ids likely still exist for a reason. If changing the 63 01 instruction has an effect, it seems that the footers arent completely ignored. We just have to figure out what we can and cant change, and deduce why...
Yes! That's what I think as well and have been trying to tell you. For one, you can't boot a game without using the ID of an already included game, so using 0x0000 like you say works on SNESC would definitely not work here. Also, games, even the more complex ones with special chips, work correctly even with the wrong Preset ID (would Star Fox 2 even boot with the Preset ID of Mario Kart on the SNESC? I've got the SA-1 version of Gradius 3 running with Mario Kart's footer without slow down even on the crazy stupid bubble stage). So knowing that, it's probable that something else changed as well. Hell, it's possible that they exist now only because NERD already had the roms organized like that in folders and were too lazy to change their storage system and footers are only a label now.

In fact, here are 2 more tests build off that idea. They both use Joe & Mac 2's footer/ID, but with a modification. I changed the use of instruction 50 to 44, and the value to the appropriate pointer. I chose this games footer to modify as it seemed closest to what should be a valid custom SFA2 footer. No need to change the length or anything. It's also only 1 of 2 with a > 2 byte instruction and of those 2 the instruction+value length matches at a total of 8 bytes.

SFA2 Test 7
SFA2 Test 8

The differences between the 2 patches are just where the footer is located. Middle or end of file.
Ah crap, I forgot about these two patches when preparing the roms for the other tests. I'll definitely try them later.

Also, remember that unlike with the SNESC, this app will be updated with more games (possibly as soon as next month) so there's bound to be something new to learn with each update. Hopefully they add a game that can teach us something about how this whole thing works. Sadly, the really useful ones like SFA2, Secret of Mana (for the hi-res thing, although Super Family Tennis is already out), etc are likely to never come because Capcom and Square Enix have their own collections with these games on Switch. The SFA2 on Street Fighter Collection is not the SNES version, but it's still a slim chance. But Act Raiser (and Soul Blazer too, I think?) was on Virtual Console so maybe that will come in an update and we can fix the audio for the other Quintet games.

Edit:
thanks i was able to fix the game by adding this to the super mario world footer

new Footer: 12106803740670020C
Wait, did that fix the hi-res mode looking wrong too or just the glitchy looking stuff?
 
Last edited by RadMcFist,
  • Like
Reactions: k1r92 and 18Phoenix

DarkAkuma

Well-Known Member
Member
Joined
Sep 20, 2008
Messages
412
Trophies
1
XP
2,459
Country
United States

FYI, all of these footers are either untouched stock game footers, or slightly adjust stock game footers. I didn't change preset ID's as my current theory is that stock game ID's make the footers valid. I also chose footers based on length and included values so any edit id make was minimal.

I'll assume that Dungeon Master look as it did with my SNESC tests, with the SMK footer. That probably means that DSP-3 support wasn't stuck in. DM not booting with the modified Star Fox footer probably just means that ID requires that specific chip byte value set.

ToP not booting probably means that no work has been done on ExHiROM compatability. Or at the very least there's more to the 0x63 parameter than id think, if it is indeed for ROM mapping.

SoM. Sorry, I haven't read all the replies in this post. Yea. thats Super Family Tennis's footer. I think the 0x68 param in that footer effect usage of hi res mode, and over scan framing issues. Hmm. The fact that it doesnt boot with that footer, but does boot with SMK's could be down to the ROM Map param. This will be a bit of a frankenfooter, but you can try this...

Code:
47 02 00 00 BD 10 68 03 74 06 63 01 6A 38 70 02 10 00 00 00 43 61 6E 31 // I chose to expand this SMK footer to fit in the param, rather than replace something. consider this a test to see if expanding the footer size is safe too...

SMW. I just I'm not surprize the volume byte doesn't work. It didn't on SNESC either. But at least there I understood why it still existed. Not as such on switch where they created a new footer format and param just for volume, and it doesnt work...

SMK. I am surprised that SMK's second controller still worked. The byte can easily be mistake for supported player count, but its counterpart on the SNES was for enabling detection of other controllers. Likely a performance saving thing of skipping checking a second controller for possible input each frame. The player count in the titlesdb id figure is like the one in the SNES's .desktop file, and is more for menu information.

Star Fox. So it is Super FX clock speed. I looked into the chips stats, and they just didn't quite add up. I'd have expected a value compatible to 10.5 or 21 if it was such, but the decimal values for those hex shorts are 1340 and 1610. They both games should technically run at the same speed too, so I don't see the point in different values. I'm guessing these values are arbitrary, and just dialed in based on the emulators performance to since the emulated SuperFX chip up with the emulated SNES system.

Yoshi's Island. Yea. The chip isnt used i a lot of normal gameplay. It's used for a lot of warping and stretching effects. So you may have to play into the game a little. I'd expect the things it's used on to be slower that normal with that modified footer.

Oh, man, I was gonna mention in the post you were replying to that one great possible off-shoot of getting SFA2 working is getting Star Ocean to work as well! It's a game I'd also love to see working. I've said it before and I'll say it again, it's a real shame that you can't do these test yourself. I'm sure you'd get there much faster without having to rely on our inexperienced help. In any case though, count on me to try my best to help as long as you're willing!

Well, you will be in luck if we can get SFA2 working, because the major work for SO is stuff I got done over a couple months last year. Getting the SNESC, or SNES Online to boot SO is just one task. Getting it to look and play well was a project in itself. I had to develop a patch of around 30,000 ROM edits. Since the work on that patch is done, it will be as easy for me to port it over to the switch .sfrom format as SFA2 ends up being.

Yes! That's what I think as well and have been trying to tell you. For one, you can't boot a game without using the ID of an already included game, so using 0x0000 like you say works on SNESC would definitely not work here. Also, games, even the more complex ones with special chips, work correctly even with the wrong Preset ID (would Star Fox 2 even boot with the Preset ID of Mario Kart on the SNESC? I've got the SA-1 version of Gradius 3 running with Mario Kart's footer without slow down even on the crazy stupid bubble stage). So knowing that, it's probable that something else changed as well. Hell, it's possible that they exist now only because NERD already had the roms organized like that in folders and were too lazy to change their storage system and footers are only a label now.

I'm what we refer to as a "purist". While in the SNESC community it means something different, I don't care for using 0x0000 (at least with games that have an official ID). It's not an official ID. It's basically a fallback. I mention it because, as I said, most games booted with it in some form or another. Point being that a lot of games booted and "seemed" to play fine, regardless of what ID you used. But on closer inspection issues would be found if a game wasn't using a more optimal, or its correct id. So even if a game "boots" with SMK's ID, i'd sill like to find a way to make non-stock game preset IDs work... it would be better in the long run.
 
  • Like
Reactions: 18Phoenix

18Phoenix

Well-Known Member
OP
Member
Joined
Nov 21, 2005
Messages
766
Trophies
1
XP
2,298
Country
Germany
thanks i was able to fix the game by adding this to the super mario world footer

new Footer: 12106803740670020C

OMG - wonderfull, thanks for discovering, man.

I used the Mario Kart footer as always and changed these digits to 6803 in there.
Smash Tennis works great.
Secret of Mana menus are no more blurry using the same change !!!
HURRA :grog:

Which other games use highres ?


--------------------- MERGED ---------------------------


i got trails of mana and dragon quest 3 working with the canoe patches
Cool. Which patches, haven't found one for Trials of Mana.
Can the normal Seiken Densetsu 3 (J) patch be used ?
 
Last edited by 18Phoenix,

18Phoenix

Well-Known Member
OP
Member
Joined
Nov 21, 2005
Messages
766
Trophies
1
XP
2,298
Country
Germany
OMG - whyyyyyyyyy :ohnoes:
Secret of Mana (U) works fine with 6803.
But the German version ,Secret of Mana (G), that works fine unchanged, doesn't even start with 6803.
Whyyyyyy :(

Can someone help please?
 
Last edited by 18Phoenix,
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
    Xdqwerty @ Xdqwerty: roms wont boot with wood r4menu