Help using ca65/ld65

[pinkpuff]

I'm trying to figure out the details of how to use these tools to create a .nes file from a .asm source file.

I tried downloading one of the demos (http://wiki.nesdev.com/w/index.php/Full_palette_demo) and found that it would compile just fine with ca65 but when I used ld65 as follows:

Code: Select all

ld65 -t nes full_palette.o

it says this:

Code: Select all

ld65: Warning: ~/Documents/Software/cc65-master/cfg/nes.cfg(63): Segment `HEADER' does not exist
ld65: Warning: ~/Documents/Software/cc65-master/cfg/nes.cfg(63): Segment `STARTUP' does not exist
ld65: Warning: ~/Documents/Software/cc65-master/cfg/nes.cfg(63): Segment `VECTORS' does not exist
ld65: Warning: ~/Documents/Software/cc65-master/cfg/nes.cfg(63): Segment `CHARS' does not exist

Looking at the source code, it does appear as though it has indeed has segments with those names... What is going on here, am I doing something wrong?

[thefox]

Not sure exactly how or why, but it looks like ca65 is choking on the Macintosh line endings that the file uses (0xD instead of the 0xA used in *nix, or [0xD, 0xA] used in Windows). So it seems to be a bug in ca65.

You can fix it the file for example with Notepad++ (Edit -> EOL Conversion -> Windows Format).

[cpow]

Looking at the source code, it does appear as though it has indeed has segments with those names... What is going on here, am I doing something wrong?

Did you try passing ld65 the name of your config file with -C <file> or --config <file> ? I think it expects ./nes.cfg by default for -t nes.

EDIT: NINJA'd - thanks thefox

[thefox]

I dug a little deeper into the source. The root of the problem is that ca65 assumes (rightfully so) that it will only get "\n" line endings after opening the file in text mode. Since the "\r" endings don't get converted to "\n", it consumes the entire file as a part of the first comment line.

[tepples]

Classic Mac OS used ProDOS line endings (\r), but OS X switched to UNIX line endings (\n).

Python's "rU" mode automatically translates all three line ending disciplines (UNIX \n, ProDOS \r, and MS-DOS \r\n). If you have Python installed on your computer (and if you're not running Windows, you probably already do), try running the source code through this program:

Code: Select all

#!/usr/bin/env python
# fixlineendings.py: convert a text file's newlines to native
# By Damian Yerrick, no rights reserved, no warranty
from __future__ import with_statement
import sys
with open(sys.argv[1], "rU") as infp:
    body = infp.read()
with open(sys.argv[2], "wt") as outfp:
    outfp.write(body)

[Movax12]

Open and save the file with wordpad.exe: usually fixes line endings.

[pinkpuff]

Hm I suppose I should have mentioned earlier that I'm using Ubuntu linux... my bad, sorry about that.

Anyway I changed the line endings to windows-style ones (I'm using Geany, it has a built in feature for doing that), and now I'm getting this error instead:

Code: Select all

Warning: Segment `CODE' is not aligned properly. Resulting executable may not be functional.

When I loaded the output file in FCEUX it ran but it didn't show the full palette as seen in the screenshot on the wiki. It just had a bunch of different blue horizontal bars repeated over and over.

[Movax12]

Nintendulator will do a better job with this demo, though I don't know how well it will work with Linux.

[lidnariq]

Nintendulator works reasonably under wine.

[pinkpuff]

Ok so I guess the blue line part is just the emulator, but the bit about the "CODE segment" alignment is still confusing.

[thefox]

Anyway I changed the line endings to windows-style ones (I'm using Geany, it has a built in feature for doing that),

In that case you could've as well converted it to *nix style line endings.

and now I'm getting this error instead:

Code: Select all

Warning: Segment `CODE' is not aligned properly. Resulting executable may not be functional.

The code was probably written for an older version of cc65 that didn't have this warning (or the author ignored it). It is shown when .align is used, but the corresponding segment doesn't have "align=xxx" specification in the linker configuration with xxx greater or equal to the alignment requested in the code.

For example, if .align 256 is used in the code, ca65 (when assembling) assumes that the current segment starts at an address multiple of 256. If align=256 is specified in the linker configuration, this is always true. If align is left out of the linker config, it may or may not be true. In your case, it worked regardless because there were no other segments with data before the CODE segment.

And don't worry if you didn't understand the above, it's really not that important.

To fix the warning, you'd have to dump the default NES configuration from ld65 (ld65 --dump-config nes), add align=256 to the segment definition of the CODE segment, then use the new configuration file instead of "-t nes" when linking.

[pinkpuff]

Thanks for the help, everyone!

To fix the warning, you'd have to dump the default NES configuration from ld65 (ld65 --dump-config nes), add align=256 to the segment definition of the CODE segment, then use the new configuration file instead of "-t nes" when linking.

Isn't there something I could edit in the asm file instead of messing with the config file? Or would that just be even more complicated?

[Movax12]

If you're planning to learn asm coding for NES and want to stick with ca65, you should setup a proper config file for your project(s) anyways.

viewtopic.php?f=2&t=10435

[pinkpuff]

That thread seems to have a bunch of different config files in it. Which one should I use? Is there something wrong with the default one? Or is it normal to have a different config file for each project? If it is, that seems a little strange to me, as it seems like it should be a configuration for the target system (NES) rather than the code... isn't it?

[lidnariq]

It is the configuration for the system, but the cartridge one plugs into a NES can significantly change how the system acts.

The cartridge can add extra RAM, or the ability to address more than 40960 bytes of data, or more complicated things. (This is why we have the notion of "mappers" in the iNES header.)


In addition, you may wish to change the mapping if you are using modules of code that need to be in different places, or aligned to specific things.