#110070 - Ant6n - Sat Nov 25, 2006 5:14 am
Hi,
i have just been attempting some scroller type using mode 3. i intended it to do it very similarly to text type scrollers, with wraparound. Now i notice that bg_control gets ignored, and it seems its not possible to wrap around in the bitmap modes. Is that true, or did i overlook something?
(I just wanna make real sure before i go to mode 5 with its half horizontal resolution or mode 1/2/4 with its 8 bit limitation)
anton
#110071 - tepples - Sat Nov 25, 2006 5:18 am
GBA bitmap modes do not support horizontal wrapping of the background image. For vertical wrapping, you could reset the current screen position halfway down the screen.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#110166 - Ant6n - Sun Nov 26, 2006 4:47 am
This is somewhat related to my previous question, relating to the exact workings of the lcd-controller. in the GBATEK it says this:
"VRAM, OAM, and Palette RAM Access
These memory regions can be accessed during H-Blank or V-Blank only
(...)
The CPU appears to be able to access VRAM/OAM/Palette at any time, a waitstate (one clock cycle) being inserted automatically in case that the display controller was accessing memory simultaneously. (Ie. unlike as in old 8bit gameboy, the data will not get lost.)"
Now this is somewhat vague to me since the usual way to access memory is through the cpu; who would the ominuous other one be that cannot acces these memory areas at any time? DMA? Does that mean i can copy to VRAM during the H-visible time using cpu? But not DMA? Isn't DMA done by cpu anyway?
It seems to me that if its not possible to access VRAM at all during H-visible, what is the point of the 'Video Capture Mode' of dma3 (since it couldnt transfer a mode3 picture)?
Anton
#110169 - tepples - Sun Nov 26, 2006 6:10 am
Yes, it is possible to access GBA VRAM during draw time. Heck, some games even run code in VRAM; it's the fastest 16-bit memory that the GBA has.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#110170 - Ant6n - Sun Nov 26, 2006 9:34 am
so i could copy some video data (like 10K) with some DMA while screen is being drawn.
I understand a dma will pause the cpu. So if an interrupt occurs during a dma transfer, it will only be taken care of after the dma is completed, right? (i.e. making long dma's potentially dangerous if there are other vcount intterrupts going on..)
#110210 - tepples - Sun Nov 26, 2006 8:55 pm
A copy using the 'stmia' instruction (CpuFastSet) may be only 10% slower than a DMA copy, and it responds more quickly to interrupts than DMA.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#110212 - Ant6n - Sun Nov 26, 2006 9:09 pm
but if do the stmia thing during a vcount interrupt, it will still stall other interrupts, as far as i know (unless you have a real sophisticated irq-handler). its probably best to do a repeating dma using dma3, each time starting at hblank.
Which leads me to another question (i know this is tedious, but this stuff is really hard to test): if there is a dma and an irq scheduled at hblank, who has priority?
anton
#110487 - Miked0801 - Tue Nov 28, 2006 9:28 pm
By a few tics at most. DMA will stall the CPU until the entire xfer is complete. A stmia will stall at most worst case around 40 cycles - much less is transfering to IWRAM or VRAM. Also, beware calling CpuFastSet as it has to go through a software interrupt to get at the calls. It's usually much easier to either in-line your own fast copy or to do a structure to structure assign and let the compiler do it for you:
typedef struct
{
u32 fourBytes;
u32 eightBytes;
u32 twelveBytes;
u32 sixteenBytes;
} FOO;
FOO foo1, foo2;
codeFoo()
{
foo1 = foo2;
}
The above code compiled ARM will turn into a 4 register ldmia, stdmia combo which is the fastest way to copy data of less than about 32 bytes or so.
And yes, you could setup a HDMA interrupt to handle copies for you if you wished - which would get rid of the IRQ handler overhead.