Forums

So I am working on a 256KB Game Gear game and I think the problem (with me knowing next to nothing) is that stuff past bank 7 has a screwed-up palette that I didn't put in there. Is there something special that I have to do in order to make a game past 128KB? I say this because I'm working on a game, and levels 9 and 10 (which are stored past bank 7) have the incorrect palettes.

No, there is nothing special about the higher banks.

Maybe it's more a problem of your workflow, and the palette information is not stored in the right banks?

I think I fixed it by removing some code that changes one color of the palette to black. I don't know why having that in would change every color of both pallets to just seemingly random values.

Gamegearguy wrote

I think I fixed it by removing some code that changes one color of the palette to black. I don't know why having that in would change every color of both pallets to just seemingly random values.

Is there any chance that code was being called from an interrupt? If so, it might have executed midway through some other VDP data transfer, causing the remainder of the data to be sent to the palette instead of VRAM.
Just an idea!

yes, as willbritton said it really sounds like some code is pushing data to CRAM when the data was meant for VRAM.

The debugger in Emulicious can detect if this happens.

Author	Message
Gamegearguy Joined: 06 Sep 2015 Posts: 268 Location: United States	Palette going wacko Posted: Tue Jan 16, 2024 10:34 pm
	So I am working on a 256KB Game Gear game and I think the problem (with me knowing next to nothing) is that stuff past bank 7 has a screwed-up palette that I didn't put in there. Is there something special that I have to do in order to make a game past 128KB? I say this because I'm working on a game, and levels 9 and 10 (which are stored past bank 7) have the incorrect palettes.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Wed Jan 17, 2024 7:11 am
	No, there is nothing special about the higher banks.

kusfo Joined: 29 Mar 2012 Posts: 886 Location: Spain	Posted: Wed Jan 17, 2024 11:34 am
kusfo Joined: 29 Mar 2012 Posts: 886 Location: Spain	Maybe it's more a problem of your workflow, and the palette information is not stored in the right banks?

Gamegearguy Joined: 06 Sep 2015 Posts: 268 Location: United States	Posted: Wed Jan 17, 2024 1:06 pm
	I think I fixed it by removing some code that changes one color of the palette to black. I don't know why having that in would change every color of both pallets to just seemingly random values.

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Wed Jan 17, 2024 1:36 pm
	Gamegearguy wrote I think I fixed it by removing some code that changes one color of the palette to black. I don't know why having that in would change every color of both pallets to just seemingly random values. Is there any chance that code was being called from an interrupt? If so, it might have executed midway through some other VDP data transfer, causing the remainder of the data to be sent to the palette instead of VRAM. Just an idea!

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Wed Jan 17, 2024 3:24 pm
	yes, as willbritton said it really sounds like some code is pushing data to CRAM when the data was meant for VRAM. The debugger in Emulicious can detect if this happens.

Forums

View topic - Palette going wacko