Rockbox mail archiveSubject: Re: ROMbox for fm recorders?
Re: ROMbox for fm recorders?
From: BlueChip <cs_bluechip_at_webtribe.net>
Date: Thu, 22 Jul 2004 20:54:11 +0100
> > Will I get slapped for mentioning that you can gain about 7K
> > by replacing the bigger of the two random number generators?
>Huh? Where should that be hiding?
Errr, sorry dude, I don't understand the question.
The (mighty and impressive) Marseinne Twister can be replaced with the
Linear Congruity algorithm I have implemeted as the bc_rnd() plugin library.
FULL docs (explanations, bibliography, etc) on the algorithm I used are
included in the zip file on my site.
Be warned though, I use a ">>8" at one point (else the numbers are just not
random enough ...I like a specific pattern in my random numbers - LOL)
Although the cpu supports >>8, I *THINK* the compiler still implements a
nasty macro ...but I actually spotted that on a differnt disassemble, and
have yet to check the actual bc_rnd library code itself.
As such, if you implemented such a scheme, it may be worth doing it in
Because of the >>8, the numbers are only 24bit ...but I questioned how
often I would ever want a random number in the range
The Starfield demo (requesting iirc about 200 random numbers per frame)
was, in part, written to test the algorithm. Feel free to confirm my results.
Someone said a loonngg time ago that it had been rejected due to ack of
random'ness, and yes, without the >>8 the sequence is thoroughly unacceptable
WRT assembler: If you look at the line() function in the bc_gfx lib, you
will see how (thanks to amiconn) I have optimised the abs() function
...essentially, both C and assembler are provided and the 'right' one is
For such tiny bits of code (and maybe bigger), *I* believe that it is
acceptable to offer optimised and unoptimised solutions... If another
processor comes along - everything is fine, and the coder has the option to
add a #ifdef NEW_CPU if he does not like the result C gives him.
Hope I covered what you needed to know,
Received on 2004-07-22