nesdev.org

Hi,
I'm trying to teach myself to read NES assembly code & I hit a snag.
I used disasm6 v1.5, both with and without use of a CDL file from FCEUX and the resultant ASM file is chock full of invalid Opcode errors.
Here is a sample section:
I'm assuming that this isn't correct and that something went wrong?
I know that it's possible for this to happen if I have a bad ROM dump & I saw bootgod's site mentioned but I don't know how to check the CRC32 values of the file I have against the database.

Thanks

Out of context, it's impossible to know what this is. Not code. Possibly data.

Probably better to step through the running game in a debugger, if you want to learn. Or better yet, look at some open-source properly labelled source code.

I've been reading 6502 asm for 30 years, and I can't just look at a random bit of compiled code and have any idea what I'm seeing. Sometimes I do, like when there's a STA to a sound register, I know it's part of the music code. But usually I don't know.

Do like dougeff said. With the emulator you can even hex edit the code/data 1 byte at a time in real time and see how the game changes (use savestates and breakpoints for this). Emulators recommended: mesen and fceux.

I'm off the opinion that disassembling code is not a particularly efficient way to get started with learning assembly. A full commercial game can be pretty daunting, specially without labels and comments. Also, if you're not already acquainted with common game programming patterns, it'll be really hard to make any sense of the raw assembly code.

I can understand the sentiment of wanting to see what makes your favorite games tick, as opposed to dealing with boring introductory programs, but even experienced coders have a hard time making sense of disassembled code, so that's hardly a good path for people who are just getting started.

That's data, not code. 100% certain. I can tell by the pattern. You get a kind of "gut feeling" for this stuff the familiar you get with it; pretty sure everyone here can attest to that. :-)

You cannot simply take a ROM and dissassemble it and expect "obvious" results. It doesn't work like that. It's up to you, the individual doing the reverse-engineering, to figure out what is code vs. data. Disassemblers tend to not cater well to this kind of thing**. You get to put in long, long, long hours. PRG doesn't always mean "program/code" either, as many games use CHR-RAM thus graphical data is stored in PRG (and sometimes is compressed too, varies per game). You get to RE all of it. :-)

You're better off if you can pinpoint something you want to reverse-engineer -- try to use breakpoints in FCEUX/Mesen/etc. to find out "where" the code might be, disassemble things (hopefully with the correct PRG bank and origin address), then look at that specific code. You will be working in the emulator in real-time *as well* as referring to the dissassembly. Large games that involve mappers (i.e. switch PRG) make this a bit more complicated.

I could show you what I did with the Neo Demiforce FF2e/FF2j intro replacement, where I had to disassemble the last PRG bank (which represented $C000-FFFF) + inject my intro code and graphics + reassemble the entire thing (meaning I had to use a dissasembler that generated code that could be reassembled by a compatible assembler), but I haven't gotten around to putting together something official/clear/concise that explains it. It's a mess -- RE'ing always is. Here's the directory listing and bat file, which won't make much sense to you, but gives you some idea of the mess. The disassembler I used was TRaCER for MS-DOS (I'm the author) and the assembler I used was x816 for MS-DOS. Note neither of these programs work on present-day Windows:
make.bat: Other random brain dump stuff:

Part of the above process involved using fc /b to compare the newly-assembled ROM to that of the old, to ensure only the bytes that differed were the stuff I had changed. Back then hex editors like HxD didn't exist, but there were other tools that did it similarly; I just happen to be used to fc which came with DOS/Windows.

I recommend doing exactly that with a straight disassembly (i.e. no changes) as well: disassemble something, then reassemble it using a compatible assembler, and see if the results are identical. If they aren't, then you get to figure out why -- it's often the assembler picking some wrong addressing mode, an incompatibility between disassembler and assembler, or a downright bug in the assembler.

If things match, great. After that, you get to try and start "piecing together" bits. That often means going and editing the disassembly by hand to deal with places where there are code and data intermixed, turning the data into .db statements, and then manually fixing the code so it's legible. This often happens on a "data/code boundary", where the piece of data happens to be a legitimate instruction (but isn't actually code), thus disassembled code with an operand, but the *actual* code is all of, or part of, the operand bytes themselves. This is hard to describe in words so here's an example. Take these addresses and their raw bytes:
These might get disassembled like so:
But after appropriate analysis/reverse-engineering, it's determined that $FA00 is actually code, while preceding bytes are data. So once cleaned up manually, you get this:
How you determine this is through a combination of using an emulator to "walk through" the code in real-time to figure out what's actual code vs. data, and staring at the disassembly + following it carefully. In this example, I learned that there was code doing jmp $fa00 so I therefore knew $fa00 itself had to contain code -- then later found some code that read $f970 to $f9ff as data. Hence, I knew what was what.

I'll add that this was in the days *before* there were emulators with CDL capability... but it doesn't change a thing -- you still have to know what it is you're looking at, you can't rely on a machine to "magically figure it out".

If your reaction is "oh my god, doesn't that take a lot of time to do?!?!" the answer is a big fat yes. Welcome to reverse-engineering.

As for games which use mappers / multiple banks of PRG, quite often you have to split the ROM up into its individual PRG banks and dissassemble each as needed. An example of some of the never-completed work I did on Rampart (Japanese release) required that (I've since deleted all my work since someone last year or the year before made an English release so my work was pointless), ditto with some work I was doing on RoboWarrior / Bomber King:
RoboWarrior is mapper 2 / UNROM game, so the last 16KB bank is hard-wired to $C000-FFFF. You'll probably notice how I disassembled certain banks: prg00, prg01, and prg06 all had scattered code I was needing to examine/RE, and of course, prg07 (the last bank, thus a good starting point since it contains all 6502 vectors; for mappers like this it tends to contain "the guts" with critical routines that get used everywhere, etc.). Started with the last bank, then gradually worked through the code (emulator + disassembler combined) until I figured out what other PRG banks I needed to look at, disassembled them, blah blah. The disassembler I used for this was disasm6 v1.5. There's no .bat file because I was doing everything manually by hand.

Starting to get the picture?

** Warning to pedants: yes I'm aware of a PHP-based disassembler that can read/use CDL files. You cannot tote this as a one-line "solution", and shouldn't. Because then you have to explain how to generate a CDL file, and how an emulator generates that file, and how the emulator determines code vs. data, and how the person playing the game while generating the CDL has to do every single thing possible in the game, down to miniscule things like loading a menu from point A vs. point B, pressing up vs. down vs. left vs. right in every place in the game including pause screens, etc. -- when I say LITERALLY DO EVERY SINGLE THING, I do mean LITERALLY **EVERY SINGLE THING**.

There must be some "manual" for 6502 in Japanese that shows how to do the "read data past the JSR with stack manipulations" as for some reason a lot of Japanese games I look at do it. so you get
JSR somePlace
.word Address, Address, Address, Address
code

just to make things more confusing.. this trend seems to carry onto the SNES where there are multiple ways to skin the cat...

But basically as said above, reversing a 6502 game is a "grand-master" task, you really need to know how code works, flows, understand all the archaic tricks the programmers might have used, be able to make judgment calls on what is code and data, find Tables etc However you need to understand the data and then you will understand the code. Also using something interactive like Regenerator makes it a fair bit faster to edit and add variables.

Oziphantom wrote:There must be some "manual" for 6502 in Japanese that shows how to do the "read data past the JSR with stack manipulations" as for some reason a lot of Japanese games I look at do it. so you get
JSR somePlace
.word Address, Address, Address, Address
code

On the 6502, this technique goes all the way back to the Apple II firmware written by Woz. It's not unusual on the Z80 either.

Dragon Warrior 3 and 4 actually do this with BRK! Effectively they use BRK as a prefix for a set of software-defined instructions. The most frequently used one, as you might expect, is the "far JSR" (call a subroutine in a different ROM bank, storing the return bank on the stack) but some of the software-defined instructions are more high-level things like playing sound effects, printing messages, and getting/setting character status (HP, experience, etc.)

If you use BRK this way on the NES, your NMI handler has to detect the NMI hijack condition, and if necessary chain into your BRK handler rather than RTI into invalid code. The way the Dragon Warrior games do this is by encoding the software-defined instructions such that the first byte after the BRK always has bits 0 and 1 set--which no legal 6502 instruction does. The NMI handler epilogue peeks at the byte at the return address, and if it is not a 6502 instruction then it jumps to the BRK handler instead of executing an RTI.

If you want to learn to read NES (6502) assembly by using this method, take one of the commented disassemblies, like http://www.romhacking.net/documents/367/ (Metroid). You can find disassemblies of many other commercial games on that site, with varying levels of completeness.

little bit late, but Dragon Warrior 3 fully disassembled and somehow re'ed. https://github.com/zeromus/DragonWarrior3

the special BRK opcodes are macrocified and can be read much more easier than the original commands

That’s data that disasm6 doesn’t recognize as data for whatever’s reason so it treats it as code. Disasm6 tries to guess what is data based on if the memory area is read using lda or similar.. this chunk must not be read using those methods nor has the emulator encountered it when you recorded the cdl file. It could just be dummy bytes