Recommended assembler for NES development beginner [POLL]

[thefox]

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.)

I've never been very fond of using other people's code without understanding what exactly is going on.
...

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.)

[dougeff]

The amount of "magic" code that gets thrown at the aspiring programmer's face is minimal

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.

[darryl.revok]

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.

[tepples]

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.

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

Templates containing config files, assembling scripts, macro packages, whatever, make something that's dead simple (NROM) appear complicated as shit.

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:

Code: Select all

#include <stdio.h>
int main(void) {
  puts("hello world");
  return EXIT_SUCCESS;
}

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

Also, before any of this, before I even downloaded the NES template, I went to the Easy 6502 tutorial.

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

Can you explain a little more about the snapshot?

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.

[darryl.revok]

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

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.

[tokumaru]

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

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.

[koitsu]

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:

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.

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.

[Alp]

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.

[rainwarrior]

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.

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.

[NovaSquirrel]

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.

[koitsu]

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...

[Alp]

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.

[tokumaru]

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.

[rainwarrior]

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

[tepples]

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.

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?