Moving Forward with my SNES projects

Monday, January 11, 2021

Now that some time has passed, and things have settled after dropping my Switch projects, it's time to think about whats next.

As I look around at my projects and notes, and consider what its the most interesting/fun thing to work on. Well, I'm a bit all over the place for the moment. I immediately dove into past projects I found enjoyment in purely for myself, those being the Game Code list and SFROM Tool. These I enjoyed because the work was useful to others, but there was no demand for them that made me feel pressed. I could work on things at my own pace, and take the time to have fun doing so. I find figuring out the SFROM format details interesting in a similar fashion to solving puzzles like sudokus. Reverse engineering for what I do is a lot of evaluating the data I know to fill in the blanks enough of that which I don't so after the process of elimination, what remains is clear.

There's not a lot left for work on the game code list. But still... I made some new conclusions. In my first days back working on this stuff I deduced that 0x111C belongs to Super Turriacan 2 E-PAL, and 0x1125 belongs to Power Instinct J-NTSC. I can't say I'm 100% certain, thus I cant label them as "verified". But for me the evidence is fairly strong. The short of it is, the de-compiled code suggests these.

As always, with this list seeing further progress, what remains ahead is going to be that much more difficult to solve. While it may look like more, there are about 12 remaining game codes that are valid to the emulators. 4 more that may or may not be valid, and at least 2 or more that are unused but probably reserved. On the other side, there are about 19 known games that should, or may have a spot on the list.

I can make some guesses based on available data. But for the moment I'm unable to work towards verifying anything more. At the most, as mentioned in my christmas post, maybe DQ 1+2 and 3 at some point.

But for now, 2 new ones to this level of confidence is nice to see!

Next I started working on some stuff that has continued to puzzle me from the start. Some unknown values in the .sfrom header formats.

While I have looked, I haven't put much effort into looking through the code to better understand these unknown values since I added disassembly to my tool belt. So I tried again. There are 2-4 values in header 2 (what I now call the Info Header), and 1-2 in header 1 (what I now call the File Header) that could use further understanding. Generally, I'd focus on the Info Header with this stuff, but this time I figured id put more attention on the File Header. This time too, I also dug out my disassembly of the WiiU code. As there was more to learn from it due to it containing debug strings.

In previous attempts I found reference to the term "key", and seemingly related to it "wiiu para" and "max speed". I cleaned things up and concluded now that key refers to something else. Key is the name of a value in the File Header that has always been 00 00 00 00 in any post v1.0.1 sfrom I have ever seem to the point that I thought it might just be unused space. There is another similar value right next to it, but it remained un-named. That value was what pointed to wiiu para and max speed.

My idea from here was that, I observed changes in the sfrom format between early versions to later versions on the WiiU. Changes with these values. So perhaps I needed to disassemble an earlier version of the emu. I did just that, and as a result. I found what I was looking for! The other File Header value is called "Manual". The relations are now, Manual->wiiu_para and Manual->maxspeed. Further, with cleaning up my understanding I was able to conclude that 8 bytes in the Info Header are in fact real values and not just padding. To go along with the above, Key->unknown1 and Key->unknown2.

When I think about it, key and manual are like headers of their own. Not part of header2. The fact that they have offsets pointing to them in header1 clearly suggest is. They may be placed there in a consistent spot, but they dont have to be.

In total, there are basically 5 headers:

• File
• Info
• Key
• Manual
• Patch

Before it was just seen as 2, and a 3rd pointless header being Patch. (patch is its official name too. Only File does not have an official name and had to be given one by me)

Anyway. Try as I might, I cant find names for the Key values, or strong enough code to allude to the purpose to give them names myself. The Key Header offset is processed in SNESC canoe, the Manual Header offset is not. On WiiU, both are parsed and stored. But only manual values seem clearly used in any way.

There wasn't much progress to make beyond that for now. So I moved on again.

As time was passing, things were not changing with the Switch community in any significant way like I was allowing for and hoping for. I truly did not want to cancel the projects, and remained open to coming back if change was sparked and I was proven wrong. That was not happening. And this was sinking in. These projects were now officially dead, even to me. It was time to abandon the last thread of hope for them.

So, looking at the time I spent on those projects, it would be a shame to see it as all a complete waste of time. Certainly there's something I can salvage from it all and take forward with me, right? And yea. Well, beyond becoming familiar with disassembly, there's a couple other things. I learned how to hack the emu and I learned some C#/WPF stuff for creating a app like CaVE with several aspects of the code I had not used before. This is stuff I can take forward!

Seeing things like this, I wanted to see if there are any SNESC canoe hacks that I can do that might be worth doing. I figured I'd start with something simple. Enabling 2:1 HiRes mode with other game codes. Basically, the most usable game code for other games to enable 2:1 is 0x1016. And that sucks as it causes weird gamma issues. What I came up with for the hack was, to enable ALL game codes to use 2:1. This is not the most proper of hacks. You don't need it enabled for all, just... something else. If you were to use the hack for other games that don't need 2:1 it would be a waste, if it even would be playable at all. But the way I see it, you would only use this hack specifically for those other games. So why not?

I changed some things around, and in the end. Bang. All codes 0x1000 and over enable 2:1 mode now. It was nice seeing games like SD3 not have weird gamma issues and requiring extra patching simply to fix what shouldn't be broken in the first place.

Next I tried 2:2 mode... but that did not have the same luck. At the very least, I can say it helped clarify some code for me. For now, I didn't want to press to hard. I didn't have a ton of ideas for hacks just yet, and figured I'd let them come organically.

About the next best hack idea I have right now... is almost more of a bug fix. It's not in high demand though. This would be to get the SDD1 chip byte functioning more like you would expect. As is, SDD1 support is broken up into 2 things. Disabling calls to the SDD1 chip, and processing "SDD1" pointers patched into the ROM. The 4 SDD1 game codes enable both of these. The SDD1 chip byte however only enables 1, the calls to the SDD1 chip. It does not enable checking the ROM for SDD1 pointers. This fix for this would be simple. Everything would function just as it does already, accept now other codes could use the SDD1 pointer format. This would not help for Star Ocean to boot on 3DS/WiiU (though I'm not working on those yet). In truth, it would only help with another small project I decided to work on.

Dungeon Master! This is an unsupported special chip game. I've been thinking of it for a next canoe hack after SO for a while. I figure that since the chip results in the same issue, graphics tiles being gated from loading behind the chip. Maybe the SDD1 patching format could be used with it. But even then, I can just boot it with Star Oceans ID. So I don't seem to need the SDD1 hack. But as I'm writing this, I'm now thinking otherwise. I'll move along for now before I talk about that part.

But yea. I dove hard into trying to understand the format/layout of the dungeon master rom. I spent a few days on it, and while I thought I was beginning to understand... I simply was not getting results.

In the end I was concluding that, if I was to do a hack... I should probably just do a non-sdd1 pointer hack instead. I suspect I could achieve the same result by just expanding the ROM from 1MB to as large as 3MB if needed, and create a resulting rom that may even boot on flash carts and such. Though, I don't know if such carts already support DSP2 and thus such a hack existing would be pointless outside of canoe.

I stopped making progress, so I moved on again.

Next, I worked on sfrom tool. Something was bugging me for a while... so I rewrote the entire SFROM parsing class. I felt it could be more streamlined, and designed better from the ground up to support 3DS. When I first made it, 3ds data bins were not on my mind. So support was kind of tacked on eventually. Now, with the new code the reading and writing of sfroms and data bins is all the same code. Just output differently based on selection.

Next, I had an idea for the game code input fields. I did mess with it at some recent time. I forget when. But I changed it to optionally show the old current game code format, and the new, proper format. Hex versus number. Going between the 2 formats will be optional for now, to help with a transition for some.

Now though, I had an idea to make the code selection a bit more casual friendly. The idea being that, why not allow users to select from a list of code ids clearly labeled with the game for that id? No need to reference an external list. I have all the info to support this already in the program. I just need to write some code to make it available where I need it. So I did that.

Its only supported for the new game code format, as I'll use that to help encourage the transition. But yea. It's nice and simple. Want to experiment with other games codes for some random game? Say, maybe you want to try SMKs? Just select "189 Super Mario Kart E-NTSC" and the code will be set to 189.

Next, I moved back to working on the header stuff. But was still struggling to make much progress. But I did add 3DS disassembly to my tool belt. Which may prove helpful at some point. At least, it disassembles more clearly than the wiiu emu, though sadly with less debug info...

Then finally, I moved onto DQ1&2+3. I finally got this wii emu disassembled, and the hope was to note a lot of settings to help deduce the game codes. That was... failing, but I haven't given up hope yet!

But I did make one interesting discovery. I found an internal list of games embedded in the code. One that reminded me a lot of a claimed "leaked" list from the 3ds years ago, that spread around a couple news sites. What is interesting about this list is, it listed un-released VC titles. Some of which were mentioned in that 3ds list, and more interesting to me... some of these unreleased games had product IDs assigned to them! Seeing as I used product IDs to unlock the game code list, I was very hopeful! But sadly, I'm not sure there's any clear direct info to help unlock the verifications of remain game codes from this. They may still prove helpful, but not easily.

I programmatically sifted through and dumped the list. I posted it in a tab over on the game code list. I don't understand everything about it. I just haven't dealt with the wii emu much before. But my current conclusion is, this is likely the closest counterpart to the game code list, for wii. On wii, games were instead indexed by their file names instead of a game code. The file names are often their product ID, but not always. When not, they are usually an amalgamation of their original SNES cart product id with a 3 character (generally number based) extension. I even found a few ROM with such file names embedded as hidden extras in Wii VC titles.

There are a few interesting games to note. I marked most such games with different colors. For example, Super Smash TV was never mentioned as a unreleased VC title before. Some known unreleased games even got product IDs assigned. Like Super Bomberman 3 being AO. I would have pegged SMAS a long time ago had I known about this list too...

This convinced me that I need to look into other Wii VC titles code. This list, while long and very near complete, does not list all known released SNES Wii VC titles. Proving that this was compiled before other games were added. So I needed to look through a later game. Kyūyaku Megami Tensei: Megami Tensei I・II seemed like a good choice. But it was the last remaining Wii title I needed to dump. So I tried again.. and found success! I now have VC and PCM patches for that too! You can find those pinned in the #nintendo-vc-cc-nso Discord channel for now.

But, looking through the code for that list... didn't have the results I expected. There's still a list in it, but it contains less info, and its seemingly very corrupt. Half gibberish, half words. Just enough to make out the names of many games, and a few rom file names is all. I tried MMX2 too, as its likely one of the last released titles. But its just as gibberish.

So I had to work with what I had. And the end result?

EVERY known unreleased game, other than PICROSS NP VOL.2-4 was in these lists. Meaning, that the 3DS "leak" list was complete BS! It was never a list for 3ds specific intended upcoming games. Those games consideration, or work on support existed before then, on the Wii. That 3ds list seems directly related to and based off this list, judging by the contents. Well, more so the general VC list instead of the one from DQ. Heck! Even Star Ocean is on the list from DQ, which blew my mind! This rewrites what I thought I knew about its timeline of support, and calls into question if it truly wont work on platforms before SNESC. I need to unlock understanding of the code more than ever!

I cant explain the general VC list just yet. Its very stripped down from the near complete list from DQ. I don't know why these games are on the list, and others not. But maybe time will tell.

For now, I just hope some of this info helps deduce the remaining game codes. At the very least, I now know that all the remaining known but un-assigned games are all valid to be considered everywhere in the remaining space.