Assembler Decision

[tokumaru]

Well, what happened is that us ASM6 fanboys got to answer your question first! =)

There are other favorites around these parts besides ASM6 (maybe other members will recommend them to you soon), and some of them are really good and have a lot of features, but the problem is that they require a lot of configuration before you can even assemble anything. You have to make configuration files describing the system and the cart you are using, what's ROM, what's RAM and so on. And even if you download configuration files made by others, you still have to deal with linking, which is something I'm not quite sure I understand.

For these reasons I went with ASM6, because it's as straightforward as it gets without sacrificing versatility. Just give it an ASM file and it will spit out the final binary file, no worries.

[GradualGames]

I like to use ASM6 still to test out aspects of NES programming I don't yet understand. It is definitely very easy to set up a program in ASM6, assemble and you're ready to go.

CA65 does have a bit of extra setup, but if you knew what you were doing in ASM6 prior to using CA65, it is actually the exact same thing. Instead of having .org, .base, and .pad in ASM6, you put all that stuff in a setup file and abstract that information into what are called "segments."

I've found for a large game project, the ability to use CA65's segments and memory areas has been invaluable for refactoring, and for keeping related data grouped together (even though individual chunks of data may reside in multiple PRG banks).

I think the advice already given is good, start out with ASM6 and if you eventually work on a large, complex game project you might want to check out CA65.

[3gengames]

I use NESASM and haven't had any problems with anything close to "corruption" Oh well, it works for me....and Sivak if I recall him mentioning.

[ibeenew2]

bunnyboy also uses NESASM. Everyone craps on it but nobody knows why anymore. Almost all the problems were with much older versions that were fixed. Notice how this "corruption" problem isn't even mentioned: http://nesdev.com/bbs/viewtopic.php?t=3726

That doesn't mean you should choose it above ASM6 just that it isn't the shit everyone claims. The most successful projects (PowerPak, Battle Kid, etc) were made with it.

[cartlemmy]

Cool, thanks for the extra input I'll definitely give NESASM a look as well.

[Memblers]

That doesn't mean you should choose it above ASM6 just that it isn't the shit everyone claims. The most successful projects (PowerPak, Battle Kid, etc) were made with it.

There is no source release for either of those projects, so that's not much help. I'm surprised Battle Kid was made with it (without much trouble), quite honestly. There also isn't any kind of documentation with the NESASM update, so it's not very easy to tell what changed. NESASM has been around since 1998 at least, last official update over 10 years ago that has been plenty of time to find problems. People advise against it only because they want to save others the time of finding the problems themselves.

NESASM, for one thing forces you to use 8kB banks, while ASM6 (or any other 6502 assembler) doesn't impose any arbitrary size limit. You can't overflow a bank (though even NROM is a flat 32kB).

As for other assemblers, CA65/CC65 is notable for being in development for a really long time (being rewritten entirely over that time I'm sure). It also includes a C compiler, but you really have to know what you're doing to use it (there aren't any usable NES-specific libraries and it's strict ANSI C).

[ibeenew2]

There is no source release for either of those projects, so that's not much help.

Theres no source for any major project, so that doesnt matter when picking an assembler. There is source for smaller complete projects like cyoa and ttxo. there are good accurate tutorials using NESASM. those tutorials should probly be writen for asm6 too.

People advise against it only because they want to save others the time of finding the problems themselves.

Then why didn't people list those problems in the thread so they could be fixed?

[Dwedit]

Does NESASM force you to use the low-byte unary operator (is it < or >, I forget) to use zeropage instructions? I know one of the assemblers does that, and I wouldn't be able to put up with that.

[tokumaru]

Does NESASM force you to use the low-byte unary operator (is it < or >, I forget) to use zeropage instructions? I know one of the assemblers does that, and I wouldn't be able to put up with that.

I think it does. But AFAIK, ASM6 has a related limitation: it doesn't let you use absolute addressing to access ZP memory, so you have to .db the opcode and .dw the address if you want to do it. Unless that has changed since the last time I checked.

[blargg]

On the NES you can just add $800 (or $1000 or $1800) to the zero-page address if you want to access it with absolute addressing. Or use y indexing, which has no zero-page mode.

[Memblers]

There is no source release for either of those projects, so that's not much help.

Theres no source for any major project, so that doesnt matter when picking an assembler.

Yeah, true. There aren't many completed big projects, Neotoxin comes to mind as one that did have source posted (not sure if that was a release or a leak though).

People advise against it only because they want to save others the time of finding the problems themselves.

Then why didn't people list those problems in the thread so they could be fixed?

They've been listed in other threads (probably on the older forum too, for posts before 2004), but I think one important reason is that NESASM has lots of non-standard syntax. Such as not defaulting to zeropage (STA $00 coming out as STA $0000), and of course the [] vs () for indirect thing. Then too by the time someone changes the banking system, it would then be incompatible with older NESASM sources, so it may be wise to rename it to something else so people can still assemble their old stuff. Because there really are a lot of sources around that use NESASM, since it had been around for a while (same can be said of DASM as well, at least for ccovell's old stuff).

And the NESASM v3.0 is just an EXE, no docs or source, so whoever would want to fix any remaining issues/bugs will have to start back at v2.x. Maybe bunnyboy could post the modified source sometime, but I dunno, I wouldn't blame him if he doesn't want to spend much time on that.

[tepples]

There is source for smaller complete projects like cyoa and ttxo.

There is also source for projects such as Concentration Room and LJ65, both of which use ca65. But then they're both NROM-128, so they don't really count as "big" projects.

[ibeenew2]

And the NESASM v3.0 is just an EXE, no docs or source, so whoever would want to fix any remaining issues/bugs will have to start back at v2.x.

Source has been at http://nespowerpak.com/nesasm/nesasmsrc.zip for at least 1.5 years. Others recompiled it for Mac etc.

[Dwedit]

I think it does. But AFAIK, ASM6 has a related limitation: it doesn't let you use absolute addressing to access ZP memory, so you have to .db the opcode and .dw the address if you want to do it. Unless that has changed since the last time I checked.

Are these the only times where you need ZP addresses treated as full 16-bit addresses?
* ABS,X without wraparound (into the stack page, yay)
* Timed code where you need to exact amounts of cycles and you need to burn 4 instead of 3 cycles
* Self modifying code

[tepples]

Are these the only times where you need ZP addresses treated as full 16-bit addresses?
* ABS,X without wraparound (into the stack page, yay)
* Timed code where you need to exact amounts of cycles and you need to burn 4 instead of 3 cycles
* Self modifying code

* Relocation of zero page with 'tad' instruction (see the SNESdev forum), but for this you'd be using an assembler with explicit 65816 support.