I feel like making ca65 project templates

[tepples]

So I feel like making some project templates for ca65, consisting of a simple program that displays "hello world" and beeps the speaker when the player presses A. And I feel like making them for every mapper that one might consider using for a homebrew game.

CA65 seems like a very professional choice, and I guess I would use it if I didn't have to spend so much time tinkering with it before getting it to do anything useful.

That's probably my fault for not making project templates for each major cartridge board. Which boards do you anticipate people wanting to use for quick projects, besides NROM-128/256, UNROM/UOROM, and SNROM?

[clueless]

Nah... Finish your compo entry! If Jeroen's compo is abandoned, then those of us working on entries can do something else with our work. Maybe make a combo-cart or still have a contest, but with some alternate judging and prizes (real or imagined). Or make a combo-cart, sell on retrousb and split for profits, and open-source it 2 years later?

[tokumaru]

Sounds like an interesting idea. I'm pretty lost when it comes to configuring these complex assemblers, so much that I don't even know what files are supposed to be created/modified. I am also clueless about the actual assembly process... I am used to giving a program source code and it spitting out a binary image, so I don't really know why you'd need intermediary things like object files and what the hell linking is.

But I wouldn't like things to be so easy that I could overlook those details completely, I would actually like to understand why they exist, because I hate doing things I don't understand. I'm a person that is not satisfied to simply get the expected results, I must understand why I got such results. I don't like to just feel "lucky" that it all worked, because luck is not something you can count on, knowledge is. So if I don't understand it, I don't use it.

Regarding mappers, I'm sure that CNROM and TxROM are very popular. Other MMC1 boards too.

[3gengames]

Agreed on those boards. Just simple demos for all the mappers would be good, and just adjust for the board by the user. It wouldn't be that hard with a good template!


And yeah, I don't like using anything I didn't write, sort of because I don't trust it, but I also feel like I'm not doing the work so I stay away from any one elses stuff. ^_^

[MetalSlime]

Sounds like an interesting idea. I'm pretty lost when it comes to configuring these complex assemblers, so much that I don't even know what files are supposed to be created/modified.

For ca65, a guy named SecretServiceDude posted his configuration for an UNROM project a couple years ago. It's here:

http://nesdev.com/bbs/viewtopic.php?p=39883#39883

If you study it briefly (starting with the batch file) you should get a general idea of how it all fits together. Once you have a sample to work off of it's not too much trouble to learn. When I started, I just copy/pasted SecretServiceDude's project and spent an afternoon tinkering with it, using the ld65 and ca65 docs for reference. I fiddled around making configs for other mappers and shuffling around where different segments of code went. Peeking at the .lst and .map files that were generated helped me understand what was happening at each step and it all came together for me. You just have to get your hands dirty.

So I feel like making some project templates for ca65, consisting of a simple program that displays "hello world" and beeps the speaker when the player presses A.

Another thing you might add to the templates would be bank-switching code, PRG and CHR where applicable. If the mappers are configurable you could set up environment variables and conditional assembly. It would make the templates easier to use right out of the box.

[Wave]

Another thing you might add to the templates would be bank-switching code, PRG and CHR where applicable. If the mappers are configurable you could set up environment variables and conditional assembly. It would make the templates easier to use right out of the box.

That's what I'm trying to do with my "framework" for neshla. It has a file for mapper capabilities, such as mirroring, chr banking, prg banking... And uses #ifdef areas depending on mapper defined for de project.
Currently supports:
MMC1, MMC3, AXROM, GXROM, CPROM, BXROM, UXROM, CNROM

Header file-> http://neshlagamefw.svn.sourceforge.net ... xt%2Fplain
ASM file -> http://neshlagamefw.svn.sourceforge.net ... xt%2Fplain

[MetalSlime]

Wow. That's pretty handy. So all the user would have to do is say "I'm using AXROM" and everything would be set up for them. Nice.

[Wave]

Wow. That's pretty handy. So all the user would have to do is say "I'm using AXROM" and everything would be set up for them. Nice.

Yes, and you could change from one mapper to another if the newer can do at least what the older could (or can do it in combination, like changing 8k chr in mmc3, the framework automaticaly does 2x2x1x1x1x1 (or viceversa) instead)

[thefox]

Just to let you know, the development version of CC65 makes it possible for the linker config file to import symbols. This should allow a pretty easy to use, multi-mapper template to be made, while using only one configuration file. I'm not completely sure how well it'd work, haven't thought it through yet, but I think it should work...

Something like this should be possible:

Code: Select all

  ; - these define the ROM structure
  .define NUM_PRG_BANKS   4
  .define MAPPER   2 ; etc...
  ; - this include file calculates a bunch of variables like segment sizes
  ;   based on the symbols defined above, and exports them for
  ;   the linker configuration file
  ; - for example, if it wants to "remove" a segment, it can set its size
  ;   to 0
  ; - it also defines the iNES header
  .include "std_nes.inc"

Something like this should make it a lot easier for newcomers to get started with CA65.

[ManicGenius]

Yes please make some. I need to get a starting foothold on this thing.