#76141 - qw3rty - Sat Mar 18, 2006 5:00 pm
Hi, I have problems with corrupted graphics on M3-gba-movie player.
My program works fine via WMB or Supercard (SD), but on the M3-flahcard, the text-backgrounds (on the main screen) are totally corrupted.
My program uses three text-backgrounds, each has 16 colors.
Background 0 is animated - I cycle through 5 different MAPs (mapbase 26-40 ?!).
background 1 and 2 share the same character base.
On the sub-screen everything works normal...(at least with the newest m3-firmware)
P.S. the nds has flashme v6 installed.
#76143 - cory1492 - Sat Mar 18, 2006 5:05 pm
I have the same problems, but when I use Pepsiman-M3powerloader (from here) I usually dont get a corrupted sub screen. Give it a go, I think there are deeper homebrew problems on the M3 than there ought to be.
#76148 - qw3rty - Sat Mar 18, 2006 6:33 pm
Pepsimans Loader fixed the sprites, but unfortunately the backgrounds are still corrupted.
I think I have to check out the TXTWriter topic (and source)- txtwriter first had problems on M3 too, and textwiter uses text-mode, just like my program.
Oh, I have the problems on the MAIN screen btw.
#76178 - cory1492 - Sat Mar 18, 2006 11:53 pm
My situation is: Using Main screen as framebuffer, using sub screen as 256 color bitmap - when loading the sub screen graphics do not display properly (it actually looks like: if I load something on a 256 color rot bitmap and then change the mode to text/sprite mode without clearing the vram in code)
It was worth a shot anyway, perhaps pepsiman knows more than just the "start2d and screenswap" that could make homebrew work "normally" on the M3. I still think M3's homebrew support is kinda botched (and was pleasantly shocked that his loader was able to make MK2 menu work on M3, considering how much trouble other stuff has given me)
edit:/ I just ran through the txtwriter thread and they never did come to a solution (the keyboard was still garbled on the screen)
#76187 - qw3rty - Sun Mar 19, 2006 3:45 am
| cory1492 wrote: |
| ....(it actually looks like: if I load something on a 256 color rot bitmap and then change the mode to text/sprite mode without clearing the vram in code)..... |
Mhhh....I have to look into this....setting VRAM to 0 by hand is a matter of a few lines code.... I hope I can report any success tommorow.....grrr...this is holding my complete project up :-/
#76194 - waruwaru - Sun Mar 19, 2006 9:05 am
I hit the same issue on my M3/CF tonight, I think I might have figured out part of the problem. In my case, the program works fine in DeSmuME, but get corrupted sprite/palette on hardware. Running the same scripts through DSLua produces different results from time to time. After some playing around, found my scrambled graphics/sprite issue had something to do with memory alignment and dma copy. I changed my sprite/palette memory allocations to always return a 32bit aligned address, and most of the corruptions are gone. What's left now seems more random. Same sprite/palette address shows corrupted graphics sometime, but not others. Maybe I am missing some other places where I need to allocate aligned memory, or there are some timing issues with M3/dma routines.
_________________
DSLua - a scripting language for your DS!
#76198 - qw3rty - Sun Mar 19, 2006 10:18 am
I'm ruling out DMA-transfer as source - the only time I use DMA-transfer is to update my OAM.
waruwaru, waht mode are you using. Is it also a tiled mode ?
I have the feeling it has something to do with tiled backgrounds...
#76235 - qw3rty - Sun Mar 19, 2006 6:27 pm
It seems that I have found the problem :
the M3 boot-menu seems to left traces in the VRAM and Sprites-VRAM.
Setting the complete VRAM to 0 seems to eliminate the problem.
include following code right after setting the VRAM-Banks :
for (i = 0; i < (131072/4 * 4); i++)
{
BG_GFX[i] = 0;
}
/*for (i = 0; i < (131072); i++)
{
SPRITE_GFX[i] = 0;
}*/
maybe you have to edit the names of BG_GFX and SPRITE_GFX, since I use alt_registers.h
EDIT : There are still problems with the Sprites, but Pepsiman's loader solves it, at least with my program :)
#76318 - Sektor - Mon Mar 20, 2006 3:20 pm
That fixed it. Splash screen isn't displayed but the rest of the program works fine on M3CF E16 with flashme6.
I posted links to the fixed txtwriter source and binary in the txtwriter thread.
_________________
GTAMP.com/DS
Last edited by Sektor on Mon Mar 20, 2006 10:53 pm; edited 1 time in total
#76334 - qw3rty - Mon Mar 20, 2006 8:08 pm
Great :)
We seem to have most of the problems with M3 under control :D
#76337 - knight0fdragon - Mon Mar 20, 2006 9:17 pm
what exact genre is your demo anyway?
_________________
http://www.myspace.com/knight0fdragonds
MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206
#76371 - cory1492 - Tue Mar 21, 2006 2:47 am
great stuff qw3rty; the stuff about DMA and VRAM definitely confirms my suspicions.
Im just looking at the "plug_ndsrom_sccf.h" from moonshell right now, and am wondering how much of that sort of stuff they never bothered to do in their "homebrew support" (clearing the video CR, clearing the ITCM/DTCM, clearing the DMA channels)...
Here is a quick cut-down of the file and it should clear out everything fairly quickly using DMA... although I am not certain if it will toss anything out of wack with Arm7 (shouldnt, although they may leave A7 in a bad state too), and it may duplicate something in crt0 already(very little if it does at all).
http://nds.cmamod.com/files/resetmem.h
I figure calling this before the poweron and setting the video modes should fix most any homebrew (it works really well when loading homebrew from/in moonshell at any rate, but that is not exactly supported on M3 at this point).
#76586 - ttursas - Thu Mar 23, 2006 12:13 am
I also battled with my M3-SD, and came to the conclusion that don't put anything into the subscreen VRAM during the very first frame. M3-SD boot program is still hanging in the system (some interrupt?) and overwrites the subscreen VRAM?
I forced my program to wait for the first VBLANK before doing any gfx uploads into the VRAM, and this solved the black-sub-screen problem completely.
Could SNES-DS be suffering from the same symptom??? Just a wild guess...