Recommended assembler for NES development beginner [POLL]

I know the topic of preferred assembler has been discussed in-depth multiple times. There is even a poll here, on a very similar topic: viewtopic.php?f=10&t=9961

This question is different for one specific reason: This question does not concern what you use. This question concerns what you would most recommend to someone just beginning NES development, and possibly programming in general.

The answer should reflect a weighing of features between options, as well as short-term learning curve vs. long-term ease of use.

I am posting this thread primarily for the poll results, as a source to link for the most recommended assembler for a beginner among the NESdev community. The link is part of a proposed edit for this wiki page: http://wiki.nesdev.com/w/index.php/Nesdev, which is prominent in search results and largely outdated.

Edit: This is my first time creating a poll and I see now that making changes erases the old votes. (That makes sense) Please recast your vote unless you'd like to propose a change to the voting options.

NESICIDE uses cc65 under the hood.

No doubt sin cc65 .

Programming in C greatly simplifies things . EXAMPLES EXIST enough and Doug tutorial ( https://nesdoug.com/ ) You learn very fast.

Isn't CA65 the assembler?

I copied these answers from the previous poll. I appreciate any suggestions and if anyone has an option not on the list, or has an issue with an option on the list, please feel free to post and I will change it.

I'm making the following revisions:

Removing NESICIDE
Renaming CC65 option to CA65 (although, I would say I think the included CC65 suite features should be factored into the decision, if you feel beginning with familiarity with them is important.)

Isn't the question about assemblers, though?

The problem with ca65 is the need to make a config file, and understad how everything in it affects the layout of the ROM. You can obviously skip this step if you use someone else's template, but ca65 config files go beyond just mapper configuration... The way you handle RAM, ZP, pseudo-fixed banks, everything affects how you write the code later on. If you use someone else's config file you're forced to organize your ROM their way. You don't get the same freedom you have with ASM6 or NESASM unless you learn how to customize the config file.

Perhaps the sentiment is "The best assembler is the one that lets you switch to C with the least friction once you realize you need C for a particular project."

I like ASM6 because it just works. No surprises or gotchas.

I don't really think the linker config is that big of an issue for starting out with NES development on ca65. Beginners should really be starting out on NROM, and shouldn't really be attempting to do anything that requires messing with the link script, and just having them put code in the "CODE" segment and graphics in the "CHR" segment is fine. If anything, it seems more intuitive to me than having to teach ORG and such just to get started.

It is, but I would think that the ease of incorporating additional features if they become desired should be factored, pretty much what tepples said. If you feel an NES developer should have C as an available tool, (even if not at the very beginning) and the initial learning curve of ca65 is easier than needing to switch later and possibly transition an existing project, then this would be a good reason to pick ca65. If you feel that learning ca65 will be easier after more experience, and that transitioning later if necessary, is easier than starting from ca65 off the bat, that would be a good reason to pick something else.

Anything but NESASM is fine. NESASM it unbelivably terrible. Beginers are fooled by it's name, but it's really not an optimal assembler for the NES.

Of course it is! It creates iNES headers automatically, making it the best of the bunch! In other assemblers you need clumsy db/byte directives. NESASM is a big time saver, because writing the header is like 20% of the work that is creating an NES game. It even requires the PRG-ROM to be divided in 8KB banks, so you can very easily make MMC3 games, the gold standard when it comes to NES software. Why would anyone ever need banks of different sizes when they could be using the MMC3 or more advanced mappers? And what about that different syntax? That really makes this assembler stand out... When you go online looking for 6502 snippets and you see that boring standard syntax you get that nice feeling that your software is better than everyone else's! You feel so superior that you even give up on using any of that boring incompatible code as reference for anything.

And here's how to handle those fanboy arguments:


Take these macros. Please.


Money, dear boy. When you decide to manufacture your game, you might get charged less for cheaper mappers like discretes, A53, or MMC1. This means you get to keep more of the selling price.

I think NESASM is good for a beginner who wants to quickly see a working result without spending much time on learning advanced topics like header format or config scripts.

Any tool is good as long you can accomplish your goal. My memory could be fuzzy but some homebrew were made with nesasm and released on cartridge and ended quite fine. Battle kid is one of them.

@tokumaru : I was going to object when I suddenly noticed this was sarcasm... oh well. At least it was funny.

I'm going to quote a relevant section of the first post before I continue:



Knowing this, I've chosen ASM6 based on the following assumptions (which may or may not be true in every situation):

• The person in question has a small amount of experience with at least one higher level programming language and is willing to learn 6502 assembly language. (This leaves out the "beginning programming in general," for which I would not recommend NES development at all.)
• The person in question doesn't want to fumble with linker scripts, but would like to be able to define a NES 2.0 header in case their project needs a non-standard configuration. (This second part removes standard NESASM, but may include NESASM from Unofficial MagicKit.)
• The person in question isn't planning on moving towards consoles with similar CPUs (PC Engine/TG16, SNES/SFC). (If this is true, my answer changes to the cc65 suite, since default ASM6 isn't equipped to handle the 65816 or HuC6280.)

ASM6 pros

• No fumbling with linker scripts. (uses .org $xxxx for defining sections)
• Relatively simple program code. (program is a single C file, easily compiled)
• Can program for any 6502 machine; not limited/targeted to NES.
• Supports macros.
• Supports both @localLabels and cheap nameless labels (+/-).

(Of course, a number of the poll options share some of these pros.)

ASM6 cons

• Doesn't support using absolute zero page addresses $0000-$00FF without manually encoding the opcodes (ca65 uses e.g. a:$00FF for this; I've only really found this to be a problem when reverse engineering commercial ROMs though, so your opinion will vary if this is actually a con or not.)
• Original version doesn't support any undocumented opcodes (I still need to make/test a patch for this) (not particularly a big deal, IMO, unless you really want to use them.)
• The flip side of ASM6 being able to program for any 6502 machine: not many "unique" features for NES development (I personally don't see this as a con, but others might.)

Anti-NESASMism is at an all-time high here. Yes let's scare total begginers with stuff unrelated to actual 6502 or NES programming.



If you want new people to read two (3?) paragraphs of text and then give up CA65 is the best, but I'm not so sure about actually doing anything with it. You're all underestimating "NES development beginner". I still don't understand how to set up other assemblers, hell it might not even be as difficult as I think it is but it ceirtainly looks like it. Maybe someday I'll take some time to learn how to set them up but for now NESASM suits me well besides annoying silent cross page errors.

As said by our buddy here:

As a beginner, i'm more interested in interface and the amount of interfacing required. As such, ca65 is a bit much to chew, while asm6 seems pretty ideal. NESICIDE as a studio layer above ca65 might change my mind. 'Naked' ca65 could do with a better config library bundled with the distribution. I think qbasic for dos was a very good example of how to introduce programming. Everything you need is built into the interface of the editor. You can run, compile, debug and consult a very well written reference at the convenience of a key press, and there's nothing you need to set up before you've got your first program running.

I've tried nbasic a couple of years ago and didn't fall for it, but i can't remember the exact reasons.

I've used LAX a bit in hacks to help make room for new hooks, but that's it for unofficial opcodes. I don't view them as necessary otherwise. Nevertheless, i think assemblers should support them and make it the programmer's choice to use them or not.

I've taken that quote in account. That is why I recommend ASM6 despite using WLA-DX myself. For several reasons I wouldn't recommand WLA-DX to the newcommer.

Your 3 ASM6 cons really doesn't sounds like cons at all for me. ASM6 might not support full-length access to ZP which could be bothering if you use indexed addressing to go past the ZP into the stack page, but honestly this case is *very* rare. However, assemblers which does require you to specify whether you are using ZP or not, such as NESASM and to a lesser extent WLA-DX, are a major annoyance.

@Tokumaru: In your NESASM apology you forgot to mention it is great to define variable location directly instead of having them assigned by the assembler, because this makes it easier to debug your code in FCEUX, and because array sizes never changes, period

I started with NESASM, myself, but only because I came in through bunnyboy's legendary tutorial. The tutorial itself has problems, and NESASM is probably the worst assembler I have ever used, but it did the job.

Similarly, I learned to program in BASIC many years ago. It's rather obsolete now, and there are a lot of drawbacks to it as a language, but it was available to me, and it worked, and I learned. I wouldn't recommend it to anybody at this point, but at the time there were great books, tutorials, and code listings in BASIC available to me. It's not really a "good" language, but it had fantastic learning resources.


If you ask me what I'd recommend for NES, I'll always say ca65. I've got little sympathy for complaints about header/cfg, because beginner templates for these are both trivial and readily available, and on top of that you've got people here on the line ready to help you with both those things any time you ask. This community is a bizarrely nice one in that respect; people rarely give you grief about asking a question that's been asked 100 times before, they usually just politely answer it for the 101st time.

But... it doesn't matter at all. NESASM is OK for beginners. So is ASM6. So is ca65. They're all good. If you learn one it's really not that hard to learn another. Pick the one that seems easy-- which probably means: use the one that has examples you want to learn from. NESASM is still the King of n00bs for this reason.


I do have an actual recommendation for beginners, but it has nothing to do with language: keep your goals very small as you begin. Don't expect to be able to make a Blaster Master with your first project. You have a lot of learning to do before you even get to Flappy Bird, or 2048.

Worry about which language to use when you're ready for something bigger.

...and worry about which language someone else will use for their project never.

The intent inherent in my vote for ca65 is that the beginner would download a project template for NROM, unzip it to a new folder, and start putting code in main.s. The project template would contain a bunch of library-type source code files for things like disabling IRQ sources and waiting 2 vblanks upon reset, but lesson 1 that just turns the screen green and beeps the speaker wouldn't need to explain the functionality and design rationale behind every line of code in each library file.


Then the question becomes one of what goals a beginner is likely to have for his or her first half dozen projects.


Thank you. Perhaps it's that I see re-asked questions as a chance to find things that are missing, wrong, or poorly explained on the existing wiki pages.

Snapshot: At this point, it's 12 (44%) for ASM6, 10 (37%) for ca65, and 5 (19%) between NESASM and MagicKit.

Okay, I think I see where this poll is going. I'd like to add a time limit at this point, (another week or so) but I'm afraid adding a time limit may erase the current votes. Can anyone confirm or deny this?

I'll start a thread in the wiki board when I get ready to post a draft for the entire page, but for the time being, I'd like to get feedback on the assembler portion. The community is the authority on this so please post any suggestions/corrections/etc.

I would like to try to keep the terminology non-intimidating for a beginner. I'd also like to keep it objective, and I do feel that currently it has a hint of subjectivity that needs to be tweaked out. Also, concise is very important, but it also needs to give enough information to be useful. As this is likely one of the first sites a person will see when looking into NES development, I think that from beginning to end, it should explain any information contained within itself.

So before the assembler part, there's an introductory paragraph at least. I'll save those parts for another thread and keep this about assemblers, so let's assume at this point our reader:

1. Wants to develop for NES. (Really we don't know more specifically than that.)
2. Has been introduced to the idea that they are writing in assembly code for a processor called the 6502

Assembler:

The assembler is what will take your programmed code and create a ROM which you can play on a NES console or emulator. It translates assembly code into machine code, and formats your program in the way you define. There are various options for assemblers targetting the 6502 processor, but two main options recommended by the NESdev community:

1. ASM6 - According to a NESdev community poll, ASM6 is the most recommended assembler for a beginner. (http://forums.nesdev.com/viewtopic.php?f=2&t=14330) It is not lacking features required for the general workload of 6502 assembly programming. It is missing some more advanced features, which can be seen as a positive for beginners as it helps to keep the learning curve low. The way the language is programmed for ASM6 follows general accepted standards, and there is a large community of users for this assembler.

Download ASM6

2. CA65 - CA65 is a 6502 assembler included with the CC65 suite, and use of it permits the highest range of features. It is the second most recommended assembler for a beginner, by a narrow margin. For a non-programmer, it will have the highest learning curve, as you will have to learn to create a linker file from the start. It could be argued, however, that the practices associated with formatting your program with a linker file may be more easily maintained in the long run.

CA65 will allow for some options not available through other assemblers, such as integrating the C programming language into an NES program, and source level debugging. The methodology for working in CA65 will be the most familiar to those with experience in C, so prior programming experience may factor into your decision.

Download CA65 (as part of the CC65 package)

Other Assemblers Targetting 6502:

NESASM - NESASM is an assembler most notable for its use in the popular "Nerdy Nights" tutorial series. It has a small number of loyal users, but many who have used the assembler in the past would recommend against it. Of the three most popular assemblers for NES development, this one uses a syntax least in accordance with assembly standards. It is also very particular about the way code is spaced, which is not an issue with the previous two assemblers mentioned.

Download NESASM

It is also worth noting if you wish to follow the Nerdy Nights tutorial, that members of the NESdev community have created examples of the tutorial files written for ASM6 and CA65, so your choice of assembler is not required to match that of your first tutorial.

Nerdy Nights ASM6 Example Link
Nerdy Nights CA65 Example Link

(Consider adding some sort of cheat sheet for Nerdy Nights to ASM6/CA65 conversion, just covering directives used in the tutorial)

(I don't know much about these other assemblers ATM)
MagicKit - Download (Description?)
NBASIC - Download (Description?)
NESASM - Download (Description?)
NESHLA - Download (Description?)
WLA-DX - Download (Description?)

I combined MagicKit and NESASM in my snapshot because they are the same product. MagicKit has that name because it appears to be produced by the same team behind MagicEngine, an early TurboGrafx-16 emulator. NESASM is a version of PCEAS, the assembler in MagicKit, modified to add an iNES header, and its MMC3-oriented bank size matches that of the built-in mapper in the TG16's HuC6280 CPU. Unofficial MagicKit is a fork of NESASM with more features.

NBASIC and NESHLA aren't really assemblers as much as attempts to make a language higher level than 6502 assembly but with less overhead than C.

The source code for NESASM is on github. I was wondering if the bank size limit could be easily changed, thus making it not such a pain to have banks over $2000 bytes.

https://github.com/thentenaar/nesasm/tree/master/source

5 minutes of looking at the code, and I didn't spot the bank size definitions. I thought it might be bank_limit in main.c, but that seems to define how many banks a project can have.

Maybe it's this line...

if (loccnt > 0x2000) {
if (proc_ptr == NULL)
fatal_error("Bank overflow, offset > $1FFF!");

Anybody out there want to tackle this easy task of editing the code and recompiling?

Well, in this thread it has been argued that beginners shouldn't be making linker files, and should use ready-made templates instead. (Note that all assemblers have this burden to some extent: a beginner is not going to easily understand vectors, or NESASM's banking system (and how it relates to iNES banks), or how to use .org properly. So they will need some kind of a template to start with.)

Oh well... I guess this is probably how tutorials do it, but reading the documentation I see it actually has 3 directives that seem very useful for declaring variables and structures: DS, RSSET and RS. Still, I don't trust NESASM as a whole... mostly because of the baffling quirks (things like line length limitations, indentation, silent failures, and so on) that are discovered from time to time.

I'm perfectly happy with ca65 right now. I've been using a lot of its features (mainly its macro system, backed up by the many built-in commands and functions) to automate things in my current project. And I still think that ASM6 is the best assembler to get things done quickly and without hassle, so that's the one I'd recommend for beginners.


I've never been very fond of using other people's code without understanding what exactly is going on. And when I do get what's going on, I often prefer to write my own version of it, to make sure I really got it. The memory layout of an NROM program (which is what every newbie should be going for) is really simple, and I think both ASM6 and NESASM get points for being able to easily assemble a single ASM file directly into an NES ROM without any code hidden from the programmer. The amount of "magic" code that gets thrown at the aspiring programmer's face is minimal (a few DBs for the header, an ORG for the start of the program and another for the vectors, in the case of ASM6), and since it's always there, in the middle of the program, it should naturally start to make sense as the programmer continues to mess with the code, because he's directly dealing with it all the time.

Config files, on the other hand, are hiding the memory layout from the programmer, and assembling scripts are also hiding the way the ROM is built (assembling + linking). A person will never learn naturally about things that are hidden, they'll have to deliberately study those things to make any sense out of them. To me, studying this wasn't particularly hard because of my previous knowledge of memory mapping I acquired from dealing with ORG statements, something I wouldn't have if I had used someone else's hidden code when I got started.

Templates containing config files, assembling scripts, macro packages, whatever, make something that's dead simple (NROM) appear complicated as shit. With ASM6 or NESASM you can start simple, as someone's first programs should be. Writing the contents of the ROM linearly also helps with understanding the memory layout, before a person is comfortable to freely mix segments and such.

I have some thoughts on this matter, and I'd like to share some of my beginner experiences.

At some point eary in my exploration, I downloaded tepples's example project file. I remembered my days as a kid beginning qBasic by monkeying around with the Gorilla banana toss game. I thought I could get some grasp of what's going on by just looking at it. I have to say though it was a bit much for me at the time. First thing I notice is, "Woah! this is a lot of files!" but I didn't give up immediately. I believe I most likely went into main.s first. Now something like, ".include", i can gather from context. I'm knowing at this point that I'm going to have to reference most of the instructions to understand them, but I believe the point at which I realized that this was beyond me is when the highly descriptive comments went over my head.

Now this experience is not meant in any way to reflect poorly against the template created by tepples. It is obviously something intended for someone with enough experience to at least know what an NMI is. I will probably use this template if/when I transition to ca65. The point that I aim to make is that without appropriate hand-holding, templates can be intimidating to a beginner.

I believe this intimidation can be amplified by templates with a lot of files, and arguably by better written code, but isn't exclusive to it. I feel that things like the setup code can be very confusing to a beginner and are really better of left alone for a while. If that stuff EVER needs to be messed with, odds are you'll feel comfortable doing so when it's needed.

Really I believe the benefit to Nerdy Nights was the separation of steps and the fact that I could pretty much skip to the part where I'm putting graphics on the screen. From there, I was able to identify a single element of NES development from which I could see immediate results. The sort of thing I'd wanted to see since I was a child; my graphics displayed on screen by a Nintendo Entertainment System.

I believe being able to separate a single sandbox from the complex parts was what made it work for me.

Also, before any of this, before I even downloaded the NES template, I went to the Easy 6502 tutorial. I have to say, I've thought about it, and I believe this may be the best very first tutorial for a beginner. No tools are required; the web page has an embedded emulator. You're not messing with complex hardware idiosyncrasies but basic assembly concepts and opcodes. Using this tutorial was the first point at which I thought, "So this IS possible..."

I've thought about this too and I feel the wording should reflect the option to use a template. Also though, considering that (currently at least) a majority of users have preference for ASM6 as a first assembler, I think it would be unfair to not, in some way, briefly describe why this assembler may have a higher learning curve.

Can you explain a little more about the snapshot? Should I integrate your changes into my next draft or add my changes to your snapshot?


Another thing that I am unsure about on the draft is the amount of content dedicated to the Nerdy Nights tutorial. Now, this currently being the defacto tutorial, I feel like it's kind of a obligatory service to not necessarily guide a person there, but to consolidate information to help a person make an informed choice on acquiring tools before approaching it. However, I think there are a few issues with having arrows pointing toward that tutorial. For one, it's not a part of NESdev and won't be perpetually updated by the community; two, it targets a non-recommended assembler, and three, I believe most experienced 6502 coders would agree that it doesn't always teach the best practices. For the sake of doing what works for now, it seems the simplest method to provide links for Nerdy Nights related info. The problem with this I see though, to easily direct a beginner in using ca65 or (to a lesser extent) asm6, pretty much requires a tutorial for the tutorial. It's probably the easiest, as most of this work has already been done, it just needs to be consolidated. However, it's surely not the cleanest solution.

I've attached the tutorial that tepples started writing at one point, that he sent me to get me started on NES development. While it's very incomplete (never covers sprites, doesn't clear the nametable, doesn't initialize RAM) I think it does a good job of showing off how a ca65-targeted tutorial can be very approachable to a beginner.

Each of the steps gets their own folder with just one source code file to look at each, and it's a lot less overwhelming than trying to make sense of a project template that's aimed at more advanced developers. Instead of a makefile it just uses batch files, which are right in the folders for the steps and which have comments explaining what they're doing if the person wants to know. Instead of Python scripts for converting tiles they're just already in the correct format.

It was very easy for me to figure out what was going on and extend the "Hello World" text demo into a crude text scroller.

I use xa. It's as simple as it gets, and that's the way I like it. The only reason I wouldn't recommend it to a[nother] beginner is its habit of treating anything it doesn't understand as a label - typos silently assemble to nothing. But I've only run into that problem once myself, and I do think that less is more when you're getting started.

I've half a mind to write my own, but that wouldn't help anyone.

Me neither.

I can see the benefit in learning everything from the ground up, but I can also see the benefit in hiding some details to focus on the most important parts (6502 instruction set and basics of the available hardware registers) until one is ready to understand the rest of it. I guess it comes down to how one wants to prioritize the learning.

(By the way, I also voted for asm6. I really don't know what the right answer is. Maybe it doesn't really matter all that much.)

I was just reading an article on Reddit 'Stop Designing Languages. Write Libraries Instead.'. I feel the same about NES programming. We have tutorials, we have assemblers, we have tile editors, what we need are MORE 'libraries' of 'magic code'. Just include the library, and a detailed explanation of how it works, and anyone will be able to program a game.

If a developer out there can program a game without knowing much at all about NES hardware architecture specifics, I think that is a good thing.

This is great for some functions, but I think the largest library would have to be "NES game engine"

A lot of things wouldn't be able to work independently of one another. All of the libraries would have to be programmed expecting the same organization of data. I couldn't just plug, say, a collision detection routine into my game because it doesn't know how my map data is arranged, and there are too many possibilities to make a library for each. At this point, I feel like it couldn't be so much a collection of random libraries, but rather plug-ins for an open-source game engine.

A tutorial would cover this when it gets to the mapper chapter.


In ca65, it's supposed to be as simple as using cl65 to turn .s into .nes. But for some reason, the VECTORS segment in the included NES linker config is bigger than necessary: I'm seeing it start at $FFF4 in crt0.s, and the included linker config appears confused as to whether it starts at $FFF4 or at $FFF6. Another problem with ca65's included linker config its that its assumption of WRAM on the cartridge PCB has caused actual problems for a developer that wanted to replicate a finished game on cartridges.

But without scripts, how else is the beginner supposed to produce graphics in the format that the NES expects? Use a severely outdated YY-CHR to work around hardcoded backslashes in the present version? Just use ASCII art for everything and assume the environment provides a font? The file neschar.inc is theoretically just as hidden.

I'll try another means of explaining: Compare to hello world in C:

Where does stdio.h come from, and how is that different from library files packaged in a template?


So would it be a good idea to target the NES programming tutorial to people who just completed Easy 6502?


By "snapshot" I was referring to the vote counts at the time I made that post. What you should take away from this is that NESASM originates in MagicKit, a set of tools to develop homebrew TG16 games.

I'd be curious to see if others feel similarly that this tutorial is a good method of getting some of the foundations of assembly without over-complicating the matter. There's also the problem though that the knowledge base is dependent on an outside source.


CA65 and ASM6 are so close that it might not be fair to give as much as an "endorsement" to either one but rather objectively stating the pros and cons in a concise manner.

I'm also thinking that I should limit the descriptions of all but the top two assemblers to a single sentence. This would remove mentioning of tutorials from the tools section, as the topic of tutorials is too large to do justice and still keep the tools page concise. I feel like the person should leave the tools section with a text editor, an assembler, maybe a compiler if that's their flavor, an emulator, some graphics tools and perhaps some sound tools. Then there can be links to a page that addresses tutorials more in depth.

That worked for me. Back when I first started, 17 or so years ago, we obviously didn't have as many resources as we do today, but somehow I was able to piece together a simple ROM that worked in Nesticle (and most certainly not on real hardware, since back then we didn't even wait for the PPU to warm up) with a few walking sprites I made from my favorite anime series. I could barely understand what I was doing, and coming from QBASIC, assembly was hard as fuck to grasp.

It wasn't until I discovered Michal Kowalski's 6502 Simulator, years later, that I finally understood how the CPU worked. Being able to experiment with the instructions in a controlled environment, without having to interface with additional hardware, allowed me to fully grasp what the work of the CPU was.

Jumping straight into NES development without any prior knowledge of assembly is like going to college in a country whose language you don't speak... You're gonna have to learn the language and the subjects at the same time, which can be quite confusing. If you take the time to learn the language first, you're gonna have a much easier time with the subjects later on.

I already cast my vote, and was trying to stay out of this thread as much as I could, but tokumaru said something that warrants focus:


This is probably the most key point there is to make in this thread. So once again, I feel like I have to educate people as to the realities of software development on a platform and CPU that is foreign to the easy majority of people who want to get involved with it -- but this general advice applies to more than just the NES/6502.

If a person who doesn't understand 6502 assembly language is thrown into the fray that is ca65/ld65's config/template files and all the rest (having to explain all the SEGMENT and MEMORY bits in particular) they're going to become overwhelmed and annoyed quickly, likely giving up. I've had friends/colleagues of mine experience exactly that (one of them, funny enough, does low-level development; he actually worked at Hex-Rays!). This point applies even if you give them pre-made templates, because eventually they're going to have to futz with it. Mid-lecture reminder: the person has no 6502 assembly knowledge, and learning that should be their primary focus at first. And to learn that, they need a tool that is simple and isn't going to get in the way of their primary focus (learning the language). It's something that should try to correlate as "close" as possible to what they'd see in a debugger.

This is where a "bare-bones/simple assembler" like asm6 has the upper hand. The only "convoluted" parts for starting out are the 16-byte NES header and use of org. You can literally give them those for a simple NROM image and be like "we'll cover the details of this in a later chapter, for now use these lines to make the NES header and set the origin address to $C000 and focus on learning 6502!" People are going to prefer a copy-paste into a single .asm file over "here, extract this .zip, which has all sorts of crap in it, and then deal with paths and files and make sure you change X/Y/Z to reflect...", sorry to say.

IMO, ca65/ld65 present a fairly substantial learning curve (the config/template bits are, I think, still the #1 thing discussed here when people start using the cc65 suite, including for SNES development), and sometimes all it takes is "a complicated tool" to destroy someone's desier to learn an actual programming language/architecture. The learning curve with asm6, IMO, is substantially less, allowing the individual to focus more on the 6502 aspect than "the assembler and it's related 'stuff'". Dwedit's post on the first page sums it up.

Personally, I've stuck with NESASM, simply because it's portable. There's no need to install any dependencies/libraries. Which is a pet-peeve of mine.

As for tutorials? It's very lacking across the board. Any tutorial is easily applied to any other compiler, so long as you know the differences in syntax/functionality. So that's not a problem.

Before I had nuked my portfolio, I was hosting some translated Japanese tutorials on my site, because they were generally more thorough than anything else available.

O_o? Which assemblers being discussed here require any kind of additional dependencies or libraries to install?

ca65.exe requires (and comes with) ld65.exe as well, but that's the only thing I can think of, and I'm not sure that should even qualify.

Even if you're compiling the assemblers, asm6 is just a single .c file that only uses standard C stuff, and you can't get any more portable than that.

I'm not aware of any dependencies asm6 nor the cc65 suite requires on Windows. They're both literally "unpack-and-go". Maybe Alp found binaries (for cc65) which had weird/unnecessary DLL dependencies? Neither require anything like Cygwin either, so...

CA65 was the first compiler I checked out, and it installed a bunch of junk. I promptly uninstalled it. I don't like cluttered compilers.

I much prefer portable applications than installed ones, so I always look for zipped packages instead of clicking the first big green button that's shoved in my face. I'm pretty sure that there are portable cc65 packages available for download, so you don't need to install anything. It does come with a bunch of stuff that people write just looking for an assembler will never need, but at least everything is neatly contained in one folder.

I've never even heard of an installer for cc65. Where did you get it?

Was it things like linker configuration files, runtime libraries, and the like for home computers like Apple II, Commodore 64, and Atari 800? Or was it things like od65, da65, etc. that aren't normally used when building an NES project?

The cc65 suite zip that **I** downloaded (cc65-snapshot-win32.zip) came from here (which is linked directly off the main github page). Attached is the file listing from the .zip I have (not necessarily the one on the site now, but you can see timestamps in the listing). There is no installer, dependencies required, or any other "junk" other than lots of predefined templates, include files, etc. (all of which is normal -- people need to remember ca65/ld65 are part of cc65, so there's a lot of stuff there that's helpful for cc65 but isn't needed).

I will note that the snapshot links to SourceForge, which has had a history of injecting crap into people's stuff. The cc65 folks should find somewhere else to dump their snapshots, IMO.

There used to be a VBScript file included for installation. It's gone now but you can find some references to it if you google for "install.vbs cc65". I never used it even when it was there.

I decided to cast my vote for asm6 in the end. If you don't need verbose etc, nothing is simpler than dragging and dropping a sourcefile onto an exe and have a binary ready, which apparently works if you contain asm6 in the project folder.

It *could* have a wider acceptance of syntax, though, for cross-compatibility and newbiefriendliness. For instance, take size/offset definitions for includes either before or after the path, etc. But that's just extreme nitpicking.

I'd still advocate for something like a qbasic editor if the scene wants to encourage more newcomers. Notepad++ is all fine, of course, but an environment where the compiler can talk back to the editor, and where every instruction has a reference card and a few related examples, is what made microsoft's take on BASIC so popular; more so than the language itself, i think. I concider qbasic microsoft's finest piece of software in terms of user friendliness. Or maybe it's rose tinted nostalgia? User interfaces takes time, though...

I made a quick proof of concept for nesasm regarding the label length limitation 5 years (?) ago so maybe something like this shouldn't be an issue but.. I didn't touch the code for 5 years either so I would need to check it again.

I'm neither for or against nesasm since I did use it at the begining. As long as it does the job I'm fine with it and since it's open source, if you find something that annoys you then you can fix it, why not.

Warning if you use NESASM/MagicKit, that it uses nonstandard syntax. In my opinion this nonstandard syntax is better than the standard way and I prefer it; also I have made a version of NESASM/MagicKit which includes many of my own improvements (especially support for more advanced macro capabilities), so that is what I use.

Maybe the code I modified a long time ago was from the things you modified? It's been a while and I don't remember. I modified the issue regarding macro length limit, just found the source code. Did you had a repository for it?

I have no repository of it, sorry

Doesn't XA requires DOSBOX to run ? Before I used to use that, and it was amazing, but there was thiss... em... little problem.

It appears to be the same assembler you get from Ubuntu's repository when you sudo apt-get install xa65. (Compare the copyright file.)

I absolutely love ASM6, and I think it's good for beginners because it's specifically designed with the NES in mind. It's simple and minimalistic, yet includes a lot of really nice features like its macro capabilities and it's reusable bidirectional labels - and +. ca65 is nice, but it wasn't specifically designed for the NES and as a result includes a lot of stuff that has little or no relevance for NES programming. Plus, ASM6 is super simple to use.

I wouldn't say that... It may have been created by a guy who makes NES programs, but nothing about it is of exclusive use for NES programming. It's a pretty generic assembler really... the most unique features I can think of are the abilities to temporarily change the PC without affecting output (useful for declaring variables) and to reset the PC to start a new ROM bank, but those features are useful when developing for many other 6502 machines.


Then don't use that stuff!

One thing I miss in ASM6 is a better way to handle ROM banks. Labels don't carry any bank information whatsoever, so you either have to keep track of where everything is manually (too error-prone), or keep track of the bank indices using a symbol, and create a new symbol copying its value for each label you need to remember the bank (e.g. UPDATE_VIDEO_BANK = BankIndex near UpdateVideo:). It would be nice if you could set a bank index so that all subsequent labels would "belong" to that bank, and you could easily extract that information elsewhere.

Another thing I miss is being able to output the values of symbols and labels, so it'd possible to display useful information about the ROM being assembled (e.g. more specific error messages, used/free space, etc.). AFAIK, the only way to display messages is with ERROR, which only handles constant strings and stops assembly. I actually miss being able to manipulate strings in general, to do things like create dynamic identifiers, which I've been doing a lot lately.

To do dynamic identifiers and the like, you could write a custom preprocessor whose output is fed to ASM6. I wrote a preprocessor for two or three projects in the Action 53 multicarts, so that I could take code designed for NESASM (LAN Master) or alien (1007 Bolts), feed it to my pet snake, and give the result to ca65.

If we decide to build the early tutorial around ASM6 for its simplicity, how would we handle the transition from simple projects to complex projects (where ca65 has somewhat of an edge)?

Perhaps eventually a follow-up tutorial (this also reduces the scope necessary in getting the first tutorial up) and in the meantime, join the forum community, introduce yourself, search posts and post questions.

I don't think a beginner tutorial has to handle that complex projects. It's up to the beginners what assembler to use for their own projects after they have completed the tutorials.

Having finally tried ca65 a bit I can say that it's not bad although I haven't really used it's more advanced functions. Still the cleanness of asm6 is hard to beat. It has the simplicity of NESASM but without all the problems.

Although I feel like the asm6 vs ca65 war is mostly about personal preferences, I think asm6 is more suitable for beginners for the same reasons Koitsu already said. The config files and linker just helps confusing the beginner more than necessary, at a time when it's more important to grasp 6502 and the hardware.

For those who want to mess about with it, I easily compiled cc65 in the Ubuntu-on-windows setup that the Windows 10 Insider Preview (yuck) allowed me to use. I also had no trouble using the binaries I had built for my main Debian system. Obviously these aren't steps for beginners, but it did make the same makefile work on both operating systems (sort of) without any changes.

A more direct method is to just compile it with MinGW and the MSYS shell, which produces regular Windows executables. I think cc65 will just build on anything that has GCC and Make.

A beginner on Windows is just going to grab some pre-compiled executables though and those are easy to find for whatever assembler they choose.