Romhacking => Newcomer's Board => Topic started by: Meijin on February 20, 2013, 05:02:10 am

Title: 6502/65816 Assembler
Post by: Meijin on February 20, 2013, 05:02:10 am
Do you guys know which assembler is best suited for these two platforms? Can I have it? Thanks.

I found this assembler on google, but it seems I can't get it run properly, is there anyone willing to download it and have a try and tell me how to run it?

I just stepped in the programming world so can you tell me the difference between Assembler and Dissassembler?
Title: Re: 6502/65816 Assembler
Post by: LostTemplar on February 20, 2013, 05:39:41 am
I just stepped in the programming world so can you tell me the difference between Assembler and Dissassembler?

No offense, but if you have to ask this, you're probably not ready for assembler...

An assembler takes your human-readable mnemonics (i.e. NOP -> $ea) and translates them into the target machine's machine code. Most assemblers also support more high-level features like macros, for example.
A disassembler is just the other way around: it takes the target machine's machine code and converts it back to human-readable mnemonics (i.e. $ea -> NOP).

So, the assembler is the tool you use to produce new code, and the disassembler the tool you use when or if you want to reverse-engineer existing code (that's not available in human-readable form, for example your favorite game's ROM).
Title: Re: 6502/65816 Assembler
Post by: DougRPG on February 20, 2013, 11:46:59 pm
Can I have it? Thanks.

??  :huh:

As LostTemplar said, probably you are not ready. You need to study a lot of programming first, and in some years you can try again. This is not a begginer stuff.
If you cannot even run a program, you have a lot of work to do first.
Title: Re: 6502/65816 Assembler
Post by: FAST6191 on February 21, 2013, 12:58:14 pm
Though assembler and disassembler are not exactly flammable and inflammable territory and I would agree proper assembly is likely to take years to get to a lot of damage can be done with just a few skills.

That said I have no particular answer to the matter at hand and I will not insult you by spending 30 seconds searching and picking out the best result there.
Title: Re: 6502/65816 Assembler
Post by: Meijin on February 22, 2013, 04:43:35 am
I thought as much, I'm just curious.

Can I ask one more question? It's my intent to become most involved in making cheat codes (i.e, game genie) and not in translation work. If so, on which parts of ASM should I focus and which ones can I ignore?

I've done a few cheat code hacking techniques and a bit familliar with the basic mostly some infinite codes. But the advanced codes such as no encounter, one hit kill, etc require ASM knowledge.
Title: Re: 6502/65816 Assembler
Post by: FAST6191 on February 22, 2013, 07:31:51 am
Cheats are one of the entry level (at times) assembly type hacks. I assume we are observing the gamegenie= rom altering, gameshark/codebreaker=memory manipulation distinction. Game genie is little more than patching method so I will ignore any formatting there. I should note that the DS and many modern systems will have their binary (as in the code that touches the processor) in memory so memory cheats on such systems can be very far reaching as you can edit them like you would any other section of memory.

Realistically I could argue that assembly of any form requires every type of computing knowledge and cheats do not escape that (I could easily make an example requiring database and network knowledge and there is also the "glitching" side of things but we will avoid that one for now). In practice I think we can find a middle ground.

Basic gameshark to assembly (and so game genie) takes one of two routes in my experience
1) You build a proto memory manipulation cheat engine- these devices will hook the code every vblank or some such and write the value that needs writing. You replicate this in the code but altering the game binary (otherwise known as hooking the binary) to add this memory manipulation.
2) You edit the game. Say for losing health there is probably a routine in the game that in higher level coding would read something like
IF [character hit]
THEN [do damage calculation+knockback+whatever]
ELSE [carry on with life]
Rather nicely if you already have a memory cheat for this then you can get a debugging emulator to halt the game when it sees something tickle this memory area.
Anyway many are your options at this point- the basic method would be to find the eventual "sub" instruction* for the health and turn it into an add, turn it into a NOP (no operation- it does it and skips to the next one) or do something else entirely.
The better method would possibly be to find the "if character hit" and make that a NOP or change the branch to always follow the "not hit" route.
This also brings you onto the walk through walls cheats which are somewhat similar. This is also where the "you must learn it all" things come into play- some games will run a parallel "track" (quite literally in a racing game) to adjust abilities accordingly, other games will have collision detection (I am sure we have all seen 3d games use paper thin things and call it an object, also I am sure we have all fallen through the level at some point). Still negating or modifying such things should be but a thought exercise once you have figured out what methods it uses.
Moon jump.... similar and not. If the game has double jump you are laughing as you just have to find the "check when air/double jump is done" section and patch it out- you can do this with basic cheats if you are good (it is likely just a little flag in the memory) but I would agree it helps if you have assembly skill to get there. Otherwise.... two main schools in you either modify movement (if jump pressed then move character 3m in the air becomes 6m in the air or a nice accumulator function if you are better) or kill gravity.
Spectator/ghost modes are a different matter- some might choose to use variations of the above two methods, some might have to code something properly and some might choose to find a spectator/ghost mode already in the game and force movement controls onto that.
One hit kill have various methods. The obvious one would be to crank the damage up to 11, another could be to use a variation on the "if hit" back in infinite health but apply it to an enemy and trigger their death routine, another would be to weave between the two and drop the enemy health to zero leaving the game to take care of the rest.
No encounter... much like moon jump if the game has an encounter manipulating spell/item you are laughing (if it completely avoids "all but boss" you can probably even do it in a memory cheat and even do it without so much as contemplating assembly if you are fast on the memory dump/scan commands- normal and scan it, immediately use encounter item and scan it- you probably now have infinite encounter items and infinite no encounter or a small enough pool to do it well). If it is a drops by 75% option it gets harder as you have to figure out what it does and how it works- if it is just a storage value and can be cranked to 100% you are laughing once more but if it is a hardcoded 75% then other things might have to happen. Should you be doing it "properly" or not have items then it might be best to figure out how random is random- is it a timer of sorts, is it number of movements..... and hose that up (again you might be in memory manipulation country). You could also do the actual routine governing it. Games with touch this enemy on the world map to encounter (my favourite sort of method here) probably want to go back to the hit detection side of things. My favourite anecdote here is skies of arcadia on the dreamcast would spin up the disc shortly before a random battle but I am not sure where I want to go with that right now.
I know your little list was examples of things you aspire to pull off rather than actual examples needed so I will stop here for the time being.

I took pains above to cover just how many options there are available to you for as you are changing how the game works you may have broken the game in some form- how many RPG games have the "must lose this to further story" fight? How you work around this is up to you- you can make it selectable, you can force it, you can instead make a button combo to refill health..... so you hopefully you can see why you need to think almost in circles. Trouble is such thought patterns are often the antithesis of modern programming languages (Python makes an effort to contrast itself with Perl and other languages that do have many ways to skin a cat) so you might face a measure of unlearning. Of course the games you play on (especially older consoles) had programmers with similar decisions when they were programming the thing in the first place (and as anybody that has done this at length will tell you- these programmers are not always functioning at "masters of the art on their very best day" level).

For an example on the point above there is nothing stopping the game from having many methods to do the same thing, the example I was given and will now give is think how many ways there are to die (and lose a life) on the original mario for the NES
Fall down a pit
Hit an enemy
Hit an obstacle
Run out of time
Later games also had false mushrooms, you could be trapped by movement....
In each case it might have a sub instruction to lose a life for each of them as branching is a pain and though memory is tight it would usually stretch to two instructions.

There is nothing stopping you from combining the two schools, indeed some of the "selectable option" type trainers do exactly this.

Another anecdote- 007 mode on Goldeneye on the N64. You could choose damage, accuracy, health and more for your enemies. Such functions also played into any allies you had (negated somewhat by a magnum being Natalya having a magnum) and are a nice example of programmer shortcuts and the "break the game" logic.

*Assembly uses mnemonics which are short letter combos and sometimes phrases that indicate what they do- some processors will have hundreds and some only a handful, in almost all cases there are only about 20 core ones (arithmetic, boolean logic, memory manipulation and branching) used for almost everything and the others are variations on those themes (straight branch, branch if conditions met, branch if other conditions met....). More complex processors like the modern X86/X64 (what your PC most likely runs on) do have very complex instructions for very specific tasks, most consoles up to the likes of the original xbox (which was basically X86) will be relatively simple though.

To answer your question in a far shorter manner you are going to have to learn data representation, this is true of all ROM hacking though but here you can probably afford to/will want to spend more time learning about how arrays, how things can be stored in memory (computers do like their 8 and 16 bit sections but there is nothing stopping the upper 4 bits, or some other arbitrary amount, from being something entirely unrelated to the other section, it usually is related in some way but if you are looking for a simple number flipping the top bit of it changes the number entirely) and probably pointers (not sure how common memory pointers are as far as cheats go on the earlier consoles, the DS and GBA use them all the time though) where most would be ROM hackers will spend most of their initial time contemplating how to find tables for a game and other such things. The actual manipulation is seldom more than basic arithmetic and boolean logic (primarily as processors seldom do more than basic arithmetic and boolean logic) and for most cheats (including the complex stuff) you will probably not have to write any more than a basic subroutine at best.

I did prattle on a bit in my GBA/DS guide but for now I think PC style assembly ( , and on top of your existing code making will be better. If you have not already read it then for pretty much every console is also on your reading list.
Title: Re: 6502/65816 Assembler
Post by: Meijin on February 22, 2013, 11:55:20 pm
so there's so much for me to learn about before attempting to make some of those advanced codes huh. I need to know the general assembly before taking on the specific processor that I want to dig in, is that right?

As amazing as always, FAST6191. Your posts have been very helpful.
Title: Re: 6502/65816 Assembler
Post by: FAST6191 on February 23, 2013, 05:35:35 am
Before you can wander up to any game and expect to have a good chance of getting something done then yeah it will be a lot of learning.

Before you can find a game that you can get something done on then not so much.

A rough equivalent would be for your RAM codes where you just need to find a static location that is the exact value you are looking for and you have your cheat vs throwing the person that just learned to do that into a situation where the RAM section during runtime (maybe even a pointer to a pointer), is otherwise encrypted/mirrored/complementary and has say the upper 4 bits of an 8 bit code saying what item it is and the lower 4 saying how many (that would also be a better example of the combined values things- I do still want to stress it does not have to be related in the slightest though) and expecting them to get far.

Here we sometimes see a few problems- most people that wander in hell bent on translating a mega 90 hour epic RPG are one thing and will usually be pointed at something simpler. However related to that I would not be surprised in the slightest if I went to tackle a "simple" puzzle game tomorrow and found myself beating my head against some high end maths, some spectacular coding, some terrible coding (trying to guess what someone less competent was trying to do is often hard enough if you have source code, looking at assembly does not always make that easier) and I would not be surprised to see them using some form of bytecode scripting language instead (probably not so much on machines sporting any of the processors you listed though but when you do encounter it then it is often a nightmare to pull apart directly from the assembly level)- Puzzle Quest on the DS uses a bytecode form of lua. However you might have already met this in RAM code making so abandoning a game and moving onto another or getting settled in for a 3 month project to make an infinite health code to a licensed game that nobody really wants to play might not be such a problem for you.
Have a go at reading the first few sections of the tonc ASM guide (for the GBA) and have a go at following along with (also for the GBA). However I will return to the moon jump in a game with double jump example from earlier - I would much rather have that on a complex DS game (I am thinking castlevania at this point) than try to figure out the same for the first NES Mario (assuming I am equally good at both systems with equally good tools for them both). Similarly taking a cheat for infinite lives, doing a disassembly of the game to find (disassembly makes plain text you can search in notepad) what function manipulates the location the cheat describes, seeing the read, the subtraction and the putting it back in memory and then you swap in an add for the subtract instruction- congratulations you have just coded the game to have infinite lives (possibly until it crashes for having too many to hold but then you might go back and instead of add have a command to set a value).

General assembly is something that possibly does not exist by virtue of it being able to be inferred from any other processor; you might find yourself annoyed at the syntax (mov r1, r2 might mean copy the contents of r1 into r2 or it might mean copy the contents of r2 into r1 depending upon the assembler you are using- the same architecture can have different assemblers though it is considered somewhat bad form to do the opposite of the dominant assembler for that architecture, on the other hand you could move from a 68000 to an ARM processor and what was bad form is now "suck it up and deal with it or code your own assembler for it"- coding your own/tweaking an existing one is often what happens and drama ensues), you might trip up with the different flags (carry flags, results of compares used in later branches.....), you might get tripped up by memory handling (in X86 having instructions write directly to/read directly from memory is normal enough, in ARM7 and ARM9 which the GBA and DS use then you can still write to memory via the processor but it is only available to a handful of instructions geared at that task) and if you are going backwards to older processors you might lose out on something (not every processor has a divide instruction or a divide instruction that moves with any haste, it might appear in the hardware though* or you might have to set up log tables or you might have to code around it- I want a third of the experience for this battle still generates the same result as I want three times experience for this battle if you set things up properly****).

*I avoided mentioning this but beyond the processor you often also have maths capable hardware, maths capable BIOS instructions and similar such functionality, if it was just learning CPU then it would possibly not be so bad but chances are you will also have to learn the hardware as well. Where most ROM hackers will probably also want to learn the graphics subsystems as well though you can probably get away with a lot less there**. Also yes this means that while I probably can claim a reasonable knowledge of the ARM7 and ARM9 processors thanks to the GBA and DS if you threw me onto a tablet that also uses a similar instruction set I would probably have a lot of reading to do.
In the case of the divide function in hardware he DS has this- you write values to a memory location and so many cycles later the result will appear at another,
I do not know if you know much of boolean logic at this point but think how the NAND function is a universal function if you chain enough of them that are set up in the right way or more likely that several things that sport boolean logic functions will tend to omit a handful of them save NAND, OR and XOR as you can OR something and then do a NAND against FFFF to get NOR and so on.

**saying that a few games do use OAM (graphics are broken into three formats- backgrounds, sprites/objects and 3d if the system has 3d with them having memory and being handled by another section of memory) and that OAM stuff can make for walk through walls, especially on "single screen" type games***.

*** assembly knowledge, much like ROM hacking in general, has an alarming tendency to see you know every aspect of the game from the maths that underpins it and upwards. This can make you a terrible bore and can see you pick apart everything that crosses you path which some find reduces enjoyment (for me it went the other way and now I would not trust me to be an arbiter of taste).

****especially fitting in light of the *** above is yeah you will probably also run up against game logic vs computer logic at some point- for the multiplier above switching the div for a mult might well work but it could also break progression in the game that was otherwise hardcoded to make for difficulty/ease.

Judging by my ever increasing list of asterisks I am starting to waffle so I will tie it off again for the time being.