Rockbox mail archive

• Next message: Mike Holden: "Re: cvs: apps tree.c,1.184,1.185"
• Previous message: TP Diffenbach: "RE: another 8MB upgrade success story"
• In reply to: TP Diffenbach: "RE: another 8MB upgrade success story"
• Next in thread: Björn Stenberg: "Re: another 8MB upgrade success story"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Same reason that we merged the player-old and player-new firmware together. Less confusing for people, easier to switch back and forth, less builds, etc.

-Justin

---------- Original Message ----------
To: (rockbox_at_cool.haxx.se)
From: TP Diffenbach (rockbox_at_diffenbach.org)
Subject: RE: another 8MB upgrade success story
Date: 3/19/2003 3:16:28p

> Why do you prefer to have rockbox dynamically recognize your memory size,
> rather than build for a particular size?
>
> Quoting Leif Sawyer <lsawyer_at_gci.com>:
>
>
> > I could really use that 8M upgrade, and knowing that the code
> > "just knew" how to deal with that would make my life simpler.
> > (Of course, i still have to get the upgrade.. :-( )
> >
> >
> > It sounds like the first thing is just to outline exactly what
> > buffer changes need to take place, reserve a few bytes in memory
> > for 'hardcoding' these values, then adjusting them if we find
> > more than 2M. ( X << 4 , or whatever the local equivalent is to
> > quickly multiply by 4, as that's the difference..)
> >
> > Would that be a reasonable approach?
> >
> >
> >
>
>
> --
> Archos FM needs a Rockbox!

• Next message: Mike Holden: "Re: cvs: apps tree.c,1.184,1.185"
• Previous message: TP Diffenbach: "RE: another 8MB upgrade success story"
• In reply to: TP Diffenbach: "RE: another 8MB upgrade success story"
• Next in thread: Björn Stenberg: "Re: another 8MB upgrade success story"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]