SNES Online: Findings

Saturday, November 30, 2019

As you should be easily aware of, I've shifted my research over from SNES Classic to SNES Switch Online. I'm still interested in SNES Classic, there's just more to figure out and work on right now with the Switch.

After I released CaVE I started getting back to work on the Switch .sfrom footer format. I got the basics documented and supported in SFROM Tool. But there's several unused parameters that have not been figured out.

Looking in the code, you can generate a full list of the params by value. And you can figure out which ones use a single byte value, and which use multi bytes. For some params, I had the convenience of there being support for the familiar SNESC sfrom format headers, and I could tell when a value is shared between the 2 and figure out the purpose for the one in the NSO .sfrom format. This is how I figured out how to use param 44, and get SFA2 and Star Ocean supported.

After that though, I had other things to focus on, so progress stopped. Now though I've been back to work! And I've figured out a few more params!

First up, we have...

SNES Mouse support?

First brought to me by RadMcFist, as he randomly tried param 6D with a game that just so happened to have programming to return an error if you were using a "Special Input Device". He then tried Mario Paint and some shooting games, but didn't get results. Input just didn't work. I put that on the shelf and considered it just might be a byte for that. The Mouse and Super Scope.

Recently I was contacted by LuigiBlood in regards to some information to satisfy his curiosity and questions about canoe possibly supporting BSX, and the Mouse. I mentioned that param, and he went and tested it. But he found that input does in fact work... just not the cursor. It seems its a half finished emulation of the SNES Mouse. You would figure that the touchscreen would emulate the cursor if it was fully emulated. But it is not.

Later I was in another part of the code when I noticed a check to param 6Ds value. Along side it was a check to a odd Preset ID range. I mentioned it to LuigiBlood, and he promptly went on to test those IDs. And sure enough, those preset IDs also enabled mouse support!

Verdict from all this? Nintendo is, or was considering releasing mouse supporting games on the Switch service. Likely mainly Mario Paint, but Mario & Wario maybe too. At the very least, it looks like Mario & Wario was assigned a present ID for testing.

Epilepsy Protection

Next up, we have Param 61 and Param 41. I figured these were both related, and they are. I didn't notice at first with my testing, other than them just making things slow. But RadMcFist recognized their effect from his NES Online experience. They are Nintendos terrible Epilepsy Protection. On the NES Online these were labeled Armet Version and Armet Threshold, and were params in the titlesdb file. Now, for whatever reason, they are footer params. They seems to work exactly the same.

I guess, be thankful they didn't enable these! But in a future release of SFROM Tool, you can if you want...

Resolution Control

And next? We have param 72, and by extension, param 68.

In the code I knew param 72 was related to param 68. Param 68 was officially used with Super Family Tennis, and was shown to enable HiResMode. But that was it. I hadn't had param 72 tested, and there was not much data on params 68s options.

When I went and tested 72, I noticed it stretched the screen vertically. It was easy to conclude that this was a option to help deal with overscan issues. But I needed to put things into context, and be able to properly explain its purpose, values, and as well as param 68s proper purpose, value and relations. In code, for SFROM Tool.

So after discussing it a bit with LuigiBlood, we came to an agreement. Param 68 is Resolution Ratio, and param 72 is Resolution Height.

Res Ratio has 4 modes. 1:1 Low, 2:1 High, 1:2 Low, 2:2 High. The 1's and 2s are important because those are multipliers.

Res Height can be a value between 0 and 239. 0 is treated as 224.

The SNES's resolution mode is set to display as:

256 * Res Ratio (Left of colon) = Width
Res Height * Res Ratio (Right of colon) =  Height.

So considering the 2 standard heights, you have 8 standard resolution options.

• 256x224
• 512x224
• 256x448
• 512x448

• 256x239
• 512x239
• 256x478
• 512x478 

I like providing people the option to set their own values when I can, So in SFROM Tool you will be able to supply height values other then those 2. But if you use the stock values, that will be your options.

I wanted this figured out and properly displayed so that people could make better informed decisions on what values to use for a game. Not just do overkill with everything and use 512x448 / 512x478 with everything. In fact, very few games need those highest resolutions. For most games that have blurry text, 512x224 will suffice.

With that done... it was time to start tackling the difficult ones...

The Advanced Options

Params 6A, 53, 74, and 50 were all that were left (as far as I knew at the time). 50 seemed extremely difficult, so I didn't/don't want to focus on it yet. 74 also seemed confusing, and I didn't want to focus on it yet either. But I had to.

But first, I had to realize something. A mistake made early on by someone else that I just didn't question because I figured they knew more than me. Param 63.

Falo deemed that as a HiROM byte, as it was used with the only stock HiROM game. He even backed up that claim with saying that he found that in the code its checked, and then the code reads SNES ROM header data from the default Lo/Hi ROM addresses. This was never something I could find in the code myself. I just figured I was dumb and hadn't been able to find it yet.

In fact, what I did find in the code flys in the face of the need for a ROM Map byte altogether. It took Nintendo like 15 years... but they finally implemented an automatic header locating routine themselves. In fact, its a modified version of the technique byuu proposed years ago that's been more and more widely adopted. A scoring technique. In short, header scoring just checks data at both Lo and Hi ROM addresses, assigns a score value based on the data at those addresses falling into certain value ranges, and at the end chooses either Lo or Hi ROM based on which check scored better. Its a good technique, and in fact, I figured if Nintendo could finally do it, I could too for SFROM Tool!

Anyway... I was forced to start questioning that params purpose. I DID find reference to the param, just not in anything related to the SNES ROM header. Over the course of the following work I just had to conclude it was not a ROM Map value, and undo the code in SFROM Tool that treats it as such.

Dot Clock Speed part 1

Now back to the other params. I first tried working on Param 53. In testing, it had a significant impact on performance. But its purpose was unclear. I felt it was a general frame timing thing, while LuigiBlood felt if was sound cpu speed related. It obviously effected sound. I just figured general timing could do so too. Since we couldn't reach a consensus on it, I decided to move on for now.

Refresh Period Modifier

Next thats left is param 6A. It has 2 known uses. Super Mario Kart and Brawl Brothers. Both with a value of 0x38 (56). It's purpose was unclear. No change has been noticed in Brawl Brothers yet when zeroing it, but RadMcFist did notice a difference with SMK a couple months back. Zeroing it causes a flicker to happen during split screen races. My limited SNES technical knowledge just figured it had something to do with Forced Blank timing, and knowing even that much I knew I was out of my depth.

As I tried to figure this out, is when I made my realizations on param 63 as well. It was checked at about the same spots in code as param 6A, and seemed somewhat related. But I couldn't make sense of either yet.

Compatibility Mode

I didn't want to work on param 74 yet, but RadMcFist decided to start testing it. Its good he did as, it is in fact closely related to params 6A, 63, 53 and 50. His tests found it improved compatibility with Quintet games, which were broken even with fix patches.

Focusing more on that param for the time being, I was able to log how its used, and... its basically a control param to supply preset values for params 6A, 63, 53, and 50. For param 50 it mostly just enables/disables param 50s use, and if disabled preset flags are used instead.

I don't fully understand param 74. But for now I'm comfortable referring to it as "Compatibility Mode". There are 7-8 different modes, with minor differences. Modes 0 and 3 are the only ones that appear to be identical from looking at the code. I can't explain their purposes yet, but the most significant ones are 6 and 1. 6 is the general one used by most official games. 1 is drastically different, and at this time appears tailor made for games like the Quintet games (likely mainly ActRaiser, as that's an officially released VC title). My best theory atm is that this param was an attempt at generalizing the different types of games that require specific emulation setup, into only a handful of groups. I think this idea was later dropped as better code was written to auto detect some needs, and as well as just using the params themselves for finer, game specific tuning.

Timing

Back to 6A, 63, and 53 now! These were puzzling me quite a bit. After trying a few different approaches, eventually I found some commonality with the internal values they are used with and some tech details. I also found another instance of similar data being set in a region specifically used for network play. Having all that data grouped together, along with some other values... I was able to make some decent matches and guesses. So...

I think 6A is what I'd call "Refresh Period Cycle Start Modifier", 63 is "Scanline Length Modifier", and 53 is "Dot Clock Speed".

These... are not your average user level options. They are options designed specifically to address quirks in emulation of specific games. So in SFROM Tool, I label them as Advanced. They should only be set based off compatibility recommendations.

In fact... I don't think I'm going to even try to explain them. It would just be gibberish to most people. And for the people it is not, they probably will already understand them.

So that just leaves param 50...

Sound Properties

This one is difficult for me. It was difficult in general. In code it was clearly divided up by its bits. But any attempts at changing it randomly did not seem to show any results.

The only result noticed for a while was that 1 specific bit happened to cause a sound quirk with Aladdin. But that was not much to go on.

So this one sat on the shelve for awhile until I had everything else at least mostly figured out.

When I did finally decide to focus on it, I figured the best place to start was by dumping all the instances of the internal settings of the bits per game to a param50 value. I figured that may help shed some light on it, and using these values or tweaking these values with those games may yeild the most noticeable differences.

I gave all my data to RadMcFist to test... and he kind of took it another direction. But that direction yeilded results of its own. He noticed that certain values meant for other games fixed an audio issue with Warios Woods.

At first I was trying Chrono Trigger with my own testing, but wasent getting much for results, and instead getting side tracked. So I too tried Warios Woods. I quickly noticed the audio issue, and deduced down which bit fixed it. In fact, in my testing I found that another bit also fixed it, though not as well.

I'll admit. I'm kind of copping out here. Rather than figure out the entire exact usage of the param, I just decided to conclude it as "Sound Properties" and move on for now. I notice subtle changes by flipping different bits, and supplying difference values. But I'm not truly able to make sense of it. Things don't match up to documents, and testing yields inconclusive data. Maybe I'm just worn out atm, or maybe its because a SFROM Tool update and fixes for the Quintet games/Sound glitch games are needed. I just feel atm that understanding the exact details of this param is not important, and instead since I can clearly conclude that the whole of the param is sound related, and effects things like echo and pitch, calling it "Sound Properties" and moving on its reasonable for now.

For now, I just want to get this part of the research done, and get a new version of SFROM Tool released, as RadMcFist seemed pretty adamant about getting the Quintet game fixes out asap. I wanted to further understand the options first before telling people to use them, and see them treat options like a magic, cure-all bullet, and set things blindly. It's impossible to undo mistakes with made in haste with stuff like this. There's still a few mistakes we are dealing with in the SNESC community from Clusters poor choices made early on. I think it proved to be a good thing that we waited too, since I feel the better, more proper fix for those games was realized after later research.

Now for some unrelated discoverys!

SA-1 Options

First up is, SA-1. Ever since Bosco figured out the Special Chip byte as much as he did, the SA-1 options have puzzled me. Why 6? What are the differences? What VC/CC games use what version?

At this time, I still cant answer much of that. But I can answer the last one. It appears that SMRPGs and Marvelous use SA-1 (3), and The Kirby games use SA-1 (6).

Whats odd is that, the switches code has Marvelous using SA-1 (6), at least with compatibility modes 0, 1, 3, 4. I think compatibility mode 6 auto detects and finds out what it needs.

At least this is 1 step further to understanding the differences. ATM its just presumed these version options emulate different SA-1 chip speeds.

Here's the real interesting one for me!

Megaman X

I found Preset ID 0x1115 a while ago. It stood out as very strange... It was checked along side a lot of special chip games, but didn't appear to be for anything. After some adjustments of the Preset ID list, I pegged that ID for "Kyūyaku Megami Tensei: Megami Tensei I・II". I figured it just required some odd coding because it was a 2 games in 1 cart thing.

The ID behaved kind of like a DSP chip id. It would boot Dungeon Master, but not play it past the intro. 0x123F does this too though. I just chalked it up as an oddity, accepted my conclusion, and moved on.

Then recent work on figuring out the Switch emu code led to its own discovery.

On the switch, Megaman X is treated very oddly. It has its Preset IDs checked, and any game loaded with that Preset ID is mapped very uniquely. The mapping, at least at a glance, resembles the HiROM map routine. MMX is a LoROM.

This reminded me of how on the VC/CC, MMX is a oddity that uses the HiROM value for the ROM Map byte. I chalked it up as a typo, and didn't think much of it. But that's 2 things pointing to a weird coincidence...

So I did some testing. And noticed that, when MMX runs without its Preset IDs that enable that weird mapping, it bugs out in the demo. This lined up with LuigiBloods suggestion that its treated differently because of its copy protection.

When not using that ID, X will spawn without all the upgrades in the demo. Including the Dash. And as the input is preprogrammed, it will immediately desync because when it dashes X is expected to have moved further than he does. This spawning without upgrades is something that happens with the copy protection. So yea. I guess the weird mapping gets around that.

But how does this relate to 0x1115? Well, that ID was along side MMX ids checks too, in addition to special chip games. I didn't think much of it because... MMX is not a special chip game.

Then, I was looking through the SNESC code and notice something new and strange. Special Chip value 5, what my tool listed at "DSP2 (?)", was checked with the MMX IDs... And 0x1115.

It was time to put 2 and 2 together, and conclude something new. Chip value 0x05 =  MMX. Preset ID 0x1115 = MMX E-PAL (a version that existed on VC, but I could never place on the list before).

This is a strange revelation as, that means that the Special Chip list is not a Special Chip list. I'm still going to refer to it as that, but its more like a "Special Game" list. Special Chips, Special Mapping, Special code to ignore things, etc.

For now I've moved "Kyūyaku Megami Tensei: Megami Tensei I・II" back to its old spot in the list, as that makes the most sense. Of note, 0x1115 does not appear to work on the Switch. The switch has seemed to drop compatibility for most PAL games. I've updated the Special Chip option in sfrom tool with MMX for value 5, (along with DSP1 now being DSP1A), and made a special note about why MMX is listed there, in case people think its some sort of hoax trying to claim theres a new undocumented chip.

This has also caused me to update the SFA2, and in turn Star Ocean, patches to use the HiROM value for ROMmap. This is because SFA2 did not have a ROMmap byte on WiiU, but did on 3DS. On 3DS it was set to the HiROM value, and I just thought it was a bug as SFA2 and SDD1 ROM Maps are more of LoROMs. I now think this was done on purpose like MMX, and its the expected more proper map value for SDD1 games.

Ogre Battle 

Lastly I've made an update to Ogre Battle E-NTSC's concluded ID.

This area in the list was one of the others with some confusion. E-NTSC ids generally are listed before the J-NTSC ids. But here, the 2 spaces for Ogre Battle suggested otherwise. The J-NTSC ROM would not boot with the second ID, so I was forced to swap them.

Recently, after looking at both the code of the Switch and SNESC versions of the emu... I was force to start considering something. The previous ID, 0x10B6, just seemed to directly related to the Ogre Battle IDs. There is clearly a Prince of Persia E-PAL VC ROM. So I figure it was there. We had 4 ID and 4 games that needed to be assigned in the range of 0x10B5-0x10B8. So naturally it seemed like 0x10B5+0x10B6 would be for the 2 PoP games, and 0x10B7+0x10B8 would be for the OB games.

That's not the case though. Both 0x10B6 AND 0x10B8 are for Ogre Battle E-NTSC. And Prince of Persia E-PAL? I don't know. Its probably going to be like another Final Fight 2 J-NTSC situation, and be in an odd tacked on spot. But I see nothing in the code atm to suggest its placement, so its no longer on the list.

There is a glitch with Ogre Battle E-NTSC. And my hope is that its new, more proper id will help fix it. But the person I asked to test it hasn't gotten back to me. Regardless, I think the ID is correct either way, and such a result would only serve to further conclude that. A negative result would not change it as... 0x10B8 is for Ogre Battle E-NTSC too, just it was for the Euro release.

That's it for now! =)