my mingw based gcc for arm has been updated with gcc 3.3.3

http://homepage.ntlworld.com/wintermute2002/

any problems give me a shout :)

Dave

I was going to start this off by arguing that you should use 32 bit not
16 bit as it should be more efficient on the ARM.  If you start off with
signed 8 bit samples, want to add them and clip them and store the
result back as signed 8 bit, using a signed 32 bit variable would be
ideal on the ARM.  I would argue that if you use a 16 bit signed
variable the compiler should clip to 16 bits before doing the compare:

short sa;
char ca,cb,cc;
...
	 sa=ca+cb;
	 if(sa>127) sa=127;
	 if(sa<-127) sa=-127;
...

ca and cb are loaded and signed extended into registers using the ldrb
instruction, so everything internally is a 32 bit signed variable
before doing the first compare, a generic compiler should clip sa to 16
bits to insure it is not comparing a number greater than 16 bits can
hold, perhaps in this case the compiler is smart enough to know the add
is from 8 bit and spares this step
Sure enough if you change the char ca... to short ca...then gcc does in
fact clip sa before going on to the compare.  (I would still argue as a
habit on the ARM to use an 32 bit signed for this sort of thing instead
of 16 bit signed, for performance)

Here is the scary thing I found, using the RVCT compiler (eval) from
ARM, the compiler had NO PROBLEMS with this code:

short sa;
char ca,cb,cc;

int main ( void )
{
	 sa=ca+cb;
	 if(sa>70000) sa=127;
	 cc=(char)sa;
	 return(0);
}

The compiled code actually compared sa with 70000 not realizing that sa
is a 16 bit variable and could never be greater than 70000.
This bothers me...

ADD R1,R1,R2
SUBS R12,R1,#0X11000
SUBGES R12,R12,#0X170
STRH R1,[R0,#4]  ;sa
MOVGT r1,#0x7f
STRGTH r1,[r0,#4] ;sa

Perhaps the code will never have the GT flag set and isnt harmful, but
just wastes cycles.  I will have to think about that.

Gcc performed as expected, gave a warning that the comparison could
never be true and simply didnt generate code for the comparison, it did
the add and stored sa to cc and was done.

David


On Tue, 2004-01-27 at 02:09, gb_feedback wrote:
> Are you limiting the output (by adding in 16 bit
> and then limiting)?:
>  if (sampleL > 127)
> 	 sampleL = 127;
>  if (sampleL < -127)
> 	 sampleL = -127;
>
> --- In gbadev@yahoogroups.com, Josh DeBonis <joshdebonis@y...> wrote:
> > I'm trying to mix 2 sound samples on the GBA.  When I
> > play them individually, they sound great. When I mix
> > them together, a sound is produced, but it's not
> > pretty.  I am simply adding the values of each sample
> > together (it is a sample of the amplitude). I have
> > tried scaling down the amplitudes before I add them,
> > to prevent clipping, and this does not prevent the
> > problem. Do I have to do any strange adding because of
> > twos complement?  Anyone know what I might be missing?
> >
> > Thanks,
> > Joshua
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! SiteBuilder - Free web site building tool. Try it!
> > http://webhosting.yahoo.com/ps/sb/
>
>
>
>
>
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
>  http://groups.yahoo.com/group/gbadev/
>
> To unsubscribe from this group, send an email to:
>  gbadev-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to:
>  http://docs.yahoo.com/info/terms/
>
>

On Monday 26 January 2004 22:54, Guido Henkel wrote:
> Your samples are clipping, that's what you're hearing.
>
> What you have to do is to add the two of them and then create the average.
>
> destSample = ( sample1 + sample2 ) / 2;

uuuwww... no, please dont, this is a common misconception. while this will
prevent the clipping, it is still not what you want.

what you need to do is

a) sum up the amplitudes of all channels you want to mix, ie in your
case sum=smp1+smp2

b) clamp the resulting value against the high and the low limit like this:

if (sum>highlimit) sum=highlimit;
else if(sum<lowlimit) sum=lowlimit;

gpz

Are you limiting the output (by adding in 16 bit
and then limiting)?:
	 if (sampleL > 127)
		 sampleL = 127;
	 if (sampleL < -127)
		 sampleL = -127;

--- In gbadev@yahoogroups.com, Josh DeBonis <joshdebonis@y...> wrote:
> I'm trying to mix 2 sound samples on the GBA.  When I
> play them individually, they sound great. When I mix
> them together, a sound is produced, but it's not
> pretty.  I am simply adding the values of each sample
> together (it is a sample of the amplitude). I have
> tried scaling down the amplitudes before I add them,
> to prevent clipping, and this does not prevent the
> problem. Do I have to do any strange adding because of
> twos complement?  Anyone know what I might be missing?
>
> Thanks,
> Joshua
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free web site building tool. Try it!
> http://webhosting.yahoo.com/ps/sb/

Your samples are clipping, that's what you're hearing.

What you have to do is to add the two of them and then create the average.

destSample = ( sample1 + sample2 ) / 2;


Guido

   ----- Original Message -----
   From: Josh DeBonis
   To: gbadev@yahoogroups.com
   Sent: Monday, January 26, 2004 8:56 AM
   Subject: [gbadev] Sound mixing


   I'm trying to mix 2 sound samples on the GBA.  When I
   play them individually, they sound great. When I mix
   them together, a sound is produced, but it's not
   pretty.  I am simply adding the values of each sample
   together (it is a sample of the amplitude). I have
   tried scaling down the amplitudes before I add them,
   to prevent clipping, and this does not prevent the
   problem. Do I have to do any strange adding because of
   twos complement?  Anyone know what I might be missing?

   Thanks,
   Joshua

   __________________________________
   Do you Yahoo!?
   Yahoo! SiteBuilder - Free web site building tool. Try it!
   http://webhosting.yahoo.com/ps/sb/


         Yahoo! Groups Sponsor
               ADVERTISEMENT





------------------------------------------------------------------------------
   Yahoo! Groups Links

     a.. To visit your group on the web, go to:
     http://groups.yahoo.com/group/gbadev/

     b.. To unsubscribe from this group, send an email to:
     gbadev-unsubscribe@yahoogroups.com

     c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

I'm trying to mix 2 sound samples on the GBA.  When I
play them individually, they sound great. When I mix
them together, a sound is produced, but it's not
pretty.  I am simply adding the values of each sample
together (it is a sample of the amplitude). I have
tried scaling down the amplitudes before I add them,
to prevent clipping, and this does not prevent the
problem. Do I have to do any strange adding because of
twos complement?  Anyone know what I might be missing?

Thanks,
Joshua

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

hi

i'm coding using devkit_v4 and C

I am having trouble using FRAS with my project.

When calling a fras-function somewhere in the code, the linker
includes those functions from the fras-library (of course). But as
soon as it does that, the program refuses to work at all...

i had to call one of jeff frohwein's functions defined in crt0.s
(__FarProcedure) in order to be able to call the fras-funcs without
generating an error.


Now it compiles w/o any error or warning msg, but locks right after
being loaded into an emulator.

This also happens when i include the fras-functions from the
asm-sources instead of linking to the library...


if there was something wrong with the interrupts not being set up
properly, the program should show something at least, but not lock!
(i'm starting the timers before i call any fras-function, but they
don't increment...they just stay at zero)


I think it might have something to do with crt0.s, but it's just a
guess....
(i've enabled interrupts there and they're working as expected)

any suggestions?

thanks a lot
schoebey

I tried a copy of ARM's RVCT (RealView Compiler Tools) v2.0.1

The numbers and some updated code that builds on RVCT and ADS are posted
at http://www.dwelch.com/gba/dhry.htm

Looking at the numbers the new compiler is 7 percent faster than ads
1.2.  And is 22% faster than the last gcc 3.4 ran I did (experimental
version).

I have also been playing with the htsoft.com armc compiler, no numbers
to post, they do have or will have a version available that does thumb
mode soon.

David

j> There seems to be way too long between posting and moderating in this
j> group - which brings down the pace incredibly and makes this group
j> almost unusuable for discussion.

j> Anyone agree with me?

I like this group because it is moderated. Only relevant, informative
mails go thru. No spam, no flames and no offtopic threads.

I did the same, looked at VBA and got it workin in the emu - but on
hardware (XG2 Turbo) the date of month and hours are wrong like this:

When date is 16 or higher, 4 is added
When hour is afternoon (PM) 3 was added (I think)

allthough after messing around lately I got hours like this:

0-11:59 AM is OK
0-11:59 PM give 80 to 92, like there's a PM flag

I looked at your code but doing it that way doesnt work at all on
hardware (normally you write 5 4s and the a 5 before reading) - maybe
the Pokemon clock is more accepting?

<swedish>
Förresten, försökte med din mail & icq tidigare men fick inte tag på
dig - har du nåt aktuellt kontakt-sätt? :)
</swedish>

--- In gbadev@yahoogroups.com, Fredrik Olsson <flubba@h...> wrote:
> Den 2004-01-09 18:46:56 skrev "jonas_minnberg"
<jonas_minnberg@y...>:
>
> >
> >I'm in the process of figuring out how this works, but it would be
> >much easier if I could find some real documentation. Has anyone
> >opened up either Pokemon or a flashcart with RTC and found a
> >component-number so I could look it up on the net?
>
> I used the source from VBA ( http://sourceforge.net/projects/vba/ )
as a starting point, but it didn't work on hardware, so I got someone
to test it on a Pokemon cart and after some coding/testing back and
> forth it now works quite good. If you want to you can download the
PCEAdvance source from http://hem.passagen.se/flubba/gba.html

Den 2004-01-09 18:46:56 skrev "jonas_minnberg" <jonas_minnberg@...>:

>
>I'm in the process of figuring out how this works, but it would be
>much easier if I could find some real documentation. Has anyone
>opened up either Pokemon or a flashcart with RTC and found a
>component-number so I could look it up on the net?

I used the source from VBA ( http://sourceforge.net/projects/vba/ ) as a
starting point, but it didn't work on hardware, so I got someone to test it on a
Pokemon cart and after some coding/testing back and
forth it now works quite good. If you want to you can download the PCEAdvance
source from http://hem.passagen.se/flubba/gba.html

I believe that most people who used to post here went
to http://forum.gbadev.org when that started.
The format works a lot better than here IMO.
Also I'm sure I've seen an answer of sorts to your question there.

--- In gbadev@yahoogroups.com, "jonas_minnberg" <jonas_minnberg@y...>
wrote:
> There seems to be way too long between posting and moderating in
this
> group - which brings down the pace incredibly and makes this group
> almost unusuable for discussion.
> I suggest we turn moderation off - I'd rather sort through the odd
> junk mail than this. And you can always kick members who behaves
> really badly.
>
> Anyone agree with me?

There seems to be way too long between posting and moderating in this
group - which brings down the pace incredibly and makes this group
almost unusuable for discussion.
I suggest we turn moderation off - I'd rather sort through the odd
junk mail than this. And you can always kick members who behaves
really badly.

Anyone agree with me?

I'm in the process of figuring out how this works, but it would be
much easier if I could find some real documentation. Has anyone
opened up either Pokemon or a flashcart with RTC and found a
component-number so I could look it up on the net?

Yes I found those too but as I guess you also noticed you can't
access the attachments (I guess they're not saved).

Anyway, I got the source now.

-- Jonas

--- In gbadev@yahoogroups.com, "Chris White" <kisyfier@n...> wrote:
> Heres the TWO emails that I have in archives with ref to lz77
> ... etc

--- In gbadev@yahoogroups.com, "jonas_minnberg" <jonas_minnberg@y...>
wrote:
> Someone posted the source for a LZ77UnCompWram() compatible
> compression routine a while back, but it is unavailable now - any
> chance of it getting posted again?

Part of "Tetanus On Drugs" Milestone 3:
http://www.pineight.com/gba/#tod

I haven't yet had the chance to look into making it compatible
with LZ77UnCompVram().

--
Damian

Heres the TWO emails that I have in archives with ref to lz77

-----Original Message-----
From: Alex Ganea [mailto:alex_toresh@...]
Sent: 22 February 2002 16:10
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] lz77 bios compression

Ok here I go with the source (again), it's also for testing the new
attachement feature! thx mod btw ==D
Sorry for the incovenience.

PS: Note that this source was not written by me, the author is unknown.
I also written a C decompressor (for optimisation reasons), ask me if
you want it.

   ----- Original Message -----
   From: Alex Ganea
   To: gbadev@yahoogroups.com
   Sent: Friday, February 22, 2002 10:35 AM
   Subject: Re: [gbadev] lz77 bios compression


   Hmm seems the attachement didn't make it. Here is the source:

   -> Note to Mod: It would be nice to allow attachements? I know that
attachements gave rise to abuse in the past, but if you're filtering the
messages why not allowing that? I'm not sure that a deny policy is the
best here. Also note that the source I posted hasn't any copyrighted
material in it, LZSS is an algorithm free of use as far as I know.


   [mod answer:
   Ok, attachments are now allowed :) But please don't include
attachments without a good reason, and very small files only! If this
doesn't work out I will of course have to remove this privilege again. ]


   ------------------------------------- comp.h

[cropped by mod]


Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

Ok here I go with the source (again), it's also for testing the new attachement feature! thx mod btw ==D
Sorry for the incovenience.

PS: Note that this source was not written by me, the author is unknown.
I also written a C decompressor (for optimisation reasons), ask me if you want it.

  ----- Original Message -----
  From: Alex Ganea
  To: gbadev@yahoogroups.com
  Sent: Friday, February 22, 2002 10:35 AM
  Subject: Re: [gbadev] lz77 bios compression

  Hmm seems the attachement didn't make it. Here is the source:

  -> Note to Mod: It would be nice to allow attachements? I know that attachements gave rise to abuse in the past, but if you're filtering the messages why not allowing that? I'm not sure that a deny policy is the best here. Also note that the source I posted hasn't any copyrighted material in it, LZSS is an algorithm free of use as far as I know.

  [mod answer:
  Ok, attachments are now allowed :) But please don't include attachments without a good reason, and very small files only! If this doesn't work out I will of course have to remove this privilege again. ]

  ------------------------------------- comp.h

[cropped by mod]
 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Someone posted the source for a LZ77UnCompWram() compatible
compression routine a while back, but it is unavailable now - any
chance of it getting posted again?

-- Jonas Minnberg

That might not be entirely true because the BIN data contains less header
information than the RAW data. There are 48 bytes of header data in the RAW
data versus 12 bytes in the BIN data. The header data that gets dropped
includes yet to be identified randomly looking data. It is better to simply
repair the RAW data than to convert it first to BIN and then back to RAW. In
fact, I have the RAW-to-BIN decoding running on my PC as native x86 code,
and could, if I had the time, make a tool that could repair the RAW data.
Currently my priority is to turn my "decoder" into an "encoder" so that we
can FINALLY start generating our own dotcodes, containing our own mini-games
or other stuff.

-----Original Message-----
From: Damien Good [mailto:d_good@...]
Sent: donderdag 1 januari 2004 23:17
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Re: e-Reader dissection

although, if the reed solomon encoding/decoding process gets figured out,
then I am sure a 100% error free raw file can be made from the error free
bin file.


----- Original Message -----
From: "Tim Schuerewegen" <Tim.Schuerewegen@...>
To: <gbadev@yahoogroups.com>
Sent: Thursday, January 01, 2004 5:43 AM
Subject: RE: [gbadev] Re: e-Reader dissection


> One important thing that people ought to know is that the RAW data is not
> 100% error free. If you would scan/dump the same dotcode over and over
> again, you will get slightly different RAW data each time. These errors
get
> corrected by the Reed-Solomon decoding of the e-Reader and the resulting
BIN
> data is therefore error free. Remember this if you decide to print out
some
> dotcodes using my printing tool. E.g. if you have printed a dotcode based
on
> a RAW dump containing lots of errors, then you will add these "printed"
> errors to your own "scanned" errors and lower the chance of getting a
> successful read.
>
> -----Original Message-----
> From: Damien Good [mailto:d_good@...]
> Sent: donderdag 1 januari 2004 13:07
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] Re: e-Reader dissection
>
> more e-reader info at http://www.alpha-ii.com/caitsith2/ereader
>
> the released bin/raw data of the e-reader cards might cause controversy,
but
> at the same time, the items these cards unlock, can also be unlocked with
an
> action replay,  and the bin/raw data is very similar, that it might help
> with the reed-solomon code cracking.  (heck, the dotcodes on the actual
> powerup cards look very similar, with only a few bytes in the bin data,
and
> maybe 20-60 bytes in the raw data being different.)
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
>  http://groups.yahoo.com/group/gbadev/
>
> To unsubscribe from this group, send an email to:
>  gbadev-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to:
>  http://docs.yahoo.com/info/terms/
>
>
>







Yahoo! Groups Links

To visit your group on the web, go to:
  http://groups.yahoo.com/group/gbadev/

To unsubscribe from this group, send an email to:
  gbadev-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to:
  http://docs.yahoo.com/info/terms/

although, if the reed solomon encoding/decoding process gets figured out,
then I am sure a 100% error free raw file can be made from the error free
bin file.


----- Original Message -----
From: "Tim Schuerewegen" <Tim.Schuerewegen@...>
To: <gbadev@yahoogroups.com>
Sent: Thursday, January 01, 2004 5:43 AM
Subject: RE: [gbadev] Re: e-Reader dissection


> One important thing that people ought to know is that the RAW data is not
> 100% error free. If you would scan/dump the same dotcode over and over
> again, you will get slightly different RAW data each time. These errors
get
> corrected by the Reed-Solomon decoding of the e-Reader and the resulting
BIN
> data is therefore error free. Remember this if you decide to print out
some
> dotcodes using my printing tool. E.g. if you have printed a dotcode based
on
> a RAW dump containing lots of errors, then you will add these "printed"
> errors to your own "scanned" errors and lower the chance of getting a
> successful read.
>
> -----Original Message-----
> From: Damien Good [mailto:d_good@...]
> Sent: donderdag 1 januari 2004 13:07
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] Re: e-Reader dissection
>
> more e-reader info at http://www.alpha-ii.com/caitsith2/ereader
>
> the released bin/raw data of the e-reader cards might cause controversy,
but
> at the same time, the items these cards unlock, can also be unlocked with
an
> action replay,  and the bin/raw data is very similar, that it might help
> with the reed-solomon code cracking.  (heck, the dotcodes on the actual
> powerup cards look very similar, with only a few bytes in the bin data,
and
> maybe 20-60 bytes in the raw data being different.)
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
>  http://groups.yahoo.com/group/gbadev/
>
> To unsubscribe from this group, send an email to:
>  gbadev-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to:
>  http://docs.yahoo.com/info/terms/
>
>
>

One important thing that people ought to know is that the RAW data is not
100% error free. If you would scan/dump the same dotcode over and over
again, you will get slightly different RAW data each time. These errors get
corrected by the Reed-Solomon decoding of the e-Reader and the resulting BIN
data is therefore error free. Remember this if you decide to print out some
dotcodes using my printing tool. E.g. if you have printed a dotcode based on
a RAW dump containing lots of errors, then you will add these "printed"
errors to your own "scanned" errors and lower the chance of getting a
successful read.

-----Original Message-----
From: Damien Good [mailto:d_good@...]
Sent: donderdag 1 januari 2004 13:07
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Re: e-Reader dissection

more e-reader info at http://www.alpha-ii.com/caitsith2/ereader

the released bin/raw data of the e-reader cards might cause controversy, but
at the same time, the items these cards unlock, can also be unlocked with an
action replay,  and the bin/raw data is very similar, that it might help
with the reed-solomon code cracking.  (heck, the dotcodes on the actual
powerup cards look very similar, with only a few bytes in the bin data, and
maybe 20-60 bytes in the raw data being different.)

more e-reader info at http://www.alpha-ii.com/caitsith2/ereader

the released bin/raw data of the e-reader cards might cause controversy, but
at the same time, the items these cards unlock, can also be unlocked with an
action replay,  and the bin/raw data is very similar, that it might help
with the reed-solomon code cracking.  (heck, the dotcodes on the actual
powerup cards look very similar, with only a few bytes in the bin data, and
maybe 20-60 bytes in the raw data being different.)

----- Original Message -----
From: "Tim Schuerewegen" <Tim.Schuerewegen@...>
To: <gbadev@yahoogroups.com>
Sent: Wednesday, December 31, 2003 11:12 AM
Subject: RE: [gbadev] Re: e-Reader dissection


> I just released a bit of e-reader information too, including a dotcode
> printing tool (some ppl already have it), more to follow soon...
>
> http://users.skynet.be/firefly/gba/e-reader/
>
> -----Original Message-----
> From: Damien Good [mailto:d_good@...]
> Sent: woensdag 31 december 2003 3:42
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] Re: e-Reader dissection
>
> http://www.alpha-ii.com/caitsith2/ereader/dot-code%20block.jpg -
explanation
> on how the raw data is stored in the dotcode blocks in the strip.
>
> Now, the only thing that is really stopping us from
> developing our own dotcodes, is the fact that we do not know how to
> encode/decode the nintendo specific reed-solomon codes.
>
> essentially, it goes like this.
>
> Binary data + reed-solomon codes = Raw data. (unsolved)
> Raw data + 8/10 Modulation = Dotcode dots. (solved)
>
> It would be helpful to know where the e-reader functions are, in the rom,
> and what each of them does.  maybe we can reverse engineer the
reed-solomon
> encoding/decoding out of one of the functions.
>
>
>
>
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
>  http://groups.yahoo.com/group/gbadev/
>
> To unsubscribe from this group, send an email to:
>  gbadev-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to:
>  http://docs.yahoo.com/info/terms/
>
>
>

"they"?
"code"?
"data"?

-----Original Message-----
From: Daniel [mailto:webmaster@...]
Sent: woensdag 31 december 2003 16:30
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Re: e-Reader dissection

Sgstair was telling me that they have downloaded the code and are looking at
it.  He can tell you how to access that data..

----- Original Message -----
From: "Damien Good" <d_good@...>
To: <gbadev@yahoogroups.com>
Sent: Tuesday, December 30, 2003 6:41 PM
Subject: Re: [gbadev] Re: e-Reader dissection


> http://www.alpha-ii.com/caitsith2/ereader/dot-code%20block.jpg -
explanation
> on how the raw data is stored in the dotcode blocks in the strip.
>
> Now, the only thing that is really stopping us from
> developing our own dotcodes, is the fact that we do not know how to
> encode/decode the nintendo specific reed-solomon codes.
>
> essentially, it goes like this.
>
> Binary data + reed-solomon codes = Raw data. (unsolved)
> Raw data + 8/10 Modulation = Dotcode dots. (solved)
>
> It would be helpful to know where the e-reader functions are, in the rom,
> and what each of them does.  maybe we can reverse engineer the
reed-solomon
> encoding/decoding out of one of the functions.

--- 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

I just released a bit of e-reader information too, including a dotcode
printing tool (some ppl already have it), more to follow soon...

http://users.skynet.be/firefly/gba/e-reader/

-----Original Message-----
From: Damien Good [mailto:d_good@...]
Sent: woensdag 31 december 2003 3:42
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Re: e-Reader dissection

http://www.alpha-ii.com/caitsith2/ereader/dot-code%20block.jpg - explanation
on how the raw data is stored in the dotcode blocks in the strip.

Now, the only thing that is really stopping us from
developing our own dotcodes, is the fact that we do not know how to
encode/decode the nintendo specific reed-solomon codes.

essentially, it goes like this.

Binary data + reed-solomon codes = Raw data. (unsolved)
Raw data + 8/10 Modulation = Dotcode dots. (solved)

It would be helpful to know where the e-reader functions are, in the rom,
and what each of them does.  maybe we can reverse engineer the reed-solomon
encoding/decoding out of one of the functions.

Sgstair was telling me that they have downloaded the code and are looking at
it.  He can tell you how to access that data..

----- Original Message -----
From: "Damien Good" <d_good@...>
To: <gbadev@yahoogroups.com>
Sent: Tuesday, December 30, 2003 6:41 PM
Subject: Re: [gbadev] Re: e-Reader dissection


> http://www.alpha-ii.com/caitsith2/ereader/dot-code%20block.jpg -
explanation
> on how the raw data is stored in the dotcode blocks in the strip.
>
> Now, the only thing that is really stopping us from
> developing our own dotcodes, is the fact that we do not know how to
> encode/decode the nintendo specific reed-solomon codes.
>
> essentially, it goes like this.
>
> Binary data + reed-solomon codes = Raw data. (unsolved)
> Raw data + 8/10 Modulation = Dotcode dots. (solved)
>
> It would be helpful to know where the e-reader functions are, in the rom,
> and what each of them does.  maybe we can reverse engineer the
reed-solomon
> encoding/decoding out of one of the functions.

--- 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.

> (-) 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.

> 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.

--
Damian

http://www.alpha-ii.com/caitsith2/ereader/dot-code%20block.jpg - explanation
on how the raw data is stored in the dotcode blocks in the strip.

Now, the only thing that is really stopping us from
developing our own dotcodes, is the fact that we do not know how to
encode/decode the nintendo specific reed-solomon codes.

essentially, it goes like this.

Binary data + reed-solomon codes = Raw data. (unsolved)
Raw data + 8/10 Modulation = Dotcode dots. (solved)

It would be helpful to know where the e-reader functions are, in the rom,
and what each of them does.  maybe we can reverse engineer the reed-solomon
encoding/decoding out of one of the functions.

> Ever tried caching decompressed cels in EWRAM?
>
> --
> Damian
The following are my assumptions, please feel free to correct them.

Caching to the EXTRAM (or VRAM itself by double buffering) will have
the following (+)positive and (-)negative  consequences:
(+)If you are streaming compressed frames of a sprite, in addition of
using vblank time for doing decompression and transfer, caching will
also allow you to use time outside vblank for this purpose and thus
increasing the amount of data decompressed in each frame.
(-)Consumes extra EXTRAM/VRAM. (not really important since usually
there is quite a lot of free EXTRAM in most applications)
(-)Cached data has to be re-transfered to VRAM during vblank (since
the data is already decompressed a quick DMA should lessen the blow)

And the most important of all:
(-)Consumes greater cpu time.

Which brings me to the conclusion that caching data to make up for
poor transfer speeds (due to compressed data) will give you more time
to complete your transfers (because you can use out of vblank
scanlines) although at the cost of greater cpu usage, since you will
be doing data transfers inside AND outside the vblank.

This will work remarkably well if you have spare time outside vblank,
because inside vblank, all you need to do is to quickly DMA from
EXTRAM to VRAM.

But if this is not the case, the only way (I think) to achieve higher
transfer speeds would be using a simpler compression algorithm (like
RLE), or even...., not compressing data.. >_< .

Thanks for answering.

Ronald

--- In gbadev@yahoogroups.com, "ronald_chenu" <ronald_chenu@y...> wrote:
> >LZ77 compressed sprites were used in Battle Bots game.
> >They were depacked in real time.
> Thats exactly what I'm trying to do, but 300 KB per sec
> (5 per frame at 60fps) it not going to work for me :(

Ever tried caching decompressed cels in EWRAM?

--
Damian