Disassembler for 68K
 

What is the best decompiler for 68k? I am reverse engineering the Sidewinder level format and need to look at the code.

I've only ever decompiled my own code for debugging, never anyone else's.

What's good for this?

Decompiler? What you want is a disassembler. Resource is the most used Amiga one, but if you're using WinUAE the debugger might be worth checking out :)

IRA is very good and even has a windows port. IDA 68k is the best but not free

Ghidra is similar to IDA and runs on various platforms. Disassembles and decompiles 680x0 code from raw bins, amiga hunk, sysv elf, a.out, etc. https://ghidra-sre.org

Didn't find where ghidra can load amiga hunk format. Not without extensions it can't.

Ghidra is probably best if you don't have an IDA Pro licence (*cough*), or you could also try Radare2 (use "Cutter", recently much improved GUI for r2 - this also includes the Ghidra decompiler as a plugin).

For understanding level formats, you'll need both dynamic (WinUAE debugger) + static (tools above) analysis probably.

I disassembled sidewinder a few years ago, grab it here:

http://franck.charlet.pagesperso-ora...p/side_src.zip

Afair, IDA have bugs regarding m68k disassembling (pc relative mode and short variables addressing mode aren't handled correctly).

yes, IDA isn't suitable if you want to rebuild your app. IRA is much better for this.

I had trouble getting the text mode to work with IRA so that it would add the text into the source files.
Some times I would disassemble a binary with ReSource and then reassemble it and it would be bigger than the origional. I never had that problem with IRA, actually the binary ended up smaller.

This problem is highly likely to be me not reading the manual.

IRA has bugs but I've been using it a lot and it does the job. R means "reassembler" :)

I remember reassembling BattleChess from IRA disassembly and it worked.

It has bugs, but nothing that can't be fixed by post processing. I've already written python scripts to fix some instructions that don't work (BTST #xx,y). I've already written some code to try to recognize text in data. I can dig that up if you're interested.

You're doing it wrong in both cases. The reassembled binary should have EXACTLY the same size as the original.

When the automatic text detection doesn‘t work then you just have to add a TEXT directive to the config file for the region in question.

Make sure all optimisations in the assembler are disabled. At least until you reached a perfect reassembly.

Or by reporting them to the authors, as IRA is still under active development. ;)

Do you mean that some BTST are not recognized? BTST on memory with a bit number > 7 is ignored. You can enable that with -COMPAT=b.

See above. Use the TEXT directive.

Maybe I should make some tutorial how to use IRA, but I hope that it is clear that reassembly is not finished after a single run. You will constantly check the output, change the config file and regenerate. Until the output is perfect.

I can't reproduce the BTST stuff with a simple example. But when I reversed big games with either POTGO tests or blitterwaits (using BTST.B) it sometimes issued DC.W instead.

I also can crash IRA/lock it with some exes. I have to switch to d68k which I don't like that much.

I'm using an outdated 2010 version. Will upgrade.

A tutorial would be appreciated. As much as this program is appreciated for years :)

I'll try Ghidra. I guess WinUAE is going to be necessary too.

Fortunately it doesn't look too bad in that it probably just loads the level data into RAM and operates on it from the main loop of the game, so shouldn't be too hard to find with the game running.

Sadly I think the original source code for Sidewinder is long gone, which would have made this so much easier.

I posted the disassembled (with Resource) source code above, perhaps you missed it ?

I saw it but it needs a lot of work. Most of the symbol names are missing and even just finding the main loop isn't easy. Maybe once I have dived in with WinUAE it might be more useful.

For adding all the symbol names in it's easier to work in the disassembler I think.

I use to find mainloops all the time for instance to find levelskips or insert CD-music play. I have a good technique with WinUAE. Let me explain.

Play the game and break with shift+F12.

First get rid of the case where you're in an interrupt with "fi RTE", then "t". Unless there's a trap within an interrupt, that should get you back in non-VBL part of the game.

Note down the value of A7. Then use "fi" instruction to find next RTS and "t" to return from it. See if A7 increases. If it doesn't, that's because the RTS is from a subroutine. So ignore that one.

After a few moments, you find the highest A7 value. Means that you're in the main loop. Put breakpoints here and there to find the point beyond which the breakpoint doesn't hit. There's probably a label, and below a BRA to it.

I realize that i didn't include the .rs (for Resource): http://franck.charlet.pagesperso-ora...mp/side_rs.zip

Since the first post was about reversing the level format, if the individual levels are loaded from disk I would find the disk loader (search for writes to DFF07E/DSKSYNC, work back to find the loader entrypoint then find references to this) and breakpoint after loading to find what the game does with the loaded data (typically depack it then parse it, so it should be one of the first few subroutines called after loading).

If it doesn't load individual levels (they're all stored in RAM), use typical 'trainer techniques' to find the level counter and then find references to this for the leveldata-handling routines.