nesdev.com

Remember that's the stack. Not many bytes after famitone2 available.

Don't wait till January to find one. It takes time to write songs.

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

Maybe you could ask the musician from Nebs & Debs. I heard him on the latest assembly line podcast, he didn't sound like he was working on a project currently.

Can't remember his name. He also did Alter Ego.

It's Richard “Kulor” Armijo.

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

I have written a private draft of a wiki article comparing them.

Well tepples, release the article to the public and I'll read it...

Yes, I have to watch the stack when using memory at $01xx, but I have to watch the stack also in standard memory. (the cc65 stack...) That's one of the thing you are "fond of" when programming the NES, isn't it? It's a bit like programming the Atari VCS.

Another thing, can you define the SEGMENT for a linked lib in the cc65 config file somehow? Here, I've linked the standard cc65 runtime library and it appeared in the CODE segment.
Not a big deal, but it would be nice to know - just in case I'll run out of ROM. (that will happen sooner or later, I'll suppose)

I don't think you can, without recompiling the library. (And even then, you have to modify the source code, I believe.)

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

If you want to separate those by segment it'd probably be easier to just use a different segments for your own code (#pragma code-name, etc.) and let the libraries use CODE/DATA/RODATA.

Yes, that's what I'm doing right now: Using these pragmas for the main code. That works.
Additionally, I have tweaked the setup of the banks, to get 28k for the main C code (BANK2X) by reducing the size of the common bank. That works well, as long as I only switch banks with code from the common bank.

ROM-space seems to be sufficient for now, but I'm still fighting with the limited amount of RAM:
- changed the map format: 148 additional bytes
- disabling music while decrunching: 186 additional bytes
- moving tables into zeropage: 96 additional bytes

Hm... Can I use the RAM at $02xx temporarily if I disable sprites in PPUMASK?

As far as I know, the runtime library is a must if you code in C, and you shouldn't place it somewhere you can page out, as it will render common tasks such as calling functions impossible. The runtime should be always present, in the fixed bank (if you are aiming for UNROM, that is). Why would you want to move it out of the CODE segment, anyways?

_________________
http://www.mojontwins.com

You don't have to disable sprites. The sprites are copied into internal OAM RAM and retained there as long as sprites are rendering.

The RAM at $0200 is just used as a temporary holding place for the data before it is sent to the OAM RAM by DMA (write to $4014). If you don't do a DMA nothing in regular RAM will affect the sprites currently displayed.

@rainwarrior: Oh! Nice. I was thinking the OAM will decay, but obviously I misinterpreted the wiki...

@na_th_an: Hm... Yes, you're right, the runtime lib should be placed in the common bank and it doesn't make sense to place it somewhere else. Nevertheless, if I could rename the runtime lib's segment, I could get rid of the pragmas in the main code. But it's not a big deal and currently, I'm too lazy to change that...

There's an open feature request on using some other bank for the runtime.

Re: putting the runtime in a different bank

I managed to do this on a project, but then later switched the entire thing to ASM, thus not needing a runtime.

The solution was (AxROM mapper) to compile each bank (of $8000) separately, and then concatenating everything as the last step in making the final ROM. That way, the entire runtime would be available in every bank.

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

That's what I do with GNROM like mappers. Work on separate NROMs, then concatenate everything together. Use a small area in RAM which is not zeroed on startup for communication, place your bankswitching code in a fixed segment at the end of ROM space (for instance) so the very same chunk of bytes is in every NROM at the same place, and you are set.

_________________
http://www.mojontwins.com

update: a boulder test...
There're still no tilesets or anims from Zolionline, so I guess it's questionable that we finish the game before the deadline.