--- In gbadev@yahoogroups.com, Ronald Chenu Abente <ronald_chenu@y...>
wrote:
> This brought many questions about the way the GBA
> renders the screen each frame. As we all know there
> are 228 scanlines per frame, but only 160 of them are
> actually used to render sprites and BGs.
> Is the CPU totally 'free' for other tasks during these
> 'hot' 160 scanlines?

Yes.

> Are there issues with accessing different parts of the
> memory map because, say, the CPU tries to update some
> unused memory of the OBJ VRAM while the LCD hardware
> is rendering sprites?

There might be a couple cycles of "wait states", but you'll
usually get far fewer than one per read or write on average.
More importantly, GBA VRAM contention introduces no
corruption issues like the NES and the 8-bit Game Boy had.
The NES shared an address bus between the PPU's refresh and
the CPU's port to VRAM; the GBC just disconnected the VRAM
from the memory map during draw. The GBA's memory controller
is much smarter than that, and VRAM is the second fastest RAM
in the GBA.

> That's why we've been thinking of using fast memory
> transfers (via DMA or CPU copies), during vblank of
> course, of each frame of a sprite from ROM to OJBVRAM
> (achieving animation of all sprites by streamlining
> frames directly). We know this has already been
> implemented in many games in a limited fashion

At least Kirby: Nightmare in Dream Land and Sonic Advance copy
the hero sprite's cel into RAM every frame. Mario Kart Super
Circuit does it for all driver sprites when running from ROM
(i.e. when not a multiboot slave).

> and where wondering about the reasons for doing it just
> to such extent (since this seems to leave plenty of cpu
> cycles unused).

Read this white paper on the topic:
http://www.pineight.com/gba/managing-sprite-vram.txt

Besides, the more CPU cycles you don't use, the better, as you
can tell the BIOS to turn off the CPU until the next vblank or
until a given scanline and drain the battery less.

--
Damian