Anyone wanna help me make a SNES → C code converter? (yeah, for real)

[elderthesmall]

Hi, I already posted this on romhacking.net, but got no luck, so I'm reposting it here instead.

So, I'm working on this weird-but-kinda-cool idea.

I'm making a tool that takes actual SNES binaries (65c816 code)
and spits out C code that you can compile on a normal PC.

Not an emulator.
Not a decompiler.
Literally a "Hey SNES ROM, become C now" machine.

What I need help with:

65c816 instruction translating (the part where my brain explodes)

figuring out PPU edge-cases without crying

APU stuff I will probably regret doing

general tool-smithing / testing ROMs

I can't use GitHub yet, so I'll throw files on Pastebin / whatever hosting people prefer.
Quote
Quick Edit
More...

[Myself086]

I made a static decompiler for my private emulator. It's incomplete but gets most of the code running. I mostly used it for decompression methods and loading screens.

Several instructions trigger warnings and must be verified manually: BRK, CLD, COP, JMP (abs), JMP (abs,x), JMP [abs], JSR (abs,x), RTI, SED, TCS, TSC, TXS, WDM, XCE.
Sometimes REP and SEP if they affect either D flag.
Some rare edge cases with PHP and PLP.

Mine isn't public and poorly maintained. I can certainly help with yours.

I recommend being familiar with making emulators or making your own for 65c816 instruction set before moving on to translate them to C.

[elderthesmall]

Thanks a ton for replying — that means a lot. It’s super encouraging to hear you’ve already built something similar.

I’d love to get your insight as I work on the instruction translator — especially around the edge cases like REP, SEP, and PLP. If you're open to it, do you have a preferred way to chat (DMs, Discord, email)? I’d love to run ideas by you or share progress as things move forward.

I’m currently building tools in Python for ROM parsing and plan to use C for the translation output. I’m also experimenting with tools like DiztinGUIsh for trace-based analysis.

[Oziphantom]

SNES Decompilation is basically impossible.

Your C code will need to basically emulate 65816 connected to a SNES memory map. At best you would will end up with the ASM commands converted to a bunch of C calls which speed the execution speed a fair bit I guess over reading the byte stream and parsing on the fly, but probably not that much. You won't be able to get the code back to "C function" versions of the ASM code, you will be in some cases or game designs, but for the general SNES case, the 65816 is a crazy out there CPU that does things C just won't understand and you will need to handle it just swapping the address space all over the place at every instruction.
PS1 and N64 works because those games are for the most part 95% written in C so you are putting compiler outputted asm back into somewhat readable C which is a lot easier. While the SNES has no such concepts and won't translate nicely into C.

Then you get into a whole Swiss Army Knife of "racing the beam" tricks you would need to handle.

[SNES AYE]

SNES Decompilation is basically impossible.

Does “basically” mean literally impossible, or just extremely difficult? If it’s the latter, I’d like to encourage anyone willing to take on such a huge challenge in the SNES development community.

So, I'm working on this weird-but-kinda-cool idea.

Assuming the answer above is “extremely difficult”, I doubt there are many who would try to achieve something so demanding, but sometimes those are the very people who accomplish true greatness. It’s a shame I can’t help personally, but I’m there in spirit.

[Oziphantom]

SNES Decompilation is basically impossible.

Does “basically” mean literally impossible, or just extremely difficult? If it’s the latter, I’d like to encourage anyone willing to take on such a huge challenge in the SNES development community.

There are some games on the SNES that were written in a C compiler. Earthbound for example, which you could do the de-compilation for. Mortal Kombat also has some really weird stuff going on, I think Sim City was also C. So those games you can. Mario Paint, Picross games. You are probably looking at ~20.. 50 tops.
Some games will be basic bitch enough that a C decomp would be possible for the vast majority of it. Then a small percentage of games will be at best "yes this is a giant single function with gotos everywhere and a bunch of global variables that make registers rather than actual C functions" "decomp" and then a lot of games will be "here be dragons, not going to happen" of which Capcom games would be an example.

[Fiskbit]

I have split off the discussion about SNES compilation (the opposite of what this thread is about) and casual SNES development to its own thread. Please continue discussing binary -> C translation here.

[Memblers]

mkwong98 on the forum here has done a similar thing for NES, it might be useful to see how that works.
viewtopic.php?t=26098

[Oziphantom]

The NES one is interesting, the 6502 is going to cause potentially a huge pile of issues with it eventually. However the 65816 is a whole 7 levels above the 6502 in terms of "weird and wacky stuff it can do to make C impossible"

[segaloco]

As mentioned on RH, the m/x state alone is going to be a nightmare to keep straight. You can't drop into any random address in an SNES ROM and know what that subroutine expects these registers to be. You can guess based on some context clues, but this alone would make the necessary analysis quite complicated.

Then there's the question of are you porting the CPU compute but keeping the peripheral interfacing the same or are you also planning on preprocessing things like tiles and audio into native formats? There is a huge difference between producing a "portable" version of a game and producing what is in effect a bundled emulator with the computational bits simply pre-processed. I could see a situation where you strip out the execution engine of an emulator and drop in a C-ified version of some title, still relying on the emulators implementation of all the other bits.

So much of it comes down to what the goal is. Is it quicker native execution? Increased maintainability via a high level language and/or modern APIs? Simply as a study tool? There are a lot of different angles you could take depending on what your end goal is.

[93143]

I could see a situation where you strip out the execution engine of an emulator and drop in a C-ified version of some title, still relying on the emulators implementation of all the other bits.

That would only work if the program timing were completely decoupled from the timing of anything else in the system. Any game where it matters how long a certain piece of code takes to execute would work differently or not at all.

[segaloco]

Depends on the time base. If the peripheral bits depend on the CPU core or some other bit to be their master timer, then the "ported" code need only also implement that time base. If one of the peripheral cores *is* the master clock, then the ported code just needs to honor that clock as its time base. That's just a specific case of the general question of: How much of this job is making a SNES asm program a comparable SNES C program vs how much of this job is then translating the SNES interface into something else, be it a total runtime translation (i.e. emulation cores) or a bunch of porting of peripheral interface logic and data formats?

These could be two wholly separate affairs.

An effort to translate 65816 code targeting the SNES architecture to C code targeting the same would yield much in the way of portable code for simpler calculations and algorithms this way. At this point, "machdep" pieces could be segregated off for easier porting of what still needs addressing. This has the added benefit of you still have a native port, albeit less efficient. You have something to verify against intimately all along the way since your first goal was 1:1 compatibility (although maybe not 1:1 speed). The math being right though is huge.

On the other hand, a separate effort could be had in first trying to introduce portability interfaces to the asm version of a game. In this regard, you create stubs and dummy memory for the stuff the native implementation doesn't need but you ensure the same subroutines are called with the same arguments, same register states, etc. Basically instead of the inside out approach of getting the C out of the assembly first, this is preparing the assembly to hopefully decompile to more readily portable C. Going from this angle has the added advantage that if you're working out all the performance kinks along the way, the final asm product before you C-ify it is much closer to what your other versions will be, so it is possible to maintain the results of this work as an optimized branch of the engine for deployment on native hardware. Of course this means if you make changes you either need to implement them in both 65816 and C each time, or you need to incorporate C directly. A happy medium is most C compilers will let you simply compile but not assemble, emitting the assembly code that was generated. This is not a conventional use of C but if you want a starting place, C can be compiled, then the assembly edited to remove compiler cruft, replace runtime routines with custom implementations, etc.

Which direction really again comes down to the goals, whether it be better understanding of the title, code to use for new work, efficiency gains on diverse platforms, etc.

The goals are important too because some of these goals may simply be met by emulators better in the long run. That said, an emulator could possibly be made to be a tool itself in this sort of thing. Playing a game is after all performing a dynamic analysis of its code, simply through a controller and TV rather than debugger and ICE. Think like how a breeder reactor uses all those extra neutrons to make boom booms, an emulator could use all that runtime data to poop out a reasonable approximation of a program that would then run the same.

[Zonomi]

Snesrev has made a tool to create his SMW and Zelda 3 SNES to C ports, unfortunately, he didn’t release it, and he has been missing for months.

[93143]

since your first goal was 1:1 compatibility (although maybe not 1:1 speed).

What about games where 1:1 compatibility requires 1:1 speed?

Take Air Strike Patrol. It does a couple of mid-scanline raster effects, including the plane's shadow, using an H-IRQ. Keeping in mind that S-CPU instructions take between 3 and 17 pixels to execute, and that therefore the IRQ has to start well back from the position of the desired effect, how would you guarantee that these effects would work properly without manual intervention?

And what about programs that rely on cycle-counted loops instead of IRQs?

It seems to me that a machine-code-to-C translator would have to be unreasonably intelligent to handle these sorts of cases. Rather than just translating the logic, they'd have to make up code from whole cloth to match the resultant behaviour of the video output. Much like an emulator, the timebase would have to become something the code does rather than something that dictates how fast the code runs. Trying to make it portable while also able to run properly on an actual SNES seems outright impossible...

The same goes for audio data transfers - unless it's a fine-grained bidirectional-handshake method, code timing is going to be extremely important for at least one of the two CPUs involved. The translator would have to be smart enough to completely rewrite the transfer code in these cases.

[segaloco]

Whatever thing is being done by an IRQ interrupt on the real hardware could possibly be recreated in a different way on a computer. The IRQ-based approach to things was often taken to get over the limitation of not enough scrollplanes. You could have as many virtual scrollplanes as you want in a PC conversion of something. HUDs for instance could simply be a separate drawable, overlaid on the main background, the IRQ handling is to cleverly address a limitation, not because that effect intrinsically can only be performed by nametable substitution in a single scrolling field.

I'm not saying this covers every single case, but many specialty uses of the hardware are to get it to do something it doesn't have the system resources to do, not because that effect is only achievable in that way. Heck, most raster effects I suspect would be simplified on a computer because given the low resolution, highly inefficient but easy-to-understand algorithms may work at the expected speed. It really depends on how abstractly the subroutine involved exposes the parameters of the effect involved. The more general the interface, the more the implementation can change without affecting assumptions about how the effect is called for.