#46773 - LOst? - Thu Jun 30, 2005 1:08 pm
I have a problem with my first DS demo. I have set up the main display to show one BG, and it uses map, palette, and tiles from my GBA demo. In dsemu the actual tiles the map is showing are corrupted, and in dualis it shows up like it's supposed to. On the real hardware everything is just black.
Have you had this problem? Is there something I need to think about?
Here are the settings I use:
| Code: |
// Power on both displays using 2-D core
POWER_CR = POWER_LCD_TOP | POWER_2D | POWER_LCD_BOTTOM | POWER_2D_SUB;
// Assign main BG to VRAM_A
VRAM_A_CR = VRAM_ENABLE | VRAM_A_MAIN_BG;
// Enable BG 0 on the main display
DISPLAY_CR = MODE_0_2D | DISPLAY_BG_EXT_PALETTE | DISPLAY_BG0_ACTIVE;
// Disable sub display
SUB_DISPLAY_CR = 0;
// Configure BG 0
BG0_CR = BG_16_COLOR | BG_TILE_BASE (1) | BG_MAP_BASE (0) | BG_32x32;
// Copy ROM palette
dmaCopyWords (3, bgPalette, bg_palette, 128 * 4);
// Copy tiles
u16* bg0_tiles = (u16*) BG_TILE_RAM (1);
dmaCopyWords (3, bgTiles, bg0_tiles, (sizeof (bgTiles)) * 4);
// Copy map
u16* bg0_map = (u16*) BG_MAP_RAM (0);
dmaCopyWords (3, bgMap, bg0_map, (sizeof (bgMap)) * 4);
|
Something's wrong here? Something I forgot?
#46818 - LOst? - Fri Jul 01, 2005 3:14 am
Impossible to develop for the DS. I just need to change one little thing in the code to make emulators crash. And it still is black all over the real hardware display.
#46821 - rize - Fri Jul 01, 2005 3:42 am
Well, you shouldn't have extended palettes enabled if you're only using 16 color mode.
Also, if you're using 16 color mode, then the palette for your graphics should be designed for that and your tiles better index the palettes appropriately.
I'm not familiar with dma yet so I'm not sure if you're doing that right. Are you putting the palette in the right place?
Aside from the dma which I don't fully understand yet, the only other thing that strikes me as off is bg_palette
The macro BG_PALETTE points to the normal location for the ordinary main screen palette (16x16 or 256)
If all of that is straight and you're loading memory properly, it should work. Dualis suggests that you're loading memory properly, except maybe the palette.
#46824 - LOst? - Fri Jul 01, 2005 4:04 am
| rize wrote: |
Well, you shouldn't have extended palettes enabled if you're only using 16 color mode.
Also, if you're using 16 color mode, then the palette for your graphics should be designed for that and your tiles better index the palettes appropriately.
I'm not familiar with dma yet so I'm not sure if you're doing that right. Are you putting the palette in the right place?
Aside from the dma which I don't fully understand yet, the only other thing that strikes me as off is bg_palette
The macro BG_PALETTE points to the normal location for the ordinary main screen palette (16x16 or 256)
If all of that is straight and you're loading memory properly, it should work. Dualis suggests that you're loading memory properly, except maybe the palette. |
The problem is the dma. I'm copying the array bg_palette to BG_PALETTE using DMA during the Vblank interrupt. The DMA doesn't work on the real hardware. And channel 3 only works in the emulator. I want to use channel 0 (immediate copy).
DMA is there for usage. I don't like it when I can't use it.
#46825 - rize - Fri Jul 01, 2005 4:09 am
yeah. the extended palette flag should be ignored if you set the color for a bg to 16 color mode
so I'm not surprised it's the dma. I don't know much about dma yet, but you can probably sort it out if you've used it on the gba
#46827 - LOst? - Fri Jul 01, 2005 4:15 am
| rize wrote: |
yeah. the extended palette flag should be ignored if you set the color for a bg to 16 color mode
so I'm not surprised it's the dma. I don't know much about dma yet, but you can probably sort it out if you've used it on the gba |
In GBA I have to use DMA0 because nothing else can set the background offsets during VBlank interrupt. That means I will not be able to scroll the first scanline.
The extended palette flag is from your example. I have removed it now. It doesn't really make any difference right now.
#46833 - LOst? - Fri Jul 01, 2005 5:07 am
>.<; DMA doesn't work. Why is DS unable to use DMA (in ARM9)?
#46834 - DekuTree64 - Fri Jul 01, 2005 5:14 am
| LOst? wrote: |
| >.<; DMA doesn't work. Why is DS unable to use DMA (in ARM9)? |
Cache. You're probably trying to DMA from memory that hasn't been flushed out of the cache yet, so it's not what you're expecting it to be.
Or DMAing TO a place that hasn't been flushed, and then when it is flushed it overwrites your DMA'd data.
Solution: Flush the memory ranges involved before doing a DMA.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#46835 - LOst? - Fri Jul 01, 2005 5:18 am
| DekuTree64 wrote: |
| LOst? wrote: | | >.<; DMA doesn't work. Why is DS unable to use DMA (in ARM9)? |
Cache. You're probably trying to DMA from memory that hasn't been flushed out of the cache yet, so it's not what you're expecting it to be.
Or DMAing TO a place that hasn't been flushed, and then when it is flushed it overwrites your DMA'd data.
Solution: Flush the memory ranges involved before doing a DMA. |
How do I flush the memory? Also how to I place the arrays in the bigger memory (not the 32k)?
#46837 - DekuTree64 - Fri Jul 01, 2005 5:26 am
Try DC_FlushAll(). Not sure, but there might be a DC_FlushRange or something to only flush the areas you want. Flush all should be fine though.
To put an array in main RAM, you'll need to use an attribute to tell it to go into the .ewram section. I don't remember the exact syntax, but I think there's a #define called VAR_IN_EXRAM for it. To use that, do like
| Code: |
| u8 bigArray[32769] VAR_IN_EXRAM; |
and it should go into main RAM (4MB).
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#46838 - LOst? - Fri Jul 01, 2005 5:29 am
| DekuTree64 wrote: |
| DC_FlushAll() |
Do I need to flush every time I use DMA?
#46840 - DekuTree64 - Fri Jul 01, 2005 5:36 am
| LOst? wrote: |
| Do I need to flush every time I use DMA? |
Pretty much. If you're sure your data isn't in the cache, then you don't need to, but most of the time there's no guarantee. Kind of sucks when you're used to using it for everything on GBA, but it is still useful for blasting things to VRAM, or copying other large chunks of data around.
For small chunks of data, you'll probably be better off with a normal CPU copy.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#46841 - LOst? - Fri Jul 01, 2005 5:36 am
VAR_IN_EXRAM was a success! The DMA now works because the memory array is in the right place
#46842 - LOst? - Fri Jul 01, 2005 5:38 am
| DekuTree64 wrote: |
| LOst? wrote: | | Do I need to flush every time I use DMA? |
Pretty much. If you're sure your data isn't in the cache, then you don't need to, but most of the time there's no guarantee. Kind of sucks when you're used to using it for everything on GBA, but it is still useful for blasting things to VRAM, or copying other large chunks of data around.
For small chunks of data, you'll probably be better off with a normal CPU copy. |
What I plan to do is using HDMA. It will do a DMA every hblank, so that I can do raster effects. I hope one flush will be enough <.<;
#46844 - DekuTree64 - Fri Jul 01, 2005 5:50 am
| LOst? wrote: |
| What I plan to do is using HDMA. It will do a DMA every hblank, so that I can do raster effects. I hope one flush will be enough <.<; |
Yeah, once you finish filling out your table, flush it and you should be good to go.
It doesn't matter if it ends up back in the cache at some point (by reading data near it or something), because the correct data is in RAM, and unless you change it, the same data would be in the cache too.
It's confusing, but the speed is worth it when your memory is as slow as the DS's main RAM :)
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#46845 - LOst? - Fri Jul 01, 2005 6:06 am
| DekuTree64 wrote: |
| LOst? wrote: | | What I plan to do is using HDMA. It will do a DMA every hblank, so that I can do raster effects. I hope one flush will be enough <.<; |
Yeah, once you finish filling out your table, flush it and you should be good to go.
It doesn't matter if it ends up back in the cache at some point (by reading data near it or something), because the correct data is in RAM, and unless you change it, the same data would be in the cache too.
It's confusing, but the speed is worth it when your memory is as slow as the DS's main RAM :) |
How do I set up the HDMA? This didn't work:
| Code: |
s16 scanline [192*2] VAR_IN_EXRAM;
...
DC_FlushAll ();
DMA_SRC(0) = (uint32) scanline;
DMA_DEST(0) = (uint32) BG0_X0;
DMA_CR(0) = DMA_16_BIT | DMA_START_HBL | DMA_REPEAT | DMA_DST_RESET | DMA_ENABLE | 2;
|
#46849 - DekuTree64 - Fri Jul 01, 2005 6:36 am
| LOst? wrote: |
How do I set up the HDMA? This didn't work:
| Code: | ...
DMA_DEST(0) = (uint32) BG0_X0;
... |
|
Make that
| Code: |
| DMA_DEST(0) = (uint32) &BG0_X0; |
the rest looks fine to me
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#46851 - LOst? - Fri Jul 01, 2005 7:17 am
| DekuTree64 wrote: |
| LOst? wrote: | How do I set up the HDMA? This didn't work:
| Code: | ...
DMA_DEST(0) = (uint32) BG0_X0;
... |
|
Make that
| Code: | | DMA_DEST(0) = (uint32) &BG0_X0; |
the rest looks fine to me |
Only one problem. DMA0 doesn't work. And you can't use DMA3
#46852 - DekuTree64 - Fri Jul 01, 2005 7:33 am
Huh? Why doesn't DMA0 work? And why can't you use 3?
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#46862 - LOst? - Fri Jul 01, 2005 12:18 pm
| DekuTree64 wrote: |
| Huh? Why doesn't DMA0 work? And why can't you use 3? |
DMA3 isn't as high priority to finish the copy at the Hblank (why DMA0 is needed when doing HDMA).
DMA0 won't work in emulators, and it is hard to see if something even happened on the real hardware.
EDIT: All of a sudden DMA0 works, and so do HDMA. Wierd. I have worked for so many hours, and all it needed was a little bit sleep (me sleeping of course, not the code)
EDIT: But not on the real hardware >.<;