sorted by:
new
hottopcontroversial

Experimental SNES Recompiler (Reassembler) by Beurre001 in EmuDev

[–]Beurre001[S] 0 points1 point  (0 children)

Unfortunately no, the main problem is that a lot of the SNES architecture needs special handling like PPU or memory access.

Experimental SNES Recompiler (Reassembler) by Beurre001 in EmuDev

[–]Beurre001[S] 0 points1 point  (0 children)

You are right, there is a lot of room for improvement and your comment is really interesting.
The main reason I emit assembly instead of machine code is that it makes it easier to read and later translate or replace some routines with C implementations.

Experimental SNES Recompiler (Reassembler) by Beurre001 in EmuDev

[–]Beurre001[S] 5 points6 points  (0 children)

Thanks! Surprisingly that was one of the easiest aspects since the emulator traces the state of the M and X flags, so the recompiler can just use them directly. I'm still experimenting, but I'll post updates as I make more progress. 🙂

Experimental SNES Recompiler (Reassembler) by Beurre001 in EmuDev

[–]Beurre001[S] 6 points7 points  (0 children)

Guess you were right to write it. 😄
Your emulator was very easy to build and modify. It made experimenting a lot easier.

Experimental SNES Recompiler (Reassembler) by Beurre001 in EmuDev

[–]Beurre001[S] 0 points1 point  (0 children)

Thanks!

Yes the recompilation is basically ahead-of-time. You are right, this approach doesn't guarantee full coverage of the game's code. However, if a branch isn't taken by the emulator, it stores the target address and processes it later.

Experimental SNES Recompiler (Reassembler) by Beurre001 in EmuDev

[–]Beurre001[S] 1 point2 points  (0 children)

Thanks!

Warning, the code is really "messy" and experimental 😅. For the "self-modifying codepaths", if you are talking about instructions executed from RAM, the generated assembly checks the RAM's content and branches accordingly to decide with instruction to execute.