OAM filled PRG ???

[MS-DOS]

Hi all, I have a problem, when I use the ram I dedicated for OAM, it makes an overflow on my PRG...

I explain, the code below allows me to display the bar that hides the generation of the map when I scroll.
Here I set my sprites, nothing complicated.

But this code which is in bank 2 (PRG2), will generate an overflow on bank 3 (PRG), really weird ...
Below is the error code.


Here a part of my nes.cfg


Isprite: pushing sprites into memory


And my array that I push in the OAM


I do not see anything weird, yet I've been looking for hours, that's why I'm calling for help.

Thank you in advance

[tepples]

You might have just written too much code. Change ld65 in your linker to ld65 -m map.txt, then please upload map.txt here.

[gauauu]

I'd guess your code is actually going into the PRG segment instead of PRG0. What's your .pragma look like (and where) for setting the bank of this code you're currently writing?

edit: Tepples beat me to it, but yeah, a map file should make it obvious.

[MS-DOS]

Done

Edit:

[gauauu]

Code: Select all

Segment list:
-------------
Name                   Start     End    Size  Align
----------------------------------------------------
..snip...
STARTUP               00C000  00C162  000163  00001
CODE                  00C163  00E56D  00240B  00001
DMC                   00E500  00F8FF  001400  00001
ONCE                  00E593  00E59E  00000C  00001
VECTORS               00FFFA  00FFFF  000006  00001

Your STARTUP plus CODE segment comes to $256e in size, which is bigger than PRG (size = $2500). Tepples was right, you have too much in CODE.

[MS-DOS]

Okay thanks ! But HideBar function is in CODE2 so why does it take up space in CODE?

If I remove HideBar function, it compiles correctly and CODE gains free bytes

[dougeff]

Did you "include" a file somewhere inside bank2.c ?

If so, the included file might have a pragma which changes the code location.

Also, I've seen that the c library functions always end up in the "code" segment. And I think they only compile into it if they are used (not 100% sure).

[rainwarrior]

Also, I've seen that the c library functions always end up in the "code" segment. And I think they only compile into it if they are used (not 100% sure).

These are both true. Adding C code in some other location could draw more supporting CRT code into the "CODE" segment.

[calima]

Yep, it's probably the multiplication pulling in three support functions, by 4, by 16, and arbitrary.

[MS-DOS]

okay thanks everyone for your answers ^^, and thanks for -m map.txt command, i didn't know it!

[na_th_an]

You should avoid * and / like the plague, specially when coding in C for a 6502.

I don't understand why you multiply scrollY*(temp*16). Shouldn't it be scrollY+(temp*16)? If so, this code does the same without multiplication:

Code: Select all

void HideBar () {
	tempWord = 0;
	aux = scrollY;
	for (temp = 0; temp < 16; ++temp) {
		HIDEBAR [tempWord ++] = aux;
		HIDEBAR [tempWord ++] = 0;
		HIDEBAR [tempWord ++] = 0;
		HIDEBAR [tempWord ++] = scrollX
		aux += 16;
	}
}