Best way to get Source?

[jeepnut24]

What is the best way to get source for a game? Ive seen a few games out there, but not really what Im looking for. How well do the disassemblers work? Will I end up with source that DASM can compile?

[Nukey Shay]

What is the best way to get source for a game?

It's impossible really (unless the original source code used to create the game turns up). What you see at places like The Dig are reverse-engineered disassemblies. If they can be edited to the point that all constants are transformed into labels (making them relocatable), they are dubbed "source codes", even tho they really aren't.

 

 

Ive seen a few games out there, but not really what Im looking for.

What is it that you are looking for? Some of us have completed or partially-completed reverse-engineered files...and some games can be done fairly quickly.

 

 

How well do the disassemblers work?

I've had little problems with Distella. The tricky part is working with 2600 games that are larger than 4k (since you'll need to split the file up into multiple pieces and make .cfg files for each so the disassembler will know what areas are program code and what areas are raw data. The automatic code-detection won't work for any bankswitched carts.

 

 

Will I end up with source that DASM can compile?

More exactly, you'll end up with a disassembly that can be recompiled. Just running the game thru the disassembler will still leave many things unlabelled (like any indirect jumps, reads, etc.). In order to make the code completely relocatable so that you can add or modify any aspect of the game at will, you'll need to reverse-engineer the disassembly by tracking down all of those literal values and change them to labels by hand. It's a slow process...but not impossible.

[Nukey Shay]

Here are the steps that I take when attempting to reverse-engineer a game:

 

1 ) Split the binary into 4k pieces if it is larger than that. I use a free utility called HJsplit...that you can find on the web. If you are splitting it up, you'll end up with files that are called mspac.bin.001 and mspac.bin.002 for example. To make things easier, I just remove the ".bin" part in the middle of the names so they will be easier to type in later (i.e. use DOS's 8/3 format for the names).

 

2 ) Using Showgfx or Hack-o-matic, write down the locations of areas that are obviously raw data (like long strings of zeros, identical values, graphic images). Write them down and put them aside for a moment.

 

3 ) Look at the value near the very end of each part. Hack-o-matic or Showgfx will display this address as $0FFD ($07FD for a 2k game). This is the high byte for the starting address of the game. In 2k/4k games, it is -almost- always $Fsomething (I think Alien uses E for it's addresses)...in split binaries, each half will have a different letter (like $Dsomething for the first half and $Fsomething for the second half in an 8k game). That first letter (D or F in this example) is what you need.

 

4 ) Using that letter (or letters, if you are working with multiple parts) and the table you made in step 2, create a .cfg file for the game. The ORG value should be that letter + 3 zeros, and all those addresses you wrote down should begin with the same letter instead of the zero that HOM or Showgfx used. Open up textpad to make the file. Here's an example for Ms. Pacman...

 

Contents of mspac1.cfg:

ORG d000

CODE d000 d002

GFX d003 d007

CODE d008 d5b8

GFX d5b9 d5c1

CODE d5C2 d927

GFX d928 da41

CODE da42 db81

GFX db82 dbc7

CODE dbc8 dbff

GFX dc00 dff1

CODE dff2 dff7

GFX dff8 dfff

Contents of mspac2.cfg:

ORG f000

CODE f000 f314

GFX f315 f31c

CODE f31d f3e4

GFX f3e5 f3e8

CODE f3e9 f435

GFX f436 f439

CODE f43a f484

GFX f485 f52e

CODE f52f f5a7

GFX f5a8 f5ab

CODE f5ac fd15

GFX fd16 fff1

CODE fff2 fff7

GFX fff8 ffff

Note that all of the segments are selected as being either code or graphics. It's true that some of those parts that you've labelled as GFX are actually just data tables, but I find it much easier to use by doing it this way...so it will place each data value on a seperate line in the upcoming disassemblies...as well as showing the exact address location where each one came from in the original binary - this is very useful when trying to convert data that holds indirect address values into labels later on.

Excuse me...got a bit ahead of myself for a second

 

 

5 ) Now you are ready to disassemble. The split binary and the .cfg files should be in the working folder that Distella can "see". Enter the commands to disassemble the game...and you are best off to include switches to turn off the A register, display processor time used, include your .cfg files, etc. I always use -pafsc followed by the .cfg file name. Example for Ms.Pacman:

distella -pafscmspac1.cfg mspac.001 > mspac1.asm

and

distella -pafscmspac2.cfg mspac.002 > mspac2.asm

 

 

That's it The parts should now have easier-to-decypher assembly files made, with all the program code and data seperated. If you open them up and see a lot of undocumented opcodes or BRK instructions or such, those areas were probably mislabelled as CODE instead of GFX in the .cfg file. Edit the .cfg and try again.

 

Test out your new .asm file. Try recompiling it with Dasm to see if it plays OK before doing any changes of your own. For split binaries, you'll have to compile both halves...

dasm mspac1.asm -f3 -omspac1.bin

and

dasm mspac2.asm -f3 -omspac2.bin

 

...and then join them together...either by using the program HJsplit, or just doing a file copy with the /b switch...

copy /b mspac1.bin+mspac2.bin test.bin

...that command would join both the halves into a new binary called "test.bin".

 

 

 

 

6 ) Easy part is over. Now on to the more difficult task...you need to track down the immediate values (#$) and the data tables that hold addresses and change those into labels. Some are easy to figure out...like if the program is reading values from a table, dumping them into ram, and then performing an indirect instruction on them (like LDA ($DF),Y...the values it previously saved to addresses $DF+Y and $E0+Y hold an address. Find the areas where values are saved to those ram locations). Some are more difficult to find...like if the program is using some type of logic routine to "build" the value that is saved to those addresses.

 

If you don't plan on modifying the space required by the actual program, you should be able to skip the more difficult step 6. As long as you are filling up "holes" that you create by erasing instructions by using the NOP command (1 for every byte you take away)...you should be able to recompile it with no problems. Adding instructions to the program code, that is where you'll have to worry about decyphering them.

 

Keep in mind that if you are modifying instructions that are in the game's DISPLAY KERNAL, it is extremely important that you pay attention to the number of machine cycles used by those instructions...and match it up exactly to what your modified code is doing. If an instruction took 2 cycles, you might end up with a garbled display if you edit it to be an instruction that takes 3 cycles The 2600 is very picky about how much time is taken when it's trying to position sprites.

 

And ALWAYS save a backup before you save the edited code. I can't count the number of times this little step saved my butt!

[jeepnut24]

WOW. thanks for all the info. I was hoping to start with sometime of sprite modification and work my way up to a complete hack of some sort. Any suggestions? Megamania is my current favorite and doesn't seem to be overly complicated.

[Nukey Shay]

For sprite modifications, you can use the much quicker method of just editing them right in Hack-o-matic. This works fine for changing their appearance. Most games will also allow you to make the sprites smaller in height just by entering zeros...but to make them larger than the originals or to find out where the color locations are for them, disassembly is pretty much the only way. And a complete reverse-engineering would be essential if you wanted to even attempt something more radical...like changing MM into a Sneakers clone. If you've never worked with machine-language coding before, I'd suggest that you started with a platform that is not as dependant on precision...like using Atari800Win's monitor mode But if you are only interested in changing properties such as sprite colors, even a quick disassembly of a game should point you in the right direction to find which bytes to change. Take note of the instructions that save values to the COL registers (distella will label them automatically)...and backtrack to find where those values are coming from.

[jeepnut24]

I was thinking more about changing the sprite shape rather than just color or size.

[liquid_sky]

you can change the shape in hack-o-matic really easily.