It is currently Sun Aug 25, 2019 7:40 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: cc65 not compiling code
PostPosted: Sat Aug 10, 2019 12:58 am 
Offline
User avatar

Joined: Fri Mar 16, 2018 1:52 pm
Posts: 93
Location: Finland
According to a tutorial I've been looking at, you have to write something like this in a .bat file to get cc65 to compile code:

Code:
ca65 test.asm -o test.o
ld65 test.o -o test.nes -t nes


However, when I try to compile, there is no output file nor any errors displayed. Well, there could be, but the command line closes before I can see if there are any. Does cc65 have a function similar to the "pause" function in NESASM3?


Top
 Profile  
 
PostPosted: Sat Aug 10, 2019 1:06 am 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1289
PAUSE is not a function of nesasm3, it's one of the windows command line. Adding PAUSE to any .bat, NES related or not will have the same effect.

Edit, because it was only implied, not directly stated: You can add PAUSE to this script too.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Sat Aug 10, 2019 1:33 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4208
Location: A world gone mad
Also, please fix your argument/flag order. It is a bad habit to simply "append stuff" to a command line; always follow usage syntax per help commands or documentation (and for ld65). There is no universal standard for parsing these arguments.

TL;DR: change your script to:
Code:
ca65 -o test.o test.asm
ld65 -t nes -o test.nes test.o

Also, you probably don't want to use -t nes, but you'll find out why soon enough on your own.


Top
 Profile  
 
PostPosted: Sat Aug 10, 2019 3:39 am 
Offline
User avatar

Joined: Fri Mar 16, 2018 1:52 pm
Posts: 93
Location: Finland
Okay, so now that I can see the error messages it seems like the error I was getting was the chr file begin too big. But since the mapper I'm using allows that much chr I'm assuming that -t nes doesn't account for mappers. If I remove it, ld65 says that it is missing a memory configuration. I couldn't find much useful information on how to create one, so I might need some help here.

EDIT: I might be able to get the RAM and PRG parts correct, but I'm not sure how I should make the configuration for CHR


Top
 Profile  
 
PostPosted: Sat Aug 10, 2019 5:10 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21564
Location: NE Indiana, USA (NTSC)
Which mapper, how big is PRG ROM, and how big is CHR ROM?

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Sat Aug 10, 2019 5:13 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4208
Location: A world gone mad
Right now nothing accounts for mappers in assemblers/linkers other than NESASM. You get to manage all related parts of it yourself, both the code and the "organisation" of how it's used in the assembler/linker. ca65/ld65 makes this process a bit easier (particularly ld65) -- you may want to refer to some examples that Tepples has put together for some mappers, with an exclusive focus on PRG:

* https://github.com/pinobatch/snrom-template
* https://github.com/pinobatch/bnrom-template

You may also find the bank attribute on a MEMORY entry in your ld65 configuration useful when combined with the .bank directive in ca65 (not the same as .bankbyte!). It makes storing/retrieving the PRG or CHR bank number of a particular bank very easy. It is an easily overlooked feature given the formatting/layout of the documentation.

That said: you didn't disclose what mapper you're working with, but the above should give you the general idea. Also, if you are starting out with NES development, I suggest ignoring mappers entirely and just use mapper 0 / NROM to make your life easier for now -- worry about mappers later.

As for CHR: make separate MEMORY/SEGMENTs for each one, and then declare the segment in the assembly source along with an .incbin statement to reference the actual .chr files themselves. It's that easy. You may find this post of mine helpful, which was for MMC3.


Top
 Profile  
 
PostPosted: Sat Aug 10, 2019 12:08 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2550
Location: DIGDUG
You need to make a configuration file .cfg.

Here's a basic example.

https://github.com/nesdoug/01_Hello/blo ... k_vert.cfg

And you need to separate your code into different "segments" to determine where it ends up. For example, you want to incbin. your CHR into a CHAR segment, and have that listed last in the memory definitions.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Sun Aug 11, 2019 8:59 pm 
Offline
User avatar

Joined: Fri Mar 16, 2018 1:52 pm
Posts: 93
Location: Finland
I managed to make a config that compiles, but there are still some segments in the examples that I don't know the use for. Mainly ONCE, HEAP and LOWCODE. Then there are a few that seem similar, but I'm not sure what's the difference. STARTUP vs. INIT and DATA vs. RODATA. Knowing the use for these might also clear some confusion around some of the attributes used.


Top
 Profile  
 
PostPosted: Sun Aug 11, 2019 9:15 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7568
Location: Canada
RODATA is Read Only data. Just stuff that goes into ROM that isn't code, e.g. a const array goes here.

DATA is read/write data. C variables go here. There's also additionally an initialization block in ROM that gets copied into DATA's RAM location at startup to fill them with their initial values.

HEAP is used for malloc/free, you probably don't need this.

STARTUP is used to contain the code that gets run immediately after power/reset.

I forget what ONCE, LOWCODE, and INIT are used for. To be honest a lot of these aren't super useful and can probably be omitted unless you want to use very specific features of cc65's included C libraries.


For my most recent NES C project, my CFG used only the essentials: dgolf.cfg

This was combined with a simplified version of cc65's C runtime startup, which basically just initializes DATA: dgolf.s:cc65_init


If we're not talking about C and you're just making an assembly program there's even less that's really required, and all the names are arbitrary. You can call segments whatever you want.


Top
 Profile  
 
PostPosted: Mon Aug 12, 2019 12:26 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 965
ONCE = INIT = library constructors for code run at startup, only once. For other platforms this is stuff like input and graphics drivers, not relevant for NES.
LOWCODE is support functions placed in a "common bank" on some atari platforms, to be always accessible. Not used on NES.


Top
 Profile  
 
PostPosted: Mon Aug 12, 2019 4:29 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21564
Location: NE Indiana, USA (NTSC)
I've used the LOWCODE mechanism for small bits of code that I copy to RAM in order to use them with data scattered across multiple banks of a 32K bank switched ROM. See, for example, interbank_fetch.s in Action 53.

The ONCE/INIT sounds like it'd be good for code that needs to be in a certain part of PRG ROM, such as keeping MMC3's reset code above $E000.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Mon Aug 12, 2019 1:38 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4208
Location: A world gone mad
OP is not using C (see their script). None of the segments being discussed matter. Their existence has already confused the OP because they are more intended for use alongside C. Rainwarrior's above post, last line, is all that's relevant.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group