Homebrew Discussion SNES Online - Mod Discussion

[DarkAkuma]

No development at all in two days. Hope you guys haven't given up.

I haven't given up. I'm just waiting on someone to test Falos hack to enable all preset ids. Otherwise, I've taken understanding the switch .sfrom format as far as I can for now. There are still a few parameters in the switch footer to be figured out, but as evidence by the SDA pointer param, they probably need full access to all the ID's to be properly documented.

 

[18Phoenix]

Like i said already multiple times, all non-existing presetid's return a null-pointer right after loading the rom, it's pointless to try them.
They simply can't work... without another exefs patch:

.text:0000000000021458 E8 04 00 54                 B.HI            loc_214F4                                       ; Branch
to
1F 20 03 D5 NOP

this is the "Brawl Brothers" PresetId check, the first check in the function, just nop it and all preset id's should work, but of course i didn't test this and it will break online functions of the other snes games, but we can't play online anyway, so not much is lost.

Dear master Falo, could I ask you kindly again to tell us what to change like you did it last time in post #8
As a noob I don't understand your code, I'm sorry.

Change E8 04 00 54 to 1F 20 03 D5 ?
There is often E8 04 00 54.
loc = line of code ? Not found at 214F4.
Pleeeeease help

 

[DarkAkuma]

Dear master Falo, could I ask you kindly again to tell us what to change like you did it last time in post #8
As a noob I don't understand your code, I'm sorry.

Change E8 04 00 54 to 1F 20 03 D5 ?
There is often E8 04 00 54.
loc = line of code ? Not found at 214F4.
Pleeeeease help

I believe it would be:

-REMOVED-

Sorry for getting to this version of the hack a couple days late. I've been trying to get a disassembler and a decrypted main.bin set up the past few days on order better explore things, and provide that proper hex location.

 

[RadMcFist]

I believe it would be:

Go to 0x21CE0
Change "E8 04 00 54"
To "1F 20 03 D5"

Sorry for getting to this version of the hack a couple days late. I've been trying to get a disassembler and a decrypted main.bin set up the past few days on order better explore things, and provide that proper hex location.

Hey, take all the time you want, we would be stuck on day one if it wasn't for you and Falo's help!

In any case, I already did that and it didn't work. Same result as with the cheat file, no games load. Unless I did something wrong, which I'm pretty sure isn't the case, but it would be great if someone else could confirm. 18Phoenix, maybe?

 

[18Phoenix]

Hurra - SX OS v2.9 Beta is out now

ATTENTION - there seem to be problems for some updating the FW.

Better wait a bit more, 9.0.0 isn't needed now anyway, all games running.

 

[DarkAkuma]

I had a new thought, based on some findings/conclusions ive made from skimming over the code.

Could someone test SFA2, but generated with my SFROM Tool?

I know traditional .sfroms were tried, but I don't think SFA2 was specifically tested as such. My new thought is that the traditional .sfrom code that exists in the switch app ONLY supports SDD1 games.

 

[RadMcFist]

I had a new thought, based on some findings/conclusions ive made from skimming over the code.

Could someone test SFA2, but generated with my SFROM Tool?

I know traditional .sfroms were tried, but I don't think SFA2 was specifically tested as such. My new thought is that the traditional .sfrom code that exists in the switch app ONLY supports SDD1 games.

Without adding/changing any specific footer? I'm pretty sure I already tested that but I'll do it again.

 

[DarkAkuma]

Without adding/changing any specific footer? I'm pretty sure I already tested that but I'll do it again.

Yes. No changes. If traditional .sfrom support is to work, it wouldn't use a switch footer.

 

[RadMcFist]

Yes. No changes. If tradition .sfrom support is to work, it wouldnt use a switch footer.

Just tried it, didn't work. Tried it just as it comes out of your tool and just in case since it's pretty easy to do, also tried with the stock SMK footer and with the two other minimal footers you made that work with other games. None of them booted.

Should I have done something differently in your tool? I just opened the SFA2 rom, didn't change any parameters and saved it as an sfrom. I have all the patches downloaded also, if that makes any difference here.

Maybe we should try to boot an sfrom of a different game generated by your tool, a game that we already know boots?

 

[DarkAkuma]

Just tried it, didn't work. Tried it just as it comes out of your tool and just in case since it's pretty easy to do, also tried with the stock SMK footer and with the two other minimal footers you made that work with other games. None of them booted.

Should I have done something differently in your tool? I just opened the SFA2 rom, didn't change any parameters and saved it as an sfrom. I have all the patches downloaded also, if that makes any difference here.

Maybe we should try to boot an sfrom of a different game generated by your tool, a game that we already know boots?

I guess I forgot to mention, apply the VC/SDA patch. But yea, that should be it. Well, since you said you downloaded all patches, don't apply the PCM patch if you downloaded that. Though even if you did I'd think it would still boot.

The purpose of this test is because I think the code is set up to only allow traditional .sfroms to work if they are SDD1 games. I don't see a point in testing other games. I assume plenty of those were tested already. I'm not concerned with the switch footers at the moment. This a different test.

I'm not sure what, if anything, could be wrong about a .sfrom generated with my tool if my theory about the code is correct.

You could maybe try my Star Ocean patch too (no translation). Or Street Fighter Zero 2.

 

[AlanLC]

Based on Nes Online updates, is the emulator updated when an update that adds more ROMS is released? In the next SNES Online update will you have to use another cheat or figure out how to patch another one to disable signature check?

 

[RadMcFist]

I guess I forgot to mention, apply the VC/SDA patch. But yea, that should be it. Well, since you said you downloaded all patches, don't apply the PCM patch if you downloaded that. Though even if you did I'd think it would still boot.

The purpose of this test is because I think the code is set up to only allow traditional .sfroms to work if they are SDD1 games. I don't see a point in testing other games. I assume plenty of those were tested already. I'm not concerned with the switch footers at the moment. This a different test.

I'm not sure what, if anything, could be wrong about a .sfrom generated with my tool if my theory about the code is correct.

You could maybe try my Star Ocean patch too (no translation). Or Street Fighter Zero 2.

Tried everything, nothing worked. Not Zero 2, not Japanese Star Ocean.

Based on Nes Online updates, is the emulator updated when an update that adds more ROMS is released? In the next SNES Online update will you have to use another cheat or figure out how to patch another one to disable signature check?

If Nintendo wants to, yes, of course they can update anything and change everything and we'd have to figure everything out again. They've changed stuff with updates on the NES Online app, with at least two updates being big ones that were a pain in the ass to adjust to (I think there were two, can't remember well), but that one didn't have a sig check. I've a feeling the signature check thing will haunt us with every update and the kicker is that we will probably want to update for new features so we can't even ignore the updates.

 

[DarkAkuma]

Tried everything, nothing worked. Not Zero 2, not Japanese Star Ocean.

Dang. That would have really made sense too. I'll just have to keep at it to figure out with traditional .sfroms don't work. Best guess is, that the code found that branches to either newer or older sfrom support is a sort of vestigial code. It's not crossed in the normal execution, and instead for switch .sfrom support, other code is used.

 

[18Phoenix]

Like i said already multiple times, all non-existing presetid's return a null-pointer right after loading the rom, it's pointless to try them.
They simply can't work... without another exefs patch:

.text:0000000000021458 E8 04 00 54                 B.HI            loc_214F4                                       ; Branch
to
1F 20 03 D5 NOP

this is the "Brawl Brothers" PresetId check, the first check in the function, just nop it and all preset id's should work, but of course i didn't test this and it will break online functions of the other snes games, but we can't play online anyway, so not much is lost.

I believe it would be:

Go to 0x21CE0
Change "E8 04 00 54"
To "1F 20 03 D5"

Sorry for getting to this version of the hack a couple days late. I've been trying to get a disassembler and a decrypted main.bin set up the past few days on order better explore things, and provide that proper hex location.

NO game starts for me with the code changing above, only Brawl Brothers.
I used both code changings together. Or must the signature check be on again ?

 

[DarkAkuma]

NO game starts for me with the code changing above, only Brawl Brothers.
I used both code changings together. Or must the signature check be on again ?

Yea. Looking at the code myself now, I'm not sure I get the logic behind the premise of that hack working. It's supposed to be something like, skipping the first check in a function would somehow make other ids work. But the code does not seem structured for something like that to happen. Instead it looks more like changing the code to skip even checking the Brawl Brothers preset id at all and instead just forcing support for only Brawl Brothers by jumping strait into the code being gated behind the id check.,

I think the intent is to skip all the stock game preset id checks, but im not sure how that would make anything better. The entire function would return null, not having flipped any switches what-so-ever, and thus not enabling any preset ids to be compatible. But I don't completely understand the code yet, so I may be missing something. While the function is full of stock game id checks, and no other ids. Other ids do exists and are checked elsewhere in the code. So maybe its hoped that those checks are all that's needed.

I guess I can see a premise for it working, as it forces all ids to load at least some compatibility settings at all. But all games would be seen as brawl brothers and use the settings for only that game. The code for the other stock games shows clear differences in the settings those ids load, but with this hack those settings are ignored and replaced with brawl brothers' settings.

I'll look to see if I can find a decent place for a simple hack that keeps all stock games functional as intended, but allows other games to try and load with the settings of 1 stock game. The structure of the code is quite weird. I think its been obfuscated, as otherwise it seems like it was designed by a moron...

EDIT:

You can try this if you want. If i got it right, all stock games and their Preset IDs should work as normal. And every other Preset ID should work as if using Zelda ALttP's Preset ID. (Or if I got it wrong, then maybe either all stock games work except zelda and non-stock game ids still do not work.)

-REMOVED-

 

[AlanLC]

Looking forward to testing Mario 64, Banjo Kazooie and Star Fox with Widescreen patch in future Nintendo 64 Online

 

[18Phoenix]

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.

            public long UserAccountSaveDataSize; //0x3080
            public long UserAccountSaveDataJournalSize; //0x3088
            public long TemporaryStorageSize; //0x3168

8 Byte int64 values.

No, I doubled all 3 values, the app works fine, but it crashes again during closing software

View attachment 180248

Any other suggestion ?

Theme: closing-app-crash
Everyones new suggestions are welcome



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

Go to 0x22658
Change "28 06 00 54"
To "1F 20 03 D5"

At 0x22658 ??? Or how it's seen here a bit lower ?

 

[DarkAkuma]

At 0x22658 ??? Or how it's seen here a bit lower ?

Hmm. I'm not sure why our locations are different, but yea. That appears to be the right spot in your binary. 0x226AC. In the future if I post such hack locations, ill try to include the surrounding bytes to help mitigate such location difference confusion.

 

[18Phoenix]

Hmm. I'm not sure why our locations are different, but yea. That appears to be the right spot in your binary. 0x226AC. In the future if I post such hack locations, ill try to include the surrounding bytes to help mitigate such location difference confusion.

Ok, I'll test it, but later.
But very strange with the postion.
I didn't add something, just changed. If the lengh will be changed a warning is coming, so it shouldn't happen by mistake.

 

[DarkAkuma]

Ok, I'll test it, but later.
But very strange with the postion.
I didn't add something, just changed. If the lengh is be changed a warning is coming, so it shouldn't happen by mistake.

I have checked, and my decrypted main.elf binary has not been altered since it was generated. It's easy to miss hitting the insert key in HxD and switching between overwrite and insert mode. I could see accidentally Inserting a few bytes, but the difference seems to be about 84 bytes total, which is hard to believe would be unnoticed.

The location differences have me worried that a failed test may not be conclusive that the hack doesn't work, if the binary itself is corrupted.

EDIT:

I was going to get this privately tested first, but I'm not getting a response. So...

Upon digging through the code, I've noticed a minor thing. That a few more ID's than the known stock E-NTSC/J-NTSC game ID's, "should" work. Though all of these are just PAL versions of the stock games. So nothing REALLY interesting. It's just due to the way the code checks if a ID is valid game or not. It does so by a range check that often just happens to encompass the PAL ID(s).

While there's evidence that support for the different region versions of these games use the same code, meaning these new IDs should offer no more compatibility than their US/JAP counterparts. Well, IDs are checked elsewhere in the code, and generally done on a more specific basis. So these MAY offer some alternative/improved compatibility options. Maybe at the very least allow those PAL versions to play better.

47 02 00 00 CF 10 70 02 74 06 6A 38 0C 00 00 00 43 61 6E 31         // BRAWL BROTHERS E-PAL
47 02 00 00 1A 10 74 06 70 01 0A 00 00 00 43 61 6E 31               // F-ZERO E-PAL
47 02 00 00 5A 10 76 82 74 06 70 02 0C 00 00 00 43 61 6E 31         // Kirby's Dream Course E-PAL
47 02 00 00 C9 10 70 01 74 06 0A 00 00 00 43 61 6E 31               // SUPER E.D.F. EARTH DEFENSE FORCE E-PAL
47 02 00 00 05 10 76 28 74 06 70 01 0C 00 00 00 43 61 6E 31         // Super Ghouls'n Ghosts E-PAL
47 02 00 00 BF 10 74 06 63 01 6A 38 70 02 0E 00 00 00 43 61 6E 31   // Super Mario Kart E-PAL
47 02 00 00 42 10 74 06 70 01 0A 00 00 00 43 61 6E 31               // Super Metroid E-PAL
47 02 00 00 1C 10 76 82 74 06 70 01 0C 00 00 00 43 61 6E 31         // The Legend of Zelda: A Link to the Past D-PAL (German)
47 02 00 00 1E 10 76 82 74 06 70 01 0C 00 00 00 43 61 6E 31         // The Legend of Zelda: A Link to the Past F-PAL (French)
47 02 00 00 20 10 76 82 74 06 70 01 0C 00 00 00 43 61 6E 31         // The Legend of Zelda: A Link to the Past E-PAL

There are a few notable absences from this list though. Pilotwings E-PAL and Super Mario World E-PAL. Both games ID checks lacked the range to include them. I could maybe do a small hack to enable them, but as I'm waiting on a hack to be tested now, we can worry about that later.

There was one other curiosity in the code. While Japanese stock game ids are generally supported in the western version of the app, Hoshi no Kirby 3 J-NTSC's ID (0x10A3) was not. That ID must be specifically enabled on the Japanese version of the app, likely in place of the US version. Pilotwings J-NTSC's ID may be unsupported on the Western app too... the code is weird, and not 100% clear...

I'd recommend testing these footers with the US version of the ROM first, just to know the ID works at all. Assuming it does boot, then try and see if the PAL version works. But I wouldn't expect the frame rate/speed to be proper. The FPS byte has been dropped completely in the new version of the .sfrom format, while in the SNESC version it just didn't effect anything. I doubt Nintendo added a special check for PAL games to adjust the frame rate speed for these IDs, as I do't think they would spend time on PAL ROMs anyone as they now tend to release the US 60hz version of the ROM in PAL regions instead.