Re: [Ipodlinux-devel] status update 17.02.03

[<arm...@ya...>]

Bernard Leach <le...@bo...> wrote:
> 
> An extension of that would be to then put the decoding routines
> in fast ram (since we wouldnt be using it as the buffer).
> I'm not sure how big a win this would be but it is how the real
> firmware works...
> 

My guess is that this will be a _big_ win. The internal SRAM is
likely to be 32bit wide, with low (probably zero) wait-states when
accessed from the ARM.

The system SDRAM on the other hand (Samsung part No. K4S561632 ??) is
16bit wide, has the overhead of refreshes etc and is probably clocked
slower as well (anyone with an open ipod and a 'scope handy, please
put a probe on pin 38 of the SDRAM chip and let us know for sure...
:-).

The most important code in madplay to speed up is the imdct36
assembler function and the contents of synth.c. The later may take a
bit more work, but the former is fully PIC so a quick and dirty test
would be to hack madplay to memcpy the whole of III_imdct_l into fast
SRAM at program startup and then call it from there via a function
pointer (its only called from 2 places in layer3.c).

How big is the internal SRAM by the way ???

Andre
--





__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com