#10729 - funkeejeffou - Sat Sep 13, 2003 3:24 pm
Hi,
I have some code running in Mode4, everything works fine, but sometimes, my graphics are all color wrong, and thats because my palette is changed. I don't know how, nor why.
I'm using 3 timers (0 1 and 2). Timer 0 works with DMA1 for sound_buffering.
Timer 1 is in cascade with 0 and provoques an IRQ on overflow.
DMA3 is used to clear the screen.
And I'm using the swi 0x80000 (sqrt in ARM code) once per frame.
I wonder if all those things working together are the cause of the palette getting screwed.
Are there any precautionsto take when using a bios call plus an IRQ (cause IRQ uses the bios)?
The palette is at 0x5000000 adress, there is nothing near it with wich I interfer. How can this be?
#10731 - funkeejeffou - Sat Sep 13, 2003 3:36 pm
Oh I forgot one thing!!!!
I'm using a constant scale of the screen, it is stretched up to down by a 0.75 factor. And the problem appeared since I made this...
#10738 - sajiimori - Sat Sep 13, 2003 6:43 pm
I'm curious, what does the palette change to? Random colors, something based on the original palette, or a pattern of some sort?
Does all of it change, or just a portion?
Are you using 256 color or 16 color?
How often does it happen?
After it happens the first time, does it change again?
Do you notice any pattern as to when it happens?
#10750 - funkeejeffou - Sun Sep 14, 2003 12:28 pm
Ok, here are the answers Sajimori :
I'm using 256 colors in Mode4.
The palette screws up sometime at the beginning, sometimes after 5 minutes, and other times never...
The "new palette" is always the same : it is based on the original one, but all have too much green.
When it happened once, it doesn't change anymore, this funky palettes stays here (tested on VBA and hardware).
The most astonishing part is that the code still runs normally, only the colors changes.
I've seen in the GBATEK specs that 0x4000002h is the green swap register. When I saw that, I said to myself it must be that, but when I manually write a 1 in it, nothing happens. Somebody knows about that?
#10755 - sajiimori - Sun Sep 14, 2003 7:10 pm
Hmm...I'm pretty much stumped on that one. Make sure there's no BG color blending going on anywhere (though that wouldn't actually change the contents of palette RAM), and also remember that the palette is repeatedly mirrored across the whole 0x05... range, so accidentally writing anywhere in that area can affect the palette.
Besides that, just start removing sections of code and testing until you either removed a part that makes the problem stop happening, or you have a small enough portion of code that you can post it here.
#10828 - funkeejeffou - Wed Sep 17, 2003 12:30 pm
I think I know where the problem came from, but I can't figure out why.
I had placed 8K of data (constant data, so there were only read instructiuns) in VRAM starting at 0x6014000. When you look at Mode 4 specifications, you can see that you have 16K of free VRAM for OBJ tiles, but I do not use them and have put data in it as VRAM wait states are 1/1/2 (respectivelly 8b/16b/32b).
Any ideas how can this screw up a palette?