Progress Updates - Super Metroid SA-1, incoming Super FX games, next steps for widescreen games

Hi! I have not been able to share much updates lately - I often forget that most of my work is programming and reverse engineering based and sometimes even if you are doing a lot of work you usually don't have anything to share since you are building new projects from scratch. That's the situation for Super Metroid SA-1 in particular.

For that reason, I'm been out of social media since I'm been busy with my 'real life'  work too - as a Software Engineering; for not having to stop the SNES projects I tend to stay away from everything that is not important - which includes from Discord to LinkedIn. It works cool, you always end up realizing that they are not important as you thought it was (specially things like Facebook).

If you recently messaged me (via Discord, Twitter or email...) but you didn't get a reply yet, don't worry, will make sure to reply it in the incoming days. And if you would like to reach me for some reason, don't be afraid to! I will reply whenever I get the time :)

Super Metroid SA-1 - a real reverse engineering challenge

Super Metroid is huge. 3 MB. Proportionally it has a lot of code. Gradius III and Super Mario World both are 512 KB. This means SM is 6x larger than them and it indeed causes may more work to do than the conventional.

The disassembly file is so far around 43 MB (megabytes) big, with over 500k lines of code and data. The challenge currently is finishing the remaning ~5% uncovered region and mark it either as data or code. Once that is done, I have to generate the RAM remapping files. However, unlike SMW and other games which is 512 KB big and uses a simple LoROM mapping, Super Metroid uses a larger LoROM map which reaches up to bank $DF. Banks starting at $C0 on the SA-1 chip is considered HiROM, so what to do now?

Super Metroid Bank Mapping:

$80-$9F -> 1st MB

$A0-$BF -> 2nd MB

$C0-$DF -> 3rd MB

SA-1 Bank Mapping:

$00-$1F -> 1st MB (LoROM)

$20-$3F -> 2nd MB (LoROM)

$80-$9F -> 3rd MB (LoROM)

$A0-$BF -> 4th MB (LoROM)

$C0-$FF -> HiROM banks, which can be either first 4 MB or last 4 MB.

--------

In other words, a special ROM remapper feature will be required for Super Metroid too. I never tried this myself and I don't know how complex this will be. It's the first time that I got into this situation; I know it will certainly not be easy at all and once the RAM and ROM remapping is applied to Super Metroid, another huge step will be still needed which is activating the SA-1 chip and moving the critical code paths to the faster CPU, without breaking S-CPU and S-PPU/S-APU (Bus B) communication. Testing will be super welcome and essential for getting Super Metroid SA-1 running.

Once Super Metroid is done, we will get either Star Fox or DOOM as the first Super FX optimization game

I know many people are having high expectations when it comes to Super FX games and what the SNES is capable of via adjusting games to make them get a better performance from the hardware. Specially after The Real Phoenix offered me to make a Super FX cartridge capable of running with +25% overclock via a clock switch. This will let me not just optimize games via the original 21.5 MHz clock but I will also be able to experiment games running at 27 MHz too.

Overclocking is an interesting thing because Super FX is one of the very few enhancement chips that overclocking is possible on the hardware. The SA-1 chip, which has its base clock tied to the SNES master clock for example can't be overclocked due the master clock also being used as the NTSC/PAL timing reference.

Star Fox originally ran with the slower 10.74 MHz Super FX revision and getting at 21.5 MHz will be a cool upgrade already. Remember that the objective of the Star Fox optimization patch is to make it run either at 20 or 30 FPS without making the game run faster than the intended, developed speed.

DOOM is also an interesting case. Along with the overclock, there is an optimization case that halve the frame buffer I/O since the Super FX draws two pixels-in-one. While it's a low resolution technique, for the people interested in playing the game in the original state but with more speed, this I/O reducing can be an interesting opportunity to make the game run much faster since the main bottleneck between the SNES and the Super FX chip is exactly the I/O. There is not much information yet on the possible gains over this but certainly with the combination of the 27 MHz clock + the I/O optimization we can make the SNES DOOM version run with a better performance than the original one.

Either DOOM or Star Fox will be picked as the first project. Star Fox has more chances of happening first, but in case I end up getting stuck in the Star Fox development (which means I will require much more time than expected), DOOM is already a great alternative to show off what the SNES can do when coded to reach its upper limits.

Widescreen Games, What's Next?

I have not forgotten about Super Mario World Ultrawide. The release is still expected to come soon; since the reception of the 18:9 version was quite good without more breaking bugs present, I will start moving into the 21:9 version that will end up being slight different than the 16:9 version because an internal resolution of 448x224 dramatically changes a lot of things on the engine that the 16:9 version didn't do.

Why 21:9 changes the game heavily? For example, the boss fights must be redesigned because the player can fall from the platforms totally (and I'm not talking about Bowser, which was a design decision - but rather bosses such as Roy, Ludwig, Morton, Reznors, etc.). In addition, levels that has sprites intended to appear as soon as Mario starts moving like the stream of Koopa Troopas at Yoshi's Island 2 will be slight adjusted to not break the stream. Other levels that are either short (<=512px), vertical or depends on the initial camera scrolling will have some rework too.

Big sprites like Banzai Bill, the Big Boo, Rotating Platforms and such may glitch in the 21:9 version because on the extreme screen edges there may get confused if the sprite tiles should be drawn to the extreme right or to the extreme left side. For such reason, they will also need a redesign to make sure all tile position calculation are done in the 16-bit format and in 8-bit format as they were designed to. The SA-1 chip will be important to make sure the calculation change will not cause slowdown at all.

Once Super Mario World is done, I would like to try a different style game... Like F-Zero or Super Mario Kart for example. That way I will be able to know which game genres might work better or not with widescreen and document that for more people knowing about. I think it will still take a couple of months until we see a complete widescreen game out like Super Mario World but I'm sure there will be a lot of cool things coming in the future.