Decompilation tools

[Dunk]

I'd be interested to know which decompilation tools you used. I'd love to learn how to do this properly, as I've always wanted to see how the alternate realities were put together. There is so much that goes on behind the scenes in those games that it would be well worth decompiling

[xot]

This is Kroah's site, not mine, so I'm sure he'll chime in here at any moment, but I might as well list what I used for hacking MULE.

I should start by suggesting you be very familiar with the Atari hardware and its capabilities before trying something like this. A book like Compute!'s "Mapping The Atari" is a must. It provides lots and lots of great information about the inner workings of the Atari computers. An HTML version is available online. There are other good books as well. For instance I regularly used one that contains a helpful Atari color chart.

I made the disk image myself using Xformer and an Xformer/SIO cable with my Atari ST computer and Atari 1050 disk drive. Any download on the internet should be good. There are slight differences between the various MULE disk images depending on how they were cracked, or whether they were hacked to run on Atari XL computers. There may even be more than one official release although I am skeptical of such claims. I haven't seen any evidence that there are any common versions that differ in terms of gameplay.

I started with Atari800Win PLus 4 which has an excellent debugger. Not all versions have the debugger. Another good choice might be GEMulator which seems to have a great debugger but I haven't yet been able to figure out how to get it to start. It seems to require the GEMulator hardware in order to activate the debugger (even though the 8-bit emulator shouldn't be using the hardware in any way). If anyone knows please tell me.

For MULE, since the game is completely loaded into memory, I simply began by saving a memory snapshot right after the game loads. I actually saved many memory snapshots throughout the game to help identify the parts of code that change, ie. game data or any self-modifying code. The Atari800Win debugger can show you the stack, the registers for the 6502, ANTIC, GTIA, PIA, and POKEY chips, display list data, the last 32 JMP/JSR calls, etc. It also has the basic tools you need for setting breakpoints and tracing or stepping through code.

Then I used the awesome Dis6502 do a lot of the machine code to symbollic code conversion (disassembling). Dis6502 was specifically made for hacking Atari stuff so it has all of the standard memory locations and ROM routines already mapped. It also does ATASCII to ASCII conversion and can help you find, view, and mark sections of code, data, and graphics. In order to get started I had to do some things to trick Dis6502 into thinking the memory snapshot was actually an Atari executable BIN file by prepending/appending any necessary header/footer data that would normally be found in an Atari executable file. Since Dis6502 can only support 32KB binary files, I had to split the 64KB memory snapshot in two.

Finally, I used Notepad to do a lot of search and replace (converting raw addresses to descriptive labels), and to document the code or rewrite it into psuedo-code. I also kept a seperate file that tracked all the memory locations and subroutines for the game.

As I worked, I tested things by replacing data or altering code during the game using the debugger, or by taking chunks of code (subroutines) and probing it with different data to see what it does. I sometimes did this on an Apple ][ emulator since it also uses the 6502 and the Apple ][ has a built-in 6502 monitor which makes testing small snippets of machine code very easy.

I used AXE for some basic binary editing and diff checking.

This is my first major decompilation effort. I don't know that there is a "right way" or a "wrong way". I tried a lot of tools, I think I ended up using the best ones.

[Kroah]

Wow, Xot, what a cool overview you made ! You are always welcome

First of all, like Xot explained it, you must know very well the hardware and OS (ANTIC, POKEY, GTIA) and their interactions with the user (interrupts, I/O, dynamic registers...). I've never really coded any serious assembler program, but i've learned it very quickly because i already know others assemblers (68000, x86) and the hardware is like any other platform (cpu and specialized processors for sound, gfx and IO).

For reference books, I personnaly love these online links:
- Mapping the Atari: http://www.atariarchives.org/mapping/
- De'Re book: http://www.atariarchives.org/dere/

The debugger of Atari 800 win PLus is your friend. It gives you conditoinal breakpoints, history of instructions and jumps, execution to the next RTS/RTI, ...

After this, and the main work, is the disassembling. And for this, there's only one IMHO: IDA Pro ("Interactive DisAssembler"). It's not a freeware, but there's an old free version to begin with. I've bought the full version because it can be scripted and is multi processor (for atari ST coool). It can analyse the entry point you give him (through a memory dump for example or from a binarie) and it decompiles everything for you, going into procedures, following the jumps (but not vectors table, too bad)... It gives you cross references and dynamic follow up too. I prefer to work with a memory dump, because you can at any moment give him another one without redoing all the work and with the datas you know from the emulator.

But to really understand all the disassembled code, you must map the addresses to their meaning in renaming them (thanks to http://www.atariarchives.org/mapping/memorymap.php and the use of the scripting).

After that, you go to the emulator and play your next disassembled game. You must perfectly know this game, because all the difficulties came from assembling the parts of the puzzle. And the better you know the game, the easier you'll be able to understand the meaning of memory addresses and code.

With try and retry, you'll have renamed lot of addresses and procedure, and things get clearer.

For example, i've just completely decompiled "Gateway to Apshai" this two last days (wow some interesting things discovered )

Concerning alternate reality, i think it will be reaaaaally difficult because of the multiple loading phase and complexity of code, but it's my opinion. I think you should begin with a simpler game, loading in 1 step.

I hope it helps you, but if you have some questions, me (and surely Xot) will be happy to hear them

Regards,
Kroah

[xot]

De Re Atari is a great book, a real classic. Gateway To Apshai sounds like a fun project. That was one of my favorite cartridges back in the day. The shear number of rooms is pretty impressive and the gameplay was really ahead of its time.

[Dunk]

Thanks for your help with all this.

This gives me quite a bit to be going on with. AR was never planned on being an initial foray, it was always the dream once I'd learned how to do it better, along with Omnitrends Universe.

I'll start off with some of the basics, and see how I get on. I covered x86 assembler when I was at college before uni, so i've probably forgotten a fair whack of it now as my job mainly entails using SQL server and VB now. Time to brush up again

[doctorclu]

I would imagine RPG's are the most fun to decompile, mainly due to the statements and remarks in the code. May have to try this soon.

[xot]

If RPG's are your bag, all of the Ultima games are very hackable, and it's as good a place as any to start learning. Maybe start by hacking the savegame files, then move onto the conversation trees, then maybe work out a sprite viewer or map display, then move on to a "trainer" or a cheat or modified game items. Some of my earliest and most fulfilling hacking was on Ultima games.

[freemale221g]

What Decompilation tool did Kroah use to decompile alternate reality the city for the ST?

[Kroah]

What Decompilation tool did Kroah use to decompile alternate reality the city for the ST?

I used the free version of IDA Pro Disassembler. I don't know if it's still available on their site though.