Question about how NES hackers do ASM

[Chaos Rush]

So, as someone with GBA ASM experience, typically when inserting ASM code into a GBA ROM, what you would do is write out the ASM code in Notepad and save it as a text file, and then use a batch compiler like HackMew's thumb.bat to convert it into a binary file, and then just copy+paste it into free space in a GBA ROM (and then you would have to hex edit an existing routine to jump to the new routine, of course).

For NES ASM hacking, what is the "normal" way to do it? Because what I've been doing is simply looking at an opcode chart and manually doing it in hex, byte-by-byte, and it feels really tedious, and is also very time consuming. I'm wondering if there's some way where I can just type ASM code into a text file and convert it to 6502 ASM ready for use in a NES ROM? I'm running Windows 10 and every assembler I've tried downloading from the main site won't run on my computer because these assemblers date back to the 1990's.

[Gideon Zhi]

You use a cross assembler. I personally use xkas; it was built for the SNES though so you may have to fiddle with it to get it to do NES addresses correctly. But you can use that to assemble a text file containing your code directly into a ROM. Not sure if there's anything better for the NES these days.

[Revenant]

I use my own version of xkas which I added NES support to and other things, but it's based off of v14 whereas everyone else always used v06, which has its own slightly different/incompatible syntax. You might find it useful, though. The (only) Windows build is here.

The only thing I've actually released using it is some patches to accompany my Kirby's Adventure editor, but it's probably a decent example of how to use it to patch a NES game.

(Don't mind the fact that I start comments with "//;" - the actual syntax is just "//" but I added the semicolon just for the sake of syntax highlighting that I was too lazy to change at the time )

[jonk]

I'd generally defer to the experts here. I haven't attempted to modify an NES ROM yet and I'm still myself learning about various cross assembler tools. I'm currently looking into tass64, for example. (You can read the manual for it here.)

But I did start out looking for a tool for SNES ROMs, some months back, and before knowing about this site in particular. So I was pretty ignorant, generally. I only knew that I wanted an assembler with ROM patching capability and it also had to run easily in Windows 10, provide source code that I could just drop into Visual Studio 2015, and where the source wasn't too ornery (it should be easy to read and modify.) What I found was a modern tool that emulated an old 1980's tool for the Apple computers. With a few modifications, it does the job simply and easily. I included some additional syntax so that it knows how a ROM may be formatted (for those cases where there is a memory mapper behind its use, for example.) But you probably only need one statement for that information on an NES. It directly modifies the ROM. It's an assembler and linker and patcher, built into one. (I probably will later modify it so that it emits patch files in various standard patching file formats. But for now, I just run the pre-modified ROM against the newly modified one to get that.)

In my case, I was setting up my son who is autistic and was working like you describe -- but using Lua code he wrote to either generate (data statements) or patch in hex code that he hand-assembled over a period of some months. I had tried over and over to get him to use an assembler tool, but just considering the idea is often a great difficulty -- it requires "newness" that makes it difficult. So I had to blaze the path a bit and create a tool that I knew he could easily use and apply right away, with the idea that getting the difficult bits out of the way would allow him to later focus more attention to assemblers and linkers, generally, after he got a serious running start here. So this tool was built up for that purpose -- to give him a very simple, one-stop tool that would read assembly code and generate a testable ROM as its output. That allowed him to just write assembly code and not have to think much about linking or patching tool issues. As he uses it more and more, those bits will become well-understood and I can then ween him off of the tool and towards more general purpose assembler + linker + patcher tool chains.

If you are interested in trying it out, I'd try and help as well. You can start at this page. That page includes a completed example for modifying an existing SNES ROM (which needed two mapping statements to describe the ROM format.) But keep in mind that I haven't yet tried it on an NES ROM. It's just that in my ignorance here, I don't see why you couldn't use it for that purpose. It wants to assemble 65816 assembly statements, but if you stay with the 6502 source I think you should be okay. But again, I'm not certain. Finally, the assembly source format is matched up with the older Apple tool and may be somewhat different from other assemblers. It doesn't seem a lot different, but keep it in mind.

Source code is included and it just drops right into Visual Studio. I didn't provide all the project files, though. If you wanted them, I could offer them, but it's really pretty easy to just set up a project and include the source. It compiles straight away, without difficulties.

[Madsiur]

I use my own version of xkas which I added NES support to and other things, but it's based off of v14 whereas everyone else always used v06, which has its own slightly different/incompatible syntax. You might find it useful, though. The (only) Windows build is here.

I don't want to hijack the thread but I've been using v06 for some time and I have a hard time seeing the advantages of using v14 for someone coding 65816, though your additions and goals for your version are useful to others and more than honorable. I'm kinda looking for the best 65816 assembler for medium scale assembly projects, but looking at xkas, WLA DX, ca65 and 64tass differences just confuse me more. 64tass and ca65 documentation seems the most complete though.

[dougeff]

I highly recommend either asm6 or ca65 assemblers. And I recommend something better than Notepad, like Notepad++.

For 'inserting a patch into a game' typically, I disassemble the original, and insert the new ASM, and reassemble.

Disasm for asm6. (Frantiks disassembler)
http://www.romhacking.net/utilities/674/

http://www.romhacking.net/forum/index.php/topic,12177.msg178059.html#msg178059

Da65 for ca65 (comes with it) (on github)
http://cc65.github.io/cc65/


June 19, 2016, 07:59:44 PM - (Auto Merged - Double Posts are not allowed before 7 days.)
Frankly, I'm surprised to see so many people using xkas. I thought that was an SNES assembler. I suppose most SNES ASM is compatible with NES.

[nesrocks]

Tipically, how long does it take to disassemble a nes game to an assemblable (damn that's an ugly word  ) version? I tried with super pitfall but it generated so many errors because it treated everything like code. That was using disasm and asm6.

[dougeff]

It produces gibberish asm when it treats data like code, but it should still reassemble into a working game.

Honestly, I can disassemble (poorly) a small game in a few minutes. A large game in half an hour.

The hard part is understanding the code and knowing what/how to make changes. It can take me 2 hours just to locate one RAM address that I want and make sure it does what I think it's supposed to do.

[bruddogtecmo]

I second what dougeff wrote... asm6 combined with notepad++. Especially for doing simple patches. But it can hold up well even for large projects. Especially when combined with WUDSN IDE.

If you use FCEUX's datalogger to help determine what is code vs data combined with disasm6 you can get a "disassembled" game pretty quickly

AS far turning that dissambled code into something with meaningful comments and labels... well that takes a LOT of time.

[Disch]

For Final Fantasy, I pretty much just work off the disassembly I already made (which reassembles)

For anything else, I a custom assembler a while back that I never really properly released.  I was thinking about remaking it and/or polishing it up for release, but then I got distracted with another project.

[Chaos Rush]

Disasm for asm6. (Frantiks disassembler)
http://www.romhacking.net/utilities/674/

http://www.romhacking.net/forum/index.php/topic,12177.msg178059.html#msg178059

Thank you for this, I think this is exactly what I was looking for. Hopefully it should make hacking Final Fantasy II easier.

[Jorpho]

Does anyone use Brian Provinciano's NESHLA, or is that only useful when coding something from scratch?

[elmer]

Does anyone use Brian Provinciano's NESHLA, or is that only useful when coding something from scratch?

Thanks for the mention of NESHLA, I hadn't seen that before today.

It's an interesting and minimalist approach to making assembly language easier to write.

It doesn't seem like a good "hacking" tool IMHO because, from what I'm seeing so far, it doesn't let you assemble code on top of an existing ROM image. I could be wrong about that, though.

[oziphantom]

If one uses 64tass, to assemble them you can use http://csdb.dk/release/?id=148862 to convert a binary into an assemblable format. It is an interactive dissasembler, so you can find labels, mark things a data,words, pointers, RTS hack pointers, text etc and it will update the source files and spit out a Tass64 file to assemble again. It doesn't understand bankable things. So you would have to split the ROM into each logical bank and do them 1 at a time ( use Offset to adjust the * to $8000 etc) then make a few asm files which you can then make a "master" asm file to handle the logical and actual address to build the ROM again.

If you are looking for an IDE that gives you syntax highlighting and lets you run scripts, auto complete and some other features try http://www.popelganda.de/relaunch64.html it is in Java so will run on anything. It supports Tass64 + a lot of others.

[jonk]

Thanks, all, for this discussion. I'm learning more as I read!

[snarfblam]

I actually wrote my own assembler, one part for the intellectual exercise, and one part to suit my own needs. It's pretty basic and uses rather standard syntax (including ASM6- and Ophis-style anonymous labels) and supports patching multiple locations with a single code file, and can produce symbol files for use in FCEUX and generally outputs IPS patches.

Prior to that, I used batch files to assemble various ASM files (using ASM6) and patch the resulting binary files into a ROM. For me, a complete build process is essential. It makes it easy to manage revisions and impossible to accidentally corrupt your ROM.

[KingMike]

I live in the stone age and I assemble NES code by inserting hex because there were no tools for it until I got used to it. I am set it my ways.
(script insertion though, I use my own tool that I modify per game)

Now SNES, I use xkas.

[yugisokubodai]

For Nes, I use nesasm.

I don't want to hijack the thread but I've been using v06 for some time and I have a hard time seeing the advantages of using v14 for someone coding 65816, though your additions and goals for your version are useful to others and more than honorable. I'm kinda looking for the best 65816 assembler for medium scale assembly projects, but looking at xkas, WLA DX, ca65 and 64tass differences just confuse me more. 64tass and ca65 documentation seems the most complete though.

I think xkas is the best 65816 assembler by now. I use both v06 and v14. Bascially, v14 can do some math that v06 can't, like the right shift or left shift.
Xkas v14 has some quirks and bugs I found so far:

1/ SEP #$20
   LDA #(label>>16)  if the label locates too far from this code, xkas will add an extra 00, this makes A becomes 16 bits large.

2/ SEP #$20
    LDA #%0000001  xkas will add an extra 00 too.

This was hurting me for a long time before I found out and fixed this with an XBA.