I am new to NES development and this forum. Hello!
I'm curious what assemblers folks use to work on NES games.
I saw this question was asked
a few years ago, and think it would be good to get an updated temperature check on the topic.
I voted Other. Answer: ca65 (cc65), asm6 (in the past), and asm6f (present-day). The assembler I pick all depends on what type of work/project I'm doing.
If you asked me which of those assemblers is my more common go-to, the answer would be asm6f.
Welcome!
cc65/ca65 are my go-tos.. it takes a little bit more work to set up, but I use macros in assembly a lot, and ca65 does them well. I also like how it has you organize your code/banks/etc. At this point I'm also super used to the syntax.
For C, cc65 is also sorta unparalleled in NES dev.
Voted "other" because I'm kinda "assemblerless" at the moment. My favorites are ASM6 and ca65, but both have limitations that bother me terribly, so I've been trying to write my own, with the features I use most from both of them.
ASM6 is great for getting small things done fast, but its "nameless" and local label systems leave something to be desired, specially because they're incompatible with each other. It also lacks any sort of bank management functionality (I like to extract bank numbers from labels).
ca65 is very powerful and versatile, but I find it annoying having to plan out my .cfg files every time I start a project, because I end up needing to use another .cfg for reference and/or look into ld65's documentation. I also hate the limitations imposed by it being a single-pass assembler.
My ideal assembler should have the simplicity of ASM6 and NESASM, the ability to assign/retrieve bank numbers to/from labels, and versatile enough scoping capabilities. That's what I'm aiming for.
I used to use asm6, then asm6f. Now I'm working with the cc65 toolchain.
IMO since you're polling about assemblers, ca65 (assembler) would be a better option rather than cc65 (compiler/toolchain).
I voted "other" because I use ca65, I don't use cc65.
I voted other because I forked asm6. Mostly because asm6f didn't create usable mlb files for Mesen, but also to add a few things asm6 was missing.
I voted "cc65" because I use ca65.
Obviously, the "cc65" option refers to ca65, which is a part of the cc65 package.
Yeah but it could imply that I know C, but I have no idea how to write a single line of C code.
Sorry for leaving CA65 out. I just learned that it is part of the CC65 toolchain last night.
I updated the poll to switch CA65 in for CC65 which wiped out everyone's votes, which I guess makes sense. Can you re-cast your ballots?
It looks like all votes are still there...
Those who vote in this poll might not be representative of the broader NES community now that NESmaker has standardized on ASM6.
NESASM. No shame!
It helps that NESASM is basically PCEAS2 since I use that very often, too.
I use WLA-DX but if I were to start new projects I'd probably use ASM6 instead. I like the idea of the assembler being very simple and portable, because that's the point of assembly language. Feature-creeped assembler should be frowned upon as a general rule, unless you have a very specific feature you need.
Also I'm sure we already have had this poll at least once, if not twice or thrice, but I agree the results could change over time, and that the search function of this forum is lacking.
tepples wrote:
Those who vote in this poll might not be representative of the broader NES community now that NESmaker has standardized on ASM6.
This really depends on what the goal of the poll is. If it's about what assembler do you actually write code for, it wouldn't apply to the majority of nesmaker users. If it's about what assembler the most games get built with, then it probably would.
Bregalad wrote:
I use WLA-DX but if I were to start new projects I'd probably use ASM6 instead. I like the idea of the assembler being very simple and portable, because that's the point of assembly language. Feature-creeped assembler should be frowned upon as a general rule, unless you have a very specific feature you need.
Yeah I like features but if my project depends on too much of them I tend to forget how I set it all up when I get back to the project years later, so simple is generally better for me as well. For that reason I use ASM6. I voted ASM6f because I use that lately, although I forgot if I actually use any of the new features the fork introduces.
I don't like WLA-DX very much. It can do a little bit of everything, but it's not very good at it.
CA-65 is nice, but it's a bit on the heavy side with the config file and all that. For SNES and PC-Engine it's lacking because direct page isn't fully supported.
I stay away from Nesasm but for PC-Engine there's not much choice. I use Elmer's fork of PCEAS for my PC-Engine needs, which is not bad at all (no forced 8 kB banks), as long as you remember to use zero page addressing manually.
gauauu wrote:
This really depends on what the goal of the poll is. If it's about what assembler do you actually write code for, it wouldn't apply to the majority of nesmaker users. If it's about what assembler the most games get built with, then it probably would.
Lately, my own personal dilemma has been what assembler a library author is expected to code for. If a library is expected to see use in projects by both people who code from scratch and people who use NESmaker, then it has to support both environments.
tepples wrote:
gauauu wrote:
This really depends on what the goal of the poll is. If it's about what assembler do you actually write code for, it wouldn't apply to the majority of nesmaker users. If it's about what assembler the most games get built with, then it probably would.
Lately, my own personal dilemma has been what assembler a library author is expected to code for. If a library is expected to see use in projects by both people who code from scratch and people who use NESmaker, then it has to support both environments.
That's true, but the majority of NESmaker users act very differently than most programmers. Unless a library has specific nesmaker support (which it sounds like you may be trying to do), most of them will never use it, as that would take programming skill. So I'd consider NESMaker users as a very different subset of people than the general developer who uses ASM6.
But your question in general is a valid one. If you want people to use your library, you want to support whatever assembler they're using. Nobody should be "expecting" an author to code for a particular platform, but you as an author might want to, if you want others to use your library.
(Voted asm6f, but I'm
extremely, extremely biased.)
never-obsolete wrote:
I voted other because I forked asm6. Mostly because asm6f didn't create usable mlb files for Mesen, but also to add a few things asm6 was missing.
1) Do you happen to have the changes published?
2) Would you mind if I implemented said changes into asm6f? I did notice the Mesen .mlb export wasn't perfect somewhat recently (last month)...
freem wrote:
I did notice the Mesen .mlb export wasn't perfect somewhat recently (last month)
Not too surprising considering it was based on my rather limited comprehension of asm6 itself. Ideally, adding a CA65-format .dbg file output to asm6 would probably be the best way forward (although improving the mlb export would be good too), but that might require a lot of effort (especially when written in plain old C)
At the moment, I'm using snarfblasm, which has a .patch directive for creating IPS patches that is extremely useful for my current projects. It's generally pretty nice, but given that it doesn't see much use, it's not the most mature and I do have some gripes about it. I tried using ASM6 a while back, but didn't care for it and was not impressed with the code (and given the trivial buffer overflows in it, I wouldn't want to assemble code with it that I hadn't first examined). The assemblers I've looked at seem to be lacking several features I'm interested in, so I'll probably take a shot at writing my own at some point.
I'm surprised to see NESASM above asm6. I would have guessed the opposite.
The invisible hand of Nerdy Nights.
Pokun wrote:
For that reason I use ASM6. I voted ASM6f because I use that lately, although I forgot if I actually use any of the new features the fork introduces.
Pardon my ignorance, but what is the difference between ASM6 and ASM6f ?
Quote:
I'm surprised to see NESASM above asm6.
I'm surprised NESASM is still used, that's what I used when I started NESDEV-ing back in 2002, good old times.
NESASM always had its followers here but CA65 and ASM6 has always been the two most popular ones (well since I started here anyway). In the old poll ASM6 was slightly more popular but when I look now CA65 seems to has overtaken it. But I'm surprised ASM6/ASM6f has so few votes this time.
Among the regulars here CA65 is no doubt the most popular.
Bregalad wrote:
Pokun wrote:
For that reason I use ASM6. I voted ASM6f because I use that lately, although I forgot if I actually use any of the new features the fork introduces.
Pardon my ignorance, but what is the difference between ASM6 and ASM6f?
It has added illegal opcode support, iNES and NES 2.0 header directives (optional), Mesen symbol integration and a few other things. All the differences are
listed in Freem's readme.
It's like a collection of various improvement forks that people made, and unless Loopy adds these features to the official version, this is the most feature-rich version of ASM6.
I use ca65 for my slow progress on an engine of my own and like to use it the most, so i voted for that. But i still use asm6 for quick little things when i just want to see how something works. And i've also started using Nesmaker a bit, which runs on top of asm6.
I did do some of the nerdy nights, but in asm6, when starting out.
The reason i prefer ca65 is that there's less room for human error, with the .segment directive and the linker and all. Setting up a project takes a while, but then it's smooth.
freem wrote:
1) Do you happen to have the changes published?
2) Would you mind if I implemented said changes into asm6f? I did notice the Mesen .mlb export wasn't perfect somewhat recently (last month)...
Here it is. Some of it was based off of asm6f, so feel free to merge whatever additions you like.