Join music to game-problem with Memory overflow in DMC(cc65)

[Axi0maT]

I have already finished the game for NES, but at last try join some music. I can leave this version without music but I think that make game feel much better whit song... Well some composer ceate song for me and I now must combine it all together.
I use CC65 with Shiru lib. In crt0.s I have:

Code: Select all

........
music_data:
	.include "music.s"

	.if(FT_SFX_ENABLE)
sounds_data:
	.include "sounds.s"
	.endif

.segment "SAMPLES"

	.incbin "music_dpcm.bin"
........

music is converted with famitone2 (by Shiru) - result in two files: music.s (11330 bytes) and music_dpcm.bin (2944 bytes)

I try compile and have this error:

Code: Select all

ld65.exe: Warning: Memory area overflow in `DMC', segment `SAMPLES' (2886 bytes)

ld65.exe: Error: Cannot generate output due to memory area overflow

My config file is:

Code: Select all

MEMORY {

    ZP: 		start = $0000, size = $0100, type = rw, define = yes;
    HEADER:		start = $0000, size = $0010, file = %O ,fill = yes;
    PRG: 		start = $8000, size = $7fc0, file = %O ,fill = yes, define = yes;
    DMC: 		start = $ffc0, size = $003a, file = %O, fill = yes;
    VECTORS: 	start = $fffa, size = $0006, file = %O, fill = yes;
    CHR: 		start = $0000, size = $4000, file = %O, fill = yes;
    RAM: 		start = $6000, size = $2000, define = yes;
    #RAM:		start = $0300, size = $0500, define = yes;

	  # Use this definition instead if you going to use extra 8K RAM
	  # RAM: start = $6000, size = $2000, define = yes;
	  
}

SEGMENTS {

    HEADER:   load = HEADER,         type = ro;
    STARTUP:  load = PRG,            type = ro,  define = yes;
    LOWCODE:  load = PRG,            type = ro,                optional = yes;
    INIT:     load = PRG,            type = ro,  define = yes, optional = yes;
    CODE:     load = PRG,            type = ro,  define = yes;
    RODATA:   load = PRG,            type = ro,  define = yes;
    DATA:     load = PRG, run = RAM, type = rw,  define = yes;
    VECTORS:  load = VECTORS,        type = rw;
    SAMPLES:  load = DMC,            type = rw;
    CHARS:    load = CHR,            type = rw;
    BSS:      load = RAM,            type = bss, define = yes;
    HEAP:     load = RAM,            type = bss, optional = yes;
    ZEROPAGE: load = ZP,             type = zp;
	
}

Yeah DMC size is 3a - I think that here is problem (58 bytes is not enought), but I don't know how add more memory (where is safe space). Trying with "happy luck" - is not good idea... crash is guaranteed

Anybody can help?

[rainwarrior]

DMC can point to anywhere between $C000 and $FFC0 (on any 64 byte boundary).

Whomever put it at $FFC0 wasn't using DPCM samples, so they made it as small as possible so it wouldn't take up space.

[rainwarrior]

Specifically, you need 2886 more bytes, so:

convert size to hex: 2886 = $B46
subtract from current start position: $FFC0 - $B46 = $F47A
move it a little further to hit a 64 byte boundary: $F440
calculate size; it should end at vectors: $FFFA - $F440 = $BBA

Put your DMC segment at $F440
Give it a size of $BBA

[Axi0maT]

Yeah.... it's correct, but in this case I must sub some memory in PRG, right? From

Code: Select all

PRG: 		start = $8000, size = $7fc0, file = %O ,fill = yes, define = yes; 

to:

Code: Select all

#PRG: 		start = $8000, size = $7440, file = %O ,fill = yes, define = yes;

Now I have not enought memory in PRG (2723 bytes more needed). This is only one way out of this situation? I must cut something in code, or delete additional samples in music?

Maybe I can use some additional memory? Some switch-bank? Or something?

[dougeff]

Congratulations on nearly finishing your game...

Option 1. Switch to a mapper that allows for more program banks to be added.

Option 2. Replace DMC samples with simple non-DMC audio.

Option 3. Shorten DMC samples as much as possible.

[lidnariq]

As a stopgap, you could target NROM-368 ... but that won't work with the extra 8 KiB of RAM which you seem to be using. Of course, with the extra 8 KiB of RAM, you may be able to decompress things from ROM on boot and put them into RAM instead.

If you can figure out how to split the data into two 32 KiB slices with duplication, BNROM with CHR-ROM is the other reasonable option.

Oh, and since you're using shiru's neslib ... look at the generated assembly. You may well find some egregiously space-wasteful C that you can optimize out.

[rainwarrior]

Just FYI, you don't need to have separate MEMORY regions for DMC and VECTORS like that, you can get what you need by just giving the SEGMENTs a start address within their memory region.

1. Get ride of DMC and VECTORS MEMORY regions.
2. Change the segments VECTORS and SAMPLES to load = PRG
3. Add start = $F440 / start = $FFFA to the SAMPLES and VECTORS lines.
4. Put the VECTORS segment below the SAMPLES segment. (They have to go in order of increasing address when assigned to the same MEMORY region.)
5. Change PRG to be $8000 in size.

The reason I'm suggesting this, is you now only have 1 size to deal with (on the PRG MEMORY region) and everything else is done automatically. Less things to manually adjust.

For instance, you could try the NROM-368 suggestion just by making a very simple change at that point:

1. Change PRG start to $4000, and give it a size of $C000 instead.
2. Change your PRG banks count in the iNES header to 3 instead of 2.
3. Add start = $4800 to your STARTUP segment (i.e. the first segment listed in PRG), so that the first $800 bytes will get correctly skipped.

I don't know how many emulators support NROM-368 at this point, but I think that small change would be enough to make it work on emulators that do.

[rainwarrior]

Also, just as a quick sanity check, you're using the -O flag when compiling, right? Without optimizations on, code generated by cc65 is much larger.