nesdev.com
http://forums.nesdev.com/

Progress Thread - Wolfling
http://forums.nesdev.com/viewtopic.php?f=33&t=16143
Page 4 of 5

Author:  calima [ Sun Sep 24, 2017 11:14 am ]
Post subject:  Re: Progress Thread - Wolfling

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

Author:  dougeff [ Sun Sep 24, 2017 11:35 am ]
Post subject:  Re: Progress Thread - Wolfling

Quote:
(there's no musician for Wolfling, yet)


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

Author:  dougeff [ Tue Sep 26, 2017 7:00 am ]
Post subject:  Re: Progress Thread - Wolfling

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.

Author:  tepples [ Wed Sep 27, 2017 6:58 pm ]
Post subject:  Re: Progress Thread - Wolfling

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.

Author:  Lazycow [ Mon Oct 02, 2017 4:09 am ]
Post subject:  Re: Progress Thread - Wolfling

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:
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)

Author:  thefox [ Mon Oct 02, 2017 6:47 am ]
Post subject:  Re: Progress Thread - Wolfling

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

Author:  rainwarrior [ Mon Oct 02, 2017 1:46 pm ]
Post subject:  Re: Progress Thread - Wolfling

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.

Author:  Lazycow [ Mon Oct 02, 2017 10:28 pm ]
Post subject:  Re: Progress Thread - Wolfling

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:
   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?

Author:  na_th_an [ Tue Oct 03, 2017 2:14 am ]
Post subject:  Re: Progress Thread - Wolfling

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?

Author:  rainwarrior [ Tue Oct 03, 2017 2:59 am ]
Post subject:  Re: Progress Thread - Wolfling

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.

Author:  Lazycow [ Tue Oct 03, 2017 10:51 am ]
Post subject:  Re: Progress Thread - Wolfling

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

Author:  calima [ Tue Oct 03, 2017 11:13 am ]
Post subject:  Re: Progress Thread - Wolfling

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

Author:  dougeff [ Tue Oct 03, 2017 3:59 pm ]
Post subject:  Re: Progress Thread - Wolfling

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.

Author:  na_th_an [ Wed Oct 04, 2017 12:55 am ]
Post subject:  Re: Progress Thread - Wolfling

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.

Author:  Lazycow [ Fri Nov 10, 2017 10:59 pm ]
Post subject:  Re: Progress Thread - Wolfling

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

Page 4 of 5 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/