Re: SNES Classic: What's left? What's next?

Saturday, November 28, 2020

Some time last year I wrote a post documenting the things I had still not figured out with the SNESClassic, .sfrom format and Preset ID list. Ever since then, a few things have changed. So I figure why not make an update?

First off, in that last post, I concluded that I had "completed" my work. Whats changed with that?

Well, SNES Online. When I wrote that, SNES Online was not out yet, if it was even on my radar at all. It being released caused me to transfer my knowledge and efforts from SNESC over to that. As a result, I have dug more into it than I had with SNESC. Particularly, I now sift through and document de-compiled code. I do that now with the Switch mostly, but also the SNES and WiiU binaries a little as well. Naturally, having access to such information is going to yield more results.

First up.

Preset IDs 0x123E & 0x1244:

I naturally have to start with this one as it was the most immediate to learn upon the Switch Online release. I suspected they were for Stunt Race FX/Wild Trax... and they were!

h2_specialChip, aka byte 0x12:

With this I was completely uncertain why there were 6 SA-1 values, and what those values specifically mean. Honestly, I'm still not 100% certain, but poking through the code did extra confirm that they are all in fact SA-1 related.

Internally, the SNESC canoe used SA-1 (3) for SMRPG and Marvelous, and SA-1 (6) for the Kirby games. The other 4 are unused. This alone doesn't paint a perfect picture of what these options do

Later on as I de-compiled the WiiU binary I learned its debug code refers to it as "Limit" with "---[SA1,Limit=%d]---\n".

Of note, on Switch Marvelous instead uses SA-1 (6) for some reason. No clue...

Kyūyaku Megami Tensei: Megami Tensei I・II:

Well, this was the title of the section in the last post. But this one takes a bit of a turn and related back to something I never covered in the original h2_specialChip section.

I pegged 0x1115 for this ID as, this ID was a odd one. In de-compiled code I poorly read years ago it was often shown along side special chip games. And the only remotely special game I had up for consideration in this range was this game. I figured it was "special" as it was 2 games in 1, and I didn't look into it further. I was wrong.

When I first started looking at my own de-compiling of the SNESC canoe, I noticed something odd. This ID was referenced along side a h2_specialChip value that was previously unknown or simply guessed at. It was also along side 2 other IDs... for Megaman X E-NTSC and J-NTSC. Yep... This ID belongs to Megaman X E-PAL!

"But why? Thats not a special chip game. Its not like X2 and X3 which use Cx4!" you say. That's correct. MMX1 is not a special chip game. But it is special in its own way.

MMX has copy protection built in as a way to combat backup devices back in the day. To emulate this game properly and work around that, Nintendo had to treat this game special and map it differently. Ultimately, that's what being marked as a special chip game generally does in these emus. Tells the emu to map it a certain way.

So with this MMX E-PAL was brought back to the list and confirmed!

Kyūyaku Megami Tensei: Megami Tensei I・II... I just bumped it around, but I'm still not certain where it goes.

h2_unknown3 & 4, aka bytes 0x1B-0x1E & 0x1F-0x22:

I havn't learned a ton about these... but I did learn something thanks to de-compiling the WiiU binary.

There's a reference to the word "key" I associated with a reference to the first of the 2, then there's also "wiiu_para" and "maxspeed".

From this, my conclusion is that the first value is more of a platform ID or sorts. 0/1 = WiiU, 2/3 = 3DS. So in the 3DS code it would probably be called "3ds_para".

Max speed was probably something meant for the speed of the emulator itself, but went unused. Or its use was removed in later revisions. I havn't tested a ton with earlier revisions.

While I'm disappointed there wasn't more to do with these to some effect, I'm happy I now know what I do, or at least what I suspect now, and just moved on. They really aren't all that important.

Finally...

Super Mario Allstars Preset IDs:

and for that matter...

PresetIDs 0x10E7-0x10E8:

It kind of spoils it right there putting those 2 together, but that's it!

I suspected SMAS to be 0x1124-0x1126. And I suspected 0x10E7/0x10E8 to be for Super Bomberman 3 or Populus. There was a smaller suspicion of those IDs being for that game, but it was less likely to me at its 2 spaces for 3 games.

This was learned simply from a recent Switch SNES Online update that added SMAS to the roster.

But wait, there's more!

Noticeably absent is SMAS E-PAL as 0x10E7 = E-NTSC, and 0x10E8 = J-NTSC. Nintendo does not release E-PAL games anymore unless that is the only English version. Otherwise, they release the 60hz E-NTSC version in its place.

But fear not! I was able to verify the ID for the E-PAL version via the code. It was a bit confusing, but in the end its... 0x1124!

This ID has cropped up a lot in code examinations as being related to this and that. It was what I coincidentally pegged for the E-NSTC version of SMAS too. But in the end its the E-PAL version.

Why? Its an odd placing, but its not completely inconsistent with how some 3rd region versions of games have been done. Final Fight 2 J-NTSC and Street Fighter Zero 2 for example are in a odd completely different place then their other counterparts. Even MMX2 has some weirdness like this, but to a lesser degree.

I'm very happy with this one, as it's not often I get to verify a ID completely from code. It's not as simple as spelling it out for me, and its all context and deduction based. It doesn't say its SMAS E-PAL in the code... its just, there nothing else that would make sense. In fact, it closely relates to a thing I notice with the Switch secretly officially supporting some PAL games without my Full Unlock hack being necessary.

...

I thought I published this post a couple months ago, but guess I didn't. So I'll do it now and give a heads up at my next post.

I've been working on the PCM audio format stuff again. Where I last left off, I threw in the towel when working on my own conversion program as I concluded that both the encoding and de-coding processes are lossy, and I could never make the program able to restore the audio to the ROM with 100% byte accuracy. I also had a couple road blocks with understanding some aspect of the format to allow my code to make quality PCM patching/data of its own to 100% match the official patches/data.

Now, some of those things have changed...