Page 4 of 11

Re: Progress Thread - Wolfling

Posted: Sun Sep 24, 2017 11:14 am
by calima
Remember that's the stack. Not many bytes after famitone2 available.

Re: Progress Thread - Wolfling

Posted: Sun Sep 24, 2017 11:35 am
by dougeff
(there's no musician for Wolfling, yet)
Don't wait till January to find one. It takes time to write songs.

Re: Progress Thread - Wolfling

Posted: Tue Sep 26, 2017 7:00 am
by dougeff
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.

Re: Progress Thread - Wolfling

Posted: Wed Sep 27, 2017 6:58 pm
by tepples
Lazycow wrote:Thanks for the hints, I wasn't aware that there're so many music players out there.
I have written a private draft of a wiki article comparing them.

Re: Progress Thread - Wolfling

Posted: Mon Oct 02, 2017 4:09 am
by Lazycow
Well tepples, release the article to the public and I'll read it... 8-)

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.

Code: Select all

crt.lib(aslax2.o):
    CODE              Offs = 0005D3   Size = 00000B
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)

Re: Progress Thread - Wolfling

Posted: Mon Oct 02, 2017 6:47 am
by thefox
Lazycow wrote: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.

Code: Select all

crt.lib(aslax2.o):
    CODE              Offs = 0005D3   Size = 00000B
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.)

Re: Progress Thread - Wolfling

Posted: Mon Oct 02, 2017 1:46 pm
by rainwarrior
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.

Re: Progress Thread - Wolfling

Posted: Mon Oct 02, 2017 10:28 pm
by Lazycow
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.

Code: Select all

	BANK0:   start=$8000, size=$4000, file=%O, fill=yes;
	BANK1:   start=$8000, size=$4000, file=%O, fill=yes;
	BANK2X:  start=$8000, size=$7000, file=%O, fill=yes;             # ext
	BANKC:   start=$f000, size=$0fc0, file=%O, fill=yes, define=yes; # common
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?

Re: Progress Thread - Wolfling

Posted: Tue Oct 03, 2017 2:14 am
by na_th_an
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?

Re: Progress Thread - Wolfling

Posted: Tue Oct 03, 2017 2:59 am
by rainwarrior
Lazycow wrote:Hm... Can I use the RAM at $02xx temporarily if I disable sprites in PPUMASK?
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.

Re: Progress Thread - Wolfling

Posted: Tue Oct 03, 2017 10:51 am
by Lazycow
@rainwarrior: Oh! :shock: 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...

Re: Progress Thread - Wolfling

Posted: Tue Oct 03, 2017 11:13 am
by calima
There's an open feature request on using some other bank for the runtime.

Re: Progress Thread - Wolfling

Posted: Tue Oct 03, 2017 3:59 pm
by dougeff
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.

Re: Progress Thread - Wolfling

Posted: Wed Oct 04, 2017 12:55 am
by na_th_an
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.

Re: Progress Thread - Wolfling

Posted: Fri Nov 10, 2017 10:59 pm
by Lazycow
Image
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. :(