Easy games for learning to disassemble?

[Argh]

Hi, I’m currently getting into disassembling Amiga games using Ghidra and the FS-UAE debugger. I started at pretty much zero, and I’ve learned quite a lot, but I’m struggling to identify easy games to get anywhere with.

For example, I’ve been mostly digging around in PD games running in Workbench with modest success (but lots of fun) but I wonder if going through games building on lots of libraries like this is actually making it harder to understand what’s going on. I’ve also dug a little around in Portal (just a bunch of text data shifted around, can’t be that hard, right?) but I got absolutely nowhere with it. Well, at least I learned early that I better avoid AMOS games…

Can someone point me to a list with games that you’d consider easy targets for disassembling?

[copse]

What is easy? Is it something small that you can disassemble completely? Is it something that you can just jump in and work out an isolated part of and then alter that? Is it something you are actually interested in? I don't have an answer for you. I think one approach might be to pick something that interests you and which you have an incentive to complete.

One approach might be to forget disassembling or decompiling a whole game. Instead think about changing some aspect of behaviour, perhaps patching a routine. An example might be something I have at the back of my mind, I'd like to replay Captive but the mouse controls are tedious. If I just located the keyboard routines and isolated which was used for which, I could patch out those and add extra keyboard handling. Then I could patch in new keyboard handling that made replaying Captive completely keyboard driven. I wouldn't need to care about the gameplay, the graphics and so on.

[copse]

Biplanes is a small game.
https://www.lemonamiga.com/games/details.php?id=1248

There's also intros and cracktros that can help get familiar with hardware usage to aid in later more complicated game decompilation.

[jotd]

would be useful if someone disassembled/RE'ed arcade games like Jungle Hunt or Bosconian.

not amiga, but smaller thus easier. Even 16k code can be a drag, be careful!

If you want 68k there's also Marble Madness 2 that I have started

https://github.com/jotd666/GameReloc...MarbleMadness2

[Argh]

Originally Posted by copse

What is easy?

Valid question, guess I should have been a bit more specific. Easy for me at this stages means short, no hardware-specific trickery, no complex structures, no copy protection that might interfere, ideally easy to debug (no fast gameplay and not too many things going on at the same time).

My main motivation is learning more about the internals of the game that fascinated me as a child (mostly Shareware, coverdisk games, unfinished game demos, etc.), partly out antiquarian interest, partly to maybe rewrite them in a modern language at some point in the far future.

Thanks for the Biplanes tip, I’ll check that out, and looking into cracktros is another good hint and probably easier to grasp than a complete game as well!

Originally Posted by jotd

would be useful if someone disassembled/RE'ed arcade games like Jungle Hunt or Bosconian.

Thanks for bringing that up but tbh I have no touching point with arcade stuff (it was ruled out for children here in Germany, haha), I think I’ll leave that to real arcade devotees

[VladR]

I honestly don't think it gets any easier than what jotd is making publicly available on GitHub as you get an actual source code you can compile, tweak and test on your own.

I'd start with something like DonkeyKong:
https://github.com/jotd666/donkey_kong

But, any other projects he's been working on and put on GitHub would work.

This way, you can at any point, instead of just using a disassembler, check the source code, which is a huge bonus in my book...

[Don_Adan]

Originally Posted by jotd

would be useful if someone disassembled/RE'ed arcade games like Jungle Hunt or Bosconian.

not amiga, but smaller thus easier. Even 16k code can be a drag, be careful!

If you want 68k there's also Marble Madness 2 that I have started

https://github.com/jotd666/GameReloc...MarbleMadness2

If I will back to life (in 1 year) and my Amiga will be still working, then perhaps I can disassemble some 68k arcade games. Many years ago I started to resourcing Japan version of Rastan. But it was only for test. I dont know other CPU's to be sure that disassembling is correct.

[Master484]

Maybe try out a space invaders clone called Amoeba Invaders. If I remeber right it only uses the CPU for everything, nothing complex, and probably was coded in ASM.

Also there is an old asteroids clone called Cosmoroids. I would imagine that both of these games are small in code size, and (hopefully) easy to analyze thanks to the very simple game mechanics.

Both of these games were on a CU Amiga magazine disk called "21 Games", which also had many other simple and small games.

[paraj]

Originally Posted by copse

What is easy? Is it something small that you can disassemble completely? Is it something that you can just jump in and work out an isolated part of and then alter that? Is it something you are actually interested in? I don't have an answer for you. I think one approach might be to pick something that interests you and which you have an incentive to complete.

One approach might be to forget disassembling or decompiling a whole game. Instead think about changing some aspect of behaviour, perhaps patching a routine. An example might be something I have at the back of my mind, I'd like to replay Captive but the mouse controls are tedious. If I just located the keyboard routines and isolated which was used for which, I could patch out those and add extra keyboard handling. Then I could patch in new keyboard handling that made replaying Captive completely keyboard driven. I wouldn't need to care about the gameplay, the graphics and so on.

I second this idea. Fully disassembling/reversing anything but the smallest programs is incredibly tedious. IMHO you'll learn more by looking at different games a bit more shallow than understanding one game completely (unless of course, that game is your white whale).

After a couple of games you'll start to notice important patterns of what you can skip, and what is probably important. You could for example set some challenges for yourself like:
- Find where handlers (interrupt/keyboard etc.) are installed and roughly what they do
- How is input handled
- See if you could make some kind of "trainer" (e.g. figure out where "lives remaining" is stored in memory)

Using ghidra on something where the source code (or close enough reference) is available is also a good exercise if you want to get more adapt at using it (e.g. defining structures) and so on.

[jotd]

Originally Posted by Don_Adan

If I will back to life (in 1 year) and my Amiga will be still working, then perhaps I can disassemble some 68k arcade games. Many years ago I started to resourcing Japan version of Rastan. But it was only for test. I dont know other CPU's to be sure that disassembling is correct.

1) you don't need amiga to disassemble.
2) Z80 is not that hard to get used to. I still cannot code in Z80 but I can understand what the code does.
3) if you have complete or 90% disassembly of something, please share!

[copse]

I have a largely decompiled Pool of Radiance I am putting aside. If people want the ghidra files let me know. I reached the point where I thought, you know I could just write my own engine and I would never have to deal with the stage where I have to get the decompiled C compiling :-) Then there's the conflicts with how the original code works and ghidra, like how the arrays are 1-based which means all the references start from the 0 point which is in the previous data. It's not a big deal but that stuff wears you down lol.

[Don_Adan]

Originally Posted by jotd

1) you don't need amiga to disassemble.
2) Z80 is not that hard to get used to. I still cannot code in Z80 but I can understand what the code does.
3) if you have complete or 90% disassembly of something, please share!

I prefer to disassembling on Amiga, even if this is slower.
From my memory, I only started to wrote program to disassembling/transcoding SPC700 code for SNES to 68000. But it was many years ago.
Learning others 8bit CPU code has for me sense, only for arcade games which I played/liked. F.e Circus Charlie, Spelunker, Pitfall, Athena.
But I think that these arcade games can be not easy for porting to Amiga, due graphics.
For now my Amigas are inactive, then no files available.
Even if some projects was finished or almost finished.

[Pyromania]

@Argh

Great question!

[Lyverbe]

Originally Posted by copse

I'd like to replay Captive but the mouse controls are tedious. If I just located the keyboard routines and isolated which was used for which, I could patch out those and add extra keyboard handling.

This is a bit off topic but just passing by to say that, unfortunately, there's no centralized location of keyboard management in Captive. It's just a bunch of 'if' scattered all around. To give you an idea, first key is checked at 417a and last at 8bf2.

[Argh]

Originally Posted by Master484

Both of these games were on a CU Amiga magazine disk called "21 Games", which also had many other simple and small games.

I think this (and the specific small games you mentioned) is exactly what I was looking for, thanks!

Originally Posted by paraj

IMHO you'll learn more by looking at different games a bit more shallow than understanding one game completely (unless of course, that game is your white whale).

After a couple of games you'll start to notice important patterns of what you can skip, and what is probably important. You could for example set some challenges for yourself like:
- Find where handlers (interrupt/keyboard etc.) are installed and roughly what they do
- How is input handled
- See if you could make some kind of "trainer" (e.g. figure out where "lives remaining" is stored in memory)

Using ghidra on something where the source code (or close enough reference) is available is also a good exercise if you want to get more adapt at using it (e.g. defining structures) and so on.

These are some great points. In a way I ended up that route because I haven’t been getting far with what I’ve been looking into so far and just started looking into the next game. But it helps me not feeling bad about it :P And my experiences really varied greatly between games, plus there’s still a lot to learn when it comes to using Ghidra and the UAE debugger (documentation seems to be very sparse).

[modrobert]

Originally Posted by Argh

Can someone point me to a list with games that you’d consider easy targets for disassembling?

Try to find games which were originally written in assembly language rather than compiled from C or other language, it will be easier to follow (except for deliberately obfuscated sections of the code like copy protection).

[jotd]

I think you should not think about disassembling something easy just to do it.

Focus on a goal (add feature, fix bug, add cheat...) on a particular game and go for it.

whdload is a good environment to apply your fixes too.

[paraj]

NB Ghidra can be a real pain in the neck for games written completely in assembly with custom calling convention. Not necessarily for understanding a specific function, but if you're reversing at a slightly higher level it can be tedious (having to use "custom storage" etc.).

Another note is that if you're working at assembly level in tandem with the WinUAE (or similar) debugger, something that takes over system and loads things at fixed addresses is much easier to deal with than system friendly stuff where load addresses may differ depending on configuration (e.g. number of enabled drives will move buffers).

[dlfrsilver]

Originally Posted by paraj

I second this idea. Fully disassembling/reversing anything but the smallest programs is incredibly tedious. IMHO you'll learn more by looking at different games a bit more shallow than understanding one game completely (unless of course, that game is your white whale).

After a couple of games you'll start to notice important patterns of what you can skip, and what is probably important. You could for example set some challenges for yourself like:
- Find where handlers (interrupt/keyboard etc.) are installed and roughly what they do
- How is input handled
- See if you could make some kind of "trainer" (e.g. figure out where "lives remaining" is stored in memory)

Using ghidra on something where the source code (or close enough reference) is available is also a good exercise if you want to get more adapt at using it (e.g. defining structures) and so on.

I did try ressourcing arcade coin-ops game programs. It's incredibly huge to do, because those games not only have a big game logic, but they also have lots of metadata for tilemaps, animations and sprites. Those are quite often coded in byte, and word. But in such quantities that from a 512kb of code, you will get a source that is 20mb in length

[jotd]

disassembling MAME games is better from MAME debugger than from ROM dumps: you only disassemble ROM code and data, but not tiles and all. I've disassembled Marble Madness 2 and it was not 20MB for a 512K game