Romhacking.net

Romhacking => ROM Hacking Discussion => Topic started by: tomaitheous on February 05, 2014, 04:43:40 pm

Title: Asm hacking
Post by: tomaitheous on February 05, 2014, 04:43:40 pm
Curious, how do you guys handle your ASM hacking projects?

 Do you use a hex editor to do all your asm hacking, or do you use an assembler? If you use an assembler, do you assembly directly into the rom or do copy the assembled code into the rom?
Title: Re: Asm hacking
Post by: KC on February 05, 2014, 04:55:54 pm
The worst thing you can do is hard code changes into the binary. So I'm using an assembler that creates modified copies of the executables and overlays. It's very important to me that every rebuild starts with a clean state.
Title: Re: Asm hacking
Post by: tryphon on February 05, 2014, 05:30:00 pm
For my Genesis hacking, I use Easy68K to write my hacked routines, then I wrote a python script to insert it to a clean ROM.

For PS2 and PSP, I use a very basic assembler (PS2DIS), and a Python script I wrote that copy the binary data in free space (it handles the free space), insert a jmp in the right place of the code, and add a jmp at the end of my custom code to where it should go back to the original code. Here again, I start from a clean ROM.
Title: Re: Asm hacking
Post by: Scio on February 05, 2014, 05:47:40 pm
I have a clean ROM where I insert the assembled code into, then I just copy the HEX to the ROM of the game I'm working on (taking care to leave a JMP at the end of it).

I used to copy directly into the ROM, but I always forgot to account for space, so it's better that way.
Title: Re: Asm hacking
Post by: Drakon on February 05, 2014, 06:17:20 pm
Curious, how do you guys handle your ASM hacking projects?

 Do you use a hex editor to do all your asm hacking, or do you use an assembler? If you use an assembler, do you assembly directly into the rom or do copy the assembled code into the rom?

Just a hex editor and notepad to type out my hex before copying and pasting it in.  The more I manually plunk in the more I memorize the codes and the faster I can work that way.
Title: Re: Asm hacking
Post by: FAST6191 on February 05, 2014, 06:59:58 pm
Most of my assembly projects are reverse engineering.

If I can apply it in cheat form I will do that.

Otherwise I will have text form and write and inject either with the assembler or by hand. I tend not to do massive rewrites of functions.

Either way a hex editor is not the tool I would be looking at for anything beyond injection of a few instructions. Text editor with some basic syntax, possibly nice IDE level text editor should I be making use of things like being able to name my memory locations, and then have the assembler insert or insert by hand if I need to do something special.
Title: Re: Asm hacking
Post by: snarfblam on February 05, 2014, 09:59:25 pm
I've never been a fan of hex editing ASM. Much like KC, for me a build process is important. I actually wrote my own 6502 assembler because, well, because I'm picky and wanted certain features. My assembler actually generates symbol files for FCEUX so things (http://dl.dropbox.com/u/12027218/Shared%20Images/AutoDrop/autodrop208.png) are easier to understand in the debugger (http://dl.dropbox.com/u/12027218/Shared%20Images/AutoDrop/autodrop207.png).

This type of process lets you easily organize and modify code without having to keep track of every little byte you've changed and makes debugging over 9000 times easier.
Title: Re: Asm hacking
Post by: STARWIN on February 06, 2014, 11:40:01 am
Just a hex editor and notepad to type out my hex before copying and pasting it in.  The more I manually plunk in the more I memorize the codes and the faster I can work that way.
This is how I do it as well, though I'm not so interested in memorizing things than I'm interested both in understanding the low level well enough and simply in avoiding tools that I would have to learn to use (or code?). I have only done small hacks though.
Title: Re: Asm hacking
Post by: FAST6191 on February 06, 2014, 12:05:05 pm
Would it then be wrong to say the general consensus is you should be able to hand encode/decode an instruction but realistically actually doing it should be left as a party trick.
Title: Re: Asm hacking
Post by: KC on February 06, 2014, 12:42:05 pm
Would it then be wrong to say the general consensus is you should be able to hand encode/decode an instruction but realistically actually doing it should be left as a party trick.
That may realistically work on primitive CISC cpus, but I want to see someone do that on a complex ARM instruction.
Title: Re: Asm hacking
Post by: tryphon on February 06, 2014, 12:56:53 pm
Even on a 68000, which is not exactly a RISC, I want to see...

Why on earth would you want to manually assemble/dissassemble something ?

Among other things, it'd show you didn't understand that if something doesn't require thinking (and so is assembling), then a computer will do it much better than you. So you're probably a bad programmer.
Title: Re: Asm hacking
Post by: justin3009 on February 06, 2014, 01:28:28 pm
I only do SNES right now, but I tend to have Geiger's open to make any physical changes, but if it's changes I make that are REALLY bad, I have the same ROM open in Translhextion BEFORE the changes.  So if it ends up bad, resave with Transl then reload with Geiger's.

Of course, I make back-ups as well before any MAJOR overhauls.  But minor ones I just do the method above.
Title: Re: Asm hacking
Post by: FAST6191 on February 06, 2014, 01:43:32 pm
I was thinking more if you have something like http://nocash.emubase.de/gbatek.htm#armconditionfield (scroll up a tiny bit) or http://nocash.emubase.de/fullsnes.htm#cpumemoryandregistertransfers in front of you then you should be able to hand encode or decode an instruction, anything after that though is you just showing off.
Title: Re: Asm hacking
Post by: Zoinkity on February 06, 2014, 02:43:16 pm
I'm almost always shoving new code into a spot made by rewriting existing code, and since R4300i assemblers aren't exactly numerous to begin with I find writing everything by hand a lot easier.  Plus, to avoid changing sometimes thousands of hardcoded hardware addresses, it's nice to just hand code something that might burn a few cycles but with enough redundancy to ensure it compresses within the same block size.

N64 hacking is a bit of a party trick anyway, but even for larger swaths of code it's just a lot easier to know it's going to fit, not fry half a dozen registers, or complain about some stupid voodoo magic or external reference it blasted well doesn't need to know about. 

So, at least in my case, it's hex editor the whole way.
Title: Re: Asm hacking
Post by: infidelity on February 06, 2014, 03:42:09 pm
I hack completely via a hex editor. I like to be able to view everything with the Code Data Logger within FCEUX.

Everyone has they're own method of writing 6502. I happened to learn mostly from kuja killer, and that was how he wrote/modified 6502 asm.

I can look at hex values and know just about all of the opcodes for them from memory.

I've gotten so much flack from people saying I don't know how to do asm if I do it via a hex editor. It doesn't matter how you write it or what method you use, as long as it works.

I'm sure if I learned from someone else, and they actualy 'wrote' it out, then probably today that would be the way I write asm.
Title: Re: Asm hacking
Post by: KC on February 06, 2014, 04:28:19 pm
... and since R4300i assemblers aren't exactly numerous to begin with I find writing everything by hand a lot easier. ...

N64 hacking is a bit of a party trick anyway, but even for larger swaths of code it's just a lot easier to know it's going to fit, not fry half a dozen registers, or complain about some stupid voodoo magic or external reference it blasted well doesn't need to know about. 

It's a bit off topic, but if you really do spend a lot of time on this, armips (https://github.com/Kingcom/armips) might be something you could make use of. It currently lacks anything N64 specific, but it's open source and if you are interested, you could contribute those parts. Most of the instruction set is already there, too. It comes with lots of other features too, one of which is checking that code doesn't get bigger than a size you specified.
Having a decent assembler for N64 would definitely be neat.
Title: Re: Asm hacking
Post by: FAST6191 on February 06, 2014, 05:26:28 pm
I've gotten so much flack from people saying I don't know how to do asm if I do it via a hex editor. It doesn't matter how you write it or what method you use, as long as it works.

Did you mean "people can not follow me" or "because I hand encode/decode people say it does not count". For the latter then people are wrong, for the former then fine but I am not sure it is a good thing.

As for "as long as it works"... devs doing that is I believe why we end up with threads like http://www.romhacking.net/forum/index.php/topic,14700 , one of the reasons project failure rates are so high and generally why ROM hacking is not easy as it might be.
Title: Re: Asm hacking
Post by: Drakon on February 06, 2014, 06:12:33 pm
This is how I do it as well, though I'm not so interested in memorizing things than I'm interested both in understanding the low level well enough and simply in avoiding tools that I would have to learn to use (or code?). I have only done small hacks though.

There's actually not that many opcodes to learn for some 8-bit systems.  The better I'm understanding the asm the faster I'm getting at writing my own code.

I hack completely via a hex editor. I like to be able to view everything with the Code Data Logger within FCEUX.

Everyone has they're own method of writing 6502. I happened to learn mostly from kuja killer, and that was how he wrote/modified 6502 asm.

I can look at hex values and know just about all of the opcodes for them from memory.

I've gotten so much flack from people saying I don't know how to do asm if I do it via a hex editor. It doesn't matter how you write it or what method you use, as long as it works.

I'm sure if I learned from someone else, and they actualy 'wrote' it out, then probably today that would be the way I write asm.

That's exactly how I work too so don't feel so bad about the flack you get.
Title: Re: Asm hacking
Post by: snarfblam on February 06, 2014, 06:21:09 pm
I've gotten so much flack from people saying I don't know how to do asm if I do it via a hex editor. It doesn't matter how you write it or what method you use, as long as it works.

Hey, nice to see you on RHDN!

I doubt most people question your ability to write ASM. The only time I've seen anyone give you flak is on NesDev, when you posted code in raw hex. For those of us who don't code in raw hex, it's meaningless numbers (and on a homebrew forum, everyone uses an assembler).

You're a better hacker than I. It's just that I honestly don't understand how you keep track of so many things with your extensive hacks using only a hex editor (and notes, I presume). I couldn't do it. I'm kinda scatterbrained, so I need lots of management and organization with my projects.
Title: Re: Asm hacking
Post by: Pokeytax on February 06, 2014, 07:07:57 pm
When doing Dreamcast hacking, I have been doing SH-4 coding by hand with a reference for lack of an alternative - that's fun. Lots of copy and paste of existing code.
Doing GBA/NDS hacking, I generally just use NO$GBA's change instruction to alter the code and obtain the hex.
Doing PSX hacking I definitely used an assembler (actually the cross-compiler MassHexASM although armips is perfectly adequate).
For actual insertion a hex editor.

I guess it varies by the situation.

Curious if there's any difference between professional coders and pure hobbyists. Personally I don't have a computer science background, avoid command lines when possible, and do things like compression and script extraction & insertion in Excel VBA because that's what I use every day at work. All my routines use Excel as an IDE with formulas to handle branch offsets, etc. If coding were my job that kind of sloppiness and inefficiency would probably horrify me, but it's the path of least resistance. I'm sorry to the people who made nice tools I am too clueless to use  :(
Title: Re: Asm hacking
Post by: FAST6191 on February 06, 2014, 07:48:36 pm
The self taught/hobbyist/education/type of education divide is a huge point of discussion/contention within computing in general (see why we have more than object oriented, functional and return oriented programming). That really should be a subject for another thread though.

Around here.... assembly is something of an abstract concept in the modern world and is typically not taught, likewise where professional coder ends and hobbyist begins is an odd one; I can be a professional PHP coder but a hobbyist assembly coder and likewise I can mess around with VHDL all day but knock about with python on the weekend. To that end I am not sure I can use the distinctions you made, as tempting as they might be. This all says nothing of ROM hacking tending to "go the other way" either -- everything from the halting problem onwards says compilation is a one way affair so some of this by necessity has to be somewhat slap dash.

However I would be surprised if RHDN counted people that absolutely and rigidly adhered to "best coding practices" when it comes to assembly type things, mainly as the "break it down into blocks" method kind of demands it.
Title: Re: Asm hacking
Post by: KingMike on February 06, 2014, 08:16:55 pm
For NES I assemble the hex by hand. It's small enough to be manageable, plus you tend to use the same opcodes so much you memorize them so it's not too much work to look up an unmemorized opcode when needed.

For SNES, I use xkas for ASM insertion and minor data changes. For major data insertion (like compressed graphics), I use my own tools.
Title: Re: Asm hacking
Post by: Pennywise on February 06, 2014, 09:14:53 pm
For the NES, I usually write up the ASM in notepad and convert it to binary, which I then insert through the hex editor.

For GB, I use GB Assembler Plus which is really fucking convenient and easy to use. It basically has its own built-in notepad and lets you load ROMs to insert the ASM.
Title: Re: Asm hacking
Post by: Drenn on February 06, 2014, 09:54:47 pm
I mostly work with the GB(C) using bgb and wla-dx. wla-dx allows me to put my code on top of a base ROM, so it takes care of the code injection for me.

I couldn't imagine doing a large-scale ASM hacking project without an assembler. Memorizing the opcodes would be tedious, but that's not the main problem... the assembler is simply much more flexible. I can move code around, define labels, insert comments, easily. This is all stuff I consider necessary for big assembly hacks.

Where a separate assembler is overkill, I'll just use bgb's debugger to insert small ASM patches. Very convenient.
Title: Re: Asm hacking
Post by: tomaitheous on February 06, 2014, 10:32:54 pm
I mostly work with the GB(C) using bgb and wla-dx. wla-dx allows me to put my code on top of a base ROM, so it takes care of the code injection for me.

I couldn't imagine doing a large-scale ASM hacking project without an assembler. Memorizing the opcodes would be tedious, but that's not the main problem... the assembler is simply much more flexible. I can move code around, define labels, insert comments, easily. This is all stuff I consider necessary for big assembly hacks.

 I feel the same way. The flexibility of an assembler is a must. Changing even a one or two instructions, or such, can change source code and code alignment. I can't imaging doing that by hand, unless the replacement code was nothing more than a few bytes.


I hack completely via a hex editor. I like to be able to view everything with the Code Data Logger within FCEUX.

Everyone has they're own method of writing 6502. I happened to learn mostly from kuja killer, and that was how he wrote/modified 6502 asm.

I can look at hex values and know just about all of the opcodes for them from memory.

I've gotten so much flack from people saying I don't know how to do asm if I do it via a hex editor. It doesn't matter how you write it or what method you use, as long as it works.

I'm sure if I learned from someone else, and they actualy 'wrote' it out, then probably today that would be the way I write asm.

 Well, that's not ASM or Assembly. That's "machine language". I mean, if you're writing code directly in a hex editor. Assembly has a syntax, even if it's nothing more than bare bones mnemonics (although almost all assemblers have a higher level functionality to them as well). There's nothing wrong with that though, if you're completely comfortable with that approach.


 Being an assembly programmer and being an assembly hacker, aren't mutually exclusive. Being one, doesn't equate to being the other. Well, IMO. Don't get me wrong, I'm not here to criticize anybody. Hackers (that hack code) are a strange and special lot. The patience and time it takes to unravel someone else's code and understand it; not every programmer is cut out for that kind of stuff. And so I was curious, how many people moved onto using an assembler for their replacement code in hacks. Of course, I'm assuming most here don't have a background in assembly programming.   



 Anyway, for asm hacking - I always include the base rom or binary (extracted from CD) into the assembler and simply assemble new code directly over it. Same with data. Here's just one small file, of many, for my Megaman hack:
http://pastebin.com/3uXBMrAW

Title: Re: Asm hacking
Post by: Scio on February 06, 2014, 10:59:29 pm
Well, that's not ASM or Assembly. That's "machine language". I mean, if you're writing code directly in a hex editor. Assembly has a syntax, even if it's nothing more than bare bones mnemonics (although almost all assemblers have a higher level functionality to them as well). There's nothing wrong with that though, if you're completely comfortable with that approach.
He's talking about translating the syntax into HEX. Like in z80, a FA is "ld a," a C3 is a JMP, a 00 is a NOP, AB is "xor e" and so on.
Title: Re: Asm hacking
Post by: optomon on February 07, 2014, 12:18:37 am
I use just a hex editor. Probably not the most proficient method by any means, just how I learned to do it. And also because I'm a masochist that has really bad ADD who likes to obsessively play around with hex numbers and is too lazy to get accustomed to using an assembler.
Title: Re: Asm hacking
Post by: KaioShin on February 07, 2014, 03:45:54 am
Editing code via a hex editor is bad on so many levels. This thread really makes me sad.

Here is a HUGE reason against it no one brought up yet. You can't easily keep track of changes. If you have all changes in a (well documented) ASM file and you notice hours or even weeks later that an old hack broke something, you can just uncomment all your changes one by one and identify the problem. You can easily reverse individual parts of your changes. If you edit the ROM directly and something breaks you are FUCKED. In most cases you can just as well start over from scratch.

Add up the hours you wasted chasing bugs and calculating mnemonics and compare it to taking 1 hour to learn how to use an assembler properly. This situation is like digging a hole with a spoon because no one showed you how to use a shovel instead.
Title: Re: Asm hacking
Post by: BRPXQZME on February 07, 2014, 04:06:59 am
That strikes me more as a not-using-a-repository issue :P
Title: Re: Asm hacking
Post by: Gemini on February 07, 2014, 06:05:38 am
Totally agree with Kaioshin's post. You don't wanna edit and stack changes with a hex editor, you better off start with something that can be recompiled entirely, just in case something gets broken in the process. Usually I have a couple batches that redo the full hacking process, doesn't matter if the source data is original or already hacked assets. Whenever something gets broken in my process, I simply restore the original data, revert the last source changes, hit compile and see if the issue goes away. If it does, I can start looking into whatever is causing the problem, but the rest of the hack still stays in place and gets preserved for good.
Title: Re: Asm hacking
Post by: Drakon on February 07, 2014, 08:09:45 am
Editing code via a hex editor is bad on so many levels. This thread really makes me sad.

Here is a HUGE reason against it no one brought up yet. You can't easily keep track of changes. If you have all changes in a (well documented) ASM file and you notice hours or even weeks later that an old hack broke something, you can just uncomment all your changes one by one and identify the problem. You can easily reverse individual parts of your changes. If you edit the ROM directly and something breaks you are FUCKED. In most cases you can just as well start over from scratch.

Add up the hours you wasted chasing bugs and calculating mnemonics and compare it to taking 1 hour to learn how to use an assembler properly. This situation is like digging a hole with a spoon because no one showed you how to use a shovel instead.

Uhm, I sometimes use winhex file compare to compare my hack to the original to find the change I made that broke the game.  Although lately I've been finding my changes that break things just by using the fceux debugger.

I agree using an assembler makes sense for large projects but it's not impossible to do it manually.
Title: Re: Asm hacking
Post by: Kajitani-Eizan on February 07, 2014, 08:37:37 am
That strikes me more as a not-using-a-repository issue :P

that merely shifts the job from figuring out where the issue lies to when the issue lies :P

and i can't believe you guys do any assembly work beyond changing some immediates or really minor work changing maybe ~20 bytes total without using some kind of assembler and/or build system. this hex editor and notepad stuff sounds like hand-repointing strings to me :P
Title: Re: Asm hacking
Post by: Pennywise on February 07, 2014, 08:52:02 am
I will say I'm still kinda in the middle of using a hex editor and using an assembler for my asm hacks. My older projects are especially bad, which are at least several years old before I started to evolve as a hacker. One project in particular I screwed up in parts by accidentally changing bytes and not changing them back. I've had to make extensive use of debugging, tracing, and ROM comparisons for single byte changes/fixes.
Title: Re: Asm hacking
Post by: Scio on February 07, 2014, 08:52:56 am
and i can't believe you guys do any assembly work beyond changing some immediates or really minor work changing maybe ~20 bytes total without using some kind of assembler and/or build system. this hex editor and notepad stuff sounds like hand-repointing strings to me :P
I once worked in this game that used a routine which mirrored the hiragana and katakana parts of the font, and used the first byte of a text string to tell which was which. This was quite lazy thinking from the programmer ("I'll just write everything in hiragana and change it to katakana when necessary"). Maybe the guy didn't know how to call the tiles directly (or he was just lazy). I tried modifying the routine to make use of the whole tilemap without any kind of mumbo-jumbo, but it was a mess, so I had rewrite one from scratch.
Title: Re: Asm hacking
Post by: Gideon Zhi on February 07, 2014, 01:06:41 pm
Most of the larger changes I make I assemble using xkas (yes, even for the NES) though I freely admit to committing the faux-pas of hexing smaller changes in by hand. (NOPs, branch adjustments, individual byte or byte-pair changes, that sort of thing) I know I shouldn't, but the changes always seem insignificant in the grand scheme of things :/ But past that, my assembly scripts are usually spread across multiple files. I generally have a batch set up to assemble them all into the binary at once, though when I'm testing new code individually I'll keep a terminal open and just re-run xkas manually when things inevitably break the first few tries.
Title: Re: Asm hacking
Post by: Zoinkity on February 07, 2014, 03:02:22 pm
Noticing the general trend is "limit hexing to minor changes on systems using variable-length opcodes".  That's perfectly understandable really, especially to ensure longer jumps/branches don't die a horrible death at the hands of a 1-2 byte push.

Repositories are more useful than a simple when.  If you're using them appropriately, you'll know what change caused the error, allowing you to work out where it lies.  Anything more than a simple, mundane change--such as altering a struct or data type--has probably changed more than one tiny snippet of code. 
Title: Re: Asm hacking
Post by: BRPXQZME on February 07, 2014, 03:28:22 pm
that merely shifts the job from figuring out where the issue lies to when the issue lies :P
You say that like they’re equally easy to deal with!

For instance, git bisect lets you do binary search on a bug/feature, git blame tells you when a certain line was changed, and git log -S lets you search for additions/removals of a string. In addition, you can get the usual benefits of repos like starting branches to experiment on different features without touching your golden baby build.

Merely switching to asm lets you do only one of these things, and only as of the last revision. It certainly doesn’t make backups for you.

Be it known, however, that git in particular is not good at binaries and very much assumes you are working with some sort of text, preferably source code with lines; you’d want to convert to some form of text to get these benefits, even if it’s just a hexdump. But still, assembly is more wieldy than hex for most systems (unless you’re Mel Kaye (http://www.catb.org/jargon/html/story-of-mel.html)), and commenting wherever you like is still a pretty good reason to use it. Though, none of this will keep you from clobbering offsets; that’s still your job (unless you have tools for that?).
Title: Re: Asm hacking
Post by: Grimoire LD on February 07, 2014, 04:26:42 pm
For what is worth I do all of my hacking in a combination of reverse engineering (I guess that's what its called? I technically follow examples that I had seen before in other parts of the game in some manners) in Geiger's SNES9X in real time so if a problem appears I can deal with it as soon as it shows up.

I have labelled and translated all spells and commands (along with some other parts of interest to me) in FFIV and deriving their true meanings from ASM (using the Tower of Babil docs as a starting point). It is extremely elementary and I need to constantly look at the wonderful ASM reference as well as these notes I have spread about.

With this information I have managed to write nearly 50 new commands/spells. Some of these writes are small things like changing Dark Wave to cast a spell and apply Zombie on use,  (5-10 byte chance while others like Peep to Geomancy keeps none of the original architecture that was there and is completely custom coding. (Roughly 200-300 byte change)

So while it may not be the ideal method as others have discussed, it works perfectly for me and for my specific projects.
Title: Re: Asm hacking
Post by: puzzledude on February 08, 2014, 12:21:29 pm
Quote
Curious, how do you guys handle your ASM hacking projects?

Do you use a hex editor to do all your asm hacking, or do you use an assembler? If you use an assembler, do you assembly directly into the rom or do copy the assembled code into the rom?

Assembler is mandatory, but I alway assemble into the copy of the rom, examine the changes and then copy to actual rom. Then I also document all changes in the blank txt file. The asm can then be inserted by others into their games by copying from this txt file into the rom directly, using hex.

But to write the code directly in hex is somewhat a robotic task, not really for people.
Title: Re: Asm hacking
Post by: KingMike on February 09, 2014, 12:42:42 am
Noticing the general trend is "limit hexing to minor changes on systems using variable-length opcodes".  That's perfectly understandable really, especially to ensure longer jumps/branches don't die a horrible death at the hands of a 1-2 byte push.

Repositories are more useful than a simple when.  If you're using them appropriately, you'll know what change caused the error, allowing you to work out where it lies.  Anything more than a simple, mundane change--such as altering a struct or data type--has probably changed more than one tiny snippet of code.

Luckily on the NES it's pretty easy to spot as it's almost a guarantee the game will hit invalid opcodes after an error, so you can just search for INVALID OPCODE or whatever string your tracer uses in a trace dump.
SNES also usually tends to crash and burn with a pretty noticeable error pattern. Especially if you look for the offset you inserted your code and follow it (more often that push/pull errors you'll probably make SEP/REP mismatches, most often to change the register size, causing some pretty glaring wrong opcodes if you know what your code is supposed to be doing)
Title: Re: Asm hacking
Post by: Chippy2000 on February 09, 2014, 10:32:31 am
Pokemon GBA and GB hacking must be the easiest ever since the dev tools are simple since you don't need any experience - you just need to choose the stuff you want or do whatever you want to the map and BAM. You're done. It's just implementing and editing wild pokemon data. ASM is good for title editing though.
Title: Re: Asm hacking
Post by: Trax on February 10, 2014, 07:36:23 pm
I use a text editor and a hex editor, and I do only NES ASM. I can't say it's by choice, because sometimes I'd like to have a few things automated, especially branch jumps calculations, but since I work on Mac, I'm not sure if a 6502 disassembler exists...

My normal way of hacking is already very close to disassembly, so my hacking notes are basically ASM written in text files, with lots of commentary. But when I want to do a specific modification that involves ASM, I make a new text file in which I explain the goal of the hack, what kind of variables it uses, etc., and I copy paste the code that needs to change and I write the new ASM from scratch. Then I insert the hex code by hand using a hex editor. After testing, if I need to tweak something, I do it in the hex editor directly, but if it needs a major change, I just return to the text file, do my work, and recopy the bytes in the hex editor when ready...

It's tedious, but I know I can get nice results with games I know very well. And most of the time, a heavily hacked game is really just a bunch of sub-hacks that are applied to the same game, incrementally...
Title: Re: Asm hacking
Post by: RyanfaeScotland on October 22, 2015, 07:53:24 am
Totally agree with Kaioshin's post. You don't wanna edit and stack changes with a hex editor, you better off start with something that can be recompiled entirely, just in case something gets broken in the process. Usually I have a couple batches that redo the full hacking process, doesn't matter if the source data is original or already hacked assets. Whenever something gets broken in my process, I simply restore the original data, revert the last source changes, hit compile and see if the issue goes away. If it does, I can start looking into whatever is causing the problem, but the rest of the hack still stays in place and gets preserved for good.

But realistically how often in this business does one have that luxury? It sounds fine if you are changing SMW or Sonic where the full disassemblies are readily available but what if it is something else like say Toejam And Earl which is fairly undocumented. Are you suggesting you should aim for a full compliable decompile first before aiming to make any changes? Not criticising, genuinely asking, as it sounds fairly impractical.

NB - Sorry for the necro but this is an interesting and still relevant discussion.
Title: Re: Asm hacking
Post by: tryphon on October 22, 2015, 08:49:57 am
Much more interesting than some debates that flourishes here and there these days :)

I think Gemini wasn't refering to a complete editable disassembly (it's indeed very rare ; for Genesis, I know about Sonic games, Shining Force - at least one of them -, and Phantasy Star II, III and IV), but rather a batch file that inserts all hacked routines to a clean ROM.

I wonder how much time it takes to disassemble a complete game.
Title: Re: Asm hacking
Post by: RyanfaeScotland on October 22, 2015, 09:10:09 am
Much more interesting than some debates that flourishes here and there these days :)

I think Gemini wasn't refering to a complete editable disassembly (it's indeed very rare ; for Genesis, I know about Sonic games, Shining Force - at least one of them -, and Phantasy Star II, III and IV), but rather a batch file that inserts all hacked routines to a clean ROM.

I wonder how much time it takes to disassemble a complete game.

Hmmm yeah I could see the benefit in doing it that way. I imagine there is already some generic patching tool out there that could be repurposed for the job as well.

I was curious about the time thing myself, was looking around SonicRetro for more information about how they went about creating their disassemblies but didn't see much concerning the actual history of the project(s) other than 'this person produced this' style entries.

I'm really keen to see what Exodus's 'Active Disassembly' is all about (I really curse myself reading up about these things during lunch then having to wait till I get home to try them!)
Title: Re: Asm hacking
Post by: freem on October 22, 2015, 02:04:59 pm
But realistically how often in this business does one have that luxury? It sounds fine if you are changing SMW or Sonic where the full disassemblies are readily available but what if it is something else like say Toejam And Earl which is fairly undocumented. Are you suggesting you should aim for a full compliable decompile first before aiming to make any changes? Not criticising, genuinely asking, as it sounds fairly impractical.

I guess this is a combination of answering your question and explaining my technique...

It sounds impractical, but for what I primarily hack (NES games), it's do-able. Tools like aNESe (http://www.romhacking.net/utilities/289/) and SmartRENES (http://www.romhacking.net/utilities/288/) allow for a re-assemblable version of the code. While a perfectly commented disassembly is my ideal goal, for hacks, you really only need to identify the code and data you're looking for. Using diff (in binary mode) to compare to a known good ROM keeps me honest, and lets me know when I've messed up. (Of course, this is only for documenting the original; hacks don't need this step :p)

FCEUX's CDL functionality is also useful when paired with a disassembler that can make use of it. (e.g. disasm6 (http://www.romhacking.net/forum/index.php?topic=12177.0)) clever-disasm (found in nescom (http://bisqwit.iki.fi/source/nescom.html)) is also useful, though you need to craft the .ini files yourself.

For other systems, there's always MAME (or IDA Pro if you can afford/buy it). MAME has a universal disassembler (unidasm) that can be built from source, supporting a decent number of processors. Granted, you'll still need to find out what's really code/data, but it's better than nothing. (You can also disassemble from MAME's debugger.)

I don't expect anyone else to do this; everyone has a workflow they enjoy using. This is what works for me.

edit: On time - smaller games are much easier to deal with, though I don't have much to show for my work right now. (Super Dodge Ball is pretty big at 128K of PRG-ROM, while RC Pro-Am is a bit more manageable.)
Title: Re: Asm hacking
Post by: Dr. Floppy on October 23, 2015, 01:46:41 am
Hex editor ASM-er here.

I must be a purist in that sense.