*****DSTT Users*****
The DSTT can and will crash and corrupt your microSD card if you don't use the DSTT option! This is due to the default RAM address used by DSATM to store the trainer code also being used by the DSTT. On other cards it would just cause a white screen and nothing more but the DSTT must be accessing the FAT during this time.

Q: What is DSATM?

Short A: DSATM (DS Auto Trainer Maker) is a program that converts ARDS codes and
lets you cheat on any cart. You can optionally add a enable/disable function for the
trainer. And lastly, you can add a slowmo function to the game either with the
trainer or by itself.

Long A: DSATM (DS Auto Trainer Maker) is a program that converts AR codes into
CPU instructions (ARM). It then then injects the instructions into the game and patches up all the loose ends so you can cheat in any game without any knowledge of hacking or coding at all.

Q: How do you use it?

A: Load up the game you want to use. If you want to cheat then select the text file
that contains the ARDS codes that you want to use (properly formatted -- see below).
Select the name to save the patched game as. Now there are two methods to patching
the game. 

Simple mode:
        Click Autopatch Game!

Advanced mode:
	First (Easy) method - Autopatch:
		This will always add the code onto the end of the arm7.bin no matter 
		what is selected in the 'RAM Address' field. When using Autopatch 
		the game will patched at the beginning so that it jumps to a
		function that copies the cheat or slowmo function to the RAM Address.

	Second method - Manual Patch:
		This lets the user decide where to place the trainer if Auto Patching 		fails. After the arm7.bin (~0x23A0000+) is usually the safest place 		to place it.

Click the button with a cracker to switch between modes.

Note: If the game uses a (M)astercode always use it as the first code in your cheat file. The (M)astercode can only be used with autopatching.

*Technical explanation* The DS only allows writing to the RAM from 0x2000000-0x23bfdff before executing the game and every (M)astercode resides above this area so it won't get copied and the game will crash.

Q: How should the ARDS codes be formatted?

A: I made the code parsing code to be as leniant as possible with formatting. There
is still one rule that should be adhered to in order to avoid any problems with the
conversion process. Always label your cheat codes! This is how the program detects
where to place the next label at in the assembly code so if you don't label your
cheats then it may cause some codes to get skipped over or an assembler error.

Q: What is DEADBEEF padding?

A: The DS has 4M of RAM for the game to utilize. The binaries (or executables if you prefer) -- arm9.bin and arm7.bin only take up part of this space. The rest of the
space is inhabited by strings of 0s until they are filled up with variables, map data, text, graphics, etc. And to top it off sometimes a space that looks to be untouched is actually cleared off by the game. This is where DEADBEEF padding comes in handy. It pads up the arm7.bin to the maximum possible size (512KB). Then it is possible to find a truely good free space to use by either using DSATM to analyse a RAM dump, by looking at a RAM dump in a hex editor, or by looking at the memory in a debugger.


