This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

ca65 templates

ca65 templates
by on (#97703)
Hi, I was looking for the ca65 templates (linker scripts) for NES development. 'Thought they were on the wiki, but weren't there.

I want to make a setup for the FME-7 board, but I'm pretty sure there's no template for that; not a problem, but I want to see all the other templates so I can 1) make a template with minimum effort with a starting point (less reading of the docs ;)) and 2) being consistent with "existing practice".

Thanks! :)
Re: ca65 templates
by on (#97704)
Probably not exactly what you are looking for, but perhaps some information that might be helpful:

You should try using 'make' and the makefile linked here: viewtopic.php?t=7691

It might take a bit of tweaking depending where you put stuff, but it does track all dependencies and assemble and link as needed. It works with win32 make as well. From there I believe targeting different boards is more about your source .segments and memory map cfg file.

Not directly related suggestion: I use Notepad++ with NppExec plugin. Nice customizable syntax highlighting and it's somewhat trivial to set it up NppExec with a run command that runs the make (assemble and link and launch emu) and capture console output which will allow you to double clink on any errors/warnings and open the file and bring you to the offending line. As well I use Nintendulator DX with all the nice add-ons for debugging, it's awesome.
Re: ca65 templates
by on (#97705)
Jarhmander wrote:
Hi, I was looking for the ca65 templates (linker scripts) for NES development. 'Thought they were on the wiki, but weren't there.

I want to make a setup for the FME-7 board, but I'm pretty sure there's no template for that; not a problem, but I want to see all the other templates so I can 1) make a template with minimum effort with a starting point (less reading of the docs ;)) and 2) being consistent with "existing practice".

Thanks! :)


You could start with the nes.ini in the SNROM template provided by Tepples and available here as part of a NESICIDE project based on Tepples' SNROM example project.
Re: ca65 templates
by on (#97706)
Thanks for the makefile, it will probably come in handy, so your intervention was useful, and I see I'm a bit rusty with makefiles. I might however make my own, there's a lot of features on that that I won't use.

Concerning your suggestion, I'm on a Linux machine, so no Notepad++, unfortunately.

Thanks cpow for the link! Looking at the linker script (an INI file?) it seems trivial, though I don't know why all ROM0..14 refer to the same location and length (it's just multiple alias for the same location?), and what's the "file=%O" setting means. Guess I'll RTFM then :).

Oh, SNROM is one of the "big" MMC1 configuration available. So I figure ROM0..14 is the first 15 16KiB banks available at $8000-$BFFF and ROM15 is the fixed last bank at $C000-$FFFF. I think that a useful macro to use with that mapper is a one like NEWBANK, that pads the remaining space of the bank and set PC to $8000. That's not generalisable to other mappers though.
Re: ca65 templates
by on (#97707)
Jarhmander wrote:
Thanks for the makefile, it will probably come in handy, so your intervention was useful, and I see I'm a bit rusty with makefiles. I might however make my own, there's a lot of features on that that I won't use.

I don't really understand this line of thinking. The makefile is 300 lines long, it's not gonna slow down your build cycle or bloat your project folder, so it doesn't really matter if some of the features go unused.

Quote:
I think that a useful macro to use with that mapper is a one like NEWBANK, that pads the remaining space of the bank and set PC to $8000. That's not generalisable to other mappers though.

It's not really possible to do padding like that with CA65 because of the object+linker approach. In other words, in any given module, you don't know where in segment (bank) the linker will place your code (unless you put all of it in a single module, which is not "the right thing" to do with CA65+LD65).
Re: ca65 templates
by on (#97709)
Jarhmander wrote:
Concerning your suggestion, I'm on a Linux machine, so no Notepad++

There should be a Gedit language file floating around.

Quote:
I don't know why all ROM0..14 refer to the same location and length (it's just multiple alias for the same location?)

The SNROM/SGROM template is designed for the 16 KiB bank switching mode of the MMC1, and a template for UNROM/UOROM would use the same linker script. A template for MIMIC-1, MMC3, RAMBO-1, FME-7, or MMC5 would be more complicated because it'd need to know whether each 8 KiB bank belongs in $8000, $A000, or $C000.

Quote:
and what's the "file=%O" setting means

Write to main output file, I guess.

Quote:
I think that a useful macro to use with that mapper is a one like NEWBANK, that pads the remaining space of the bank and set PC to $8000.

I read somewhere about using bits 23-16 of the address for a bank number, but I haven't played with that yet.
Re: ca65 templates
by on (#97710)
Here's a few CC65 projects that I have released as open source:

AOROM music cartridge source: http://rainwarrior.ca/music/moon8romsrc.zip
NSF/NES swap test sources: http://rainwarrior.ca/projects/nes/swap_tests.zip
NSF rip source for Mr. Gimmick Europe: mr_gimmick_nsf_dev.zip (attached)

If you want proper documentation on the cfg files, try here: http://www.cc65.org/doc/ld65.html

The best way to align code/data to a specific address is to create a segment for it in the cfg. Any source file can place code into any segement or multiple segments (in my assembly projects so far, I have preferred one monolithic translation unit to having several object files, but you can split it up as you like). You can easily control padding bytes (fill/fillval), and where precisely to put things in the ROM or RAM.

The basics of it is that the MEMORY regions that output to file will be output in the order specified. The SEGMENTS regions go into the the MEMORY regions, filling up each one in the order specified. Your source code then specifies a segment for any code to go into at someplace in the code. If you want a new bank, create a MEMORY block for it and as many SEGMENT sections as you need to divide it up. The MEMORY regions can also represent blocks of memory, not part of the output ROM.

The AOROM source shows how I made 32k banks. The swap tests show how I made code that is stored in ROM that can get copied to RAM (SEGMENT has a load memory region, but also a run memory region; load is where it goes in the ROM, run affects the program counter). Note: the swap test for Sunsoft 5B does not properly set up banks; this is because I was lazy and also because it was unnecessary due to how the banks are already initialized by the PowerPak before swapping.
Re: ca65 templates
by on (#97712)
thefox wrote:
Jarhmander wrote:
Thanks for the makefile, it will probably come in handy, so your intervention was useful, and I see I'm a bit rusty with makefiles. I might however make my own, there's a lot of features on that that I won't use.

I don't really understand this line of thinking. The makefile is 300 lines long, it's not gonna slow down your build cycle or bloat your project folder, so it doesn't really matter if some of the features go unused.


Of course the makefile isn't bloated, even if it was several thousand lines long I won't notice the difference when making the project (assuming there are not more dependencies in the 1000+ line makefile, otherwise it does take more time to rebuild the project of course). The thing is I prefer starting down and going up, starting with a near empty makefile, adding dependecies to the SOURCES var, letting the rules make object files, and then add recipes to make some "fancy" data generators (ex: bitmap to chr data, music data generator etc.). The makefile is small and I don't need to scroll through it. Usually, I even put my "make vars" in a separate file and I include it in the real makefile for that purpose, so I don't play with my makefile. Otherwise the makefile is perfectly fine, the only questionable thing is my attitude to prefer making my own makefiles :) [WELL, I might just shut up, take that makefile and put the "make vars" in a separate file and I'll be happy].

thefox wrote:
Quote:
I think that a useful macro to use with that mapper is a one like NEWBANK, that pads the remaining space of the bank and set PC to $8000. That's not generalisable to other mappers though.

It's not really possible to do padding like that with CA65 because of the object+linker approach. In other words, in any given module, you don't know where in segment (bank) the linker will place your code (unless you put all of it in a single module, which is not "the right thing" to do with CA65+LD65).


That's right, normally you can't use absolute addresses with a linker (though I have a exception in mind, the mplink linker) and even then that's negating the use of a linker, so we need something to tell the linker to put code (or data) at some boundaries, which rainwarrior just wrote. I just didn't think enough before replying that, my apologies.

Thanks all for your help! :)
Re: ca65 templates
by on (#97713)
Jarhmander wrote:
[WELL, I might just shut up, take that makefile and put the "make vars" in a separate file and I'll be happy].

Yeah, if you need custom rules, I think it's a good idea to put them in a separate file and include that from the "universal" makefile.
Re: ca65 templates
by on (#97714)
Makefiles are useful when you have many files to deal with.

Since the process I used only compiled a single .s file which included others, I found a simple batch file to be more than adequate.

I've since been experimenting with C, and the steps have become a little more complicated, though I tend to compile and fix compiling errors frequently, and create new .c files seldom, so I still haven't yet felt the urge to work out a makefile system.

Anyhow, makefiles are an alright solution, but they're hardly necessary in a lot of cases, and for someone trying to learn how to use cc65 they might get in the way of understanding how the compiler is invoked and used. If you're already well versed in make, it's probably not a problem at all, but for learning NES programming on cc65, I'm not sure they're very helpful.

Example makefiles are great to have around, to show people who need it how to set one up. I'm just suggesting that they don't really need to be part of a beginner's guide to cc65.
Re: ca65 templates
by on (#97715)
rainwarrior wrote:
Makefiles are useful when you have many files to deal with.

Sure thing. It is also a good thing when you use an external script to generate some data to be "incbin'd" in your assembly. But that isn't new to you; me neither ;).

I'm not new in programming, only into NES programming — or not... I did some crappy testes at least (both .nes and .nsf), but I did nothing serious. So in a few days I'll begin another test, but with an actual dude moving around. I'll come back with questions, when necessary.

Thanks again!
Re: ca65 templates
by on (#97716)
Jarhmander wrote:
I did some crappy testes at least (both .nes and .nsf), but I did nothing serious.


This is actually the *second* time today I've seen the word "testes" in mistaken use. The first was in a CM commit comment--good laugh for the FAA, I guess. Makes me worried that the number of times I've had to type "tests" for work I may have actually been typing "balls" or "nads" or "two veg". Dang.
Re: ca65 templates
by on (#97717)
cpow wrote:
Jarhmander wrote:
I did some crappy testes at least (both .nes and .nsf), but I did nothing serious.


This is actually the *second* time today I've seen the word "testes" in mistaken use. The first was in a CM commit comment--good laugh for the FAA, I guess. Makes me worried that the number of times I've had to type "tests" for work I may have actually been typing "balls" or "nads" or "two veg". Dang.


Oops :oops: :lol: I don't know why there's an extra 'e' here, even in French there's no 'e' in there so that's a mystery.
I can asure you my testes are fine; however, those .nsf and .nes I made were crappy tests. :)
Re: ca65 templates
by on (#97725)
cpow wrote:
This is actually the *second* time today I've seen the word "testes" in mistaken use.

The first time for me was in 1989 was when my grandfather misremembered the name of Tetris.
Re: ca65 templates
by on (#98043)
If you're still looking for a syntax highlighter, I have one for Gedit.
It's based on a 6502 Assembler highlighter I found...somewhere. I forgot where I got it from :V
I modified it however so now it is very similar to the notepad++ syntax highlighter that was made by miau and banshaku (I think it was the two). That file should still be around here somewhere.
In other words, jump and branch opcodes will be in a different color than other opcodes, so it is easier to spot them in long code portions.
Undocumented opcodes are not highlighted!
The file can be found here:
https://dl.dropbox.com/u/74960018/asm6502.lang
Re: ca65 templates
by on (#98046)
tepples wrote:
cpow wrote:
This is actually the *second* time today I've seen the word "testes" in mistaken use.

The first time for me was in 1989 was when my grandfather misremembered the name of Tetris.


Ok now I question your obvious infatuation with all things Tetris. :shock:
Re: ca65 templates
by on (#98047)
There is no longer any such infatuation. I am done with Tetris. Forever. Despite comments that he and Henk Rogers have made to the public, Alexey Pajitnov doesn't act as if he wants his game to become an internationally competitive sport. I can explain further in PM.
Re: ca65 templates
by on (#98090)
Grumskiz wrote:
If you're still looking for a syntax highlighter, I have one for Gedit.
It's based on a 6502 Assembler highlighter I found...somewhere. I forgot where I got it from :V
I modified it however so now it is very similar to the notepad++ syntax highlighter that was made by miau and banshaku (I think it was the two). That file should still be around here somewhere.
In other words, jump and branch opcodes will be in a different color than other opcodes, so it is easier to spot them in long code portions.
Undocumented opcodes are not highlighted!
The file can be found here:
https://dl.dropbox.com/u/74960018/asm6502.lang

Thanks! Will try this tomorrow! :)