https://docs.google.com/spreadsheet...V5cVswYlnsdKxn9xoIW2Y/htmlview#gid=2014317767
I found most of my patches here, sadly theres no a patch for trails of mana
Homebrew Discussion SNES Online - Mod Discussion
- Thread starter 18Phoenix
- Start date
- Views 116,764
- Replies 459
- Likes 17
- Status
https://docs.google.com/spreadsheet...V5cVswYlnsdKxn9xoIW2Y/htmlview#gid=2014317767
I found most of my patches here, sadly theres no a patch for trails of mana
That's cool! DarkAkuma was doing the same thing basically yesterday but we made a simple mistake. Did you get the official Trials of Mana rom from Collection of Mana to boot or was it the old rom? I think the older version boots, although I haven't tried it, but the new official version doesn't. It would be great if it was the new one. Cool about DQ3 as well! DarkAkuma mentioned there as a patch for that one before but I've been too busy to try it myself. Awesome that it works!
I'll reply to the rest of your post later, I just woke up. Don't worry about it, I'm not even sure we mentioned it. Did you gamji's post just now? He basically used the same footer you gave me before but with the Mario Kart Preset ID instead of SFT's and it worked. I was going to try that too once I got the Super Famicom version of the app but I haven't found a way to get it yet. This proves what I mentioned earlier, that even if Super Family Tennis is in the Japanese app, its Preset ID won't work on the Western one, so your footer would have worked with SoM if I had noticed the Preset ID before. I'll try this new footer you're giving me later.
Yup! Indeed it is. Although some things work differently.
Last edited by RadMcFist,
I got the old one (fan traslaton) working but with the same problem as secret of mana, the switch version most likely wont work until someone makes a patch for canoe or when nintendo adds a extended rom to the app
also tales of phantasia is working with patches
Rudra no hiho is one of the better ones and it uses it all the time for text, unlike Secret of Mana and Trials of Mana or Super Family Tennis which is just for menus, but sadly the translated version doesn't work. Try the Japanese version anyway to see if it works (probably will).
--------------------- MERGED ---------------------------
OK, cool. I know about the new one, it's just that when you called it Trials of Mana it threw me off cause that's how I tend to think about the new one ^^u
Off the top of my head, Rudra no hiho is one of the better, most relevant ones that do and it uses it all the time for text, unlike Secret of Mana or Super Family Tennis which is just for menus, but sadly the translated version doesn't work. Try the Japanese version anyway to see if it works (probably will). The original Japanese version of Trials of Mana also used it for text, but I think the patch doesn't.
Yea. That basically tests what I was wanting to see with that last footer. He just jumped ahead, while I was taking it one natural step at a time. I didn't think about Japanese footers not working, but I have seen others using them successfully.
So I guess that is for resolution and overscan. Going back to Falo's code, I suspect field_0/field_4 involve target X/Y axis of the screen. Perhaps a %*00 stretch value. Something like...
Code:
switch(ResMode) // value of param 0x68
{
case 3: // Allow HiRes Mode, scale both X/Y to fit in target frame
settings->axis_x = 2;
settings->axis_y = 2;
settings->max_res = 512;
break;
case 2: // Allow HiRes Mode, scale by Y axis to fit in target frame
settings->axis_y = 2;
settings->max_res = settings->axis_x << 8;
break;
case 1: // Allow HiRes Mode, scale by X axis to fit in target frame
settings->axis_x = 2;
settings->max_res = 512;
break;
default: // Normal res, scale by X only.
settings->axis_x = 1;
settings->max_res = 256;
break;
}I suppose if you want to could try the different values. 68 01 and 68 02. Compare them to 68 03 and default. Maybe take screenshots if there's a distinct visible result.
I've been waiting a couple days on someone to test a theory that this parameter is present in the SNESC canoe/.sfrom format. Hope so! it will be really nice, and help solve a few issues!
Last edited by DarkAkuma,
OK, I'll try that out and take screenshots!
I played a bit more of Yoshi and there's nothing slower or out of the ordinary at all, even in the first castle with the 3D panels falling right next to huge rotating sprites with a bunch of other rotating buckets and coins falling. The boss of that castle is also that chubby dude who gets huuuuge and rotates and what not, so sprite scaling and rotation and all that and it still played exactly like it does with the official footer.
By the way, I can't download the latest SFA2 patches, 7 and 8. Can you check if something's wrong?
Hmm. So maybe the value is something like a clock speed limiter. Like raising the limit for Star Fox sees it go nuts, but lowering it for Yoshi's sees it just play as normal. Probably hard for me to explain...
Or it just could be that Star Fox feeds the chip instructions and immediately processes them in game when returned, while Yoshis uses the calculations at specific times regardless of how fast the chip returns that data. It's hard to theorize that stuff for me. While I've been learning some SNES ASM and advanced ROM hacking/inter workings, I'm not that well verse yet.
...
The host seems to be having some trouble right now. Try these links instead.
SFA2 Test 7
SFA2 Test 8
EDIT:
I just had an idea about parameter 0x74. The one that's included in every game footer, and is always 0x06 except for with Super Tennis with which its 0x07. Falo said "that if its less than 0x06 it just loads a bunch of other preset ids".
My idea is that, perhaps this is why footers with non-stock game preset ids do not work. A test would be to try a preset id from my list that isnt a stock switch game, and that you know doesn't boot with the proper id. The idea being that those "other preset ids" are the proper id's, and being 0x06 and over forces them to be ignored (for whatever reason).
Code:
47 02 00 00 XX XX 70 02 08 00 00 00 43 61 6E 31 // 0x74 param completely removed
47 02 00 00 XX XX 74 05 70 02 0A 00 00 00 43 61 6E 31 // 0x74 param just lowered to under 0x06Just replace the XX XX with the reversed preset id from my list for whichever game you are testing.
Last edited by DarkAkuma,
https://www.dropbox.com/s/8bk9ouybmcfqgm5/sfa2-sfrom-test8.ips?dl=1
These didn't work ._.
Neither of these worked. Just to make sure I didn't do anything totally stupid even though I've done it correctly before, the ID for Final Fight is 0E 10, right?
Also, I finally had time to change the footer for Secret of Mana and Super Family Tennis to include the 68 03 thingamabob and, just like others have reported, they both indeed work correctly. I'll take screenshots next time so you can see, sorry I haven't done it so far. If my internet wasn't so horrible I would upload videos too but they aren't very convenient to spot performance issues unless it's a game like Star Fox because the Switch encodes videos at 30fps always so SNES or NES games end up looking like crap anyway (unless the performance is abysmal, of course).
Also, tried changing it to 68 01 and 68 02 in Secret of Mana but the game didn't even boot after that. Maybe these parameters are like the Preset ID and won't work unless one of the officia game already uses it? (I say that without even checking if we've already used parameters that are included in other games, sorry if it's stupid!)
Jep, but only for the jap original and the english translation.
Why isn't the patch working for the German translation ?
Shouldn't a patch change values that are the same in each version, even if they are translated ?
Translation means "only" changing the words and not the rest. And the patch should something but not the "words".
So why ? Is there a possibility to get a patch for the German version, too?
--------------------- MERGED ---------------------------
But you said you patched it to get it work.
I need them, what have you done, where did you find the Trails of Mana patch?
Dang. I take it you mean "didn't boot". Does SFA2 boot (with glitched graphics) with thestock Joe & Mac footer at all?
Code:
47 02 00 00 62 12 74 06 70 02 50 04 00 00 1E 00 00 00 12 00 00 00 43 61 6E 31 // Stock, unaltered Joe & Mac footerI know you've said it boots before, but that was probably with the SMK footer.
That's the correct ID, yes. Guess that idea is disproven. Shame. Would have made sense of some things.
Maybe. It is weird that SoM will boot and look good with 68 03, but not 01 or 02. From Falo's code those are valid param values and I just really can't believe they would effect the emu's ability to boot the game otherwise. Nintendo may have really tried to lock down this fork after I reverse engineered so much of it with the SNESC. Like they probably thought the preset id list was never going to be figured out because it wasn't for so long, simply because no one tried. Here I come along, figuring it all out even as far as to figure out that they were considering releasing Star Ocean on the SNESC, but likely abandoned it due to the bugs/limitations their SDA pointer format that I fixed, and suddenly people can use custom selected games with little to no issues unlike previous generations of injections.
If there are such protections though, hopefully we will figure out where and how to disable them at some point.
I had the same mistake, but the cause was one of the covers, see if any cover is not the wrong resolution.
As far as I read there exist no patches for the official Trail of Mana roms.
But there're patches for Seiken Densetsu 3 that changes the logo to Trails of Mana or Secret of Mana 2, even for translated roms, that's all.
--------------------- MERGED ---------------------------
Must be a totally wrong resolution. Because I often don't use the fixed resolution of 512x357 for covers.
Even very huge reso work but that's unwise because that just makes the size bigger for files and memory.
Last edited by 18Phoenix,
It was probably that terribab BOB game that caused this XD
Nope, SFA2 doesn't boot at all with Joe & Mac's stock footer. I'll try every stock footer later. And yes, earlier I meant that it didn't even boot, sorry. I'm pretty sure we've never gotten SFA2 to boot at all with any of the patches, by the way. Only unpatched and with the SMK footer (glitched, of course).
I played around with the modified Super Tennis versions for a while but I really couldn't see any difference at all and I tried all the values you told me to. Maybe that really is for online latency like you suspected?
Remind me if there was any tests left over from before like the Super Tennis one that I haven't done. I've had a couple very busy days with work but thankfully I'm free again and at your disposal if you come up with anything.
Maybe there's something in each game's sig file related to this? Remember that each game has a unique sig file and that we're just adding any randomly any of the stock files because the bypass method we're using still requires something to be there even if it doesn't read them. Maybe there's more to these sig files and they also authenticate the footer in some way and that's why we haven't been very successful modifying footers? Maybe if the sig files were better understood we could find a different way to bypass security that still read them. Or maybe this doesn't make any sense at all to someone who knows better than me xD
Well, at the very least they tried to make it a lot harder to hack than the NES Online app, that was just a mapper of throwing in a rom and covers with the correct names, editing the lclassics file and it would work well as long as it didn't have a mapper that wasn't used in one of the official games (which ironically means that the SNES Online app has a better compatibility since pretty much every NES game and their uncle used a mapper). Even the Famicom Disk System games worked on the Western version.
Interesting. So the basis of that test was flawed from the get-go.
I'd appreciate testing the stock footers with SFA2. At least footers from 4-6 games of varying differences. We know SMK's boots, and J&M's doesn't. Starfox/Stunt Race FX (either. basically the same footer), yoshis, SMW, BoF(? maybe, since its a capcom game...). The SuperFX games, maybe do an additional try with a modified footer to remove the special chip. Like:
Code:
47 02 00 00 3E 12 74 06 70 02 55 02 00 00 3C 05 10 00 00 00 43 61 6E 31Thats because I'm beginning to suspect the special chip byte will only support SuperFX, and will interfer with any other game and cause it to not boot.
The netplay guesses are purely guesses. Netplay is a new feature over the previous VCs and SNESC, so it makes sense to store data for it along side other data if needed.
But yea. I wouldn't really expect much of a difference I guess. It was probably set to 07 just because of a communication error among devs. "Set it to 6 or over", some time later "did he say over 6? or 6 or over? ill just set it to 7 to play it safe...".
I haven't messed with the sig file at all. I'm not an encryption guy, and I assume that's encrypted data. It may very well be that sig files validate certain preset ids/footers, even if a footer is used on more that one game. Kind of a dumb loophole, but certainly possible.
I've suspected the titledb interfers with things too, or at least may need more looking into. I think the volume and playcount entrys in the titlesdb either override the corosponding values from the footer, or just rendered them obsolete during development and they forgot/didnt bother to remove those footer params.
Further, I think that maybe the SDA graphics data might need a entry in the titlesdb. On the original Wii it was it's own file. JDCE.sda. Id be takign wild guesses at the JSON entry for supplying a path to that though, so I hope thats not the case.
...
We've tried a lot, with confusing results. I don't have many ideas to test atm. So I've been going back over previous posts and tests to kind of organize things so that a new test I didn't cover stands out. But I suppose the J&M footer not booting SFA2 at all kind of explains some of it. But really, if the SMK footer will boot it, just not if I supply SDA data, param 44 and header3, I doubt any other footer will either with modification.
Looking at my notes, its interesting that we did try the SMK footer with SDA data, but no modification to the footer. It didn't boot simply by adding adding the SDA data to the file... we never got to a test of modifying the footer to add in param 44. I'll focus my thought on that for now. Try to figure out how adding the SDA data in any form renders the sfrom unbootable... Like, what could it be expecting other than a titlesdb entry for the .sda? Hmm...
EDIT:
Test#9
Test#10
I tossed some rational around for either working, but in the end... this should just be tested. It's the SMK footer with param 44 added. #9 is footer in the mid, like it would be on WiiU/SNESC. #10 is footer at the end.
Theory for one of these working while the Tests 4 and 5 did not is, those did not include param 44, and with SDA data provided the emu has a hard time calculating the size of the game ROM. When param 44 is provided, it used its location to help calculate the rom size. Well, that at least applies to #10. #9 is a "meh. might as well have this tested too".
Last edited by DarkAkuma,
Hello, Falo
Thanks again first for your great infos. After you found out this so fast....
Do you know why the app causes a crash in the closing-app-procedure after reaching a special number of added games?
My have something to do with collecting data, that the app saves some infos while closing the app and gets too much?
Perhaps that could be avoided by deactivating something in the code to skip this crash-causing order?
I can't say for sure, but Switch games have a fixed Savegame size limit,
NES / SNES:
UserAccountSaveDataSize: 66060288 (63 MB)
UserAccountSaveDataJournalSize: 1048576 (1MB)
TemporaryStorageSize: 26214400 (25 MB)
Each game stores settings in the save and strange crash's appear if the savegame is too big.
This data is stored in the control.nacp, so you have to repack the nca to change values.
About the sig files, my patch only disables the verification -> files need to be there or else program fails, just place a empty 256 Byte file and it should work fine.
It's RSA-4096 + SHA256, these files don't contain any data, just the Signature to verify that the rom has the correct SHA-256 hash.
But there is a MD5, i don't know if that is used anywhere or just in a debug log.
NES / SNES:
UserAccountSaveDataSize: 66060288 (63 MB)
UserAccountSaveDataJournalSize: 1048576 (1MB)
TemporaryStorageSize: 26214400 (25 MB)
Each game stores settings in the save and strange crash's appear if the savegame is too big.
This data is stored in the control.nacp, so you have to repack the nca to change values.
About the sig files, my patch only disables the verification -> files need to be there or else program fails, just place a empty 256 Byte file and it should work fine.
It's RSA-4096 + SHA256, these files don't contain any data, just the Signature to verify that the rom has the correct SHA-256 hash.
But there is a MD5, i don't know if that is used anywhere or just in a debug log.
Code:
__int64 __fastcall sub_1CC70(MainStruct *this)
{
__int64 result; // x0
Rom *v3; // x8
__int64 v4; // x1
_QWORD *v5; // x0
result = sub_15B690(this->log + 128);
if ( !(_DWORD)result )
{
nullsub_8(&this->rom->info, &this->field_8);
result = LoadRom(this->rom);
if ( !(_DWORD)result )
{
result = LoadSettings(this->settings, &this->rom->info);
if ( !(_DWORD)result )
{
sub_1FB60(this->settings);
result = (*(__int64 (**)(void))(*(_QWORD *)this->settings->PresetSettings + 48LL))();
if ( !(_DWORD)result )
{
(*(void (**)(void))(*(_QWORD *)this->field_1F40 + 16LL))();
result = (unsigned int)this->field_1C;
if ( !(_DWORD)result )
{
if ( strlen((const char *)&this->field_20) == this->field_8 )
{
v3 = this->rom;
if ( v3->field_0 & 1 )
v4 = v3->field_10;
else
v4 = (__int64)&v3->field_1;
sub_15B860((__int64)(this->log + 128), v4);
v5 = this->log;
if ( *((_DWORD *)v5 + 13) == 1 )
{
DebugPrint(v5, "# RomMd5: ");
DebugPrint(this->log, (const char *)this->rom->RomMd5);
DebugPrint(this->log, "\n");
}
result = sub_1CDA0(this);
}
else
{
result = 85LL;
this->field_1C = 85;
}
}
}
}
}
}
return result;
}Very cool, I'll try this out, your explanation sounds absolutely logical.
Would be extremely awesome to get this fixed.
But in which nca is the control.nacp? I found it only in the CONTROL nca
together with the icons, but there seem to be nothing in with these numbers checking it with a HexEditor.
I only can extract the nca files by using NCA-NSP-XCI_to_LayeredFS, that works good for me.
Perhaps this prog doesn't extract all files. What must be the command line for using hactool to extract it?
Or is this file in another NCA? Haven't found it in the PROGRAM nca. MANUAL or META nca?
Sorry to bother you with that, but I'm a noob
Last edited by 18Phoenix,
- Status
Similar threads
-
Xdqwerty
what are you looking at? -
Pachee
-
Psionic Roshambo
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
Psionic Roshambo:
Loved the N64 and the PS1 at the time but Castlevania... PS1 hands down 10,000 times better. SoTN just perfect.
-
-
@
Psionic Roshambo:
Thankfully the N64 had a metric ton of other fantastic games. I do kind of hate the controller though, I didn't mind it at the time but over the years I have slowly learned to hate it.
-
-
-
-
@
Pachee:
CV64 was a good game given it was the first of it's kind, the first 3d project by kobe and was rushed with content cut because of deadlines.+1
-
-
-
-
-
