[FAST6191]

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.

[KingMike]

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.

[Pennywise]

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.

[Drenn]

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.

[tomaitheous]

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

[Scio]

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.

[optomon]

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.

[KaioShin]

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.

[BRPXQZME]

That strikes me more as a not-using-a-repository issue

[Gemini]

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.

[Drakon]

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.

[Kajitani-Eizan]

That strikes me more as a not-using-a-repository issue

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

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

[Pennywise]

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.

[Scio]

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

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.

[Gideon Zhi]

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.

[Zoinkity]

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. 

[BRPXQZME]

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

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), 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?).

[Grimoire LD]

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.

[puzzledude]

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.

[KingMike]

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)