Converting any game to SA-1 involves digging though various processes and it takes a considerable amount of time. Gradius III took around three months and most of the spent time was for generating the remap files, required for moving the game memory to the SA-1 CPU visible area. Below you can see the complete conversion diagram.
The game must be completely disassembled. DiztinGUIsh is used to generating the game disassembly, but it requires you manually reviewing the code for making sure it’s disassembling correctly. It involves at least the following:
- Separating code and data blocks;
- Checking for opcode sizes and alignment; and
- Making sure all code blocks are connected to each other.
With the disassembly done, you now have to run though SA-1’s The Last Remap tool for generating the needed remap files and afterwards analyze the game disassembly to figure out if the remapped memory locations should be applied or not. The particular process I won’t be explaining on this article, but assume that it takes a lot of time. For example, on Gradius III, 380 of the 871 indexed absolute opcode remaps had to be reviewed and manually removed by myself one by one because the game had another context on these opcodes and they were indirectly responsible for half of the game crashes during the beta patch testing phrase.
This is the main reason that it’s so hard to convert new SNES games to SA-1. In another post I will explain why is that needed, but without the game disassembly and the game remap, it’s impossible to move the game logic to the SA-1 CPU, responsible for the 10.74 MHz processing.
The solution
Recently however I found out that with bsnes-plus you can not just output trace logs, which are dumps of the game logic code (but different from disassemblies!) but also a binary file called usage map. The usage map contains some useful information about the ROM, such as which blocks are considered code, data and some of the opcode control flags.
Editing a menu option on bsnes-plus, you can export the usage map and together the trace log you can pretty much generate the entire game disassembly and its context by just playing the game! The main drawback is that you have must playthough the entire game for complete coverage. The more you play, the more different enemies, effects, stages and bosses you reach, the more the emulator will know about the ROM and more reliable the output disassembly will be.
Some games like F-Zero you can generate a reliable disassembly by playing it around a half hour, but others like Secret of Mana you would need to play the game for several hours, trigger different events, play with all magic combinations and try reaching out most of the areas.
However the good thing is that with the information available, a SA-1 game conversion that would take several months to be complete, can be reduced to only a couple of weeks using this strategy.
I edited both DiztinGUIsh and SA-1 TLR for using the usage map and/or trace log for automatically analyzing most of the manual work done by me. With that, I can focus on actually optimizing the game which is the process done on the right side of the diagram. The manual work of the remap process is now just a matter of playing the game!
Now you can help me!
The process of generating trace log and usage map is so easy that you can now directly help me generating the analysis files! Combine that with several people available to play, we won’t be just able to convert games faster but also do several games at the same time!
You can download the version 04 of bsnes-plus here: https://github.com/devinacker/bsnes-plus/releases/tag/v04. Download and extract the 7-zip file and open “bsnes.exe”.
Please note that it you must use version v04, because the most recent bsnes-plus versions will not work with this approach.
Load a SNES game by either System → Load Cartridge on the main menu or by drag-dropping the game directly on the main window. Make sure to configure the video and audio drivers on Settings → Configuration if needed.
Before playing, we should enable trace logging and save usage maps on disk. For doing that, click Tools → Debugger (1). The debugger window should open. On its right side, check “Enable trace mask” (2) first then “Trace S-CPU opcodes” (3). Then (4) click Misc → Options (5) and mark “Cache memory usage table to disk” (6). Then make sure to restart your game via System → Reset.
You can use save states and rewinds without problem. With that, the only thing left to do is playing the game! Play it and explore the most different possible combinations and endings.
Before leaving the emulator however, unmark “Trace S-CPU opcodes” (3) for marking sure the trace log file is properly written. Once you exit, bsnes-plus should output the following files on the ROM folder:
game-name-trace.log
game-name-usage.bin
IMPORTANT! If you play the game again after generating the files, you must rename the trace log file to another name because if you play it again and enable trace logging, the previous file will be completely overwritten and lost! So make sure to rename it, for example, “game-name-trace-1.log”, “game-name-trace-2.log”, etc. Usage maps does not have that problem.
Compress these files to a .zip, .7z or .rar file and submit it to me, either though e-mail vitor.vilela.mario at gmail.com or Discord Vitor Vilela#1930. With that information I will be able to convert any game to SA-1 much better and faster.
I’m accepting any game that does not use any enhancement chip, with the exception of the DSP 1-4 games. If you don’t have any game in mind, I have the following suggestions:
- Act Raiser
- Act Raiser 2
- Contra III
- Demon’s Crest
- Race Drivin’
- R-Type III
- The Legend of Zelda – A Link to the Past
- Secret of Mana
- SimCity
- SimCity 2000
- Super Castlevania 4
- Super Ghouls ‘N Ghosts
- Super Mario All-Stars
- Super Metroid
- Super R-Type
Keep in mind that even if you submit any game trace log and usage map, it does not mean that it will get a SA-1 conversion! There are several factors behind a conversion, but submitting it you will increase the chances of the conversion happening drastically!
Ready for playing your favorite game again with hopes for a SA-1 conversion?!
Very nice!
Enviarei alguns em breve, excelente trabalho.
Good luck
Very good … I’ll start doing and send you … the first will be Super Catlevania 4.
Does bsnes-plus support .lsmv files? I’ll bet you can get a significant portion of the mapping done for most games by running it with one or two 100% speedruns.
Unfortunately even if they support it, the timing differences between bsnes-plus from and the emulator which was recorded will likely make the game desync… So the thing is, the movie must be done on an emulator with the same timing specs as bsnes-plus… Which I believe only recording on bsnes-plus directly will make it possible. But cool idea regardless!
Foooo.
I retract my foooo.
It seems to me that a run that desyncs, say, 20 minutes in would still produce some useful data. I’m assuming here that a _complete_ single run is not necessary, and that it’s possible to combine maps.
I retract my foo even further:
https://repo.or.cz/lsnes.git/tree
lsnes is also a fork of bsnes. They may have similar timing characteristics.
Looks like “no” – it supports bsv files. The .lsmv format appears to be what everything on TASVideos is done in (because lsnes). The documentation on the file format is here: http://tasvideos.org/Lsnes/MovieFormat.html
It would probably be a big help to be able to get a majority of your mapping done unattended.
It would be useful if (some of) the steps in handling the emulator were automated, especially the trace log numbering…
Does the whole process make converting romhacked games to SA-1 easier as well?
For instance, if we finish analyzing Super Castlevania IV, can this knowledge be applied to the Super Castlevania IV Other Castle hack (it’s definitely worth playing, BTW: https://www.romhacking.net/hacks/3411/)?
Correct!
I’ll have to get onto Final Fight 3 – that thing has some of the worst snes slowdown in co-op or if you play with the CPU
I will start Super Aleste. Is there a google spreadsheet so we can keep track of in progress and finished games?
That’s a good idea. I will plan something about it.
Wouldn’t you be able to just use some 100% Tool Assisted Speedruns to get most of the data without having to play the actual game ? Looking forward to seeing more of these games famously known for their slowdown in action.
100% TAS would be extremely useful! The only problem is that they were recorded using other emulators and putting them on bsnes-plus would not be possible due of different emulation timings, sadly.
Hey Vitor,
awesome work with Gradius III and Contra III ! I would love a patch for Axelay! It’s a masterpiece but sadly with a lot of slowdowns.
You’re welcome, thank you! I’ll eventually work with Alexay, stay tuned in!
Are you still collecting data for Super Metroid? I’ve been wanting to replay it and found this page. I’d be willing to do anything to help, if you’re still wanting some data.
Hi! Sorry for the late reply. I’m looking forward for Super Metroid traces
Yo, just found out about all of this SA-1 (Expansion Coprocessor Chip) stuff today !
A friend told me about how it makes the SNES game “Megaman X” a blast to replay.
So would this only speed up action and adventure…or could this be used to speed up older RPGs ?
Very interesting stuff…too bad the old Nintendo Gameboy did not have an upgraded chip like this ^_^”
Cool to hear! SA-1 can be used to accelerate pretty much any game type.
Would an SA-1 enhancement fix a slowdown caused by NMI timing issues?
Because I’ve been helping with the Final Fantasy VI MSU-1 mod (not the coding aspects) for a while, and right now pretty much the only reason the mod isn’t “complete” is because we don’t have fading working because it causes slowdowns due to NMI timing issues.
If an SA-1 mod would let us fix this, I might be willing to play through an unmodded version of the game to generate the needed files to make the SA-1 mod… God knows I’ve played through the game enough to be able to ensure I don’t miss much…
Does the slowdown exist in the original game (without MSU-1) as well?
No. I’d have to check with Insidious661, the actual coder for the mod, to get all the technical details, but my understanding is the timing for things in FFVI is very tight (and tied closely to the framerate, as most things are internally timed by the number frames drawn), and in many parts the number of NMI interrupts needed for fading is enough to screw with that timing, slowing everything down.
So the normal fading works fine, but the NMI’s needed for MSU-1 fading slows things down.
I should mention I’ve never actually seen one of the attempts at getting fading working, they never made it past Insidious’ initial testings.