7 ms·
I've written a decompiler with a custom template for the 6502 (the idea is all CPUs are fundamentally the same, from x86 to 6502, so you just define a CPU as in
by zandorg 16y ago
I've written a decompiler with a custom template for the 6502 (the idea is all CPUs are fundamentally the same, from x86 to 6502, so you just define a CPU as instructions affecting flags, etc, and have custom functions for, eg., Vax CPUs).
So I reverse engineer a C64 game by first decompiling the assembly code into vanilla C, without any definitions or names. Then I do things like make the emulator refuse to write to an address I'm curious about. Then I can see what the address does, and make a definition (a name!) for that address.
What you get in the end is C-like code with all your definitions making it readable as the original source code.
The only problem I'm having is a really robust flow-control system - JMPs can get hard to parse if they're crazy. But other than that, RightBack is a great decompiler. It's also written in Common Lisp.
- sizzla 16y agoThat sounds impressive. A lot of really impressive C64 code is timing sensitive. The coder counts exact number of cycle a piece of code takes and attempts to, for example, synchronize it to the CRT rasterbeam, because the horizontal and vertical refresh frequency are known and because there is a VBL interrupt. So for example you change the background color at just the right time as the rasterbeam renders the screen to get a rainbow. Similar stuff is done with quickly changing sprites so that you can get way above the, I don't know, 8 or so sprites that are supposed to be the max possible to do in hardware. You would lose insight into this by converting the code to C.
- zandorg 16y agoHowever, it would be useful for the higher-level logic - like a print function. You decompile calls to this function, no matter how the function works.