--- In gbadev@yahoogroups.com, "Damian Yerrick" <d_yerrick@h...>
wrote:
> --- In gbadev@yahoogroups.com, "ronald_chenu" <ronald_chenu@y...>
> wrote:
> >
> > Caching to the EXTRAM (or VRAM itself by double buffering) will
have
> > the following (+)positive and (-)negative consequences:
>
> (paraphrasing here)
>
> > (+) Caching in EWRAM allows use of draw time for decompression.
> Correct. EWRAM to VRAM transfers run at 4 cycles per 2 bytes,
> filling the entire 32 KB sprite cel VRAM within about 66,000
> cycles. Vblank is 83,776 cycles long.

That will hold only if your data is uncompressed and that you are
doing a DMA transfer, I suppose

> > (-) Caching uses EWRAM.
> Correct.
> > (-) Caching uses time to move data into EWRAM.
> Correct.
> > And the most important of all:
> > (-)Consumes greater cpu time.
> Not necessarily. If you are transferring the same images over
> and over to VRAM, such as 12 frames of a walk loop, you save
> the time of repeated decompression. You can also decompress
> ahead of the animation when you know you have a lot of CPU
> time to spare in this frame's draw period.

Interesting, by implementing this kind of memory manager, the cpu
overhead of caching is effectively reduced by using even more VRAM
(more than one frame per sprite will be cached). But that shouldn't be
a problem I guess...

> > This will work remarkably well if you have spare time outside
> > vblank
> In my experience, most 2D programs for GBA have much more
> spare time outside vblank than they know what to do with.
> Still, efficient coding will drain the battery less.

Very useful information, I expected vblank to be busier than
non-vblank time, but not as you described.

Taking all this into consideration I'll run some tests and see what I
can come up with.

Thanks again

Ronald