Progress Thread - Wolfling

Moderator: Moderators

calima
Posts: 999
Joined: Tue Oct 06, 2015 10:16 am

Re: Progress Thread - Wolfling

Post by calima » Sun Sep 24, 2017 11:14 am

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

User avatar
dougeff
Posts: 2598
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: Progress Thread - Wolfling

Post by dougeff » Sun Sep 24, 2017 11:35 am

(there's no musician for Wolfling, yet)
Don't wait till January to find one. It takes time to write songs.
nesdoug.com -- blog/tutorial on programming for the NES

User avatar
dougeff
Posts: 2598
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: Progress Thread - Wolfling

Post by dougeff » Tue Sep 26, 2017 7:00 am

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

tepples
Posts: 21708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Progress Thread - Wolfling

Post by tepples » Wed Sep 27, 2017 6:58 pm

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.

User avatar
Lazycow
Posts: 98
Joined: Tue Jun 11, 2013 1:04 pm
Contact:

Re: Progress Thread - Wolfling

Post by Lazycow » Mon Oct 02, 2017 4:09 am

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)

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Progress Thread - Wolfling

Post by thefox » Mon Oct 02, 2017 6:47 am

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.)
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
rainwarrior
Posts: 7636
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Progress Thread - Wolfling

Post by rainwarrior » Mon Oct 02, 2017 1:46 pm

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.

User avatar
Lazycow
Posts: 98
Joined: Tue Jun 11, 2013 1:04 pm
Contact:

Re: Progress Thread - Wolfling

Post by Lazycow » Mon Oct 02, 2017 10:28 pm

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?

na_th_an
Posts: 543
Joined: Mon May 27, 2013 9:40 am

Re: Progress Thread - Wolfling

Post by na_th_an » Tue Oct 03, 2017 2:14 am

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?
Last edited by na_th_an on Tue Oct 03, 2017 12:48 pm, edited 1 time in total.

User avatar
rainwarrior
Posts: 7636
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Progress Thread - Wolfling

Post by rainwarrior » Tue Oct 03, 2017 2:59 am

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.

User avatar
Lazycow
Posts: 98
Joined: Tue Jun 11, 2013 1:04 pm
Contact:

Re: Progress Thread - Wolfling

Post by Lazycow » Tue Oct 03, 2017 10:51 am

@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...

calima
Posts: 999
Joined: Tue Oct 06, 2015 10:16 am

Re: Progress Thread - Wolfling

Post by calima » Tue Oct 03, 2017 11:13 am

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

User avatar
dougeff
Posts: 2598
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: Progress Thread - Wolfling

Post by dougeff » Tue Oct 03, 2017 3:59 pm

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

na_th_an
Posts: 543
Joined: Mon May 27, 2013 9:40 am

Re: Progress Thread - Wolfling

Post by na_th_an » Wed Oct 04, 2017 12:55 am

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.

User avatar
Lazycow
Posts: 98
Joined: Tue Jun 11, 2013 1:04 pm
Contact:

Re: Progress Thread - Wolfling

Post by Lazycow » Fri Nov 10, 2017 10:59 pm

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. :(

Post Reply