nesdev.org

Amending koitsu's last reply:

cc65 is the C compiler (C to assembly, or C to object)
ca65 is the assembler (assembly to object)
ld65 is the linker (objects to output)
cl65 is the combo "compile and link" (or assemble and link, in this case)

Also, the current documentation is here: https://cc65.github.io/doc/

(The old documents from several years ago that were left up for archival purposes are still unfortunately higher in google results. You should use the new ones.)


Though to be honest I avoid using cl65 in general and prefer to do separate steps for assemble and link. It may seem like an unnecessary step for a single file, but you can get better feedback about what's going on this way.

Got it! there is a comma I was forgetting
cl65 -t none -C nes.ini -m map.txt -vm -o rom.nes -g -Wl --dbgfile,rom.dbg main.s header.s
Thanks, I was really not getting what the switches do...

rainwarrior wrote:--dbgfile is available to cl65. I don't think -Wl should be used in this case.

Hmm, are you sure? I don't see --dbgfile {filename} mentioned in that document (for cl65, cc65, or ca65 for that matter). I see --debug-info for cl65, which is the same as -g, and doesn't take a filename argument.

This is why I think -Wl needs to be used, since ld65 is what supports --dbgfile per documentation and this check I did that shows it only appears in the documentation for ld65:
It's super easy for me to mix up ca65 vs. cc65 vs. cl65 vs. ld65 so it's very possible I got something wrong.

No, I was wrong about that. Was reading from the wrong tab, I suppose? I'd edited it already before you replied... but you manged to get a quote in. :S

Would recommend that you stop using those outdated documentation links, though. The current stuff is here, and a lot has changed in the past several years since those were frozen:
https://cc65.github.io/doc/

Though also in your multiple-lines example at the end, if you're doing that you should use ca65 and not cl65 for the assemble step. You get better and more direct options and output that way.

Also the -t none is a workaround for cl65 which for some reason defaults to C64 instead of none. You can omit that from a ca65/ld65 invocation and have a simpler command line. (Actually if you're using -C with the linker, -t is invalid anyway.)

That's part of my advice in general for not using cl65. It's kind of a weird black sheep in this toolset, and it probably seems like it's simplifying things by removing a step, but I think we just proved otherwise with that awful command line jockeying we just had to do.

halkun wrote:Got it! there is a comma I was forgetting
cl65 -t none -C nes.ini -m map.txt -vm -o rom.nes -g -Wl --dbgfile,rom.dbg main.s header.s
Thanks, I was really not getting what the switches do...

Ah, yes! I wasn't sure if the comma was needed since there's a substantial difference between spawning conventions, argument-wise, when it comes to arguments given to one utility that are "passed on" to another. It all has to do with how argv[] gets parsed (by cl65) and what gets passed on to the spawned utility (ld65). The comma-delimited portions are internally handled by cl65 to ensure that they're "passed on properly" to ld65, rather than parsed natively by cl65 itself (hope that makes sense!). In short, there's a substantial difference between these 3 (from the perspective of ld65's argv parser):
All of this (and more) is why I prefer just calling the compiler/assembler directly, and then the linker directly at the very end to link everything together, something rainwarrior advocates as well. cl65 does seem to be a "black sheep" of sorts; sticking to invocations of cc65/ca65/ld65 directly seems to be a better choice.

rainwarrior wrote:Would recommend that you stop using those outdated documentation links, though. The current stuff is here, and a lot has changed in the past several years since those were frozen:
https://cc65.github.io/doc/

Yeah, I think I've been lectured about this more times than I can count. :-) The reason I get them wrong has to do with the bloody search results in Google or other SEs. Searching for "cc65 documentation" gets you these (order may vary per person, based on Google's weighting algorithms):
And this is just for cc65 -- but if you look very closely, the last result is actually for ca65 (the assembler), but says "cc65" in the title hence it comes back in the search results.

This same situation applies (though slightly varied) to ca65 and ld65. For cl65 and da65 (disassembler), the situation is much more clear: you only get 2 results: the http://www.cc65.org version and the cc65.github.io version.

github.io (a.k.a. "GitHub Pages") is the "web content" part of github.com, i.e. refers to content in your GitHub repository that you can change/manage with commits like normal, as long as its maintained either via static files or dynamically by GitHub via Jekyll. (I always forget this "sub-feature" of GitHub exists, as I prefer native Markdown documents so that I don't have "multiple websites" showing essentially the same stuff (github.com vs. github.io) -- just put all the content on github.com, which renders Markdown itself, and be done with it)

In short: I wish whoever maintains cc65.org/www.cc65.org would take the time to set up proper HTTP 3xx redirects from old document links to cc65.github.io and relieve half of this confusion. Users are almost certainly going to pick a website based on the software's name over something on GitHub. The actual project maintainers have obviously revamped documentation in a good way (ex. there is no more "cc65-2.html", they just put it all into one document and used anchors), but there's "old stuff lingering" that continues to take priority search-result-wise. :-(

koitsu wrote:I wish whoever maintains cc65.org/www.cc65.org would take the time to set up proper HTTP 3xx redirects from old document links to cc65.github.io and relieve half of this confusion

I raised the issue twice in the past, and then gave up. Feel free to give it a try yourself.

Otherwise all I can do is point out that you keep linking the old documents, and offer a link to the better ones.